Le VHDL est un langage de simulation numérique. C'est initialement une commande de l'armée américaine pour standardiser les spécifications de circuits numériques. Le VHDL a été standardisé à coup de pelle à neige par l'IEEE en se basant sur le langage ADA.
Du langage de simulation, le VHDL est passé au langage de description hardware avec l'arrivée des FPGA/ASIC. Les constructeurs de FPGA fournissant des outils de conversion VHDL->netlist pour leurs propres composants. Chacun y allant de son interprétation du langage pour son propre compte.
Parallèlement, Cadence qui avait développé son propre langage de simulation pour ses outils a elle aussi ouvert son propre langage en le standardisant : le verilog.
Alors soyons clair, les deux langages sont relativement mauvais, verbeux, mal standardisés et sujet à interprétation en fonction de l'outil utilisé. La question n'est pas de savoir si Verilog est meilleur que le VHDL mais plutôt de discuter des projets libres tournant autour d'eux.
En se qui concerne les outils privateurs (cadence, mentor, xilinx, altera, …) le choix de l'un ou l'autre des langages n'a que peu de conséquences. Ces outils supportent très bien les deux langages, ils supportent même le mélange des deux dans un même projet.
En ce qui concerne les outils libres c'est une toute autre histoire.
Le seul projet sérieux se basant sur VHDL que je connaisse est GHDL. Un simulateur basé sur gcc et maintenu par Tristan Gringold. Ce simulateur fonctionne bien malgrés qu'il soit relativement lent. C'est l'outil que j'utilise intensivement pour le développement de mes projets FPGA (avec gtkwave pour la visualisation des signaux).
Mais en ce qui concerne le Verilog. On trouve beaucoup plus de projets libres qui semblent relativement abouti:
- Icarus: Permet de simuler ses projets verilog à la manière de ghdl, d'après le site internet icarus est même capable de générer la netlist pour la synthèse.
- Verilator: La simulation direct du verilog étant relativement lente, verilator converti le code en C++ pour améliorer la vitesse de simulation.
- Migen: Un module python permettant de décrire son architecture hard en python puis de générer le verilog synthétisable et simulable.
- Chisel: Ce projet permet de décrire son architecture matérielle en scala et de générer soit du verilog pour la synthèse, soit du C++ pour la simulation.
- …
Il y a certainement beaucoup d'autre projet libre que je n'ai pas exploré. Mais ce que je constate dans ma quête de logiciels libres pour les FPGA, c'est que la plupart des projets sur lesquels je tombe se basent sur du Verilog et non du VHDL.
Faut-il en déduire que le VHDL prend l'eau ? Que si l'on veut travailler avec des logiciels libres il vaut mieux se mettre au verilog ?
# Je ne suis pas d'accord
Posté par Olivier LEMAIRE (site web personnel) . Évalué à 6.
C'est pas vraiment juste ce que tu dis là, en relisant le paragraphe Beginning
D'ailleurs ça se sent toujours dans l'utilisation des outils cadence. J'utilise au quotidien la suite virtuoso qui prétend être capable de simuler de la mm façon les deux langages; c'teuh blague… Chez cadence, verilog a TRÈS clairement l'avantage. Tous les outils rapides sont capables de simuler du verilog alors que pour le VHDL il faut se coltiner un outil lent et moyennent fiable. La norme n'est pas respectée et cadence l’interprète assez librement.
Tu peux illustrer s'il te plait? Je crois que souvent on confond ces langages matériels avec des langages informatiques (je sais pas comment dire).
C'est vrai qu'il manque des outils libres pour faire du VHDL et je serai super content de voir un jour une bonne intégration ngspice/vhdl. Ca serait un truc tellement génial de pouvoir faire à la fois du VHDL, du VHDL-AMS du spice, le tout avec des outils libres…
Les logiciels de traitement de texte sont à la rédaction ce que la 2CV est à l'automobile, une vieille voiture dont on se souvient avec nostalgie mais technologiquement dépassée
[^] # Re: Je ne suis pas d'accord
Posté par gnx . Évalué à 6.
Ouais, non, ce n'est pas vraiment ça le problème, c'est que c'est vraiment (je parle surtout du VHDL) lourdingue parce que hyper-verbeux (mots-clé, begin - end machin, déclaration/instantiation des entités, conversion de types, etc.), irrégulier / pas orthogonal, parce qu'on n'utilise que 10% du langage (et que les 90% n'apportent que confusion lorsqu'on débute, ne sachant pas ce qui est utile et qui ne l'est pas), parce que le langage ne fait pas la différence entre ce qui est synthétisable et ce qui ne l'est pas (normal d'un certain point de vue mais du coup on marche sur des œufs et on se contente des 10% dont on est à peu près sûr, sinon on s'expose à de mauvaises surprises), parce que le support des attributs ou même juste des valeurs initiales dépend des outils utilisés, parce qu'il n'y a pas de préprocesseur défini…
Certains points se sont améliorés au fil de l'évolution du standard (irrégularités) et des outils (plus de trucs compris et synthétisables, support des attributs, packages), mais putain, c'est quand même toujours bien relou.
Du Verilog, je n'en ai jamais beaucoup écrit ; m'a semblé un peu abscons, pour un gain en concision /légèreté insuffisant.
SystemVerilog a l'air pas mal, mais je n'ai fait que parcourir un ou deux bouquins et je n'ai pas écrit de vrai code car les outils gratuits (au moins chez Xilinx) qui comprennent ce langage ne sont utilisables que pour les composants de dernières générations et pas pour les précédents :-(
Sinon, le mieux, le plus clair, le plus concis, c'était mon langage à moi, qui ne reprenais que les quelques concepts que j'utilisais en VHDL sans sa lourdeur, avec une apparence un peu "C". Mais il y a juste un petit problème : je n'ai jamais écrit de compilateur/traducteur vers un autre langage, donc une fois le programme écrit, tout ce qu'on peut en faire, c'est le mettre à la poubelle :-D
# FPGA HLS
Posté par flagos . Évalué à 2.
Il est possible aujourd'hui (et mature avec des outils proprio) de generer son code vhdl ou verilog a partir de C.
Savez vous s'il existe il des outils libres permettant de faire ca ?
[^] # Re: FPGA HLS
Posté par navaati . Évalué à 4.
Comprends pas cette histoire : le C, c'est pas parallèle, pas descriptif…
[^] # Re: FPGA HLS
Posté par flagos . Évalué à 8.
En fait, tu definis des fifo a l'aide de type C qui sont des ac_channel (je ne sais pas si ce typedef vient avec l'outil ou si c'est standard). Tu peux ensuite découper ton algo C en fonctions qui prennent ces ac_channels en entree/sortie, ce qui te permet de structurer une parallélisation.
Tu codes ensuite ton algo en attendant la data sur ces channels, en les processant et en les envoyant sur une channel de sortie. Tu fais ca sur des blocs, voir des sous-blocs. Tu peux ensuite dans ton C utiliser des boucles while, des boucles for, bref du C classique. Petit truc sympa: tu nommes avec des etiquettes tes boucles, tu peux dire au synthétiseur de soit le faire avec un compteur (N cycles, petite surface), soit de pisser toutes combinaisons en métal (1 cycle, grande surface). Ca permet, a partir du même code source, de faire un produit low cost ou high end.
Alors, effectivement, a la fin ton C (dit synthetisable), il a été pas mal restructuré, et on peut se demander la pertinence de le faire en C plutot qu'en vdhl: l'interet est que tu peux creer un testbench en C pur et te passer completement d'outils pour simuler, tu es directement en C. Ton temps de non-reg devient très rapide. Un autre avantage: a chaque changement de techno, il suffit de changer de target, et le vhdl généré est bon par conception.
Le workflow devient:
- tu pars d'un modele C pur, tu structures tes blocs toujours en C pur (c'est toujours un modèle),
- tu designes tes blocs en C synthetisable,
- et tu verifies chacun de tes blocs en changeant l'instance C model par le C synthetisable
Une fois que chacun de tes blocs est verifié: tu genères tout en vhdl, tu assembles, et pouf ! ca juste marche.
[^] # Re: FPGA HLS
Posté par djibb (site web personnel) . Évalué à -5. Dernière modification le 12 novembre 2014 à 21:46.
et pouf !
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
j'ai rien compris.
# Et System C?
Posté par pizaninja . Évalué à 1.
Quid de System C? C'est toujours pas synthétisable?
[^] # Re: Et System C?
Posté par martoni (site web personnel, Mastodon) . Évalué à 1.
En tout cas pas avec des logiciels libre. La base de cette lib n'est pas si libre que ça d'ailleurs, il faut s'identifier sur le site pour avoir accès au code.
J'ai plus qu'une balle
[^] # Re: Et System C?
Posté par marzoul . Évalué à 3.
Si, mais à ma connaissance seuls Catapult et les logiciels de Synopsys savent manger ça en entrée pour la synthèse. Je ne sais pas si j'ai assez de doigts pour compter le prix.
De mon point de vue, en tant que développeur d'un logiciel de HLS (AUGH), ce n'est qu'une histoire de front-end du logiciel. J'ai un front-end pour le langage C, mais on peut en faire un tout pareil pour le C++, donc le SystemC. Ce n'est qu'une affaire de conversion vers les structures de données du logiciel de HLS. Faut juste que quelqu'un s'y mette un jour, un bon coup de Clang… (on y mettrait bien un stagiaire si on en avait un bon motivé, éternel problème ;-))
# myHDL et OpenCL
Posté par freejeff . Évalué à 5.
Premièrement, je n'y connais absolument rien en VHDL/VERILIG/FPGA.
J'ai vu qu'un passionné a implémenté une description matérielle basée sur python qui se sert des générateurs et décorateurs. Il a mis en place des outils de conversion VHDL/VERILOG et permet de faire des tests. Il a effectué des benchmarks avec les outils propriétaires et lorsqu'il utilise pypy il semble avoir de bonnes performances.
http://www.myhdl.org/
Comme, je n'y connais rien, j'ai certainement dit pas mal de bétises cependant l'outils semble d'assez haut niveau en conservant des performances acceptables.
D'un autre cotés Altera a mis au point un traducteur OpenCL vers FPGA pour ces FPGA haut de gamme. Cela abaissera certainement la barrière pour les développeurs.
Beaucoup de gens qui font du VHDL et VERILOG disent que ce n'est pas une question de langage mais de logique. Je n'y connais rien mais on pourrait dire la même chose de la programmation sur MIC et GPU et pourtant il y a un énorme travail pour rendre cela accessible. Je pense donc qu'il y a un coup à jouer pour les logiciels libres.
[^] # Re: myHDL et OpenCL
Posté par Anonyme . Évalué à 1.
J’ai fais un peu de VHDL, en DUT. Pas de Verilog. Mais ce que j’en ai ressorti, c’est qu’il faut complètement revoir sa façon de travailler… alors pour un débutant je crois que Verilog ou VHDL ne fera pas de différence : il faut changer sa façon de voir la programmation.
Comme je n’avais alors jamais rien fait d’autre que du procédural et objet… je n’ai compris qu’à la fin du projet d’électronique -.-
[^] # Re: myHDL et OpenCL
Posté par martoni (site web personnel, Mastodon) . Évalué à 2.
Je connaissais myhdl, mais quand j'avais regardé il était encore embryonnaire. Visiblement c'est un projet qui avance bien, je vais me pencher dessus à nouveau.
C'est assez ambitieux de pouvoir générer à la fois du VHDL et du Verilog pour la synthèse.
Pour OpenCL, les outils de conversions ne semblent pas spécialement libre par contre.
J'ai plus qu'une balle
# Logiciels de HLS
Posté par marzoul . Évalué à 6.
Bonsoir,
VHDL et Verilog seront toujours utilisés pour les interfaces/IP très optimisées. Pour le reste les techniques de HLS sont en train de les remplacer.
Il en existe. Certains ont une spécialisation dans des domaines précis, mais je ne les connais pas assez intimement pour en faire la pub (sauf AUGH).
AUGH http://tima.imag.fr/sls/research-projects/augh/
LegUp http://legup.eecg.utoronto.ca/
GAUT http://hls-labsticc.univ-ubs.fr/
ngDesign https://www.synflow.com/
ORCC http://orcc.sourceforge.net/
ROCCC http://www.jacquardcomputing.com/
Moi je développe le logiciel AUGH :-) Je le fais aussi générique que possible.
Oui et non, leur outil n'est ni libre ni gratuit (1k€) et OpenCL impose des contraintes fortes sur les carte FPGA utilisées. Et c'est bloqué sur les technos Altera évidemment…
Xilinx aussi s'y met. Vivado HLS est très bon, mais comptez 2k€.
[^] # Re: Logiciels de HLS
Posté par martoni (site web personnel, Mastodon) . Évalué à 2.
Tout à fait d'accord avec toi, l'avenir n'est pas dans le Verilog ou le VHDL.
Mais quand je regarde les projets libres générant du langage HDL pour la synthèse, la plupart se basent sur le Verilog.
Comme souvent ces projets ne sont pas «terminés» il faut souvent mettre les mains dans le code généré, du coup si on veut utiliser des outils libres pour le faire du FPGA c'est au Verilog qu'il faut se mettre.
Le VHDL appris à l'école réduit le champs des possible dans le libre.
J'ai plus qu'une balle
[^] # Re: Logiciels de HLS
Posté par marzoul . Évalué à 4.
Autant que je me souvienne, le Verilog est surtout répandu aux US et le VHDL c'est surtout en Europe, et sans précision pour le reste du monde.
Question de masse de travail les développeurs isolés choisissent de ne gérer qu'un langage, et ils prennent celui qu'ils ont vu à l'école. Je ne pense pas que ce soit approprié, globalement, de dire que Verilog ou VHDL est mieux juste au nombre de projets "ralliés" à un "camp".
[^] # Re: Logiciels de HLS
Posté par martoni (site web personnel, Mastodon) . Évalué à 1.
La question n'est pas de savoir lequel est le meilleurs, mais plutôt dans lequel s'engager si on veut utiliser des logiciels libres pour développer avec.
J'ai plus qu'une balle
[^] # Re: Logiciels de HLS
Posté par gnx . Évalué à 4.
Hum… déjà que ce n'est pas toujours évident d'estimer la complexité de ce qui va être généré par un synthétiseur à partir d'un HDL (VHDL, Vérilog, etc.), avec ça, on risque d'aller au carnage. Surtout qu'avec l'apparence de langages classiques qui camouflera quasi-totalement ce qu'on génère, on risque d'y coller des purs softeux qui n'ont aucune idée de la nature et des contraintes sous-jacentes : autant dire qu'on n'a pas le cul sorti des ronces.
[^] # Re: Logiciels de HLS
Posté par marzoul . Évalué à 1.
C'est pas faux, mais juste en théorie.
À mon avis, en pratique, la nature des FPGA fait qu'ils resteront des accélérateurs matériels. Là, vu leur prix, le choix sera vite vu : un pur softeux qui n'arrive pas à accélérer l'appli sera vite remplacé.
Même avec des logiciels de HLS, la suite de synthèse indique toujours le temps d'exécution, la surface, parfois la puissance, et bien sûr la routabilité. Un truc codé avec les pieds a toujours tout ça de chances d'être retoqué dès les premières lignes de code.
Le seul truc qui m'embête c'est la diversité des langages d'entrée utilisés en HLS. C'est souvent un logiciel = un langage (sur-ensenble de sous-ensemble du C, du C++, du python, de Matlab, des trucs complètement ad-hoc…). Avec juste VHDL et Verilog, on était vernis. Mais là, ça va faire mal. Autant que sur CPU, toutes les libs de tout existent en C, C++, python, java, vala et j'en passe.
[^] # Re: Logiciels de HLS
Posté par Sylvain Briole (site web personnel) . Évalué à 4.
À mon avis, en pratique, la nature des FPGA fait qu'ils resteront des accélérateurs matériels.
Quand je regarde les FPGAs sur lesquels je bosse et les applications qui y sont associées, ce n'est pas vraiment le cas. Il n'y a pas qu'un seul marché pour les FPGAs.
Il ne faut pas oublier un autre avantage des FPGAs (ou plus généralement de la logique programmable): la forte intégration de fonctions logiques, avec la possibilité d'avoir un comportement déterministe "fin".
[^] # Re: Logiciels de HLS
Posté par gnx . Évalué à 2.
Pareil, je n'ai jamais été confronté à des FPGA dans le rôle d'accélérateurs matériels. J'ajouterais à ce que tu dis la possibilité d'avoir à disposition une énorme quantité d'I/O numériques (et, outre le nombre, rapides et sans latence, si c'est le besoin).
[^] # Re: Logiciels de HLS
Posté par flagos . Évalué à 2.
On disait pareil du VHDL, "rien ne vaut un mec qui assemble ses portes a la main !", mais bon non en fait :-).
Clairement, aujourd'hui le passage VHDL -> HLS entraine pas vraiment de changement de métier. Ca ressemble pas mal a du VHDL finalement, notamment parce que c'est plus simple pour les outils a gérer, et un point agréable: il y a nettement moins de verbosité en CSYN qu'en VHDL.
Au final, le passage VHDL->HLS se fait plutot bien, bien plus facilement que le passage gate->VHDL.
# Standardisation ?!?
Posté par khivapia . Évalué à 3.
"mal standardisés et sujet à interprétation en fonction de l'outil utilisé."
Pardon ? Quand on connaît le prix de fonderie d'un composant, on a envie de dire que le langage qui permet de le concevoir doit être bien standardisé pour éviter la classe de bugs associée à des interprétations variables ! Ça veut dire que ce n'est pas vraiment le cas ?!?
[^] # Re: Standardisation ?!?
Posté par Maclag . Évalué à 4.
En fait, quand tu vas faire le design, tu te reposes sur un des gros fournisseurs de solutions de tout intégrées, et chacun d'eux est qualifié/qualifie les fonderies.
C'est effectivement bien trop coûteux pour prendre le risque de se reposer sur un vrai standard.
Donc les interprétations d'un outil à l'autre, on s'en fout, de toute façon, à la fin, tu ne bosses pas avec Verilog ou VHDL, mais avec la suite de Cadence, de Synopsys, ou de Mentor.
[^] # Re: Standardisation ?!?
Posté par Ronan BARZIC . Évalué à 2.
Heu ????
Bien sur que si ces langages sont standardisés :
IEEE 1076.1 : VHDL
IEEE1364 : Verilog
P1800 : System Verilog
IEEE 1801 : UPF
Pour le standard UVM voir accelera.org
Pour le format LEF/DEF : si2.org
etc….
Je ne sais pas ou tu bosses mais c'est quand même très courant pour une société qui conçoit des puces electroniques d'avoir des outils provenant des trois différents principaux vendeurs (Synopsys, Cadence et Mentor), sans parler des d'autres outsiders (Atrenta, Ansys, BA, …)
Heureusement qu'ils utilisent des formats communs, sinon tu es prisonnier de ton fournisseur et il te le fera payer…
[^] # Re: Standardisation ?!?
Posté par Maclag . Évalué à 3.
Effectivement, les designers utilisent des outils des 3 gros à la fois (sauf petite boite avec moins de moyens). Ce que je veux dire, c'est que je doute qu'on puisse utiliser simplement le code d'un outil vers l'autre sans aucune modification.
Les formats sont censés être communs, mais ODF aussi, par exemple, et je n'irais pas envoyer un document critique fait sous LO à un client qui utilise MSO.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.