ASIC verifikáció II. 2011.12.05.

1. ASIC verifikáció II.2011.12.05.

3. e-verifikáció Tartalom • Alapfogalmak (ismétlés) • A verifikációs környezet • Constrained-random e-verifikáció • Check, coverage, testcase • e-Reusability • eRM, uVM fogalma • Verifikáció az eRM metodológia felhasználásával • e-verifikációs komponensek (eVC) • Interfész eVC • Modul eVC • SVE (Specman VerificationEnvironment) • eVC-k implementálása az uVM felhasználásával

4. e-verifikáció Tartalom • A Verifikációs környezet megtervezése • Hova és milyen eVC-t kell elhelyezni? • Mit kell check-elni? • Hol használjunk coverage-t? • Mikor kell extra test scenario? • Az e-nyelv • A nyelv jellemzői, párhuzamok más programnyelvekkel • Nyelvi elemek • Speciális nyelvi elemek • Példák

5. Alapfogalmak (ismétlés)

6. Alapfogalmak (ismétlés) A verifikációs környezet • Tartalmazza • A HDL testbench-et a DUV instance-szal • A testbench passzív (clock, reset generátor lehet rajta) • A verifikációs komponenseket checker Referencia Modell Verifikációskörnyezet coverage ?=  DUV Interfészkomponens 1011001010

7. Alapfogalmak (ismétlés) Modul szintű, constrained random, e-verifikáció • A verifikációsszintekkiválasztása • A továbbiakban a modul szintű verifikációt tárgyaljuk Comprehensive functional verification the complete industry cycle - szerző: Bruce Wile,John C. Goss,Wolfgang Roesner

8. Alapfogalmak (ismétlés) Modul szintű, constrained random, e-verifikáció • Egy teszt több futás alatt más utakat járhat be • A verifikációs teret felosztjuk kisebb egységekre • A szűkített tartományon belül egy teszt hatékonyabban működik • Ki lehet zárni a nem üzemi állapotokat futás2 futás1 HDL egy állapota BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot Állapotok egy tartományaegy tesztre

9. Alapfogalmak (ismétlés) Modul szintű, constrained random, e-verifikáció • Az e-nyelvet használjuk 

10. Alapfogalmak (ismétlés) Check, coverage, test scenario • Check: Funkciók ellenőrzésére alkalmas elem • Coverage: A lefedettség mérésére alkalmas nyelvi eszköz • Test scenario: Bizonyos verifikációs forgatókönyvet megvalósító stimulus szekvencia

11. Alapfogalmak (ismétlés) Újrafelhasználhatóság, eRM • A funkcionális verifikáció módszertanának egyik alapja az újrafelhasználhatóság. • Lényege, hogy egy modul verifikációs környezetét minimális plusz munka befektetéssel tudjuk használni egy másik ASIC esetén is • Az eRM metodológia az újrafelhasználhatóság alapkövetelményeit fogalmazza meg • Az eRM szabályrendszere megkövetel bizonyos implementálási szabályokat • Alapegysége a verifikációs komponens (VC) • A verifikációs környezet felépítése a komponensek hierarchiáján és az őket összekötő kapcsolatokon alapul my_asic_1 my_asic_2 dma_env dma_env my_dma module my_dma module

12. Verifikáció az eRM metodológia felhasználásával

13. Verifikáció - eRM eVC • Az eVC (e Verification Component) egy önálló, konfigurálható verifikációs környezet, amely általában egy interfész típus verifikálására alkalmas. • Rendelkezik minden eszközzel, amellyel az DUV stimulálható, ellenőrizhető illetve a verifikáció teljessége monitorozható. • Használható önállóan, vagy egy nagyobb környezet részeként. • Nem egyszeri használatra implementálják. • Részei titkosíthatók. Ez lehetőséget nyújt a bonyolultabb eVC-k védelmére (akár a HDL IP-k esetében). • Lehet olyan eset, amikor egy eVC egy másiktól függ • Pl.: a TCP/IP eVC használhatja az Ethernet eVC-t. A TCP/IP eVC-t ennek ellenére az Ethernet eVC-től függetlenül fejleszthetik. • Példák • Busz alapú eVC-k (PCI, AHB, OCP…) • Data kommunikáció (UART, SPI, Ethernet, MAC…) • Magaszintű (TCP/IP, HTTP…)

14. Verifikáció - eRM eVC • Az eVC-k használatának előnyei: • A standard (eRM-ben meghatározott) konfigurációs felületnek köszönhetően könnyedén beilleszthető egy már meglévő verifikációs környezetbe (plug-and-play) • Felgyorsítja a verifikációs folyamatot • Az eVC-k struktúrája minden esetben egységes • Hordozhatóság ez egyes fejlesztői csoportok, illetve cégek között (Nem szükséges mindenhol ugyanazon fejlesztői kompetencia kiépítése, a fejlesztők a saját problémák megoldására összpontosíthatnak) • Hátrányok: • Az eRM által megkövetelt eVC struktúra kialakítása sokkal több kód implementálásával jár

15. Verifikáció - eRM eVC • Az eVC-k csoportosítása: • Interfész eVC – egy adott típusú interfészhez kapcsolódik, és annak meghajtását, ellenőrzését végzi. Információkat továbbíthat a verifikációs környezet magasabb szintjei felé. • Modul eVC – nem rendelkezik aktív kapcsolattal a DUV interfészeihez, csupán bemenetként használhatja annak jeleit. Általában a verifikációs környezet magasabb hierarchia szintjén helyezkedik el és az egyes interfész eVC-khez kapcsolódik. ModuleVC InterfészeVC InterfészeVC DUV

16. Verifikáció - eRM eVC könyvtárszerkezet • Readme.txt - Az eVC csomagról tartalmaz leírást (név, verzió, könyvtárak) • e/ - az eVC forrásfájljait tartalmazza • docs/ - az eVC dokumentációját tartalmazza • examples/ - pédakódok az eVC használatához (példa konfigurációs fájl) • misc/ - egyéb… • sve/ - egyminta környezet forrásfájljait tartalmazza

17. Verifikáció - eRM Az interfész eVC felépítése • Environment unit - ez tartalmazza az eVC összes részegységét. Felhasználáskor ez kerül példányosításra. env_u Config Agent • Config – az eVC konfigurációs interfésze. Signal Map Agent • Signal Map (SMP) – portokat tartalmaz, amelyeken keresztül az eVC kapcsolódni tud a DUV-hoz. Config Synchronizer Signal Map • Synchronizer- portokat tartalmaz, amelyek közösek a design egészére (pl. clock, reset) Sequence driver Seq Seq • Agent - unit, amely egy adott interfészhez tartozó eVC részegységeket tartalmazza (pl.: UART esetében 2 agent – RX, TX) • Sequence driver- unit, amely koordinálja a user-defined teszt szekvenciákat (Seq). DUV

18. Verifikáció - eRM Az interfész eVC felépítése • Monitor – unit, amely passzívan monitorozza az interfész működését. Eseményeket ill. adatokat szolgáltat a többi részegység számára. env_u Config Agent Signal Map Agent • Bus Functional Model (BFM) – unit, amely kommunikál a DUV interfésszel. Config Synchronizer • Collector– unit, a monitor része, low-level monitorozást végez, míg a magasabb szintű protokoll implementálása a monitorban történik. Signal Map Sequence driver Seq Seq Mon BFM Coll DUV

19. Verifikáció - eRM Synchronizer • A synchronizer egy unit, amely design minden komponense által használt közös jelekhez kapcsolódik. Ilyen jelek lehetnek a különböző órajelek és a reset jelek. Feladatai: • Az órajelek ill. reset jelek detektálása a bemeneti portokon keresztül, majd események (event) előállítása az eVC többi egysége számára eVC Synchronizer CLK/RST events CLK/RST Port CLK-RST gen

20. Verifikáció - eRM Sequence, item, driver • Sequence item – a DUV számára bemeneti adatot vagy vezérlő információt realizáló struktúra (pl. egy adatcsomag, regiszter érték stb.) • Sequence – struktúra, a sequence item-ek folyama. Általában magasabb szintű funkcionalitást is tartalmaz ezek előállítására vonatkozóan (pl.: generálási kényszereket, feltételeket stb.) • Sequence driver – unit, az átvivő réteg a verifikációs környezet és a szekvenciák között • Mind a sequence item-ek, mind a sequence-k fogadására képes. • Ütemezi ezek végrehajtását • A végrehajtás során a sequence item-ek a BFM-hez továbbítódnak

21. Verifikáció - eRM BFM • Bus Functional Model – a rá kapcsolódó DUV interfész protokollját megvalósító unit. Feladatai: • Fogadja a sequence item-eket a sequence driver-től • Az item-ekben definiált paramétereknek megfelelően meghajtja az interfészt • Pontosan ismernie kell az interfész protokolljának paramétereit (pl.: időzítés, adatbitek száma stb.)

22. Verifikáció - eRM Collector és Monitor • Collector - ará kapcsolódó DUV interfész protokollját monitorozó unit. Feladatai: • Pontosan ismernie kell az interfész protokolljának paramétereit (pl.: időzítés, adatbitek száma stb.) • Eseményeket ill. begyűjtött adatcsomagokat továbbít a monitor egységnek • Alacsony szintű protokoll checker-eket tartalmazhat • Monitor- collector-tól kapott adatok feldolgozását és továbbítását végző unit. Feladatai a követelményektől függenek: • Magasabb szintű protokolláris adatstruktúrák felépítése • Ezek ellenőrzése és továbbítása a verifikációs környezet más elemei számára

23. Verifikáció - eRM A modul eVC felépítése • Register map – ez a struktúra tartalmazza a DUV regiszter leírását. env_u Config • Referencia modellek – a DUV funkcionalitását modellező struktúrák, amelyek kimenetét felhasználjuk a funkcionális check-ek implementálása során. Signal Map Synchronizer Register Map • Scoreboards – speciális monitorozó egység, általában adatok sorrendhelyes összehasonlítására használjuk őket. Reference models Scoreboards Monitor DUV

24. Verifikáció - eRM A scoreboard lehetséges kialakítása Modul eVC Scoreboard Dat Check – OK? Monitor Dat Dat IF eVC 1 IF eVC 2 Monitor Monitor

25. Verifikáció - eRM Kapcsolódási lehetőségek a komponensek között • eVC – HDL – external portokkal ill. event portokkal • eVC – eVC – ún. method portokkal ill. event portokkal • Az uVM metodológia útmutatást ad univerzális verifikációs komponensek létrehozásához • A különféle portok használata lehetővé teszi az eltérő verifikációs nyelveken implementált komponensek csatlakoztatását az e környezethez (SystemC modell, System Verilog VC…) Agent Agent Simple port SVE If_env_u Config mod_env_u Event port Config Method port SMP SMP Sync Sync Reference models Sequence driver DUV Register Map Scoreboards Mon BFM Monitor CLK gen HDL TB

26. Verifikáció - eRM SVE és virtual sequence driver • Az SVE-ben (Simulation andVerification Environment) példányosítjuk és kapcsoljuk össze az egyes komponenseket. • Jellemzők: • Tartalmazza az egyes hierarchia szinteken elhelyezkedő eVC-k példányait • Beimportálja az eVC-k konfigurációs fáljait • Definiálja közöttük a működéshez szükséges összeköttetéseket (pointerek, method-, és event portok) • Tartalmazza az ún. virtual seqeuence driver példányát • Virtual sequence driver • Speciális sequence driver. • Virtuális mivel nincs dedikált sequence item-je, de sequence-i lehetnek! • A tesztekben mindig a virtual MAIN sequence a szimuláció futtatását irányító fő szekvencia • Mivel ez a driver végzi a szimulációban a fő vezérlő funkciót, célszerű tartalmaznia a többi eVC sequence driver-eire pointereket.

27. A verifikációs környezet megtervezése

28. Környezet tervezése Modul verifikációs környezet Példányosítás az SVE-ben Pointerek a modul eVC-ből az IF eVC-kre SVE A modul eVC-ből konfigurálódik Address map Agent Agent Agent Agent Agent Agent Példányosítás az SVE-ben Példányosítás az SVE-ben If_env_u If_env_u If_env_u Config Config Config mod_env_u Config Az IF eVC-k kapcsolódnak a DUV interfészeihez SMP SMP SMP SMP Sync Sync Sync Sync Reference models Sequence driver Sequence driver Sequence driver Register Map Scoreboards Mon Mon Mon BFM BFM BFM Monitor DUV HDL TB

29. Környezet tervezése DUV encapsulated interfészekkel Példányosítás az SVE-ben SVE mod_env_u Config Address map SMP Agent Agent Agent Agent Sync Példányosítás a modul eVC-ben Register Map Agent Agent Agent Agent Monitor Példányosítás az SVE-ben Scoreboards Reference models If_env_u If_env_u If_env_u If_env_u Config Config Config Config SMP SMP SMP SMP Sync Sync Sync Sync Sequence driver Sequence driver Sequence driver Sequence driver Mon Mon Mon Mon BFM BFM BFM BFM DUV HDL TB Ez az IF eVC a DUV belső interfészéhez kapcsolódik

30. Környezet tervezése Checkek megtervezése • Mit checkeljünk? Pl.: • A be-, és kimeneti adatok konzisztenciáját • Kimeneti jelek viselkedését (IRQ kimenet pulzus szélessége elegendő-e?, reset után egyik kimenet sincs X, Z állapotban) • Regiszter interfész megfelelő működését • Komplex, több tényezőtől függő funkcionalitást (pl. state machine) • stb. • Hova jönnek a checkek? • Az interface eVC collectorába, monitorába • A collectorban általában protokoll és signal check-ek • A monitorban magasabb szintű ellenőrzés • A modul eVC monitorába • A referencia modell kimenetét felhasználó checkek • A scoreboard checkek

31. Környezet tervezése Coverage megtervezése • Mire kell coverage-t gyűjtenünk? Pl.: • Jel vektor kimeneti értékére • Egy regiszter mező értékére • Konfiguráció előfordulására • IRQ esetén, annak bekövetkezésére ill. kiszolgálására • Tranzakció paramétereire (cím, irány…) • stb. • A coverage értékére lehet ún. range-eket definiálni • A felvehető értékkészletet tartományokra bontva figyeli • Ha az összes definiált tartományban van legalább 1 találat, akkor a coverage item betöltődik • Speciális coverage típus az ún. cross coverage (coverage mátrix) • Több, már definiált item ÉS kapcsolata • Csak akkor töltödik be, ha az összes benne található item mindegyike betöltődik • Példa: • Item1: „FIFO overflow IRQ” történt • Item2: „FIFO írás” történt • Cross item = Item1 ÉS Item2: FIFO írás történt, amikor már volt overflow IRQ

32. Környezet tervezése Test scenario megtervezése • A test case tulajdonképpen egy nagy test scenario • Tervezésénél figyelembe kell vennünk a rendszer valós működését • Pl.: • Reset triggerelése • Konfiguráció beírása a DUV regisztereibe • Egyéb stimulus generálása (pl.: adatátvitel) • IRQ esetén, annak kiszolgálása (pl.: status bit törlése) • stb. • Lehet olyan scenariót tervezni, amellyel a DUV hibakezelési képességeit szeretnénk leellenőrizni • Pl.: • Nem megengedett értéket írunk be egy konfigurációs regiszterbe • Protokollsértés követünk el az egyik interfészen • stb. • Corner case scenarió esetén a ritkán előforduló események előállítása a cél • Pl.: • FIFO túlcsordulásakor beírunk még egy értéket • Hosszú futásidővel elérjük bizonyos számlálók átfordulását

33. Az e-nyelv

34. e-nyelv Bevezetés • Az e-nyelv egy hardver verifikációs nyelv • A nyelvet egy ma már a Cadence EDA toolokat fejlesztő vállalat tulajdonában levő cég a Verisity Inc. Of Montain View , CA. feljlesztette ki • Fordításához és futtatásához a Specman Elite tool szükséges • Jellemzői: • Objektum orientált • Aspektus orientált • Kényelmes használat akár a C++, akár a BASIC nyelvet ismerők számára • Használata során elengedhetetlen legalább az eRM ismerete • Különböző nyelvi elemekkel támogatja a funkcionális verifikáció speciális követelményeit (checkek, coverage gyűjtés, sequence, event, error reporting, stimulus constainig stb.) • Elsajátításához és használatához több éves gyakorlat szükséges…

35. e-nyelv Aspektus orientált unitenv_u { -- field declaration field_1 : uint; -- empty method declaration method_init_1() isempty; -- method definition method_init_2() is { message(LOW,"Hello world! Function init 2..."); }; }; extendenv_u { -- field declaration field_2 : uint; -- extending method 1 method_init_1() is first { message(LOW,"Hello world! Function init 1 first..."); }; -- extending method 2 method_init_2() is only { message(LOW,"Hello world! Function init only 2..."); }; -- extending method 1 method_init_1() isalso { message(LOW,"Hello world! Function init 1 also..."); }; }; • Unit, struct, type, method stb. bárhol kibővíthető a későbbiekben

36. e-nyelv Unit • Alap strukturális blokk verifikációs modulok implementálásához • Jellemzői: • Tartalmazhat függvényeket • Tartalmazhat változókat • Használatkor példányosítani kell • Általában statikus használat… • Örökölhet tulajdonságokat már meglévő unitoktól -- creating a unit unitenv_u { }; -- creating a unit with inheritance unitenv_second_u like ovm_env { }; -- Using the env_u unit extend sys { env: env_uis instance; };

37. e-nyelv Struct típus • Adatblokk, általában adat egységek implementálásához • Jellemzői: • Tartalmazhat függvényeket • Tartalmazhat változókat • Használatkor nem kell példányosítani • Általában dinamikus használat… • Örökölhet tulajdonságokat már meglévő structoktól -- data item struct definition structdata_item_s { }; -- creating data item struct with inheritance structdata_item_second_s like any_sequence_item { }; -- using the struct extendenv_u { data : data_item_s; };

38. e-nyelv További adattípusok • Skalár típusok • A nyelv támogatja a lebegőpontos ábrázolást • real típus (hasonlít a double típushoz a C-ben) • nem generálható !!! • További típusok • string, list

39. e-nyelv Saját adattípusok, típuskonverzió • A nyelv lehetőséget nyújt saját adattípusok létrehozásához (enumerated scalar) • Ezek is „extendálhatóak” a későbbiekben -- Type definition typedirection_t : [ RX ]; -- Type extension extenddirection_t : [ TX ]; -- Type definition - the first element value is determined typestate_t : [ STATE_0 = 1, STATE_1, STATE_2 ]; • Típuskonverzió a „.as_a()” függvény használatával -- declarations variable_1 : uint; variable_2 : int; -- operation with type cast variable_1 = variable_2.as_a(uint);

40. e-nyelv Változók deklarálása, értékadás unitenv_u { -- declarations variable_1 : uint; variable_2 : int; -- declaration limiting the width variable_3 : uint(bits:15); -- the following action is not allowed here!!! variable_3 = 12; function_x() is { -- declaraton and initialization var variable_4 : bool = FALSE; var variable_5 : state_t = STATE_0; -- value assignment variable_1 = 15; variable_2 = -29; variable_1 = 0xEF; -- value assignment to bit range in a variable variable_3[15:8]= 0xAB; variable_3[7:0]= 0x0; }; };

41. e-nyelv Operátorok • Bitwise • ~, &, |, ^, <<, >> • Logikai • !, not, &&, and, ||, or • Aritmetikai • +, -, *, /, % • Összehasonlítás • <, <=, >, >=, ==, !=, in • Timing expressions • String operátorok

42. e-nyelv Listák • Az array típus nem ismert helyette a list típus használható unitenv_u { -- list declaration example : list of uint(bits:32); function_x() is { -- clearing all items from the list example.clear(); -- add several items to the list example.add(15); example.add(46); example.add(2589); -- print the value of 0 indexed item in the list print example[0]; -- pop the first item from the list varlist_item : uint(bits:32) = example.pop0(); -- search for an item in the list list_item= example.first(it == 46); }; };

43. e-nyelv Listák • Lista módosító pszeudó függvények • add(item), add(list), add0(item) • clear() • delete() • insert(index, item) • pop(), pop0() • push(), push0() • További pszeudó függvények • count(expr) • exists(expr) • first(expr) • first_index(expr) • has(expr) • is_empty() • size() • top(), top0() • Stb.

44. e-nyelv Feltételek • if - else • Komplex feltételek írásakor érdemes a zárójelezést használni if a > b then { print a, b; } else { print b, a; }; if a == b { print a, b; } else { print b, a; }; if a in[12,13] { print a; } else if b in[13..20] { print b; };

45. e-nyelv Feltételek • Case -- type def typestate_t : [ STATE_0 = 1, STATE_1, STATE_2 ]; unitbfm_u { states : state_t; function_x() is { case states { STATE_0 : { print "This is STATE_0"; }; STATE_1 : { print "This is STATE_1"; }; default : { print "Unknown state"; }; }; }; };

46. e-nyelv Ciklusok • for unitenv_u { function_x() is { vari : uint; -- C style for cycle for{i=0; i<10; i+=1} { print i; }; for{i=0; i<10; i+=1} do { print i; }; -- VB style for k from 0 to 9 do { print k; }; for k from 0 downto 9 do { print k; }; for k from 0 to 9 step 2 do { print k; }; }; };

47. e-nyelv Ciklusok • for each unitenv_u { function_x() is { var numbers : list of uint = {1; 2; 3; 4}; for each (n) in numbers do { print n; }; for each in numbers do { print numbers[index]; }; }; }; • while unitenv_u { function_x() is { varexit_cond: bool = FALSE; vari: uint = 0; while(!exit_cond) { if i == 10 { exit_cond= TRUE; }; i+= 1; }; }; };

48. e-nyelv Ciklusok • repeat – until unitenv_u { function_x() is { varexit_cond: bool = FALSE; vari: uint = 0; repeat { if i == 10 { exit_cond= TRUE; }; i+= 1; } until(!exit_cond); }; };

49. e-nyelv Method, TCM • Method unitenv_u { function_x(param_1 : bool, param_2 : uint) is { varexit_cond: bool = param_1; }; function_y() : uintisempty; function_y() : uintisalso { print "hello"; result 0; }; check() isalso { -- function call function_x(TRUE,25); var value : uint = function_y(); computefunction_y(); }; };

50. e-nyelv Method, TCM • TCM – Time Consuming Method • Mintavételezési eseménnyel (sampling event) egybeépített függvény • Engedélyezett a különböző time consuming függvények használata (wait, sync) • Másik TCM-ből történő hívás ugyanolyan mint a rendes függvények esetében • Nem TCM-ből törénő hívás csak a „start” parancs segítségével unitenv_u { function_x() @clock is { -- wait 20 clock cycles wait[20]; print "Hello"; -- wait for another event wait @reset_e; print "reset occured"; }; run() isalso { start function_x(); }; };