Mediul de verificare

Alexandru Dinu
 Cuprins
Mediul generic de verificare
Componentele de verificare
Mediul de verificare
Modulul de top
Componente vs tranzacții
Agenții pasivi
Agenții activi
Scoreboardul
Ierarhia componentelor de verificare într-un test
Tranzacțiile dinamice
Secvențele virtuale 2
 Mediul generic de verificare

Verificarea presupune aplicarea “reguli celor 2 perechi de ochi”:

Pe baza specificației funcționale a modulului, atât proiectantul (“designerul”), cât și inginerii de
verificare creaază un model al DUT-ului. Designerul creează un model sintetizabil, care la sfârșit va
fi sintetizat și se va materializa în trasee în siliciu. Inginerii de verificare creează un model mai
abstract al DUT-ului, nesintetizabil. Dacă cele două modele puse împreună (li se furnizează aceiași
stimuli) funcționează la fel se probează faptul că DUT-ul a fost proiectat bine. Altfel, se purcede la
debug.
3
 Componentele de verificare
Componentele de verificare – sunt reprezentate de orice clasă
creată în scopul verificării. Aceste clase sunt instanțiate înainte ca
simularea propriu-zisă să înceapă (la timpul 0 al simulării).
În continuare se prezintă componentele de verificare folosite în
limbajul SystemVerilog

4
 Mediul de verificare
Inginerii de verificare, mai ales pentru modulele mai simple, în loc să
construiască un model complet al DUT-ului, folosesc doar construcții specifice
verificării pentru a se “lega” la semnalele DUT-ului și a testa funcționalitățile
acestuia. Printre respectivele construcții se numără agenții pasivi și activi,
scoreboardul, aserții, elemente de coverage, etc.
Mediul de verificare, în SystemVerilog, este reprezentat de o clasă care
instanțiază toate componentele de verificare necesare pentru a verifica DUT-ul.

5
 Modulul de top
Este un modul Verilog/VHDL care instanțiază DUT-ul, interfețele de semnale,
generatorul de ceas și reset și logica adițională necesară pentru a verifica prin
simulare modulul în cauză.

6
 Modulu de top – circulația datelor
În modulul de top, interacțiunea între componente se desfășoară doar la nivel de semnal (nu la
nivel de tranzacții sau secvențe)

7
 Componente vs Tranzacții
Componenta [ de verificare ]
Este un obiect cvasi-static creat o singură dată
înainte ca simularea să înceapă.
Este parte a unei ierarhii de componente,
asemănătoare ierarhiilor din cadrul modulelor
aparținând codului RTL. O componentă este
instanțiată fie în cadrul altei componente, fie
direct în modulul de top.
Posedă funcționalități specifice procesului de
verificare: trimitere a stimulilor (driving),
monitorizare de semnale, colectare de coverage
funcțional, etc.
Tranzacția [ dinamică ]
Creată/generată dinamic în timpul simulării
(fiecare pachet în taskul scenario îl creem cu
comanda new)
Poate fi creată în contextul oricărui modul,
componente sau unei alte tranzacții (exemplu:
generearea unui pachet în taskul scenario din
driver reprezintă crearea unei tranzacții; această
tranzacție se procesează de către driver – vezi
taskul drive_packet).
O tranzacție este un container/grupare de stimuli,
date, etc. (ex. datele conținute de clasa packet).
8
 Agenții pasivi
Agentul = o clasă de tip container care conține instanțe ale altor componente: monitor,
driver, sequncer, etc (principiul has a)
Monitorul citește traficul de date de pe interfață, preia datele și le grupează, recreând
tranzacțiile inițiale și le trimite către alte componente de verificare (ex. scoreboard)
Coverage collector-ul – componentă de verificare care adună informația de coverage din
diferite surse
Agent Config – clasa de configurare a agentului, prin modificarea parametrilor acestuia

9
 Fluxul de date în agenții pasivi
