Verificarea FPGA. Ce este asta? 6
- 15.07.15 12:53 •
- x0n •
- # 262693
- Habrahabr •
- 15 •
- 4448
- la fel ca Forbes, doar mai bine.
Prin voința destinului, am fost implicat în verificarea configurațiilor FPGA timp de mai mulți ani. Și de la început am fost uimit de numărul mic de informații pe această temă.
Dacă nu toate, atunci mulți au auzit despre FPGA. Poate că unii chiar au lucrat îndeaproape cu ei, dar cred că mai puțini oameni au dat peste verificarea proiectelor pe FPGA. Astăzi voi vorbi despre procesul de verificare.
Verificarea funcțională pe FPGA este un proces de căutare și remediere a erorilor în configurația FPGA (firmware ulterior). Veți spune ce pentru verificarea este necesar, după toate, într-o etapă de depanare FPGA în "fier" toate pot fi corectate. Este posibil, dar extrem de dificil.
În primul rând, în "glandă", căutarea erorilor funcționale este un proces laborios și consumator de timp. Aceasta duce la întârzieri în finalizarea proiectului. Pentru un proiect destul de grav, depanarea poate dura săptămâni și luni. Verificarea, cu toate acestea, vă permite să găsiți și să remediați majoritatea erorilor funcționale în stadiul modelului.
Vrei să spui că un dezvoltator experimentat FPGA nu face greșeli sau le face extrem de puține? El face! Și destul de mult.
Verificarea vă permite să detectați nu numai erorile curente, ci și erorile potențiale care pot apărea în proiectele viitoare care utilizează blocuri.
Verificarea poate fi împărțită condiționat în următoarele etape:- Dezvoltarea TK;
- Elaborarea unui plan de verificare;
- Dezvoltarea întreținerii;
- testare;
1. Dezvoltarea TOR pentru verificare
După cum știți - o abordare competentă în dezvoltarea TK elimină multe probleme pe tot parcursul proiectului. TOR pentru verificare ar trebui să descrie setul complet și cuprinzător de funcții și capabilități ale unității care trebuie verificate. În mod ideal, sarcina de verificare trebuie scrisă de echipa grupului de verificare. Acest lucru este extrem de important, mai ales cu puțină experiență a verificatorului care va fi implicat în testare. TOR trebuie să includă următoarele elemente:
• enumerarea tuturor blocurilor care vor face parte din proiect și a căror lucrare urmează a fi verificată;
• enumerarea tuturor modurilor de funcționare, a funcțiilor, a posibilităților de proiect care necesită verificare;
• enumerarea funcțiilor și a claselor de întreținere care vor fi refolosite din alte proiecte (de exemplu, un set de funcții pentru calcularea sumelor de control sau a interfețelor de transfer de date).
În mod firesc, scrierea TK ar trebui să înceapă după ce a primit toate informațiile necesare despre acest proiect.
2. Elaborarea unui plan de verificare
Procesul de planificare este probabil cel mai important și cel mai neglijat stadiu al verificării funcționale. Crearea unui plan de verificare este determinată de dezvoltarea unor strategii și tactici de lucru cu proiectul înainte de a începe. Planul de verificare este un ghid pentru echipa de proiect. Fără un plan de verificare competent, echipele aleg de multe ori un mod greșit de a găsi erori.
Planul de verificare include un set de teste cu o descriere detaliată.
Planul de verificare este documentul principal pentru echipa de verificare FPGA. Toate lucrările ulterioare se vor baza pe acest document. Toți "monștrii străini" ai sistemelor de pe cristalul Synopsys și Cadence sunt recomandați să înceapă cu un plan de verificare înainte de a începe dezvoltarea TO. De fapt, planul de verificare oferă o TK mai detaliată pentru verificare.
În descrierea detaliată a fiecărei încercări, trebuie indicați toți parametrii programabili necesari, modurile de funcționare curente, datele de intrare, de ieșire și de referință.
3. Dezvoltarea întreținerii
Trebuie reamintit faptul că dezvoltarea configurației FPGA și dezvoltarea MRO ar trebui să înceapă și să se desfășoare în paralel. Această comandă este optimă din punctul de vedere al timpului minim pentru dezvoltarea proiectului, deoarece procesele de verificare ocupă mai mult de 70% din timpul de dezvoltare al întregului proiect.
Pe baza informațiilor din toți pașii anteriori, puteți începe să creați un mediu de testare (mai departe IT). Este obișnuit să scrieți în limbi de programare create special pentru scopuri de verificare, deoarece au toate instrumentele necesare pentru aceasta. Sistemul Verilog este unul dintre limbile cele mai potrivite. Această limbă este destul de similară cu C ++, împreună cu încapsularea, polimorfismul, moștenirea.
Atunci când dezvoltați un mediu de testare, este foarte recomandat să nu uitați de "reutilizabilitate". Dacă nu există funcții potrivite, scrieți-le în funcție de posibila utilizare ulterioară. Dacă există funcții, utilizați. Este necesară organizarea lucrărilor de întreținere, astfel încât fiecare încercare să poată fi modificată fără posibilitatea de deteriorare a altor teste. Acest lucru va salva probleme în viitor, deoarece, ca și în procesul de testare, trebuie să introduceți în continuare anumite modificări în codul TO.
4. Testarea
În acest stadiu, verificatorul trebuie să lucreze cel mai strâns cu dezvoltatorul. Erori vor fi detectate în timpul testelor și vor fi detectate. Dacă nu, înseamnă că lucrul dvs. este corect. După ce ați detectat eroarea, trebuie să îi spuneți dezvoltatorului eroarea. Apoi, după corectare, verificatorul trebuie să ruleze din nou testul și să se asigure că eroarea este eliminată.
În mod ideal, ar fi folosirea sistemelor de urmărire a erorilor pentru a comunica între verificator și dezvoltator. Acest lucru vă va permite să urmăriți mai târziu care sunt problemele întâlnite adesea într-un anumit proiect sau de la un anumit dezvoltator. Și în același timp va fi o dovadă că verificatorul nu își pierde pâinea pentru nimic.
Presupun că ar trebui adăugat că nu fiecare dezvoltator și nu admite mereu greșelile lui. În acest caz, este necesar să se facă trimitere la TK, în care activitatea proiectului ar trebui să fie descrisă fără echivoc.
Vă puteți ajuta și puteți transfera niște bani la dezvoltarea site-ului
Și de la început am fost uimit de numărul mic de informații pe această temă.
Nu sunt de acord.
Firmware-ul FPGA este software (deși aici se poate argumenta, dar în acest context comparația este adecvată), de aceea verificarea sa este similară cu verificarea oricărui alt software. Există un număr suficient de articole, cărți, metodologii etc. privind testarea software-ului.
Cu toate acestea, firmware-ul este un program "neobișnuit" și are nuanțe cum să-l testezi. Aici ne ajută cărți precum "SystemVerilog for Verification" și "Writing testbenches using systemverilog", precum și site-uri ca testbench.in, precum și metodologii de verificare precum UVM, care sunt ascuțite pentru RTL.
Deci, în opinia mea, există informații în rețea :)
Mi se pare, va fi mai util pentru comunitate să-și arate testbench-ul (sau o parte a acestuia), spunând ce, cum și de ce faceți, pentru că viața reală într-un mare proiect serios nu este de acord cu sfaturile din cărți și articole de pe Internet)
Atunci gafa mea. În mintea mea am scris "informații în limba rusă", dar a fost scrisă pur și simplu "informații". Desigur, există destulă literatură în limba engleză, dar în comparație cu literatura de specialitate pentru testarea software-ului "obișnuit", informațiile sunt extrem de limitate.
Mai întâi dați definiția:
Verificarea funcțională pe FPGA este un proces de erori de căutare și de fixare
Și apoi:
deoarece procesele de verificare și de verificare a erorilor
Niciuna dintre acestea nu este adevărată.
Verificarea nu este căutarea și eliminarea erorilor, ci dovada conformității funcționării produsului în conformitate cu TOR.
Verificarea este confirmarea conformității produsului final cu cerințele de referință predeterminate. Cu cuvinte simple - am creat produsul corect, în funcție de cerințe.
Calitatea produsului este luată în considerare.
Validarea este procesul de furnizare a dovezilor că sunt îndeplinite cerințele unui anumit consumator extern sau utilizator al unui produs, serviciu sau sistem.
Cu cuvinte simple - am creat produsul potrivit folosind cerințele corecte. Se ia în considerare calitatea întregului proces de creare de produse.
deoarece procesele de verificare și de verificare a erorilor
Acest lucru am corectat.
Verificarea funcțională pe FPGA este un proces de erori de căutare și de fixare
Aici am vrut să descriu această definiție cu cuvinte mai ușor de înțeles, pentru a transmite esența.
Verificarea nu este căutarea și eliminarea erorilor, ci dovada conformității funcționării produsului în conformitate cu TOR.
Aici cuvântul "dovadă" este inadecvat, în opinia mea. Aceasta este, ca verificator, mi sa dat un produs și trebuie să demonstrez că produsul funcționează corect? Deci nu e bine. Verificatorul trebuie să verifice conformitatea produsului TK, iar dacă produsul nu se potrivește, atunci spuneți persoanei care o va remedia.
Și de la început am fost uimit de numărul mic de informații pe această temă.
Nu sunt de acord.
Firmware-ul FPGA este software (deși aici se poate argumenta, dar în acest context comparația este adecvată), de aceea verificarea sa este similară cu verificarea oricărui alt software. Există un număr suficient de articole, cărți, metodologii etc. privind testarea software-ului.
Cu toate acestea, firmware-ul este un program "neobișnuit" și are nuanțe cum să-l testezi. Aici ne ajută cărți precum "SystemVerilog for Verification" și "Writing testbenches using systemverilog", precum și site-uri ca testbench.in, precum și metodologii de verificare precum UVM, care sunt ascuțite pentru RTL.
Deci, în opinia mea, există informații în rețea :)
Mi se pare, va fi mai util pentru comunitate să-și arate testbench-ul (sau o parte a acestuia), spunând ce, cum și de ce faceți, pentru că viața reală într-un mare proiect serios nu este de acord cu sfaturile din cărți și articole de pe Internet)
Atunci gafa mea. În mintea mea am scris "informații în limba rusă", dar a fost scrisă pur și simplu "informații". Desigur, există destulă literatură în limba engleză, dar în comparație cu literatura de specialitate pentru testarea software-ului "obișnuit", informațiile sunt extrem de limitate.
Mai întâi dați definiția:
Verificarea funcțională pe FPGA este un proces de erori de căutare și de fixare
Și apoi:
deoarece procesele de verificare și de verificare a erorilor
Niciuna dintre acestea nu este adevărată.
Verificarea nu este căutarea și eliminarea erorilor, ci dovada conformității funcționării produsului în conformitate cu TOR.
Verificarea este confirmarea conformității produsului final cu cerințele de referință predeterminate. Cu cuvinte simple - am creat produsul corect, în funcție de cerințe.
Calitatea produsului este luată în considerare.
Validarea este procesul de furnizare a dovezilor că sunt îndeplinite cerințele unui anumit consumator extern sau utilizator al unui produs, serviciu sau sistem.
Cu cuvinte simple - am creat produsul potrivit folosind cerințele corecte. Se ia în considerare calitatea întregului proces de creare a produselor.
deoarece procesele de verificare și de verificare a erorilor
Acest lucru am corectat.
Verificarea funcțională pe FPGA este un proces de erori de căutare și de fixare
Aici am vrut să descriu această definiție cu cuvinte mai ușor de înțeles, pentru a transmite esența.
Verificarea nu este căutarea și eliminarea erorilor, ci dovada conformității funcționării produsului în conformitate cu TOR.
Aici cuvântul "dovadă" este inadecvat, în opinia mea. Aceasta este, ca verificator, mi sa dat un produs și trebuie să demonstrez că produsul funcționează corect? Deci nu e bine. Verificatorul trebuie să verifice conformitatea produsului TK, iar dacă produsul nu se potrivește, atunci spuneți persoanei care o va remedia.