Design grafic sau text verilog

Design grafic sau text Verilog / VHDL?

Design grafic sau text verilog

Voi încerca să ating o temă holistică: o comparație a două metode de dezvoltare, o intrare grafică a unei scheme și o descriere textuală a proiectului în HDL Verilog / VHDL.







Ce metodă este mai bună?

La o dată, voi spune că sunt un susținător al introducerii de text, deci cu siguranță nota mea poate părea părtinitoare. Cu toate acestea, iată câteva remarci mai importante pe această temă:

  1. proiectul poate fi executat bine și cu grijă, indiferent de ce metodă a fost folosită, în același mod, designul rău poate fi făcut atât cu utilizarea reprezentării schematice cât și în descrierea pe Verilog / VHDL. Calitatea proiectului depinde de calificarea programatorului mai degrabă decât de instrumentul ales (deși programatorul poate avea propriile preferințe și experiență specifică în mediul de proiectare).
  2. indiferent de prezentarea proiectului sub formă de text sau schemă HDL, compilatorul (teoretic) trebuie și trebuie să sintetizeze o imagine la fel de optimă pentru firmware în FPGA. În orice caz, compilatorul va optimiza logica combinațională, va elimina elementele neutilizate, va declanșa, va sintetiza și va optimiza lista netlist.

Acum, însă, să analizăm deficiențele și avantajele metodelor de dezvoltare în schemă sau în formă text.

În mod convențional, există mai multe criterii interdependente pentru evaluarea metodei de dezvoltare a proiectelor digitale pentru FPGA și ASIC: confort, viteză de dezvoltare, prezentare, portabilitate, gestionabilitate cod, fiabilitate.

Ei bine, în mediul Quartus II pentru schemele de desen nu există o astfel de posibilitate. Dacă doriți să adăugați o nouă componentă a circuitului, este necesar să se execute o secvență de acțiuni, cum ar fi „click dreapta“ => alegere din meniul Insert => lui Simbol => mai târziu, în selecție caseta de dialog pe lista bibliotecii primitive => l instalați pe circuit. Apoi, încă, uneori, pe care doriți să-l editați proprietățile elementului selectat, iar acest lucru este din nou un mouse, dialoguri, și apoi, după multe ore de lucru cu mouse-ul - „Sindromul de tunel“ o boală a mâinii,

Design grafic sau text verilog

Cât de multe mișcări ale mouse-ului și câte clicuri trebuie să faceți pentru a adăuga un nou element circuitului în mediul Altera Quartus II?

Desigur, viteza de dezvoltare este strâns legată de confortul mediului de proiectare (a se vedea punctul 1).
De obicei, cei care trag schemele spun că viteza de intrare nu le deranjează, deoarece gândirea la proiect durează mult mai mult decât desenul. Poate că așa este, cu asta puteți chiar să fiți de acord.

De fapt, folosesc adesea intrările grafice. Deseori în proiect am un fișier grafic de cel mai înalt nivel al ierarhiei. Apoi, modulele incluse în ierarhie sunt fie Verilog, fie componente create de expertul Altero tip FIFO, componenta controler DDR, modulul SRAM sau PLL, altceva. Un proiect simplu poate fi atras, de asemenea, dar atunci când devine treptat complicat în timp, editarea devine din ce în ce mai dificilă și complicată. Este necesar să extindeți obiectele grafice, componente, fire, pneuri, pentru a introduce ceva nou. Această deplasare a obiectelor de schemă durează destul de mult, mai ales dacă designerul are un sentiment de frumusețe și îi place schemele cu elemente aliniate la grilă. Se poate întâmpla ca, în loc să lucreze la proiectul real, o persoană lucrează la deplasarea componentelor. Imprimați un proiect grafic mare pe imprimantă devine din ce în ce mai dificil, dimensiunea hârtiei A4 nu se potrivește, aveți nevoie de A2 sau A1 sau foi de lipire.

