© evosoft GmbH ASIC verifikáció 2016. Unrestricted.

Az előadások a következő témára: "© evosoft GmbH ASIC verifikáció 2016. Unrestricted."— Előadás másolata:

1 © evosoft GmbH ASIC verifikáció 2016. Unrestricted

2 © evosoft GmbH Bemutatkozás

3 © evosoft GmbH Tartalom Bevezetés a funkcionális verifikációba Verifikációs alapfogalmak A verifikáció fogalma A tesztelés és a verifikáció közti különbség Miért van szükség a verifikációra? A verifikáció szerepe az ASIC fejlesztés folyamatában Mibe kerül egy bug? A verifikáció helye az ASIC fejlesztés folyamatában A verifikáció fajtái HDL testbench alapú verifikáció Bug-ok felfedése irányított teszttel Bug-ok felfedése randum stimulussal Constrained random szimuláció Tipikus megközelítés A verifikációs környezet felépítése constrained random stimulus esetén Pszeudó-random generálás

4 © evosoft GmbH Tartalom Bevezetés a funkcionális verifikációba A verifikáció teljességének mérése A verifikációs terv (vPan) Coverage gyűjtés Automatizált check-ek Az automatizált check-ek csoportosítása A lefedettség növelése A verifikációs projekt életciklusa

5 © evosoft GmbH Mottó Bevezető A hibakeresés kétszer olyan nehéz feladat, mint maga a kód megírása. Így, ha a lehető legjobb tudásod szerint írtad meg a kódot, az azt jelenti, hogy nem leszel képes felfedni a hibáit. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Brian W. Kernighan, 1974

6 © evosoft GmbH Verifikációs alapfogalmak Mihez viszonyítva verifikálunk? Verifikáció: funkciókat tekintve teljesülnek-e a specifikált célok, kritériumok Mit verifikálunk? Az HDL leírás (pre-silicon) funkcionális viselkedését verifikáljuk Mi a verifikáció? A specifikáció nem hibátlan Több szem többet lát: architect != designer != verifikációs mérnök A specifikáció a referencia Mi biztosítja, hogy a specifikáció hibátlan?

7 © evosoft GmbH Verifikáció Gyártás előtt, nem darabonként RTL leíráson Gate level netlistán Tervezési hibák felfedezése Teszt Gyártás után, minden darabon Elkészült ASIC-en Gyártási hibák kiszűrése A tesztelés és a verifikáció közi különbség Verifikációs alapfogalmak

8 © evosoft GmbH Miért van szükség a verifikációra? Mert hibák maradhatnak a termékben A verifikációs feladat A tesztelő mérnökök nem tudnak minden eshetőségre, az állapotok legkülönfélebb együttállására gondolni, ezekre így nincs teszt Hogy lehet olyan eseményeket letesztelni, amik létezését nem is sejtjük? Ne a mérnöknek kelljen kitalálnia az összes verifikálandó esetet Szükség van egy bizonyos fokú automatizációra A megoldás a random verifikáció

9 © evosoft GmbH Verifikációs alapfogalmak Milyen típusú hibákat kell(ene) a verifikációnak felfedeznie? II. Példa: Ha Rádió/MP3 hallgatás közben csörög a telefon, a fülhallgató ugyan elnémul, de az éppen játszott médiát rákeveri a csengőhangra (kihangosítón) Ha a telefonom ASIC lenne… I. Példa: Rádió/MP3 hallgatás közben a fülhallgató kihúzása leállítja a lejátszást 1) rádió hallgatás 2) Kihúz, leáll a lejátszás 3) MP3 hallgatás 4) Kihúz, leáll a rádió, indul a MP3 (kihangosítón) Miért van szükség a verifikációra? Egy példa:

10 © evosoft GmbH A verifikációs feladat Miért van szükség a verifikációra? Egy másik példa:DMARAM start Mem. write final Data IF ? data request grant address write

11 © evosoft GmbH A verifikáció helye az ASIC fejlesztés folyamatában Verifikációs alapfogalmak Specification HDL implementation & Verification Synthesis Layout Production Testing & Validation „Olcsó” „Drága” A verifikáció az ASIC tervezés 70%-át teszi ki Időben Költségben

12 © evosoft GmbH Mibe kerül egy bug? Verifikációs alapfogalmak A bug-os chip költségei HDL-modul chiprendszermegrendelő idő alacsony magas Egy bug javításának költsége Talált bug-ok száma Funkcionális verifikáció Tesztelés szintjei (később) Gyártási költség: Néhány millió $

