• [^] # Re: Pourquoi seulement du Verilog synthétisable ?

    Posté par (site web personnel, Mastodon) . En réponse à la dépêche Verilator 4.002. Évalué à 4. Dernière modification le 24 septembre 2018 à 09:14.

    Existe-t-il un comparatif entre Verilator et GHDL pour des benchmarks équivalents dans les deux langages ?

    Ça n'est pas vraiment comparable dans la mesure où GHDL est un simulateur «complet» qui simule toute la norme VHDL alors que Verilator se contente de la sous-partie «synthétisable».
    J'avais commencé à faire un comparatif verilator/icarus avec mon projet blp (blinking led project), il faudrait que j'ajoute GHDL au comparatif. Mais je suis certain que GHDL sera nettement plus lent que Verilator, le comparatif Icarus/GHDL serait plus pertinent.

    Il existe un projet d'adapter verilator (verilatorVHDL) pour supporter le VHDL, mais il n'est pas encore abouti à ma connaissance.

    Si verilator n'est capable de prendre en entrée que du Verilog synthétisable, c'est parce qu'il convertit ce code en un objet en C++ et/ou SystemC

    Je suis un peu étonné par cette phrase. Si le code Verilog est converti en C++, pourquoi serions-nous limité à du code synthétisable ?

    La différence fondamentale entre un simulateur «normal» et verilator (au dela du fait qu'il ne fasse que convertir le modèle en un objet C++) est qu'il ne gère pas le temps !

    Pour faire tourner le simulateur, on écrit des valeurs sur les ports d'entrées de notre design, on appel la fonction «eval()» qui va évaluer les valeurs de sorties. Puis on recommence.
    C'est à nous de gérer le temps en appelant la fonction eval() à interval régulier. Tous les #xx sont ignorés.

    J'ai plus qu'une balle