În plus, trebuie remarcat faptul că viteza de dezvoltare depinde în mare măsură de specificul și capacitățile limbajului de programare sau a mediului de proiectare.

Iată un punct important: tot ce poate fi tras în schemă poate fi descris de limbajul textului HDL, dar nu tot ceea ce este descris în limba HDL poate fi ușor implementat în schemă. Voi da câteva exemple:

modul hvsync (
// intrări:
fluxul de intrare pixel_clock,

// ieșiri:
ieșire reg hsync,
output reg vsync,
);

// parametrii semnalului video, implicit 1440x900 60Hz
parametru horz_front_porch = 80;
parametru horz_sync = 152;
parametru horz_back_porch = 232;
parametru horz_addr_time = 1440;

parametru vert_front_porch = 3;
parametru vert_sync = 6;
parametru vert_back_porch = 25;
parametru vert_addr_time = 900;
.

  • O altă caracteristică importantă a designului în text pentru Verilog HDL este posibilitatea compilării condiționate a proiectului. Aici, de exemplu, fragmentul de cod al proiectului Amber (procesor compatibil ARM și sistem pe chip).

i_irq (amber_irq),
.i_firq (amber_firq),

o_wb_adr (m_wb_adr [1]);
.o_wb_sel (m_wb_sel [1]),
.

Proiectul poate fi introdus, compilat un procesor de 5-fazic (este mai rapid, dar are mai mult logica) sau procesor 3 etape (mai lent, dar ocupă mai puțin logica). Această compilație condiționată are loc în funcție de parametrul specific AMBER_A25_CORE. Nu este posibilă utilizarea compilării condiționate în schemele. compilare condiționată este necesară, în cazul în care proiectul are un număr de exemple de realizare, de exemplu, pentru diferite tipuri de FPGA-uri pentru proiecte similare care urmează să fie incluse în proiect modul de depanare că produsul final nu este inclus și așa mai departe.

  • Cel de-al treilea exemplu este utilizarea unor construcții speciale ale limbajului Verilog HDL, care vă permit să generați și să introduceți în instanțele legate de proiect alte module. De exemplu, uitați-vă la acest cod în Verilog:






modul inst_loop
(
intrare ceas de sârmă,
cablu de intrare în,
ieșiți firul
);

indexul genvar;
genera
pentru (indice = 0; index <4; index=index+1)
începe. fu
sârmă o_q;
dacă (index == 0)
func # (index) func_inst (
.fclk (ceas),
.d (in),
.q (o_q)
);
altfel
func # (index) func_inst (
.fclk (ceas),
.d (fu [index-1] .o_q),
.q (o_q)
);
capăt
endgenerate

atribuie out = fu [3] .o_q;
endmodule

limbaj construct genera-endgenerate vă permite să setați numărul dorit de modul copii FUNC și să le conecteze între ele, după cum este necesar. În plus, fiecare copie a modulului FUNC poate fi, de asemenea, parametrizate să „știe locul lor“: în acest exemplu, # (indicele) - a trecut poziția modulului de parametri și comportamentul modulului poate depinde de acest parametru. Exemplul de mai sus face acest lucru:

Un astfel de ciclu poate crea, de exemplu, o structură de 1000 de module conectate. Cum de a desena o astfel de diagramă? Cât timp va dura? Și dintr-o dată am desenat o astfel de schemă și apoi trebuie să adaug un semnal modulului, ce trebuie să reparăm, redraw? Va fi dificil.

Există încă un astfel de argument în favoarea fișierelor grafice - vizibilitate. Se presupune că o persoană va reprezenta schema și o va implementa așa cum vă imaginați mai ușor în program. Ce se poate spune aici? De exemplu, am reprezentat o schemă, dar o pot descrie imediat pe Verilog. În general, cred că o persoană care scrie pe Verilog / VHDL ar trebui să își imagineze imediat în capul său schema descrisă în text - aceasta este corectă și ar trebui să fie așa.