Mediul de verificare culege datele de pe interfețele DUT-ului prin intermediul
monitoarelor. Monitoarele preiau datele la nivel de semnal, compun tranzacțiile și le
trimit la alte componente de verificare (în exemplu, la coverage collector și scoreboard).

10
 Agenții activi
Componentele active sunt folosite pentru a genera
stimuli, semnale de control și pentru a configura DUT-ul.
Driverul sau BFM-ul(Bus Functional Model) trimite
stimuli pe interfețe la nivel de semnal, respectând
protocolul de comunicație a interfeței.
Sequencerul este o componentă de verificare “tampon”
între generatorul de stimuli (bazat pe generare aleatoare)
și driver. Acesta trimite datele driverului sub formă de
tranzacție, nu la nivel de semnal.
Secvența este clasa răspunzătoare pentru generarea
stimulilor și sincronizarea scenariilor
Elementul de secvență (Sequence item) este o clasă care
încapsulează valorile stimulilor și constrângerile de
generare.
11
 Fluxul de date în agenții activi
Sequencerul preia datele generate aleatoriu (cu constrângeri) la nivel de tranzacție și le
transmite driver-ului într-o ordine corespunzătoare scenariilor care trebuie
implementate.
Driverul descompune datele din tranzacțiile primite de la sequencer și le transmite
DUT-ului prin interfețe, la nivel de semnal.

12
 Scoreboard-ul
Modelul de referință reprezintă o
implementare mai abstractă a funcționalității
DUT-ului.
Modelele de referință pot fi implementate în
cadrul clasei scoreboard sau într-o clasă
separată sau pot fi accesate printr-o interfață de
tip DPI-C (folosită la integrarea codului C în
mediul de verificare SystemVerilog).
Scoreboardul este folosit pentru verificarea
datelor, evenimentelor, etc și poate conține
definiții de coverage.

13
 Ierarhia componentelor de verificare
într-un test
Un test este o clasă care instanțiază
clasa mediului de verificare și pornește
un set specific de stimuli.
Fiecare test creează un scenariu
specific (sau mai multe scenarii –
dependente de seed- care au diferențe
mai mari sau mai mici între ele, în
funcție de gradul de aleatorizare al
elementelor testului), acoperind diverse
funcționalități ale DUT-ului

14
 Tranzacțiile dinamice
Tranzacțiile pot consta în pachete, date de sine
stătătoare, etc.

Obiectele sunt generate dinamic în timpul simulării.

Tranzacțiile încapsulează mai multe

proprietăți/atribute de diferite tipuri de dată. De
asemenea acestea încapsulează constrângeri de
generare.

De asemenea, tranzacțiilor li sunt asociate funcții

specifice (debug API) pentru o manipulare mai
ușoară a datelor și pentru respectarea principiului
de încapsulare (ex. de funcții: printarea datelor,
getteri, setteri).

Exemplu de clasă reprezentând o tranzacție: clasa

packet de la laborator (are proprietăți/atribute:
src_address, dest_address, etc; constrângeri (de
exemplu length%2==0;) și metode (funcțiile
pretty_print, pack_bytes, etc) )
15
 Secvențele virtuale
Permit (co)ordonarea și sincronizarea stimulilor și acțiunilor din cadrul mai multor agenți astfel încât
acestea să formeze scenariul dorit.

Secvența fizică: o secvență care este configurată pentru a trimite un anumit tip de tranzacție (care
aparține unei clase anume); tranzacția este trimisă pe magistrala fizică printr-un driver dedicat, asociat
secvenței. Cu alte cuvinte, stimulii generați de o secvență fizică ajung să fie transmiși tot pe o magistrală
fizică.

Secvența virtuală: este o secvență care nu este creată pentru o tranzacție specifică și nu este asociată cu
un driver. Secvența virtuală este folosită doar pentru a porni și controla alte secvențe/tranzacții. Acestea
din urmă vor trimite într-adevăr date pe interfețe/magistrale fizice.

16
Mediul de verificare

Alexandru Dinu