Sunteți pe pagina 1din 29

System Verilog

~Coverage~

Alexandru Dinu
Cuprins
Întrebări fundamentale despre verificarea
ASIC-urilor
Introducere
Scenario coverage
Assertion coverage
Functional coverage
Code coverage
Excepții de neacoperire a coverage-ului
Anexe
2
Întrebări fundamentale despre
verificarea ASIC-urilor
Care este definiția verificării funcționale prin simulare?
(eng) metric-driven constraint random-based functional verification
Verificare funcțională având la bază generarea aleatoare a datelor, constrânsă pentru a se genera
doar date “legale” care are ca scop îndeplinirea metricilor predefinite
Ce ar trebui verificat?
Răspunsul se găsește în Planul de Verificare (realizat în ședință comună cu inginerii de verificare,
arhitecții și proiectanții ASIC-ului)
Cum ar trebui verificat?
Detalii despre DUT sunt în Specificația funcțională (Document realizat de arhitecții ASIC-ului)
Regulile construcției unui mediu de verificare se găsesc în Metodologia UVM (Universal
Verification Methodology)
Cum a fost făcută verificarea (întrebarea se pune la sfârșitul proiectului?
Răspunsul se găsește în Specificația de verificare (o realizează inginerii de verificare)
Când se termină verificarea?
În funcție de metricile verificării (martorii de coverage, aserții, alți itemi de detectare a erorilor
3
-checkere-, etc) colectate pe parcursul simulărilor.
Introducere
Pentru a verifica un ASIC, este necesar să fie simulate toate posibilitățile de
funcționare ale acestuia în “viața reală”. Pentru aceasta, în cadrul mediului de
verificare, se adaugă martori de acoperire (=(eng)coverage ) a funcționalităților
sau valorilor obținute în simulare.
Declararea acestor martori de coverage se face în funcție de specificațiile
modulului de verificat. Înainte de a se purcede la verificarea proiectului RTL al
unui ASIC, inginerii de verificare, împreună cu arhitecții și proiectanții unui
modul creează un plan de verificare. Acest plan cuprinde toate caracteristicile
modulului care trebuie verificate. Compania Cadence a realizat un format de
Plan de Verificare executabil, prin care se poate face legătura între secțiunile
acestuia și martorii de coverage corespunzători. Astfel, după o serie de
simulări, se poate vedea direct în planul de verificare care funcționalități ale
DUT-ului au fost simulate până în acel moment.
4
Introducere
Analiza de coverage poate fi făcută în două moduri:
Type-based –se combină valoarea coverage-ului pentru toate instanțele
modulului conținând elementul de coverage
Instance-based – se arată valoarea coverage-ului pentru fiecare instanță în
parte (este mai util în multe cazuri)

Instance-based coverage:

Type-based coverage:

5
Introducere
Când se termină verificarea?
Verificarea se termină în momentul în care se îndeplinesc cumulativ și integral mai multe condiții:
toate funcționalitățile pe care le poate îndeplini DUT-ul în viața reală sunt reproduse în cadrul a
diverse scenarii de simulare. (scenario coverage)
s-au executat (cu 100% rată de succes) toate aserțiile și alte elemente de verificare care relevă
funcționalitatea corectă a DUT-ului (assertions coverage)
semnalele de interes au primit toate valorile relevante pentru funcționarea DUT-ului (în fapt,
uneori sunt alese câteva valori reprezentative pentru anumite intervale) (functional coverage)
simularea a făcut să se execute fiecare linie de cod din DUT (de asemenea, când s-a intrat pe toate
ramurile de adevăr și neadevăr a buclelor if, case, etc) (code coverage); Code coverage include
și:
în cazul mașinilor de stări (eng. Finite State Machines =FSMs), toate stările au fost atinse
(FSM coverage)
Tabelele de adevăr ale condițiilor/expresiilor logice / expresiilor booleene din DUT au fost
complet parcurse (expression coverage)
6
Toți biții semnalelor de interes au avut și valoarea 0 și valoarea 1 (toggle coverage)
Scenario Aceste secvențe de bază, precum și altele
coverage solicitate de arhitecții/managementul
Există anumite secvențe de operații care proiectului pot fi menționate în planul de
fac parte din funcționarea de bază a unui verificare. Pentru a nu se uita de
modul (ex. Power-on-reset, procedura implementarea acestor secvențe în simulare,
de handshake master-slave de pe o testele care implementează secvențele
magistrală, resetarea regiștrilor, scrierea respective sunt “mapate”(se face legătura) cu
și citirea regiștrilor). mențiunile corespondente din Vplan
Simularea acestor secvențe de bază (verification plan).
poate reprezenta un punct de pornire în Definirea secvențelor (unde se pot strecura
verificarea unui modul. greșeli de concept), cât și maparea acestora în
Vplan (se pot realiza mapări incorecte, sau se
poate uita realizarea unor legături între Vplan)
scen1
este făcută de utilizatorul uman, de aceea
scen2
spunem că acest tip de coverage este unul
scen3
Verification Plan “subiectiv”. 7
Assertion coverage - Martori de
coverage al aserțiilor
Se pot scrie numeroase aserții în mediul de verificare, dar dacă evenimentul declanșator
(triggerul) acestora nu apare, acestea nu vor fi executate. Astfel, nefiind erori, inginerul de
verificare va crede că modulul funcționează corect dar, de fapt, anumite părți ale modulului
nu au fost testate. Pentru a se evita acest neajuns, se folosește directiva cover. Aceasta,
aplicată unei aserții, arată de câte ori a fost executată aserția, și de câte ori aceasta a fost
adevărată (o execuție a aserției poate returna valori de adevăr de mai multe ori – vezi
##[m:n] ). Inginerii de verificare definesc aceste elemente de coverage, manual, de aceea se
pot strecura și greșeli (spunem că acest tip de coverage este unul “subiectiv”).

cover_name : cover (expression);


Sintaxă: cover_name : cover
property(property_expression);
cover_name : cover sequence
Exemplu: (sequence_expression);
property my_property;
@(posedge clk) (rst_n !== x && rst_n !== Z)
endproperty

MY_COVER_NAME: cover property (my_property); 8


Functional coverage
Să presupunem că imaginea alăturată
reprezintă o hartă care cuprinde toate
funcționalitățile unui modul de verificat.
Fiecare funcționalitate corespunde unei
căsuțe din tabel. Fiecare culoare
reprezintă un test de verificare. Astfel,
testul 1 a acoperit funcționalitățile
modulului hașurate cu roșu, prin testul 2
s-au stimulat funcționalitățile modulului
hașurate cu albastru, etc. Unele În raportul de functional coverage putem
funcționalități ale modulului au fost vedea ce funcționalități ale DUT-ului au fost
stimulate în cadrul mai multor teste. acoperite, care teste au acoperit aceste
funcționalități, și ce situații/valori ale
semnalelor nu au fost încă simulate. 9
Functional coverage
Dat fiind faptul că elementele de Ce parametri de simulare ar trebui
functional coverage sunt definite eșantionați?
de oameni, informația furnizată Valori de configurare ale DUT-ului (ex. moduri,
este una “subiectivă”: poate fi manipularea erorilor, întreruperi)
incompletă, sau chiar poate să Parametrii ale fluxului de date (ex. parametrii
inducă în eroare dacă itemii de pachetelor, selectarea frecvenței, tipul de trafic)
coverage au fost definiți greșit. Valori de întârziere (ex. întârzieri între pachete,
Colectarea de functional coverage tipuri de accese)
este definită de doi parametrii: Parametrii de setare a magistralelor (numărul de
Ce parametrii de simulare ar masteri /slave-i, tipul de arbitrare)
trebui analizați? Când ar trebui să fie eșantionate valorile
Când ar trebui să fie acestora?
eșantionate valorile acestora? De obicei, după ce corectitudinea valorii
parametrului a fost verificată
10
Functional
coverage
Inginerii de verificare definesc și
implementează matorii de coverage funcțional
în cadrul mediului de verificare, folosind
următoarele elemente (îngroșat apar cuvintele
cheie):
Grup de coverage – covergroup
Element de coverage – coverpoint
Diviziuni ale intervalului de valori ale
parametrilor aferenți martorilor de
coverage – bins
Combinații ale mai multor elemente de
coverage –cross
Urmărirea schimbărilor de valori în
cadrul martorilor de coverage –
transition coverage
11
Functional coverage
SystemVerilog oferă mai multe opțiuni de divizare și management al intervalelor de valori ale unui
atribut/unei proprietăți.

12
Functional coverage
Pentru a eșantiona
apelarea funcției implicite sample()
parametrii/proprietățile/atributele/semnal
pentru covergroup-ul respectiv
ele aferente martorilor de coverage, task monitor();
...
există 3 opțiuni: begin
cg_name.sample();
asocierea covergroup-ului cu un end
eveniment de eșantionare endtask

covergroup cg_name @ sample_event


....
endgroup

Definirea și apelarea funcției


sample() definite de inginerul de
verificare pentru covergroup–ul
respectiv

13
Sursa imaginii: https://www.amiq.com/consulting/2016/05/13/how-to-implement-flexible-coverage-definitions-part-1/
Code coverage
Această ramură a coverage-ului se referă la

%
codul RTL al DUT-ului, nu la codul mediului
de verificare!
Analiza metricii de code coverage arată ce
proporție din codul RTL a fost exersat în timpul
simulării, semnalează: limitările de generare ale
mediului de verificare, testele sau scenariile
lipsă, elementele de coverage funcțional care
lipsesc. Tipuri de code coverage:
Informația colectată nu depinde de experiența toggle coverage
inginerului de verificare; informația de code statement/line/block coverage
coverage (gradul de acoperire/parcurgere a branch coverage
codului) se colectează “obiectiv” și automat de expression coverage
către simulator. FSM coverage 14
Code coverage – toggle coverage

Se urmărește ca fiecare bit aparținând unui


semnal să primească și valoarea 0 și
valoarea 1. Astfel, se elimină riscul ca biții
să fie legați involuntar permanent la una din
cele 2 valori logice (stuck-at-0 sau stuck-at-
1).

De asemenea faptul că se schimbă biții unui


semnal indică activitate pe acel semnal.

Avantaje: este ușor de acoperit (100%) acest Sursa imaginii:


tip de coverage. https://www.amiq.com/consulting/2015/0
9/18/functional-coverage-patterns-bitwise-
Dezavantaje: nu este întotdeauna relevant în coverage/
verificare, nu arată legăturile existente între
biții care își schimbă valoarea.
15
Code coverage – statement / line /
block coverage
Se urmărește ca fiecare
bucată din codul RTL să fie
parcursă.

Printre cauzele nestimulării


unei părți din codul RTL pe
parcursul verificării, se pot
%
afla o verificare insuficientă,
existența unui cod inutil în
DUT, o greșeală a
proiectantului, etc.
16
Code coverage – branch coverage

Se urmărește ca în cadrul simulării să se intre și pe ramura de


adevăr și pe fiecare ramură de neadevăr (else) a fiecărei
condiții.

17
Code coverage – expression coverage

Tabelele de adevăr ale condițiilor/expresiilor logice/ expresiilor


booleene din DUT trebuie să fie complet parcurse

Sursa imaginii:

18
Code coverage – FSM coverage

Mașinile de stări din


DUT sunt identificate de
către utilitarele folosite
pentru simulare. Astfel,
se pot crea rapoarte din
care să reiasă care/câte
stări au fost acoperite și
Sursa imaginii: Cursul de electronică digitală,
care tranziții între stări au Prof. Dan Nicula
nu au avut loc.
19
Excepții de neacoperire a coverage-
ului
Este posibil ca, în unele cazuri, elemente de coverage declarate să
nu fie acoperite în totalitate. Dacă se constată că neacoperirea
completă a acestor itemi nu ascunde defecte ale DUT-ului, și
acoperirea lor ar necesita o cantitate prea mare de resurse (timp
investit de către inginerii de verificare, număr de simulări
necesare), se documentează situațiile respective, dar fără a se
elimina din planul de verificare elementele neacoperite.

20
Anexe
(sursa: Doulos,
https://register.gotowebinar.com/recording/2473894966131748355 )

21
Declararea martorilor de functional coverage

22
Colectarea coverage-ului funcțional separat
pentru fiecare instanță/obiect

23
Rapoarte de coverage

24
25
26
Comanda de eșantionare a unui
covergroup aparținând unei clase

27
28
System Verilog
~Coverage~

Alexandru Dinu