Din nefericire, trebuie să spun că personal am probleme cu circuitele de lectură. Iată un exemplu.

Design grafic sau text verilog

Văd în schemă componenta standard LPM_SHIFTREG din biblioteca grafică Altera Quartus II. Cine poate să-mi spună imediat ce semnal are o prioritate mai mare de sclr sau sarcină. Ce se întâmplă dacă ambii devin activi? Pot fi înscrise toate registrele în registru sau se vor încărca date noi în registrul de deplasare? Aici uit mereu. Mă uit la această componentă din diagramă și nu-mi amintesc ce înseamnă tot. Probabil că am puțină experiență cu schemele.

Verificatorul este mai ușor. Nu există o alegorie:

reg [7: 0] serial_send_reg;
mereu @ (posedge clk)
dacă (sclr)
serial_send_reg <= 0;
altfel
dacă (încărcați)
serial_send_reg <= next_data;
altfel
serial_send_reg <= ;

În descrierea HDL Verilog, prioritățile de semnal sunt imediat vizibile în text.

În general, în ceea ce privește prezentarea vizuală a proiectului, personal nu am preferința pentru programe.

Portabilitatea și portabilitatea proiectelor.

Cred că este clar. Dacă dezvoltatorul dorește ca desenele sale să fie folosite în altă parte decât în ​​FPGA, ar trebui să utilizeze descrieri de text pe Verilog / VHDL. Sa întâmplat că până în prezent nu există un singur standard pentru fișierele de descriere grafică a circuitelor digitale. Deci, se pare că Altera are propriul format de fișier grafic, iar Xilinx are propriul său format. Și producătorii de chips-uri ASIC nu vor accepta design grafic, vor accepta doar text.

Noi, pentru placa noastră de bază, Mars rover2 s-au angajat în portarea proiectului deschis Amber cu opencores - a fost inițial realizat pentru chips-uri Xilinx în limba Verilog HDL. Acum îl putem compila pentru FPGA Altera Cyclone III. Dacă proiectul ar fi sub formă de scheme, cred că nu vom avea nicio șansă.

În general, vizualizarea schemelor reprezintă o problemă totală. Dacă aveți nevoie pentru a arăta proiectul ca un sistem pentru unii experți, primul lucru pe care trebuie să facă - să-ți un mediu de dezvoltare, și să înceapă să pompa de Internet pachet de instalare dimensiunea de 3-4 GB. Și totuși nu se știe dacă va fi lansată sau nu, dacă o persoană nu are un OS foarte comun pe computer. Și dacă sunt pe drum și am doar un iPad sau Galaxy Tab cu mine? Textul poate fi examinat, însă schema este deja dificilă.

O componentă importantă a procesului de dezvoltare a circuitelor digitale este verificarea. Pur și simplu puneți în scenă modelarea proiectului sau a modulelor acestuia. În cazul proiectelor textuale, procesul de testare arată astfel: se scrie un program de testare separat. Programul testbench este scris în aceeași limbă ca și proiectul în sine. De exemplu, proiectul este executat în Verilog. Testbench poate fi rulat, de asemenea, în Verilog.

Design grafic sau text verilog

Programul testbencha analizează modul finit ca o cutie neagră, toate semnalele de intrare pentru cutia neagră simulează, toate ieșirile unității de testare observăm și să vedem că ele au fost destinate. Programăm impactul asupra modulului studiat și monitorizăm răspunsul acestuia. Există multe instrumente pentru o astfel de verificare. Compania Altera oferă cu mediul său de proiectare ModelSim Altera Cvart II mai mult mediu - doar pentru a simula Verilog modele / VHDL. Există un proiect deschis Icarus Verilog pentru simularea funcțională a proiectelor. Adesea o folosesc eu - este un instrument foarte simplu.