13 © evosoft GmbH A verifikáció helye az ASIC fejlesztés folyamatában Verifikációs alapfogalmak Koncepció Specifikáció HDL (RTL) leírás Tape out Szilicium ellenőrzés FUNKCIONÁLIS VERIFIKÁCIÓ Azt írtad le amit kigondolta(to)k? Azt kódoltad le (HDL), amit leírtak? ellenőrzés A tape-out úgy működik ahogy kell (HDL)? ellenőrzés A chip működése egyezik a tape-out-tal? Hogyan bizonyosodunk meg a működés helyességéről? Ellenőrzés (verifikáció) több ponton

14 © evosoft GmbH A következő rész témája Verifikációs alapfogalmak A verifikáció és a tesztelés közti különbség fontossága A verifikáció része a flow-ban 70% A bug-ok javítási költsége nő az idő előrehaladtával Több helyen kell ellenőrízni, ezek közül csak egy a funkcionális verifikáció A Verifikáció fajtái Felosztás a szimulációban alkalmazott gerjeszések (stimulusok) fajtái alapjánFelosztás a szimulációban alkalmazott gerjeszések (stimulusok) fajtái alapján Összefoglalva néhány szóban

15 © evosoft GmbH HDL testbench alapú verifikáció A verifikáció fajtái DUV és a verifikációs környezet is HDL Teljesen zárt környezet (a testbench modulnak nincsenek portjai) Ez a megközelítés bonyolult ASIC-ek esetén már nem használható hatékonyan, mert DUV TB Stimulus Testbench TB Monitor Write (0xCAFE, 0x0101) Read(0x2011) a tesztek nehezen olvashatóak megírásuk fárasztó és időigényes túl sok corner case-t kell lefedni a HDL nyelv nem magas szintű tesztelésre való stb...

16 © evosoft GmbH Bug-ok felfedése írányított teszttel A verifikáció fajtái Írányított teszt HDL egy állapota Tesztelni kívánt állapot BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot mindig egy utat jár be csak olyan hibát tud felfedni, amire a mérnök „gondolt” bonyolultabb RTL -> több teszt

17 © evosoft GmbH Bug-ok felfedése random stimulussal A verifikáció fajtái Random teszt HDL egy állapota BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot futás1futás2 rejtett hibákat könyebben, nagyobb valószínűséggel derít fel jobban képes lefedni az előre meghatározott verifikációs teret egy teszt több futás alatt más utakat járhat be “eldugott” állapotok felfedése időigényes

18 © evosoft GmbH Constrained random szimuláció A verifikáció fajtái A verifikációs teret felosztjuk kisebb egységekre A szűkített tartományon belül egy teszt hatékonyabban működik egy teszt több futás alatt más utakat járhat be, de a lehetőségek száma csökkent a verifikációs tér szűkítésével Ki lehet zárni a nem üzemi állapotokat (use case) HDL egy állapota BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot futás1futás2 Állapotok egy tartománya egy tesztre Constrained random szimuláció

19 © evosoft GmbH Tipikus megközelítés A verifikáció fajtái Több tartományt definiálunk, melyekre külön teszteket írunk Vannak állapotok, amelyeknek az elérése random stimulussal, nehézkes, sok időt vesz igénybe. Az ilyen eseteket (corner case) irányított tesztekkel szokás verifikálni. C C HDL egy állapota BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot tesztA futás1 tesztA futás2 Állapotok egy tartománya egy tesztre Corner case tesztB futás2 tesztB futás1 tesztC futás2 tesztC futás1 direkt teszt C Kulcs állapotok

20 © evosoft GmbH A verifikációs környezet felépítése constrained random stimulus esetén A verifikáció fajtái Egyes szélsőséges esetek túl ritkán fordulnának elő A valószínűségek súlyozásával a tesztek viselkedése behatárolható Például a legrövidebb és a leghosszabb ethernet csomag tesztelése verifikációs tool testcase (TC) verifikációs környezet szabályok a < 64 b > 128 constrained solver DUV 0101011010 0101100101 szabályok a > 5 b < 10 stimulus generálás Feltételesen random stimulus használatával a nem használt (nem use case) állapotok kihagyása az értékeket tovább lehet szűkíteni egy kívánt tartományra (TC-kben) A DUV funkcióinak tesztelése felosztható az egyes TC-k között

21 © evosoft GmbH Pszeudó-random generálás: seed futás seed 123456 futás seed 789101 seed 123456 Hogy tudunk megbizonyosodni hogy a felfedezett BUG-ot sikeresen javították? A verifikáció fajtái

22 © evosoft GmbH A következő rész témája A Verifikáció fajtái Testbench alapú szimuláció Irányíott teszt (a testbech alapú szimuláció stimulusa) Verifikáció random stimulussal Feltételes (constrained) random stimulus A Verifikáció teljességének mérése vPlanvPlan CoverageCoverage Check-ekCheck-ek Összefoglalva néhány szóban

23 © evosoft GmbH A verifikációs terv (vPlan) A vPlan a verifikációs folyamat talán legfontosabb dokumentuma. Útmutatást nyújt Környezet felépítése Test scenario Coverage Check A verifikáció teljességének mérése

24 © evosoft GmbH Hogyan kaphatunk visszajelzést a verifikáció teljességéről? A kulcs állapotokra coverage-t gyűjtünk Coverage gyűjtés A verifikáció teljességének mérése A coverage –ra a cél 100%! Regresszió Egy jel változása Feldolgozni kívánt adat hossza Cím tartomány És még sok minden más…

25 © evosoft GmbH Coverage gyűjtés A verifikáció teljességének mérése Coverage gyűjtés… nélkül több 100 (1000) feltétel mellett kellene teszteket futtatni, hogy megfelelőnek érezzük a verifikáció teljességét nélkül soha nem lehetünk arról meggyőződve, hogy mennyire sikerült elérni a verifikációs céljainkat, mivel nincs semmilyen visszajelzés esetén biztosak lehetünk abban, hogy elértük a célunkat HDL egy állapota BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot futás1futás2    “Kulcs” állapotok

26 © evosoft GmbH Automatizált check-ek A check-ek ellenőrzik a DUV működését automatikuasn Az ellenőrizni kívánt funkciók a vPlan-ben vannak definiálva A verifikálni kívánt funkciók Az implementálás módját, azellenőrízni kívánt funkciók check-ekre való felbontását a verifikációs mérnök dönti el Statikus és dinamikus check-ek Statikus, amikor a check-ek folyamatosan aktívak A dinamikus check-ek tesztenként külön kapcsolhatóak A verifikáció teljességének mérése

27 © evosoft GmbH Az automatizált check-ek csoportosítása Négy fő funkcionális szempont szerint lehet a check-eket csoportosítani Kimenetek/bemenetek Az adott bemeneti gerjesztésre a megfelelő kiemeneti válasz érkezik (scoreboard) Rendszerszemlélet Milyen érvényes ill. értelmes gerjsztések érkezhetnek a modult magában foglaló rendszertől Belső működés Néhány kritikus belső állapot ill. logika ellenőrzése Protokol Protokol teljesítése (timing checks) A verifikáció teljességének mérése

28 © evosoft GmbH A lefedettség növelése CDV (coverage driven verification) folyamata Tervezési fázis Eredmény értelmezése Verifikációs környezet Verifikációs terv (vplan) Eredmények (coverage jelentés) Tesztek, Stimulusok Specifikáció olvasás Coverage, check tervezése vplan frissítése Környezet javítása Constraint-ek újradefiniálása A verifikáció teljességének mérése

29 © evosoft GmbH A verifikációs project életciklusa idő magas alacsony Néhány variáció kipróbálása Tesztek írása, automatizált random tesztek, coverage gyűjtés A nehezen elérhető állapotok tesztelése Kezdő fázis Random tesztek futtatása Maradék corner- case-ek lefedése Random tesztek debuggolására fordított energia Lefedettség, a verifikáció során talált bug-ok száma A verifikáció teljességének mérése

30 © evosoft GmbH A Verifikáció teljességének mérése A verifikációs terv (vPlan) fontossága A coverage szerepe a verifikáció sikerében Automatizált check-ek Összefoglalva néhány szóban

31 © evosoft GmbH Black box verifikáció Verifikációs koncepciók A koncepció jellemzői Referencia modell a specifikáció alapján HDL megvalósítás nem ismert Vizsgálat a be/kimeneti jelek alapján Gate-level verifikációnál csak ez használható Problémák DUV Device Under Verification Reference Model ?=?= stimulus Hibás megvalósítás mellett lehet “működőképes” Pl.: belső FIFO mélysége Nehéz megtalálni a pontos hibát, csak a hatásait érzékeljük

32 © evosoft GmbH White box verifikáció Verifikációs koncepciók Tulajdonságok A HDL implementáció ismert (átlátszó struktúra) Előnyök: Hártányok DUV Device Under Verification stimulus A működés vizsgálata a HDL belső jelei alapján Könnyű a kívánt feltételeket megteremteni (pl.: számláló értéke) Implementáció függő – RTL update  testbench változtatása Nincs aktív referencia (csak az írásos specifikáció) Csak azok a funkciók vannak tesztelve, amire a mérnök gondolt

33 © evosoft GmbH Gray box verifikáció Verifikációs koncepciók Tulajdonságok Referencia modell a specifikáció alapján A funkciók HDL megvalósítása részben ismert Kívánt feltételek létrehozása (pl.: számláló értéke) A funkcinális működés vizsgálata Kimeneti- és speciális esetben a belső jelek alapján is Gate level verifikáció esetén a belső jeleket nem használjuk (black box lesz) DUV Device Under Verification Reference Model ?=?= stimulus

34 © evosoft GmbH Referencia modell és check-ek Verifikációs koncepciók Alapvető megfontolások A felhasznált belső jelek helyes értékét, és az azt előállító logikát mindenképpen tesztelni kell Reference Model stimulus ?=?=

35 © evosoft GmbH e-verifikáció

36 © evosoft GmbH e-verifikáció Tartalom A verifikációs környezet Verifikáció az eRM metodológia felhasználásával e-verifikációs komponensek (eVC) Interfész eVC Modul eVC SVE (Specman Verification Environment) eVC-k implementálása az uVM felhasználásával

37 © evosoft GmbH 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

38 © evosoft GmbH Verifikációs környezet

39 © evosoft GmbH A verifikációs környezet DUV Verifikációs környezet Interfész komponens Referencia Modell 10110 01010 ?=  checker coverage Tartalmazza A HDL testbench-et a DUV instance-szal A testbench passzív (clock, reset generátor lehet rajta) A verifikációs komponenseket

40 © evosoft GmbH Alapfogalmak 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

41 © evosoft GmbH Alapfogalmak Újrafelhasználhatóság, eRM my_asic_1 dma_env my_asic_2 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 dma_env my_dma module my_dma module 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

42 © evosoft GmbH Verifikáció az eRM metodológia felhasználásával

43 © evosoft GmbH 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 vagy HDL/ESL model 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…)

44 © evosoft GmbH 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

45 © evosoft GmbH 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. DUV Interfész eVC Modul eVC

46 © evosoft GmbH Verifikáció - eRM eVC könyvtárszerkezet eVC top directory PACKAGE_README.txt e/docs/examples/misc/sve/ 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/ - egy minta környezet forrásfájljait tartalmazza

47 © evosoft GmbH 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 Signal Map Agent Config Signal Map Sequence driver Seq DUV Config – az eVC konfigurációs interfésze. Signal Map (SMP) – portokat tartalmaz, amelyeken keresztül az eVC kapcsolódni tud a DUV-hoz. Synchronizer- portokat tartalmaz, amelyek közösek a design egészére (pl. clock, reset) Synchron izer Sequence driver- unit, amely koordinálja a user-defined teszt szekvenciákat (Seq). Agent - unit, amely egy adott interfészhez tartozó eVC részegységeket tartalmazza (pl.: SPI esetében 2 agent – MASTER,SLAVE)

48 © evosoft GmbH 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 Signal Map Agent Config Signal Map Sequence driver Mon BFM Seq DUV Synchron izer Bus Functional Model (BFM) – unit, amely kommunikál a DUV interfésszel. 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. Coll

49 © evosoft GmbH 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 Synchronizer CLK-RST gen Port CLK/RST eVC CLK/RST events

50 © evosoft GmbH Verifikáció - eRM Sequence, item, driver (ACTIVE) 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

51 © evosoft GmbH Verifikáció - eRM BFM (ACTIVE) 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.)

52 © evosoft GmbH Verifikáció - eRM Collector és Monitor (PASSIVE) Collector - a rá 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

53 © evosoft GmbH Verifikáció - eRM A modul eVC felépítése env_u Config Signal Map Register Map Monitor Reference models Synchronizer Scoreboards DUV Register map – ez a struktúra tartalmazza a DUV regiszter leírását. 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. Scoreboards – speciális monitorozó egység, általában adatok sorrendhelyes összehasonlítására használjuk őket.

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

55 © evosoft GmbH 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…) If_env_u Config SMP Agent Sequence driver Sync Mon BFM mod_env_u Config SMP Register Map Monitor Reference models Sync Scoreboards DUV CLK gen Simple port Event port Method port SVE HDL TB

56 © evosoft GmbH Verifikáció - eRM SVE és virtual sequence driver Az SVE-ben (Simulation and Verification 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-ei 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.

57 © evosoft GmbH A verifikációs környezet megtervezése

58 © evosoft GmbH Környezet tervezése Nem árt néha egy kis kitekintés… Pl. Milyen chipbe és hová kerül az általunk verifikálandó modul? Hát pl. ide! Forrás: www.ti.com

59 © evosoft GmbH Környezet tervezése Kezdjük! Miből induljunk ki? Funkcionális specifikáció Mennyi időnk van a feladat elvégzésére? Mit vár el, illetve kér az ügyfél? A következő lépések… Olvassuk el a specifikációt vPlan elkészítése  TERV ami TARTALMAZZA… az összes tesztelendő funkcióhoz tartozó check leírását a bemeneti gerjesztésekre vonatkozó coverage elemek leírását a szükséges test case-ek leírását A verifikációs környezet koncepciójának kidolgozása (papír+ceruza)  Milyen és mennyi interfészem van  Hova, milyen komponenseket használjak  Stb.

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

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

62 © evosoft GmbH HDL TB SVE Környezet tervezése „Aktív oldal” felépítése: szekvenciák If_env_u Agent Sequence driver BFM mod_env_u DUV If_env_u Address map Agent Sequence driver BFM Agent Sequence driver BFM Virtual sequence driver Pointerek az interface eVC driverekre  Kommunikációs „csatorna” a verifikációs mérnök és a környezet között  Nincs „sequence_item”-je (lásd később) csak szekvenciákat tud kezelni  Nem kapcsolódik semmilyen BFM-hez  Feldolgozza a tesztekben létrehozott szekvenciákat  A szimulátor a szimuláció elején automatikusan elindítja a MAIN beépített virtuális szekvenciát ezt használjuk a tesztek írásánál  A pointerek lehetővé teszik más (nem virtuális) szekvenciák meghívását kényelmes, minden egy helyen

63 © evosoft GmbH 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

64 © evosoft GmbH Környezet tervezése Coverage megtervezése Mire kell coverage-et 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

65 © evosoft GmbH 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, p l.: 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

66 © evosoft GmbH Az e-nyelv

67 © evosoft GmbH 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…

68 © evosoft GmbH e-nyelv Aspektus orientált unit env_u { -- field declaration field_1 : uint; -- empty method declaration method_init_1() is empty; -- method definition method_init_2() is { message(LOW,"Hello world! Function init 2..."); }; unit env_u { -- field declaration field_1 : uint; -- empty method declaration method_init_1() is empty; -- method definition method_init_2() is { message(LOW,"Hello world! Function init 2..."); }; extend env_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() is also { message(LOW,"Hello world! Function init 1 also..."); }; extend env_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() is also { message(LOW,"Hello world! Function init 1 also..."); }; Unit, struct, type, method stb. bárhol kibővíthető a későbbiekben

69 © evosoft GmbH e-nyelv Unit -- creating a unit unit env_u { }; -- creating a unit with inheritance unit env_second_u like ovm_env { }; -- Using the env_u unit extend sys { env : env_u is instance; }; -- creating a unit unit env_u { }; -- creating a unit with inheritance unit env_second_u like ovm_env { }; -- Using the env_u unit extend sys { env : env_u is instance; }; 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

70 © evosoft GmbH e-nyelv Struct típus -- data item struct definition struct data_item_s { }; -- creating data item struct with inheritance struct data_item_second_s like any_sequence_item { }; -- using the struct extend env_u { data : data_item_s; }; -- data item struct definition struct data_item_s { }; -- creating data item struct with inheritance struct data_item_second_s like any_sequence_item { }; -- using the struct extend env_u { data : data_item_s; }; 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

71 © evosoft GmbH e-nyelv További adattí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 Skalár típusok

72 © evosoft GmbH e-nyelv Saját adattípusok, típuskonverzió -- Type definition type direction_t : [ RX ]; -- Type extension extend direction_t : [ TX ]; -- Type definition - the first element value is determined type state_t : [ STATE_0 = 1, STATE_1, STATE_2 ]; -- Type definition type direction_t : [ RX ]; -- Type extension extend direction_t : [ TX ]; -- Type definition - the first element value is determined type state_t : [ STATE_0 = 1, STATE_1, STATE_2 ]; 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 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); -- declarations variable_1 : uint; variable_2 : int; -- operation with type cast variable_1 = variable_2.as_a(uint);

73 © evosoft GmbH e-nyelv Változók deklarálása, értékadás unit env_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; }; unit env_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; };

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

75 © evosoft GmbH e-nyelv Listák unit env_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 var list_item : uint(bits:32) = example.pop0(); -- search for an item in the list list_item = example.first(it == 46); }; unit env_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 var list_item : uint(bits:32) = example.pop0(); -- search for an item in the list list_item = example.first(it == 46); }; Az array típus nem ismert helyette a list típus használható

76 © evosoft GmbH 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.

77 © evosoft GmbH e-nyelv Feltételek 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; }; 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; }; if - else Komplex feltételek írásakor érdemes a zárójelezést használni

78 © evosoft GmbH e-nyelv Feltételek -- type def type state_t : [ STATE_0 = 1, STATE_1, STATE_2 ]; unit bfm_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"; }; -- type def type state_t : [ STATE_0 = 1, STATE_1, STATE_2 ]; unit bfm_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"; }; Case

79 © evosoft GmbH e-nyelv Ciklusok unit env_u { function_x() is { var i : 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; }; unit env_u { function_x() is { var i : 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; }; for

80 © evosoft GmbH e-nyelv Ciklusok unit env_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]; }; unit env_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]; }; for each unit env_u { function_x() is { var exit_cond : bool = FALSE; var i : uint = 0; while(!exit_cond) { if i == 10 { exit_cond = TRUE; }; i += 1; }; unit env_u { function_x() is { var exit_cond : bool = FALSE; var i : uint = 0; while(!exit_cond) { if i == 10 { exit_cond = TRUE; }; i += 1; }; while

81 © evosoft GmbH e-nyelv Ciklusok unit env_u { function_x() is { var exit_cond : bool = FALSE; var i : uint = 0; repeat { if i == 10 { exit_cond = TRUE; }; i += 1; } until(!exit_cond); }; unit env_u { function_x() is { var exit_cond : bool = FALSE; var i : uint = 0; repeat { if i == 10 { exit_cond = TRUE; }; i += 1; } until(!exit_cond); }; repeat – until

82 © evosoft GmbH e-nyelv Method, TCM unit env_u { function_x(param_1 : bool, param_2 : uint) is { var exit_cond : bool = param_1; }; function_y() : uint is empty; function_y() : uint is also { print "hello"; result 0; }; check() is also { -- function call function_x(TRUE,25); var value : uint = function_y(); compute function_y(); }; unit env_u { function_x(param_1 : bool, param_2 : uint) is { var exit_cond : bool = param_1; }; function_y() : uint is empty; function_y() : uint is also { print "hello"; result 0; }; check() is also { -- function call function_x(TRUE,25); var value : uint = function_y(); compute function_y(); }; Method

83 © evosoft GmbH e-nyelv Method, TCM unit env_u { function_x() @clock is { -- wait 20 clock cycles wait[20]; print "Hello"; -- wait for another event wait @reset_e; print "reset occured"; }; run() is also { start function_x(); }; unit env_u { function_x() @clock is { -- wait 20 clock cycles wait[20]; print "Hello"; -- wait for another event wait @reset_e; print "reset occured"; }; run() is also { start function_x(); }; 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

84 © evosoft GmbH e-nyelv Párhuzamos szálak unit env_u { function_x() @clock is { all of { { -- wait 20 clock cycles wait[20]; print "Hello Thread 1"; }; { -- wait 20 clock cycles wait[40]; print "Hello Thread 2"; }; run() is also { start function_x(); }; unit env_u { function_x() @clock is { all of { { -- wait 20 clock cycles wait[20]; print "Hello Thread 1"; }; { -- wait 20 clock cycles wait[40]; print "Hello Thread 2"; }; run() is also { start function_x(); }; Lehetőség van párhuzamosan futtatni kódrészleteket all of – a létrehozott szálak mindegyikének befejeződése után megy tovább first of – a leggyorsabb szál befejeződése után leállítja a többi futó szálat és továbbmegy unit env_u { function_x() @clock is { first of { { -- wait 20 clock cycles wait[20]; print "Hello Thread 1"; }; { -- wait 20 clock cycles wait[40]; print "Hello Thread 2"; }; run() is also { start function_x(); }; unit env_u { function_x() @clock is { first of { { -- wait 20 clock cycles wait[20]; print "Hello Thread 1"; }; { -- wait 20 clock cycles wait[40]; print "Hello Thread 2"; }; run() is also { start function_x(); };

85 © evosoft GmbH e-nyelv Portok simple_port Általában HDL jelekhez történő kapcsolódásra használjuk DE kapcsolódhatunk belső simple_port-okoz is unit signal_map_u like ovm_signal_map { sig_rx : inout simple_port of bit is instance; keep bind(sig_rx, external); keep sig_rx.hdl_path() == “~/Testbench_top/RX“; }; unit signal_map_u like ovm_signal_map { sig_rx : inout simple_port of bit is instance; keep bind(sig_rx, external); keep sig_rx.hdl_path() == “~/Testbench_top/RX“; }; method_port Port, amely method-okat továbbít Lehetővé teszi más nem e-ben íródott verifikációs komponensek kapcsolódását (uVM) event_port Port, amely event-eket továbbít Kapcsolódhatunk vele HDL jelekhez is Lehetővé teszi más nem e-ben íródott verifikációs komponensek kapcsolódását (uVM)

86 © evosoft GmbH e-nyelv event Speciális nyelvi elem, amely az időbeli működés specifikálását és ellenőrzését teszi lehetővé unit monitor_u { !smp : smp_u; -- event for the RX signal rise - checked @every clock rise event event rx_rise_e is rise(smp.sig_rx$)@smp.clock_rise_e; -- defining local event based on another event event monitor_clock_e is cycle @smp.clock_rise_e; -- defining local "empty" event event hello_e; -- defining event based on a condition and other events event rx_rise_and_tx_high_e is true(smp.sig_tx$ == 1) and @hello; main() @monitor_clock_e is { wait @rx_rise_e; -- emitting the hello event emit hello_e; -- if the rx_rise_and_tx_high_e event occurred print out the message if now @rx_rise_and_tx_high_e { print "We can do e-verification!"; }; run() is also { start main(); }; unit monitor_u { !smp : smp_u; -- event for the RX signal rise - checked @every clock rise event event rx_rise_e is rise(smp.sig_rx$)@smp.clock_rise_e; -- defining local event based on another event event monitor_clock_e is cycle @smp.clock_rise_e; -- defining local "empty" event event hello_e; -- defining event based on a condition and other events event rx_rise_and_tx_high_e is true(smp.sig_tx$ == 1) and @hello; main() @monitor_clock_e is { wait @rx_rise_e; -- emitting the hello event emit hello_e; -- if the rx_rise_and_tx_high_e event occurred print out the message if now @rx_rise_and_tx_high_e { print "We can do e-verification!"; }; run() is also { start main(); };

87 © evosoft GmbH e-nyelv event Az event emittálódásakor automatikusan meghívódik egy az event-hez tartozó ún. handler függvény unit monitor_u { !smp : smp_u; -- defining local event based on another event event monitor_clock_e is cycle @smp.clock_rise_e; -- defining local "empty" event event hello_e; main() @monitor_clock_e is { -- emitting the hello event emit hello_e; }; -- event handler on hello_e { print "hello is emitted"; }; run() is also { start main(); }; unit monitor_u { !smp : smp_u; -- defining local event based on another event event monitor_clock_e is cycle @smp.clock_rise_e; -- defining local "empty" event event hello_e; main() @monitor_clock_e is { -- emitting the hello event emit hello_e; }; -- event handler on hello_e { print "hello is emitted"; }; run() is also { start main(); };

88 © evosoft GmbH e-nyelv Generálás, kényszerek unit env_u { -- variable declarations variable_a : uint; variable_b : uint; variable_c : uint; !variable_d : bool; -- soft constraint keep soft variable_a > 10; keep soft variable_a in [15..20]; keep soft variable_b == 100; -- add generation weigth - use only with soft keep soft variable_c == select { 10 : 15; 90 : 115; }; -- the following line will cause a generation error keep variable_d == TRUE; }; unit env_u { -- variable declarations variable_a : uint; variable_b : uint; variable_c : uint; !variable_d : bool; -- soft constraint keep soft variable_a > 10; keep soft variable_a in [15..20]; keep soft variable_b == 100; -- add generation weigth - use only with soft keep soft variable_c == select { 10 : 15; 90 : 115; }; -- the following line will cause a generation error keep variable_d == TRUE; }; A változók értékének generálásakor megadhatunk generálási szabályokat (ún. constraint) Hard – a változó constrain-elése után nem lehet más a kiinduló szabálynak ellentmondó generálási feltétel megadni (keep) Soft – a kezdeti szabályt bármikor felülírhatja egy annak ellentmondó generálási feltétel (keep soft) Általában a változók kezdeti értékének generálásakor soft, az újbóli értékgeneráláskor hard constraineket használunk. A nem generálható változókat ! jellel kell jelölni extend env_u { -- hard constraint keep variable_a < 10; keep variable_b == variable_a; -- the following line will cause a generation "contradiction" error keep variable_a < 10; }; extend env_u { -- constraining in methods function_x() is { -- hard constraint gen variable_b keeping { it in [20..30]; }; extend env_u { -- hard constraint keep variable_a < 10; keep variable_b == variable_a; -- the following line will cause a generation "contradiction" error keep variable_a < 10; }; extend env_u { -- constraining in methods function_x() is { -- hard constraint gen variable_b keeping { it in [20..30]; };

89 © evosoft GmbH e-nyelv Squence, driver -- sequence item definition struct seq_item_s like any_sequence_item { data : uint(bits:32); }; -- Define the sequence sequence master_sequence using item = seq_item_s, created_driver = master_driver_u; -- Define a virtual sequence sequence virtual_sequence using created_driver = virtual_driver_u; -- sequence item definition struct seq_item_s like any_sequence_item { data : uint(bits:32); }; -- Define the sequence sequence master_sequence using item = seq_item_s, created_driver = master_driver_u; -- Define a virtual sequence sequence virtual_sequence using created_driver = virtual_driver_u; Az e-nyelv beépített elemekkel támogatja a sequence és sequence driver generálást A sequence a seq_item_s struktúrát használja Itt nincs dedikált sequence item tehát a sequence virtuális… A sequence makró a következő műveleteket végzi: unit előállítása Egy szekvencia előállítása, amely az adott típusú szekvencia itemeket kezeli

90 © evosoft GmbH e-nyelv Check implementálás expect – csak unitba, structba (struct member-ként) implementálható check that – csak methodban használható unit monitor_u { event ev_01_e; event ev_02_e; variable_x : uint; expect CHECK_01 is @ev_01_e => {~[0..1]; @ev_02_e}@synch.clock_rise else dut_error("ERR_000_CHECK_01 \nTHE EXPECTED ev_02 was MISSING after the ev_01!"); on ev_02_e { check CHECK_02 that (variable_x == 150) else dut_error("ERR_000_CHECK_02 \nThe variable_x doesn't have the expected value which is 150!"); }; unit monitor_u { event ev_01_e; event ev_02_e; variable_x : uint; expect CHECK_01 is @ev_01_e => {~[0..1]; @ev_02_e}@synch.clock_rise else dut_error("ERR_000_CHECK_01 \nTHE EXPECTED ev_02 was MISSING after the ev_01!"); on ev_02_e { check CHECK_02 that (variable_x == 150) else dut_error("ERR_000_CHECK_02 \nThe variable_x doesn't have the expected value which is 150!"); }; dut_error – előre definiált print formátum hibajelzésre, a hibák összesítésénél és ellenőrzésénél csak ezt fogadják el a Cadence tool-ok!

91 © evosoft GmbH e-nyelv Üzenetkezelés message() Log üzenetek kiírására szolgáló függvény Megadhatóak különböző verbosity szintek (NONE, LOW, MEDIUM, HIGH, FULL) A logban megjelenik a szimulációs időpont is out() Log üzenetek kiírására szolgáló függvény Nincsenek verbosity szintek Nem jelenik meg a szimulációs időpont Általában csak kiegészítő információk megjelenítésére használják print Hasonló az out()-hoz Struktúrák kiíratásához célszerű használni unit monitor_u { event ev_01_e; on ev_01_e { message(LOW, "Hello world!"); messagef(LOW, "Hello world! %d 0x%x“, 0x55, 0x55); out("Hello world!"); print "Hello world!"; }; unit monitor_u { event ev_01_e; on ev_01_e { message(LOW, "Hello world!"); messagef(LOW, "Hello world! %d 0x%x“, 0x55, 0x55); out("Hello world!"); print "Hello world!"; };

92 © evosoft GmbH e-nyelv Coverage cover, item és cross kulcsszavak unit monitor_u { event ev_01_e; event ev_02_e; variable_x : uint; variable_y : uint; -- coverage group definition cover ev_01_e is { item cov_var_x : uint = variable_x; }; cover ev_02_e is { -- coverage item definition using ranges item cov_var_y : uint = variable_y using ranges = { range([0..100], "var between 0 and 100"); range([101..200], "var between 101 and 200"); }; item cov_var_x : uint = variable_x; -- cross coverage matrix definition cross cov_var_y, cov_var_x using name = cc__cov_var_y__cov_var_x; -- defining complex coverage item item cov_var_x_compl : uint = variable_x using when = ((variable_x in [400..500]) and (variable_y % 2 == 0)), ignore = (variable_x == variable_y); }; unit monitor_u { event ev_01_e; event ev_02_e; variable_x : uint; variable_y : uint; -- coverage group definition cover ev_01_e is { item cov_var_x : uint = variable_x; }; cover ev_02_e is { -- coverage item definition using ranges item cov_var_y : uint = variable_y using ranges = { range([0..100], "var between 0 and 100"); range([101..200], "var between 101 and 200"); }; item cov_var_x : uint = variable_x; -- cross coverage matrix definition cross cov_var_y, cov_var_x using name = cc__cov_var_y__cov_var_x; -- defining complex coverage item item cov_var_x_compl : uint = variable_x using when = ((variable_x in [400..500]) and (variable_y % 2 == 0)), ignore = (variable_x == variable_y); };

93 © evosoft GmbH Köszönöm a figyelmet!