System Verilog

~Documentarea proiectelor
circuitelor integrate~
Alexandru Dinu
 Cuprins
Introducere
Componentele documentației
Specificația funcțională
Specificația de proiectare
Design API
Planul de verificare
Specificația de verificare
Raportul de verificare
Documentația protocoalelor folosite
Documentația specifică modulului proiectat
Documente/platforme software de urmărire a problemelor 2
 Introducere
“Failing to plan = Planning to Fail”
Documentație bună => Spor în lucru, organizare, timp mai scăzut de realizare a sarcinilor,
atitudine pozitivă a inginerilor implicați în proiect
Scrie documentația ca și ar trebui tu însăți peste 6-12 luni
Toate documentele trebuie să conțină un istoric al modificărilor
Toate documentele proiectului trebuie să conțină o secțiune cu referințe
De obicei, documentația dintr-un proiect se păstrează în format Word/Excel/Visio/HTML
Documentelele se pot păstra și într-un format executabil, pentru o vizionare eficientă a
progresului sau a rezultatelor obținute (ex. Excel-Visual Basic, planul de verificare
executabil al companiei Cadence)
Pentru o mai bună urmărire a modificărilor documentelor, și evitarea pierderii involuntare
de informații, se folosesc sisteme de versionare ale documentelor(ex. Tortoise, SVN);
astfel, sistemul informatic salvează copii ale documentelor la diferite intervale de timp,
acestea putând fi consultate ulterior 3
 Componentele documentației în
cadrul proiectului unui ASIC
• Documentația referitoare la caracteristicile tehnice ale modulului (specificația
funcțională)
• Documentația referitoare la proiectarea modulului (specificația de proiectare)
• Documentația care arată implementarea modulului (Design API) – opțională;
aceasta se poate genera automat cu utilitare dedicate inclusiv pe baza
comentariilor adăugate în cod
• Planul de verificare
• Documentul care descrie implementarea mediului de verificare (Specificația de
verificare)
• Raportul de verificare (concluziile)
• Documentația protocoalelor folosite în proiectele de verificare (UART, AMBA –
APB, AHB, SPI, CAN, I2C, etc)
• Documentația specifică IP-ului/SoC-ului proiectat (ghid de integrare, ghid de
utilizare, ghid de setare a parametrilor HW/SW)
• Documente/platforme software de urmărire a problemelor (bug-urilor)
descoperite pe parcursul verificării (Bugzilla, Mantis, JIRA, YouTrack, Microsoft
Team Foundation Server, etc)
4
 Specificația funcțională
– CE FACE ASIC-UL?
Conține:
Descrieri ale caracteristicilor și funcționalităților modulelor componente
ale cipului (ASIC-ului)
Situații de funcționare ale modulelor
Frecvențe de funcționare
Posibilitatea de interacțiune a modulelor
Poziția interfețelor cipului (pinii)
Detalii despre tranzacțiile de date și semnalele de control
Secvențe de configurare ale modulelor
Descrierea regiștrilor
Caracteristici de performanță
De obicei această specificație este scrisă sub forma unui document Word

5
 Specificația de proiectare
-CUM FUNCȚIONEAZĂ/ESTE IMPLEMENTAT ASIC-
UL? -

Conține:
Detalii de implementare a codului RTL
Aspecte variate care determină aria ocupată de modul și
frecvențele de funcționare ale acestuia
Detalii despre magistrale/interfețe interne și alte
componente
Dependențe ale codului RTL
De obicei această specificație este scrisă sub forma unui
document Word
6
 Design API

Documentație generată automat în diferite formate, pe baza

codului RTL
Exemple:
Specador Documentation Generator, Amiq
Doxygen
etc

7
 Planul de verificare
Conține:
O listă detaliată a caracteristicilor de verificat, grupate pe
categorii
Pentru fiecare caracteristică (feature) se definește un set
de metrici (coverage, checkere, aserții) care, odată
acoperite, asigură funcționalitatea corectă a acesteia
O listă de scenarii/teste care trebuie implementate și rulate
Referințe la specificația funcțională, specificațiile
protocoalelor folosite, erorile găsite, etc
Se stochează sub formă de document Word, tabel Excell, sau într-
un format executabil (ex. xml, json, Cadence Vplan) 8
 Specificația de verificare
Conține:
O descriere a abordărilor folosite în verificarea modulului
O descriere a structurii mediului de verificare și a implementării acestuia
(inclusiv figuri –ex. “yellow banana”)
O descriere a pașilor de punere în funcțiune a mediului de verificare
(comenzi rulate, scripturi) pentru a putea fi reproduse testele și regresiile
Descrierea stimulilor folosiți, a constrângerilor și a scenariilor/testelor
implementate
Enumerarea utilitarelor folosite în procesul de
verificare (+ numărul versiunii acestora)
Descrierea structurii generale a proiectului
Descrierea limitărilor mediului de verificare
Se stochează sub formă de document Word “yellow banana”
9
 Raportul de verificare
-CONCLUZIILE -
Conține:
Analiza metricilor colectate
Rezultatele din regresii
Descrierea limitărilor codului RTL
Descrierea problemelor nerezolvate
Referințe către toate celelalte documente
relevante
Se stochează sub formă de document Word
10
 Documentația protocoalelor folosite
Se descriu comportamentul agenților
folosiți în verificare
Se explică diagrame de semnale
Se definesc tipuri de date, niveluri de
protocoale
Se explică mașinile de stări pe baza
cărora funcționează anumite protocoale Exemplu de diagramă de stări
Se descriu mecanismele de semnalizare a
erorilor

Exemplu de forme de undă 11

 Documentația specifică
modulului proiectat

Pe lângă toate documentele menționate anterior, aceasta mai poate

fi formată din:
Ghiduri de integrare a modulelor proiectate în sisteme mai
complexe
Informații suplimentarea de folosire a modulelor care sunt
furnizate utilizatorilor acestora

12
 Documente/platforme software
de urmărire a problemelor
Fiecare problemă (bug) descoperită în codul RTL în timpul proceselor de verificare, validare,
sau implementare de prototip la client este documentată, etalându-se informații privind mai
multe aspecte:
Scenariul/situația care a generat descoperirea erorii
Persoana/persoanele responsabile de rezolvarea erorilor
Descrierea amănunțită a erorii
Implicațiile erorii în restul funcționării sistemului/modulului/cipului
Cum se poate reproduce eroarea, dacă aceasta nu a fost rezolvată

Se pot folosi fie tabele în care se rețin detaliile erorilor, fie platforme specializate pentru
urmărirea erorilor (ex. Bugzilla, Mantis, JIRA, YouTrack, Microsoft TFS).

13
System Verilog
~Documentația proiectelor
circuitelor integrate~
Alexandru Dinu