Diminution de la durée du cycle de conception dans les SoC co-conçus avec Renode

Dans cet article, nous expliquons comment l'utilisation de simulateurs fonctionnels open source comme Renode d'Antmicro peut faire partie intégrante des efforts de co-conception matériel-logiciel .

Dans cet article, nous expliquons comment l'utilisation de simulateurs fonctionnels open source comme Renode d'Antmicro peut faire partie intégrante des efforts de co-conception matériel-logiciel.

Alors que les marchés exigent davantage de leurs systèmes embarqués, les SoC de nouvelle génération deviennent de plus en plus complexes, ce qui entraîne des cycles de conception plus longs et une augmentation des coûts, selon Semico Research.

La réalité frustrante pour les fabricants d'appareils est que la seule façon de fournir les fonctionnalités nouvelles et innovantes, une plus grande sécurité et de meilleures performances que leurs clients demandent, est de s'engager dans la co-conception « de la pile entière », l'évolution du matériel, du micrologiciel, du temps d'exécution (OS) et la chaîne d'outils de développement en tandem. Cela permet aux équipes matérielles et logicielles de faire des compromis complexes concernant l'emplacement de la pile pour mettre en œuvre des fonctionnalités et des optimisations.

Malheureusement, la co-conception est souvent le principal facteur d'allongement des cycles de conception (et donc des coûts) lorsque les outils de simulation appropriés ne sont pas en place.

Dans cet article, nous expliquons comment l'utilisation de simulateurs fonctionnels open source comme Renode d'Antmicro peut faire partie intégrante des efforts de co-conception matériel-logiciel. De plus, nous vous montrerons un exemple de la façon dont les utilisateurs de Renode peuvent tirer parti de l'outil pour réduire considérablement la durée de leurs cycles de conception, fournir aux clients un moyen simple et efficace d'évaluer leurs solutions et de commencer à adapter la documentation logicielle en parallèle. avec des efforts d'intégration matérielle.

Où les simulateurs logiciels peuvent échouer

L'importance de choisir le bon outil de simulation est mieux illustrée dans le cas de Dover Microsystems.

La technologie CoreGuard® de Dover est la seule solution qui empêche l'exploitation des vulnérabilités logicielles et permet aux processeurs de se défendre contre les attaques basées sur le réseau. Dover a pu accomplir cela grâce à huit années de recherche et développement, d'abord en tant que plus grand acteur du programme DARPA Crash, puis chez Draper Labs, qui ont abouti à une solution hybride matériel/logiciel unique pour les systèmes embarqués.

Cette solution hybride nécessite une intégration étroite entre les composants matériels et logiciels. CoreGuard silicium IP est un processeur sentinelle qui agit comme un garde du corps, protégeant les systèmes embarqués contre les cyberattaques. Il surveille chaque instruction exécutée par le processeur hôte pour s'assurer qu'elle est conforme à un ensemble défini de règles de sécurité, de sûreté et de confidentialité appelées micropolitiques, le composant logiciel de CoreGuard. Si une instruction enfreint une règle existante, CoreGuard l'empêche de s'exécuter avant qu'aucun dommage ne puisse être causé.

Pour ce faire, CoreGuard doit suivre l'exécution du processeur hôte. C'est-à-dire qu'en moyenne, il doit être capable de retirer (approuver via des micropolitiques) des instructions au même rythme que le processeur hôte à protéger. Il est également souhaitable que CoreGuard minimise la quantité de mémoire requise pour la gestion des métadonnées.

Par conséquent, répondre aux exigences de performances, de puissance et de surface nécessite une interaction complexe d'optimisations des couches matérielles et logicielles.

L'équipe matérielle de Dover utilise un processus et une chaîne d'outils standard basés sur SystemVerilog. Les prototypes initiaux du système CoreGuard sont construits sur des SoC basés sur RISC-V. Parce que CoreGuard a un composant logiciel substantiel en plus de l'IP matérielle, il était important que l'équipe logicielle puisse démarrer bien avant que des prototypes matériels ne soient disponibles.

L'équipe logicielle de Douvres a initialement utilisé le simulateur de logiciel Spike RISC-V ISA qui est disponible à partir des dépôts RISC-V GitHub. Ils ont rencontré deux problèmes en basant leur développement commercial de CoreGuard autour de Spike :

1. Spike ne fournit aucun périphérique réaliste ; c'est-à-dire que Spike est un simulateur ISA, pas un simulateur SoC. L'équipe de Dover a commencé à ajouter des périphériques tels que les UART et le stockage persistant à Spike, et cela représentait beaucoup de travail.
2. Spike, par définition, est spécifique à RISC-V, mais les clients initiaux de Dover Microsystems sont à la fois RISC-V et Arm.

Ces lacunes ont mis en évidence le besoin de Dover d'un simulateur multi-architecture flexible avec le concept de modèles périphériques à utiliser à la place de Spike.

Comment Renode répond aux besoins importants de co-conception

Faire face à des défis d'ingénierie de co-conception matériel/logiciel hétérogènes similaires résultant du travail avec des noyaux logiciels open source, des premiers logiciels pour les plates-formes informatiques de pointe, des SoC FPGA et des architectures de processeurs émergentes telles que RISC-V, Antmicro—un logiciel axé sur l'open source fournisseur de technologies et de services :a développé un cadre de simulation flexible appelé Renode.

Renode est un cadre de simulation hiérarchique et modulaire visant à exécuter un micrologiciel de production réel (c'est-à-dire non modifié) dans une variété de systèmes complexes, y compris des systèmes interconnectés multi-nœuds, multi-architectures, hétérogènes, de niveau MCU et compatibles Linux.

Pour faire face à ces différents niveaux de complexité, Renode est construit autour d'une forte notion d'abstraction et adopte une approche orientée objet et modulaire de la simulation système. Les cœurs et les périphériques sont considérés comme des blocs de construction pouvant être connectés via des interfaces dans différentes configurations, reflétant la manière dont les vrais SoC sont construits.

Figure 1. Un exemple de SoC RISC-V simulé.

La figure 1 montre un exemple de SoC RISC-V simulé. Chaque bloc de construction, y compris le processeur, possède un ensemble de propriétés et d'API qui peuvent être utilisées pour construire le modèle de simulation de l'ensemble du SoC. De même, les nœuds uniques peuvent être combinés en un système multi-nœuds à l'aide de connexions sans fil et filaires virtualisées (6LoWPAN, UART, Ethernet, etc.). Tout cela ne nécessite pas de modifications de la base de code de Renode, mais se fait via une configuration et des scripts, ce qui diminue la courbe d'apprentissage et limite la fragmentation de la base de code.

La nature flexible du framework Renode, sa disponibilité open source et l'existence d'un support commercial fourni par ses auteurs ont permis à Dover de créer facilement un prototype d'implémentation de leur flux de travail souhaité, puis de sous-traiter Antmicro pour implémenter (et publier dans l'open- domaine source) des fonctionnalités qui ont rendu Renode encore mieux adapté à leur cas d'utilisation, comme l'exécution par instruction.

En particulier, en utilisant Renode, les ingénieurs de Dover sont désormais capables de :

• Basculez entre les efforts d'intégration basés sur Arm et RISC-V en utilisant la même configuration.
• Prototypes de SoC (à la fois de référence/minimes et définis par le client) à différents niveaux de détail/fidélité.

Modélisez la spécification de l'architecture matérielle à partir du groupe matériel de Dover, puis écrivez et testez le micrologiciel par rapport à ces modèles, pendant que le matériel est en cours de développement.

Comment Renode a considérablement réduit le cycle de conception de Douvres

La technologie CoreGuard de Dover est un produit de cybersécurité hybride dans lequel les conceptions matérielles et logicielles évoluent. Par conséquent, il est important que le processus de développement de Dover permette le développement et les tests parallèles du matériel et des logiciels.

Figure 2. Le processus de développement utilisé par Dover.

Dover utilise le processus de développement décrit à la figure 2. Les équipes matérielles et logicielles collaborent sur l'interface matérielle (qui, bien entendu, continuera d'évoluer). Alors que l'équipe matérielle commence à implémenter des blocs dans SystemVerilog, l'équipe logicielle crée des modèles des nouveaux blocs en C#, le langage natif sous-jacent à Renode. L'équipe logicielle est alors en mesure d'écrire un micrologiciel qui communique avec les nouvelles interfaces matérielles et de tester ce logiciel sous simulation Renode. Finalement, le logiciel est exécuté sur un émulateur FPGA.

Ce processus de développement, rendu possible par Renode, a aidé Dover à optimiser à la fois les simulations « basse fidélité » et « haute fidélité ».

Bien que cette simulation « basse fidélité » fasse abstraction de toute la logique matérielle de CoreGuard, Dover trouve toujours cette configuration utile dans les contextes suivants :

• Débogage de micropolitique : Lorsque de nouvelles micropolitiques CoreGuard sont développées, nous souhaitons effectuer une itération rapide sur une variété de tests logiciels, pour vérifier le comportement.
• Démos et aperçus client : Pour les démonstrations CoreGuard, une simulation logicielle pure est souvent suffisante pour informer un client potentiel sur les capacités de CoreGuard® et pour stimuler l'intérêt pour une discussion plus approfondie. De plus, Dover livre souvent aux clients un « SDK » composé de ce simulateur « basse fidélité » avec quelques micropolitiques prédéfinies, afin que le client « joue » avec CoreGuard, y compris éventuellement l'exécution de micropolitiques CoreGuard contre le logiciel du client.

Dans les simulations « haute fidélité », qui reproduisent un modèle matériel plus précis, l'équipe d'ingénierie de Dover a pu reconnaître un certain nombre d'avantages avec Renode, notamment :

• Intégration avec divers formats binaires non ELF (par exemple, à charge dispersée) utilisés par les ROM de démarrage matériel.
• Développer et tester le processus de démarrage ; copie de la mémoire flash vers la RAM, initialisation des périphériques.
• Débogage du trafic de bus à l'aide de l'instrumentation Renode.
• Débogage des périphériques (UART, PIC, l'interface CoreGuard elle-même) par instrumentation.
• Jouer avec la carte mémoire.
• Implémentation du micrologiciel vidéo HDMI, avant que le matériel ne fonctionne.

Comme indiqué précédemment, il existe des contraintes de performances et de surface difficiles que les solutions de nouvelle génération telles que CoreGuard imposent aux équipes de conception de SoC lors de la mise en œuvre.

Afin d'augmenter les performances et de réduire l'utilisation de la mémoire, il existe un large éventail d'optimisations qui doivent être effectuées, qui dépassent fréquemment la frontière matériel/logiciel.

Il est essentiel que les équipes de conception soient capables d'explorer un large éventail de techniques et de compromis possibles de co-optimisation matériel/logiciel, sans un vaste processus de développement sérialisé « d'abord matériel puis logiciel ». Un simulateur fonctionnel logiciel flexible tel que Renode permet aux ingénieurs de Dover de collaborer à travers la division matériel-logiciel pour trouver les compromis optimaux entre la complexité matérielle et logicielle, ce qui en fait une partie intégrante de leurs efforts.

Pour en savoir plus sur la façon dont Renode peut rationaliser les projets de co-conception, visitez renode.io. Pour en savoir plus sur la façon dont CoreGuard peut protéger les systèmes embarqués contre les attaques basées sur le réseau, demandez une démonstration pour voir CoreGuard en action.

Cet article a été co-écrit par Michael Gielda, vice-président du développement commercial et co-fondateur d'Antmicro.

Les articles sur l'industrie sont une forme de contenu qui permet aux partenaires de l'industrie de partager des actualités, des messages et des technologies utiles avec les lecteurs d'All About Circuits d'une manière qui ne convient pas au contenu éditorial. Tous les articles de l'industrie sont soumis à des directives éditoriales strictes dans le but d'offrir aux lecteurs des nouvelles utiles, une expertise technique ou des histoires. Les points de vue et opinions exprimés dans les articles de l'industrie sont ceux du partenaire et pas nécessairement ceux d'All About Circuits ou de ses rédacteurs.