Interesant este faptul că producătorii multor microcipuri furnizează modele Verilog ale jetoanelor lor, pentru a permite dezvoltatorilor să faciliteze depanarea proiectelor.

Există multe exemple bune de proiecte de simulare pe site-ul nostru. De exemplu, am simulat sistemul pe un cip Amber și rulați sistemul de operare Linux în sistem. Aceasta este o simulare foarte complexă, a inclus modelul de memorie SDRAM, sistemul de pe chip împreună cu procesorul, bootrom, port serial, temporizator, controler de întrerupere. În timpul simulării, procesorul examinat efectuează milioane de instrucțiuni. Este clar că o astfel de simulare lungă acoperă aproape toate stările interne posibile ale sistemului. Puteți speranța că proiectul funcționează corect.

La site-ul nostru, chiar și o dată a fost o revizuire a simulatorului de la Quartus II v9. De mult timp a fost. În versiunile ulterioare ale mediului de proiectare, Altera a exclus simulatorul din pachet. Ei bine, adevărul nu a avut succes.

Ce să faci acum? Există o singură modalitate de a simula circuitele într-un mediu quart. Deschideți fișierul schematic și apoi din meniul File => Create / Update => Creați fișierul de proiectare HDL din fișierul curent. Ca rezultat, schema este convertită într-un fișier text în Verilog sau VHDL. Ei bine și mai departe, la fel ca la oameni - utilizați ModelSim.

Nu este convenabil, există o etapă intermediară suplimentară de conversie. Dacă corectați în mod repetat circuitul și îl convertiți pentru simulare, atunci acesta poate deveni o tortură în general.

Se întâmplă adesea ca o funcție necesară să funcționeze odată, apoi sa oprit brusc. De ce? De ce? Cine și când a corectat proiectul? Cum să urmăriți în timp schimbarea proiectului?

În proiectele software pentru C / C ++, C #, PHP, Python și toate celelalte, serverul sursă este utilizat pentru a sprijini proiectul. Un exemplu tipic al unui sistem de control al surselor este Subversion sau GIT. Aceste sisteme vă permit să modificați codul proiectului și să salvați stările intermediare ale proiectului. Este, de asemenea, posibilă divizarea proiectului, îmbinarea ramurilor de lucru în fluxul principal al proiectului și așa mai departe. Poate că într-o zi va trebui să găsiți cine și când și de ce ați făcut unele modificări, poate fi necesar să vă întoarceți la versiunea anterioară a proiectului. Numai utilizarea sistemelor de control al versiunilor vă permite să păstrați în ordine un proiect mare.

Toate acestea, desigur, se aplică descrierilor de text ale proiectelor hardware pe Verilog / VHDL.
Un exemplu al proiectelor noastre în sistemul de control al versiunilor - Amber-Marsohod2 - portarea sistemului opensource pe chihlimbarul Amber pentru modelul Mars rover2. Întregul proces de portare este disponibil public pe GitHub. Și e minunat.

Când se utilizează fișiere text, este foarte ușor să se compare versiuni diferite ale aceluiași modul. Puteți doar consola comanda diff în Linux. Sau există instrumente pentru compararea și îmbinarea fișierelor text ale tipului Meld.

Dar spune-mi cum să comparăm cele două scheme: un pic mai în vârstă și ceva mai nou? Nu știu. Datorită lipsei instrumentelor de comparație grafică, utilizarea sistemelor de control al versiunilor devine foarte problematică și incomodă. Iată un alt argument important împotriva schemelor.

Concluzie Pot face acest lucru. Utilizarea textului pentru descrierea proiectelor hardware este în multe cazuri preferabilă. Mijloacele de intrare grafică pot fi returnate odată, dar numai atunci când și dacă există standarde pentru stocarea circuitelor și a instrumentelor care facilitează introducerea acestora, schemele de control și compararea acestora.







Trimiteți-le prietenilor: