L'architecture de coprocesseur : une architecture de système embarqué pour le prototypage rapide

Note de l'éditeur — Bien que réputée pour son débit et ses performances de traitement numérique, l'architecture de coprocesseur offre au concepteur de systèmes embarqués la possibilité de mettre en œuvre des stratégies de gestion de projet, qui améliorent à la fois les coûts de développement et les délais de commercialisation. Cet article, qui porte spécifiquement sur la combinaison d'un microcontrôleur (MCU) discret et d'un réseau de portes programmables par l'utilisateur (FPGA) discret, montre comment cette architecture se prête à un processus de conception efficace et itératif. En s'appuyant sur des sources documentées, des résultats empiriques et des études de cas, cet article explore les avantages de cette architecture à la lumière de quelques exemples d'applications. À la fin de cet article, le concepteur de systèmes embarqués aura une meilleure compréhension de quand et comment mettre en œuvre cette architecture matérielle polyvalente.

Introduction

Le concepteur de systèmes embarqués se trouve à la croisée des chemins entre les contraintes de conception, les attentes en matière de performances et les préoccupations en matière de calendrier et de budget. En effet, les contradictions dans les termes et expressions modernes utilisés dans la gestion de projet soulignent davantage la nature précaire de ce rôle : « échec rapide », « être agile », « être à l'épreuve du futur » et « être perturbateur ». Les acrobaties qu'implique le simple fait d'essayer de satisfaire ces attentes peuvent être harassantes, et pourtant elles ont été et continuent d'être réaffirmées sur le marché. Il faut une approche de conception qui permette de mettre en œuvre un processus itératif évolutif, et comme pour la plupart des systèmes embarqués, cela commence par l'architecture matérielle.

L'architecture de coprocesseur, une architecture matérielle connue pour combiner les points forts des technologies de microcontrôleurs (MCU) et de réseaux de portes programmables par l'utilisateur (FPGA), peut offrir au concepteur de systèmes embarqués un processus capable de répondre aux exigences les plus strictes, tout en offrant la flexibilité nécessaire pour relever les défis connus et inconnus. Avec un matériel capable de s'adapter de manière itérative, le concepteur peut démontrer sa progression, respecter les étapes critiques et tirer pleinement parti du processus de prototypage rapide.

Ce processus comprend des étapes clés du projet, chacune ayant sa propre valeur ajoutée pour l'effort de développement. Dans cet article, nous les désignerons par les termes suivants : traitement des signaux numériques avec le microcontrôleur, gestion système avec le microcontrôleur et déploiement des produits.

En conclusion de cet article, il sera démontré qu'une architecture matérielle flexible peut être mieux adaptée à la conception de systèmes embarqués modernes qu'une approche plus rigide. En outre, cette approche peut permettre d'améliorer à la fois le coût du projet et le délai de mise sur le marché. Des arguments, des exemples et des études de cas seront utilisés pour défendre cette position. En observant la valeur de chaque étape dans le cadre de la flexibilité de conception qu'offre cette architecture, il devient évident qu'une architecture matérielle adaptative est un moteur puissant pour faire avancer la conception des systèmes embarqués.

Explorer les points forts de l'architecture de coprocesseur : flexibilité de conception et traitement hautes performances

Une application courante des conceptions FPGA est l'interface directe avec un convertisseur analogique-numérique (CAN) haute vitesse. Le signal est numérisé, lu dans le FPGA, puis certains algorithmes du processeur de signaux numériques (DSP) sont appliqués à ce signal. Enfin, le FPGA prend des décisions sur la base des résultats.

Une telle application servira d'exemple tout au long de cet article. De plus, la Figure 1 illustre une architecture de coprocesseur générique, dans laquelle le microcontrôleur et le FPGA sont connectés via l'interface de mémoire externe du microcontrôleur. Le FPGA est considéré comme une partie de la mémoire vive statique externe (SRAM). Les signaux reviennent du FPGA vers le microcontrôleur et servent de lignes d'interruption matérielle et d'indicateurs d'état. Cela permet au FPGA d'indiquer des états critiques au microcontrôleur, par exemple pour lui signaler qu'une conversion CAN est prête, ou qu'une erreur ou un autre événement notable s'est produit.

Figure 1 : Schéma d'un coprocesseur générique (microcontrôleur + FPGA). (Source de l'image : CEPD)

Les points forts de l'approche de coprocesseur deviennent particulièrement évidents dans les résultats de chacune des étapes mentionnées ci-dessus. La valeur est estimée non seulement en énumérant les résultats d'une tâche ou d'une phase, mais également en analysant ce que ces résultats permettent d'atteindre. Les réponses aux questions suivantes aident à évaluer la valeur globale des résultats d'une étape :

• La progression des autres membres de l'équipe peut-elle désormais s'accélérer, puisque les dépendances et les goulets d'étranglement du projet sont supprimés ?
• Comment les résultats obtenus permettent-ils d'ouvrir d'autres voies d'exécution parallèle ?

Étape du traitement des signaux numériques avec le microcontrôleur

Figure 2 : Architecture - traitement des signaux numériques avec le microcontrôleur. (Source de l'image : CEPD)

La première étape de développement que permet cette architecture matérielle place le microcontrôleur au premier plan. Toutes choses égales par ailleurs, le développement du microcontrôleur et des logiciels exécutables nécessite moins de ressources et moins de temps que le développement d'un FPGA et du langage de description du matériel (HDL). Ainsi, en commençant le développement du produit avec le microcontrôleur comme processeur principal, les algorithmes peuvent être mis en œuvre, testés et validés plus rapidement. Cela permet de découvrir les bogues algorithmiques et logiques dès le début du processus de conception, et également de tester et de valider des parties importantes de la chaîne de signaux.

Le rôle du FPGA dans cette première étape est de servir d'interface de collecte de données haute vitesse. Sa tâche consiste à acheminer de manière fiable les données provenant du CAN haute vitesse, à avertir le microcontrôleur que des données sont disponibles et à présenter ces données à l'interface de mémoire externe du microcontrôleur. Bien que ce rôle n'inclue pas l'implémentation de processus DSP basés sur le langage HDL ou d'autres algorithmes, il est néanmoins hautement critique.

Le développement FPGA réalisé à ce stade jette les bases du succès final du produit, tant en termes d'efforts de développement que de mise sur le marché. En se concentrant uniquement sur l'interface de bas niveau, on peut consacrer suffisamment de temps aux tests de ces opérations essentielles. Ce n'est qu'une fois que le FPGA remplit ce rôle d'interface de manière fiable et sûre que cette étape peut être considérée comme terminée.

Les principaux résultats attendus de cette première étape sont les suivants :

1. Le trajet complet du signal - toutes les amplifications, atténuations et conversions - est testé et validé.
2. Le temps et les efforts de développement du projet sont réduits par l'implémentation initiale des algorithmes dans le logiciel (C/C++) ; cela est d'une valeur considérable pour la direction et les autres parties prenantes, qui doivent voir la faisabilité de ce projet avant d'approuver les futures phases de conception.
3. Les leçons tirées de l'implémentation des algorithmes en C/C++ sont directement transférables aux implémentations HDL - grâce à l'utilisation d'outils logiciels-HDL, par exemple Xilinx HLS.

Étape de gestion système avec le microcontrôleur

Figure 3 : Architecture - gestion système avec le microcontrôleur. (Source de l'image : CEPD)

La deuxième étape de développement avec cette approche de coprocesseur est définie par le déplacement des processus DSP et des implémentations d'algorithmes du microcontrôleur vers le FPGA. Le FPGA est toujours responsable de l'interface CAN haute vitesse, mais en assumant ces autres rôles, la vitesse et le parallélisme offerts par le FPGA sont pleinement utilisés. De plus, contrairement au microcontrôleur, de multiples instances de processus DSP et de canaux d'algorithmes peuvent être mises en œuvre et exécutées simultanément.

Le concepteur s'appuie sur les enseignements tirés de l'implémentation du microcontrôleur pour franchir en toute confiance l'étape suivante. Des outils, tels que Vivado HLS de Xilinx, mentionné plus haut, fournissent une traduction fonctionnelle du code C/C++ exécutable en HDL synthétisable. Les contraintes de temps, les paramètres de processus et d'autres préférences utilisateur doivent encore être définis et mis en œuvre, mais la fonctionnalité de base est conservée et traduite dans la structure FPGA.

Pour cette étape, le rôle du microcontrôleur est celui d'un gestionnaire de système. Les registres d'état et de contrôle du FPGA sont surveillés, mis à jour et signalés par le microcontrôleur. De plus, le microcontrôleur gère l'interface utilisateur (UI). Cette interface utilisateur peut prendre la forme d'un serveur Web auquel on accède par une connexion Ethernet ou Wi-Fi, ou d'une interface industrielle à écran tactile donnant accès aux utilisateurs au point d'utilisation. La principale conclusion à tirer du nouveau rôle plus raffiné du microcontrôleur est la suivante : en étant déchargés des tâches de traitement à calcul intensif, le microcontrôleur et le FPGA peuvent être utilisés pour des tâches pour lesquelles ils sont bien adaptés.

Les résultats clés de cette étape incluent les avantages suivants :

1. L'exécution parallèle rapide des processus DSP et des implémentations d'algorithmes est assurée par le FPGA.Le microcontrôleur fournit une interface utilisateur réactive et rationalisée et gère les processus du produit.
2. Après avoir été développés et validés dans le microcontrôleur, les risques algorithmiques sont atténués et ces atténuations sont traduites en HDL synthétisable. Des outils, tels que Vivado HLS, facilitent ce processus de traduction. De plus, les risques spécifiques aux FPGA peuvent être atténués avec des outils de simulation intégrés, tels que la suite de conception Vivado.
3. Les parties prenantes ne sont pas exposées à des risques importants en transférant les processus vers le FPGA. Au contraire, ils ont l'occasion de voir et d'apprécier les avantages qu'offrent la vitesse et le parallélisme du FPGA. Des améliorations mesurables des performances sont observées et l'accent peut désormais être mis sur la préparation de cette conception pour la fabrication.

Étape de déploiement des produits

Le traitement à calcul intensif étant pris en charge par le FPGA, et le microcontrôleur assurant la gestion du système et l'interface utilisateur, le produit est prêt à être déployé. Ce document ne préconise pas de contourner les versions Alpha et Bêta ; cependant, l'accent dans cette étape est mis sur les capacités que l'architecture de coprocesseur fournit au déploiement du produit.

Le microcontrôleur et le FPGA sont tous les deux des dispositifs pouvant être mis à jour sur le terrain. Plusieurs avancées ont été réalisées pour rendre les mises à jour des FPGA tout aussi accessibles que les mises à jour logicielles. De plus, comme le FPGA se trouve dans l'espace mémoire adressable du microcontrôleur, ce dernier peut servir de point d'accès pour le système complet, c'est-à-dire recevoir des mises à jour pour lui-même et pour le FPGA. Les mises à jour peuvent être programmées, distribuées et personnalisées de manière conditionnelle pour chaque utilisateur final. Enfin, les journaux d'utilisateurs et de cas d'utilisation peuvent être conservés et associés à des implémentations spécifiques. À partir de ces jeux de données, les performances peuvent continuer à être affinées et améliorées même après le déploiement du produit sur le terrain.

Les atouts de cette évolutivité du système global sont particulièrement évidents dans les applications spatiales. Une fois le produit lancé, la maintenance et les mises à jour doivent être effectuées à distance. Il peut s'agir d'un simple changement de conditions logiques ou d'une mise à jour complexe d'un schéma de modulation des communications. La programmabilité offerte par les technologies FPGA et l'architecture de coprocesseur peut couvrir l'intégralité de cette gamme de capacités, tout en offrant un choix de composants résistants aux rayonnements.

Le dernier élément clé de cette étape est la réduction progressive des coûts. Des réductions de coûts, des modifications de la nomenclature (BOM) et d'autres optimisations peuvent également intervenir à ce stade. Lors des déploiements sur le terrain, le produit peut s'avérer fonctionner tout aussi bien avec un microcontrôleur moins coûteux ou un FPGA moins performant. Grâce au coprocesseur, les concepteurs d'architecture ne sont pas obligés d'utiliser des composants dont les capacités dépassent les besoins de leur application. En outre, si un composant n'est plus disponible, l'architecture permet d'intégrer de nouveaux composants dans la conception. Ce n'est pas le cas avec une architecture monopuce, de système sur puce (SoC), ou avec un DSP ou un microcontrôleur hautes performances qui tente de prendre en charge l'ensemble du traitement du produit. L'architecture de coprocesseur offre une bonne combinaison de capacités et de flexibilité, donnant au concepteur plus de choix et une plus grande liberté, tant dans les phases de développement que lors de la mise sur le marché.

Soutenir la recherche et études de cas connexes

Exemple de communications par satellite

En bref, l'intérêt d'un coprocesseur est de décharger l'unité de traitement primaire afin que les tâches soient exécutées au niveau du matériel, où l'accélération et l'optimisation peuvent être exploitées. L'avantage d'un tel choix de conception est une augmentation nette de la vitesse et des capacités de calcul et, comme l'affirme cet article, une réduction des coûts et du temps de développement. L'un des domaines les plus intéressants pour ces avantages est peut-être celui des systèmes de communications spatiales.

Dans leur publication intitulée FPGA based hardware as coprocessor, G. Prasad et N. Vasantha expliquent en détail comment le traitement des données dans un FPGA permet de répondre aux besoins de calcul des systèmes de communications par satellite sans les coûts élevés d'ingénierie non récurrente (NRE) des circuits intégrés à application spécifique (ASIC) ni les limitations spécifiques à l'application d'un processeur à architecture matérielle. Comme décrit dans l'étape de traitement des signaux numériques avec le microcontrôleur, leur conception commence avec le processeur d'application qui exécute la majorité des algorithmes de calcul intensif. À partir de ce point de départ, ils identifient les sections clés du logiciel consommant la majorité des cycles d'horloge du processeur (CPU) et font migrer ces sections vers une implémentation HDL. La représentation graphique est très similaire à ce qui a été montré jusqu'à présent ; cependant, ils ont choisi de représenter le programme d'application comme son propre bloc indépendant, car il peut être implémenté soit dans l'hôte (processeur) soit dans le matériel basé sur le FPGA.

Figure 4 : Programme d'application, processeur hôte et matériel FPGA - utilisés dans l'exemple de communications par satellite.

L'utilisation d'une interface PCI (Peripheral Component Interconnect) et de l'accès direct à la mémoire (DMA) du processeur hôte permet d'augmenter considérablement les performances périphériques. Cela est principalement observé dans les améliorations apportées au processus de dérandomisation. L'exécution de ce processus dans le logiciel du processeur hôte présentait clairement un goulet d'étranglement dans la réponse en temps réel du système. Cependant, lorsqu'il a été transféré sur le FPGA, les avantages suivants ont été observés :

• Le processus de dérandomisation a été exécuté en temps réel sans provoquer de goulets d'étranglement
• La charge de calcul du processeur hôte ayant été réduite de manière significative, il peut désormais mieux remplir un rôle souhaité.
• Les performances globales du système complet ont été améliorées.

Tout cela a été réalisé sans les coûts associés à un ASIC, et en bénéficiant de la flexibilité de la logique programmable [5]. Les communications par satellite présentent des défis considérables, et cette approche peut répondre de manière vérifiable à ces exigences, tout en continuant à offrir une grande flexibilité de conception.

Exemple d'infodivertissement automobile

Les systèmes de divertissement dans les automobiles sont des caractéristiques distinctives pour les consommateurs avertis. Contrairement à la plus grande partie de l'électronique automobile, ces dispositifs sont très visibles et doivent offrir un temps de réponse et des performances exceptionnels. Toutefois, les concepteurs sont souvent pris entre deux feux : d'une part, les besoins actuels de la conception et, d'autre part, la flexibilité requise pour tenir compte des fonctionnalités futures. Pour cet exemple, les besoins de mise en œuvre du traitement des signaux et des communications sans fil seront utilisés pour mettre en évidence les points forts de l'architecture matérielle du coprocesseur.

L'une des principales architectures de système de divertissement automobile a été publiée par Delphi Delco Electronics Systems Corporation. Cette architecture utilisait un microcontrôleur SH-4 avec un circuit ASIC auxiliaire, le périphérique HD64404 Amanda d'Hitachi. Cette architecture répondait à plus de 75 % des fonctionnalités de divertissement de base du marché automobile ; toutefois, elle ne permettait pas de gérer les applications de traitement vidéo et les communications sans fil. En incluant un FPGA dans cette architecture existante, il est possible d'ajouter davantage de flexibilité et de capacités à cette approche de conception déjà existante.

Figure 5 : Exemple 1 d'architecture de coprocesseur FPGA d'infodivertissement.

L'architecture de la Figure 5 convient à la fois au traitement vidéo et à la gestion des communications sans fil. En transférant les fonctionnalités DSP vers le FPGA, le processeur Amanda peut jouer un rôle de gestion système, et il est disponible pour mettre en œuvre une pile de communications sans fil. Comme l'Amanda et le FPGA ont tous les deux accès à la mémoire externe, les données peuvent être rapidement échangées entre les processeurs et les composants du système.

Figure 6 : Exemple 2 d'architecture de coprocesseur FPGA d'infodivertissement.

Le deuxième exemple d'infodivertissement dans la Figure 6 illustre la capacité du FPGA à traiter à la fois les données analogiques haute vitesse entrantes et la gestion de la compression et du codage nécessaires pour les applications vidéo. En fait, toutes ces fonctionnalités peuvent être transférées vers le FPGA et, grâce à l'utilisation du traitement parallèle, elles peuvent toutes être traitées en temps réel.

En incluant un FPGA dans une architecture matérielle existante, les performances éprouvées du matériel existant peuvent être associées à la flexibilité et à l'évolutivité. Même dans les systèmes existants, l'architecture de coprocesseur offre aux concepteurs des options qui ne seraient pas disponibles autrement [6].

Avantages du prototypage rapide

À la base, le processus de prototypage rapide s'efforce de couvrir une grande partie de la zone de développement du produit en exécutant des tâches en parallèle, en identifiant rapidement les bogues et les problèmes de conception, et en validant les chemins de données et de signaux, en particulier ceux du chemin critique d'un projet. Toutefois, pour que ce processus produise réellement des résultats rationalisés et efficaces, il faut disposer d'une expertise suffisante dans les domaines de projet requis.

Traditionnellement, cela implique un ingénieur en matériel, un ingénieur en logiciel embarqué ou DSP, et un ingénieur HDL. Aujourd'hui, il existe de nombreux professionnels interdisciplines, qui peuvent être en mesure de remplir plusieurs rôles ; toutefois, la coordination de ces efforts implique une surcharge considérable.

Dans leur article, An FPGA based rapid prototyping platform for wavelet coprocessors, les auteurs défendent l'idée que l'utilisation d'une architecture de coprocesseur permet à un seul ingénieur DSP de remplir tous ces rôles, de manière efficace et efficiente. Pour cette étude, l'équipe a commencé par concevoir et simuler la fonctionnalité DSP souhaitée dans l'outil Simulink de MATLAB. Cela a permis de remplir deux fonctions principales : 1) vérifier les performances souhaitées via la simulation, et 2) servir de base de comparaison et de référence pour les choix de conception futurs.

Après la simulation, les fonctionnalités critiques ont été identifiées et divisées en différents cœurs – il s'agit de composants et de processeurs à cœur logiciel qui peuvent être synthétisés dans un FPGA. L'étape la plus importante de ce travail a été de définir l'interface entre ces cœurs et ces composants et de comparer les performances d'échange de données avec les performances souhaitées et simulées. Ce processus de conception est étroitement aligné sur le flux de conception de Xilinx pour les systèmes embarqués et est résumé dans la Figure 7 ci-dessous.

Figure 7 : Flux de conception de l'implémentation.

En divisant le système en cœurs synthétisables, l'ingénieur DSP peut se concentrer sur les aspects les plus critiques de la chaîne de traitement des signaux. Il n'est pas nécessaire d'être un expert en matériel ou en langage HDL pour modifier, router ou implémenter différents processeurs ou composants à cœur logiciel dans le FPGA. Tant que le concepteur connaît l'interface et les formats de données, il a un contrôle total sur les trajets de signaux et peut affiner les performances du système.

Résultats empiriques – Étude de cas de la transformée en cosinus discrète

Les résultats empiriques ont non seulement confirmé la flexibilité offerte par l'architecture de coprocesseur aux concepteurs de systèmes embarqués, mais ils ont également mis en évidence les options d'amélioration des performances disponibles avec les outils FPGA modernes. Les améliorations, comme celles mentionnées ci-dessous, peuvent ne pas être disponibles ou avoir un impact moindre pour d'autres architectures matérielles. La transformée en cosinus discrète (DCT) a été sélectionnée comme algorithme à calcul intensif, et sa progression d'une implémentation en C à une implémentation basée HDL est au cœur de ces résultats. La transformée en cosinus discrète a été choisie car cet algorithme est utilisé dans le traitement des signaux numériques pour la reconnaissance des formes et le filtrage [8]. Les résultats empiriques sont basés sur un exercice de laboratoire, qui a été réalisé par l'auteur et ses collègues, afin d'obtenir la certification Xilinx Alliance Partner pour 2020 - 2021.

Les outils et dispositifs suivants ont été utilisés :

• Vivado HLS v2019
• Dispositif d'évaluation et de simulation xczu7ev-ffvc1156-2-e

À partir de l'implémentation en C, l'algorithme DCT accepte deux matrices de nombres 16 bits ; la matrice « a » est la matrice d'entrée DCT, et la matrice « b » est la matrice de sortie DCT. La largeur des données (DW) est donc définie comme étant de 16, et le nombre d'éléments dans les matrices (N) est de 1024/DW, soit 64. Enfin, la taille de la matrice DCT (DCT_SIZE) est définie sur 8, ce qui signifie qu'une matrice 8 x 8 est utilisée.

Suivant le principe de cet article, l'implémentation de l'algorithme en C permet au concepteur de développer et de valider rapidement la fonctionnalité de l'algorithme. Bien qu'il s'agisse d'une considération importante, cette validation accorde plus de poids à la fonctionnalité qu'au temps d'exécution. Cette pondération est autorisée, car l'implémentation finale de cet algorithme se fera dans un FPGA, où l'accélération matérielle, le déroulement de boucle et d'autres techniques sont facilement disponibles.

Figure 8 : Flux de conception Xilinx Vivado HLS.

Une fois que le code DCT a été créé dans l'outil Vivado HLS en tant que projet, l'étape suivante consiste à commencer à synthétiser la conception pour l'implémentation FPGA. C'est à l'étape suivante que certains des avantages les plus importants du déplacement de l'exécution d'un algorithme d'un microcontrôleur vers un FPGA deviennent plus évidents ; à titre de référence, cette étape est équivalente à l'étape de gestion système avec le microcontrôleur abordée ci-dessus.

Les outils FPGA modernes permettent un certain nombre d'optimisations et d'améliorations qui augmentent considérablement les performances des algorithmes complexes. Avant d'analyser les résultats, il convient de garder à l'esprit certains termes importants :

• Latence - Le nombre de cycles d'horloge requis pour exécuter toutes les itérations de la boucle [10]
• Intervalle - Le nombre de cycles d'horloge avant que l'itération suivante d'une boucle commence à traiter les données [11]
• BRAM - Mémoire vive par bloc
• DSP48E - Partie de traitement des signaux numériques pour l'architecture UltraScale
• FF – Flipflop
• LUT - Table de correspondance
• URAM - Mémoire vive unifiée (peut être composée d'un seul transistor)

Tableau 1 : Résultats de l'optimisation de l'exécution des algorithmes FPGA (latence et intervalle).

Tableau 2 : Résultats de l'optimisation de l'exécution des algorithmes FPGA (utilisation des ressources).

Par défaut

Le paramètre d'optimisation par défaut est dérivé du résultat non modifié de la traduction de l'algorithme basé C en HDL synthétisable. Aucune optimisation n'est activée, et cela peut être utilisé comme référence de performances pour mieux comprendre les autres optimisations.

Boucle interne pipeline

La directive PIPELINE indique à Vivado HLS de dérouler les boucles internes afin que les nouvelles données puissent commencer à être traitées tandis que les données existantes sont toujours dans le pipeline. Ainsi, les nouvelles données ne doivent pas attendre que les données existantes soient terminées pour que le traitement puisse commencer.

Boucle externe pipeline

En appliquant la directive PIPELINE à la boucle externe, les opérations de la boucle externe sont maintenant dans le pipeline. Cependant, les opérations des boucles internes se déroulent simultanément. La latence et le temps d'intervalle sont réduits de moitié en appliquant ce paramètre directement à la boucle externe.

Partition de matrice

Cette directive mappe le contenu des boucles aux matrices et lisse ainsi tous les accès mémoire aux éléments individuels de ces matrices. Ce faisant, la consommation de RAM est plus importante, mais le temps d'exécution de cet algorithme est réduit de moitié.

Flux de données

Cette directive permet au concepteur de spécifier le nombre cible de cycles d'horloge entre chacune des lectures d'entrée. Cette directive n'est prise en charge que pour les fonctions de niveau supérieur. Seules les boucles et les fonctions exposées à ce niveau bénéficieront de cette directive.

Inline

La directive INLINE égalise toutes les boucles, qu'elles soient internes ou externes. Les processus de ligne et de colonne peuvent maintenant s'exécuter simultanément. Le nombre de cycles d'horloge requis est maintenu à un minimum, même si cela consomme davantage de ressources FPGA.

Conclusion

L'architecture matérielle du coprocesseur fournit au concepteur de systèmes embarqués une plateforme hautes performances qui maintient la flexibilité de conception tout au long du développement et après la commercialisation du produit. En validant d'abord les algorithmes en C ou C++, les processus, les chemins de données et de signaux et les fonctionnalités critiques peuvent être vérifiés en un temps relativement court. Ensuite, en traduisant les algorithmes à usage de processeur intensif dans le FPGA du coprocesseur, le concepteur peut tirer parti des avantages de l'accélération matérielle et d'une conception plus modulaire.

Si des composants deviennent obsolètes ou si des optimisations sont requises, la même architecture peut permettre ces changements. Il est possible d'intégrer de nouveaux microcontrôleurs et de nouveaux FPGA dans la conception, tout en conservant les interfaces relativement intactes. De plus, comme le microcontrôleur et le FPGA peuvent être mis à jour sur le terrain, les modifications et les optimisations spécifiques à l'utilisateur peuvent être appliquées sur le terrain et à distance.

En conclusion, cette architecture allie la vitesse de développement et la disponibilité d'un microcontrôleur aux performances et à l'extensibilité d'un FPGA. Grâce aux optimisations et aux améliorations des performances disponibles à chaque étape du développement, l'architecture de coprocesseur peut répondre aux exigences les plus strictes, aussi bien pour les conceptions actuelles que futures.