8
votes

Comment partager les définitions de registre et de champ de bits entre un pilote de périphérique et le FPGA informatique informatique

Y a-t-il de bons outils logiciels existants disponibles pour faciliter la génération de fichiers d'en-tête C avec les décisions de registre appropriées et les définitions de bits de VHDL? Si des outils de ce type existent, quelles restrictions elles-mêmes sur la VHDL et comment sont les choses qui devraient être exportées désignées?

Jusqu'à présent, j'ai trouvé ces outils, mais ils ne sont pas exactement ce que je cherche:

  • VREGS par VerIPool
  • Spectrareg par PDTI
  • Bitwise par Duolog

    Sur la base de ces outils, je suis également intéressé si le flux de travail approprié doit générer à la fois le C et la VHDL plutôt que d'essayer d'aller directement de VHDL (peut-être avec des étiquettes supplémentaires dans les commentaires) à c.


0 commentaires

7 Réponses :


5
votes

Vous pourriez avoir un coup d'œil à DOXYGEN , il prend en charge la langue VHDL et en utilisant des fichiers intermédiaires que vous pouvez être capable d'extraire les informations plus ou moins facilement. Un sous-produit serait votre documentation de code RTL.

Une autre option consiste à créer un analyseur C à partir des définitions YACC / Lex, vous pouvez en trouver plusieurs ici . À partir de là, vous pouvez analyser la VHDL, extraire les informations (vous devrez déterminer comment extraire la définition de vos registres) et produire un fichier d'en-tête C. C'est probablement assez compliqué.

Mais si j'étais vous, je procéderais vraiment différemment et définirais les décalages et les champs de registre dans un fichier distinct (par exemple, dans XML) et écrivez un petit script pour générer des en-têtes C et un package VHDL, ce serait Savez-vous beaucoup de temps et seriez plus robuste d'un point de vue de flux.

qui aiderait également à construire toute documentation.

Vous pouvez bien sûr automatiser le processus avec un script / ou dans un script qui prépare la base de données avant la simulation / la synthèse.


0 commentaires

0
votes

La source réelle des informations partagées est votre conception originale. Je saisra donc la conception originale sous une forme facile à traiter. Voici quelques idées ...


  1. Utilisez YAML. (ou, soupir, XML ou même une DSL très simple de votre conception.) Définissez les données d'origine. Écrivez des scripts pour la jeter en tant que VHDL et C. Toutes les langues de script prennent en charge YAML et sont également conçues pour être analysées avec des outils Shell. Vous pouvez même utiliser VHDL ou C simplifié et écrire un script pour tourner celle-ci via une simple transformation de texte dans le C ou VHDL correspondant.

  2. tout est tout dans le pré-processeur C . Vous pouvez écrire un ensemble de macro appels qui spécifient les dispositions de registre. Vous pouvez alors avoir un #if ou peut-être deux fichiers distincts .h définissant deux versions différentes de vos macros de définition, qui se développe dans VHDL et qui élargit ces mêmes définitions en c.


0 commentaires

2
votes

Je pense que cela final cependant que vous bugez vous vous envoyait dans la bonne direction. Et je suis d'accord avec Redglyph dans lequel vous devriez envisager de changer un peu de flux de travail.

Avez-vous pensé à avoir un «document maître» pour vos informations de registre de contrôle et tout a tout généré à partir de cet article - RTL, code TestBench, en-têtes logiciels de pilote et documentation?

J'ai travaillé sur des projets où les informations de contrôle ont été conservées dans une feuille de calcul maître et tout ce dont nous avions besoin généré à partir de cela. Sur une famille de chips, j'avais écrit quelques scripts Python pour générer ce produit à partir de fichiers CSV exportés à partir de la feuille de calcul. Sur un autre projet, la feuille de calcul contenait des macros pour générer les fichiers RTL, etc., dont nous avions besoin.

L'écriture des scripts internes est tout bon et bon que vous avez le contrôle total sur eux et sachez comment ils fonctionnent en détail. Mais rappelez-vous que vous devez passer du temps à soutenir ces scripts et à les mettre à jour pour faire de nouvelles choses. Et considérez ce qui se passerait si quiconque a écrit ces scripts a décidé d'aller chercher un nouvel emploi - quelqu'un d'autre serait-ce assez familier avec les scripts pour les modifier? Nous envisageons d'acheter dans un outil tierce pour les raisons mentionnées ci-dessus.

J'ai également travaillé sur des projets, les fichiers de documentation et d'en-tête étaient revenus de la RTL -IT étaient un cauchemar. La documentation habituellement traînée derrière la conception et souvent les champs de contrôle «disparaître». Je préférerais ne plus être impliqué dans un tel projet;)


0 commentaires

2
votes

Notre groupe de conception utilise SystemRDL pour capturer les définitions d'enregistrement pour notre système programmable sur puce. Nous utilisons Denali Blueprint avec des scripts personnalisés pour les différentes cibles - générer la carte d'enregistrement, la documentation PDF, la vérification, les fichiers d'en-tête C, etc.

Nous ne l'utilisons pas encore pour générer la source RTL.

http://www.spiritconsortium.org/relases/systemrdl
http://www.google.com/search?q=ystemrdl


0 commentaires

3
votes

Je suis d'accord avec Marty, créant des scripts internes pour faire ce genre de chose est amusant mais peut être problématique à long terme.

Nous avons créé un outil appelé IdesignSpec qui est implémenté comme plugin pour les éditeurs de documents qui vous permettent de spécifier des registres dans un document et générer un en-tête C, VHDL, Verilog, OVM, VMM, IP-Xact, HTML, XML, SystemRDL. , Pdf, etc. de celui-ci.

Vous pouvez générer des sorties personnalisées à l'aide de l'API TCL. Il peut également lire dans divers formats d'entrée, tels que XML, IP-Xact, SystemRDL, etc.

Le bénéfice de cette approche est que vous avez une spécification que vous avez une spécification et que tout garde automatiquement en synchronisation.

Les éditeurs actuellement pris en charge sont: MS Word 2003 et 2007, OpenOffice, StarOffice et FrameMaker.

Vous pouvez obtenir plus de détails sur http://www.agnisys.com

Voici la liste complète des solutions disponibles:

Nom de la société: Outils commerciaux (solution fournie)
  1. agnisys: idesignspec (plug-in pour Word / Excel / OpenOffice et interface ligne de commande sur Linux et Windows)
  2. Atrenta: 1team-Genesis-registres (application de bureau) -> acquise par Synopsys. Outil non disponible.
  3. Duolog: Ditigwise (application basée sur l'éclipse) -> Acquisition par bras, l'outil est toujours disponible.
  4. PDTI: Spectrareg (application Web) -> Outil non disponible.
  5. Semifore: CSRCompiler (Interface de ligne de commande)

    Outils GRATUIT / OPENSENOURCE
    1. VerIPool: VREGS
    2. Paradigmworks: SPEC2REG


0 commentaires

1
votes

La réponse peut être un peu tardive, mais nous utilisons la bibliothèque de Netpp libre et certaines feuilles de style XSL modifiées pour générer une documentation, VHDL et C Source d'une source XML. Il existe également une extension de simulateur VHDL qui permet aux bibliothèques VHDL et C échange des données pour créer une mise en réseau "FPGA virtuel" capable. Ça s'appelle GhddleX, je ne me souviens pas exactement où il se trouve, mais vous le trouverez quelque part sur le http://section5.ch Site Web sous la zone de téléchargement Netpp. C'est un peu difficile à utiliser, mais bien, c'est gratuit ..


0 commentaires

0
votes

Spectrareg vous permet de spécifier les registres au même endroit et de créer plusieurs sorties pour différents environnements (par exemple, VHDL, C, Verilog)


0 commentaires