Scrierea și rularea unui script pentru a simula codul verilog în modelsim

Buna ziua tuturor! Sper ca toată lumea a avut o vacanță bună și sunt gata să cucerească înălțimile dezvoltării FPGA cu noi forțe.

Astăzi vreau să scriu un mic ghid despre lansarea testbench pe Verilog / SystemVerilog în ModelSim fără a utiliza GUI.







Planul va fi următorul:

Să mergem! Pentru a începe, trebuie să aveți următoarele în mâinile dvs.:


  • instalat ModelSim;
  • proiect gata pentru Verilog / SystemVerilog;
  • gata testbench pe Verilog / SystemVerilog;

De exemplu, vom analiza proiectul HappyNY

1. Adăugarea unei căi spre executabilul modelsim în PATH

Pentru a verifica dacă trebuie să faceți acest lucru, puteți ușor: tip modelsim în linia de comandă. dacă ModelSim pornește după aceea, atunci puteți sări peste elementul curent. În caz contrar, pentru Windows, acest lucru se face după cum urmează: linia de comandă este deschisă și comanda este scrisă

în care calea către modelele fișierelor executabile (după ce trebuie să specificați calea spre fișierul executabil). După executarea comenzii, efectuați verificarea indicată la începutul acestui paragraf, dacă ceva nu este în regulă, repetați paragraful.

2. Scrierea unui script pentru a rula

Vom analiza această piesă a scenariului.

Comanda de transcriere cu semnalizatorul este identică cu cea a ecoului. și anume După specificarea acestei comenzi, toate comenzile ulterioare specificate în script sunt tipărite atunci când sunt executate pe linia de comandă ModelSim, adică devine clar ce comandă a fost executată și după care a apărut o eroare (dacă sa produs).

Comanda vlib creează o bibliotecă de proiect numită lucrare.

Comanda vlog cu steaguri este un apel către compilatorul Verilog.

Steagul -sv. ai ghicit, acesta spune compilatorului să utilizeze standardul SystemVerilog. Toate fișierele sunt compilate independent, spre deosebire de exemplu, Quartus. așa că dacă faceți, de exemplu, să importați anumite părți ale pachetului. atunci trebuie să le facă în fiecare fișier în cazul în care acestea sunt utilizate, fie direct în fișierul care conține pachetul (Cvart, în cazul în care nu prevedea gărzile de incluziune, arunca în acest caz, eroarea).

Steagul + incdir + .. / arată unde compilatorul ar trebui să caute includ fișiere (adică fișiere specificate în cod cu directiva `include ').

Apoi vine numele fișierului compilat.

Comanda vsim este începutul simulării.

Parametrul -t specifică precizia grilei de timp.
Parametrul -voptargs primește argumente pentru apelul automat ulterior al vopt-ului de optimizare, adică va exista un apel la vopt + acc. Acest steag include optimizări pentru diferite obiecte din proiect și include vizibilitatea acestor obiecte în simulator. Citiți mai multe despre aceasta aici la pagina 154.
La sfârșit este numele testbench-ului de nivel superior, în acest exemplu este același cu numele fișierului.

Și, în sfârșit, ultima parte a scenariului:

Mai întâi, adăugăm semnalele de care avem nevoie la forma de undă folosind comanda add wave. Rețineți că unul dintre semnale a modificat formatul de afișare la unul simbolic utilizând parametrul -radix ASCII.

Apoi, setăm unitățile scalei de timp. Rulam simularea conform scenariului scris în testbench. Întindeți (sau comprimați) imaginea din fereastra Wave astfel încât să se potrivească exact cu dimensiunea ferestrei.







3. Rulați ModelSim cu execuția scriptului

Primul pas este să deschideți linia de comandă sau terminalul și să mergeți la directorul unde sunt fișierele de script și proiect. Apoi trebuie să executați modelele de fișiere executabile cu opțiunea -do . în cazul nostru:

Nu trebuie să faceți altceva. Dacă, din anumite motive, nu ați putut adăuga calea către ModelSim variabilelor de mediu, în loc de modelsim, puteți specifica calea completă la fișierul executabil. Dacă acest lucru nu a funcționat, atunci executând manual ModelSim, puteți merge la directorul de proiect în linia de comandă a ModelSim și rulați scriptul cu comanda:

După toate procedurile descrise, ar trebui să vedeți această imagine:

Vă mulțumesc pentru atenție, noroc!

Bună ziua! Recent am încercat să fac ceva similar pentru VHDL și m-am odihnit pe faptul că, spre deosebire de Verilog, ordinea de compilare a fișierelor este importantă. IDE grave se descurcă cu acest joc jucăuș, dar "sapă" de acolo, așa cum o fac - nu s-au descurcat. În acest sens, întrebarea este - există vreo evoluție de acest fel pentru VHDL?

Pys.Sy.Esli sincer, sa dovedit a ajunge la ordinea de fișiere în compilație prin modul non-proiect Vivado, dar aceasta este o varianta prea crass. Dacă există nuclee criptate în proiect, atunci ordinea fișierelor devine deja mică și generează scripturi pentru simularea Vivado în acest mod nu poate. Pentru a crea de fiecare dată un proiect - același lucru nu este prea convenabil.

Cu VHDL nu a lucrat niciodată, așa că nimic concret de sprijin, din păcate, nu pot. O idee este de a încerca pentru a rula o simulare a proiectului dvs. folosind NativeLink kvartusa și a vedea ceea ce el Genera script și apoi încercați să-l analizeze) În ceea ce privește prezența dependentă de cip de anchetă, este nevoie deja biblioteca producătorului, acestea ar trebui să fie utilizate la specificarea bibliotecilor ModelSim.

Încercați să creați mai întâi un proiect în ModelSim, adăugați toate fișierele necesare și apoi executați comanda de compilare automată. Pe baza ordinii aranjate, faceți scenariul de bază. Proiectul nu mai poate fi folosit, dar organiza totul pe tcl, sh sau orice doriți. La intrarea în lucrare facem editarea pixurilor acest lucru nu este atât de dificil.

unele IDE-uri pot compila automat codul sursă (descriere sintetizată) pentru simulare. Designer HDL este capabil de exact tot ce compilat pentru modelsima rămâne fișiere testbencha compilate, care sunt de obicei mult mai mici și nu merită mult efort pentru a le adăuga la script-ul numai. cum ar fi vivada, de asemenea, posibilitatea de a, dar am putea fi greșit, pentru o lungă perioadă de timp nu funcționează

O abordare similară cu depanarea a fost văzută aici.
- .bat crează și elimină directorul pentru toate junk-urile asociate cu simularea;
- .tcl - funcționează cu compilare, semnale și depanare
Adăugăm doar formarea liniei vlog în părți, singur (nu într-o singură linie).
Este suficient să se întâmple atunci când mâinile (în interfață) nu se rup, iar fișierele de creare nu vor să comunice.

de fapt, scrierea unui testbench este un lucru mult mai puternic. poate la pornire pentru a seta parametrii în funcție de care se va executa un anumit test (kit de testare) de la toate mediile de testare prin schimbarea valorilor variabile de nivel testbencha de top pe baza testului selectat poate selecta diferite improvizat preparat anterior (de altfel, este mult mai ușor de a menține improvizate script-ul de creare în fișier separat, mai ales în cazul în care mai multe semnale derivate) pot dezactiva anumite elemente DUT, mai ales în cazul în care modulul de test are o multitudine de blocuri, care poate accelera sim în unele cazuri semnificativ)

1. Adăugăm că puteți nu numai .do, dar și .tcl
2. Sunteți în zadar pentru a porni dosarul rtl_work. Mulți dezvoltatori folosesc biblioteca de director / lucrare prestabilită și nu vă vor înțelege imediat.
linii:
vlib rtl_work
vmap work rtl_work

pot fi înlocuite cu:
vlib work

3. În plus, nu trebuie să ștergeți biblioteca, puteți să creați una nouă pe cea veche. El va scrie cu siguranță un avertisment că biblioteca există deja, dar nu se va întâmpla nimic rău.
4. De ce să luăm numele fișierelor compilate în bretele? Dacă acesta este un stil de codificare, atunci nu puteți înlocui o variabilă în calea fișierului. De exemplu, nu funcționează.
5.-L este necesar atunci când se leagă bibliotecile terților (cu excepția muncii). munca este legată implicit.
6. În vlog-munca de lucru este complet inutil. Acest lucru se face în mod implicit.

Vă mulțumesc, va corecta azi) inițial am fost ghidat de un script care generează kvartus folosind NativeLink, așa că unele lucruri sunt acum știu pentru prima dată (nr. 4-6)







Trimiteți-le prietenilor: