ASIC verifikáció I . 201 3 . 11.18

1. ASIC verifikációI. 2013.11.18

2. Bemutatkozás

3. Bevezetésa funkcionális verifikációba Tartalom • 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 randumstimulussal • 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. Bevezetés a funkcionális verifikációba Tartalom • 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 • A verifikációs koncepciók • ASIC-ek verifikációs szintjei • Black box verifikáció • White box verifikáció • Gray box verifikáció • Melyiket válasszuk? BB, WB, GB? • A verifikációs környezet • Modul vs. rendszer szintű verifikáció

5. Bevezető Mottó 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. Verifikációs alapfogalmak Mi a verifikáció? • 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 Mihez viszonyítva verifikálunk? • A specifikáció a referencia • Mi biztosítja, hogy a specifikáció hibátlan? • A specifikáció nem hibátlan • Több szem többet lát: architect != designer != verifikációs mérnök

7. Verifikációs alapfogalmak A tesztelés és a verifikáció közi különbség • 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

8. A verifikációs feladat Miért van szükség a verifikációra? • Mert hibák maradhatnak a termékben • 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. Verifikációs alapfogalmak Miért van szükség a verifikációra? Egy példa: Milyen típusú hibákat kell(ene) a verifikációnak felfedeznie? • 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) • 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)

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

11. Verifikációsalapfogalmak A verifikációhelye azASIC fejlesztésfolyamatában • A verifikációaz ASIC tervezés 70%-áttesziki • Időben • Költségben Specification HDL implementation& Verification „Olcsó” Synthesis Layout Production „Drága” Testing & Validation

12. Verifikációsalapfogalmak Mibekerülegy bug? Gyártási költség:Néhány millió $ • A bug-os chip költségei Funkcionálisverifikáció magas Egy bug javításánakköltsége chip rendszer megrendelő VHDL-modul Talált bug-ok száma Tesztelésszintjei(később) alacsony idő

13. Verifikációsalapfogalmak A verifikációhelyeaz ASIC fejlesztésfolyamatában • Hogyanbizonyosodunk meg a működéshelyességéről? • Ellenőrzés (verifikáció) többponton Koncepció ellenőrzés Azt írtad le amit kigondolta(to)k? Specifikáció Azt kódoltad le (HDL), amit leírtak? FUNKCIONÁLISVERIFIKÁCIÓ HDL (RTL) leírás A tape-out úgy működik ahogy kell (HDL)? ellenőrzés Tape out A chip működése egyezika tape-out-tal? ellenőrzés Szilicium

14. Összefoglalva néhány szóban • 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 következő rész témája • A Verifikáció fajtái • Felosztás a szimulációban alkalmazott gerjeszések(stimulusok) fajtái alapján

15. A verifikációfajtái HDL testbenchalapú verifikáció • DUV és a verifikációskörnyezet is HDL • Teljesenzártkörnyezet (a testbench modulnak nincsenek portjai) Testbench Write (0xCAFE, 0x0101) DUV TB Stimulus Read(0x2011) TB Monitor • Ez a megközelítésbonyolult ASIC-ekeseténmárnemhasználhatóhatékonyan, mert • a teszteknehezenolvashatóakmegírásukfárasztóésidőigényes • túlsokcorner case-t kelllefedni • a HDL nyelvnemmagas szintű tesztelésre való • stb...

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

17. A verifikációfajtái Bug-ok felfedése random stimulussal Random teszt futás1 futás2 HDL egy állapota BUG-os állapot • 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” állapotokfelfedéseidőigényes Nem “üzemi” állapot A teszt által bejárt állapot

18. A verifikációfajtái Constrained random szimuláció Constrained random szimuláció futás2 futás1 HDL egy állapota BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot Állapotok egy tartományaegy tesztre • A verifikációsteretfelosztjukkisebbegységekre • A szűkítetttartományonbelülegyteszthatékonyabbanműködik • egy teszt több futás alatt más utakat járhat be, de a lehetőségekszámacsökkent a verifikációstérszűkítésével • Kilehetzárni a nemüzemiállapotokat(use case)

19. A verifikációfajtái Tipikusmegközelítés • Többtartománytdefiniálunk, melyekrekülönteszteketírunk • Vannakállapotok, amelyeknekazelérése random stimulussal, nehézkes, sokidőtveszigénybe. Azilyeneseteket (corner case) irányítotttesztekkelszokásverifikálni. tesztBfutás1 tesztBfutás2 tesztAfutás2 tesztAfutás1 direktteszt Corner case C HDL egy állapota C C BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot Állapotok egy tartományaegy tesztre Kulcs állapotok tesztCfutás1 tesztCfutás2

20. verifikációskörnyezet verifikációs tool 01010110100101100101 szabályoka < 64 b > 128 constrainedsolver stimulusgenerálás DUV testcase (TC) szabályoka > 5 b < 10 A verifikációfajtái A verifikációskörnyezetfelépítése constrained random stimulus esetén • 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 • Feltételesen random stimulus használatával • a nemhasznált (nem use case) állapotokkihagyása • azértékekettovább lehet szűkíteni egykívánttartományra(TC-kben) • A DUV funkcióinak tesztelése felosztható az egyes TC-k között

21. A verifikációfajtái Pszeudó-random generálás: seed Hogytudunkmegbizonyosodnihogy a felfedezett BUG-otsikeresenjavították? futásseed123456 futásseed789101 seed123456

22. Összefoglalvanéhányszóban • A Verifikációfajtái • Testbenchalapúszimuláció • Irányíottteszt (a testbechalapúszimulációstimulusa) • Verifikáció random stimulussal • Feltételes (constrained) random stimulus A következőrésztémája • A Verifikációteljességénekmérése • vPlan • Coverage • Check-ek

23. A verifikációteljességénekmérése A verifikációsterv (vPlan) • A vPlan a verifikációsfolyamattalánlegfontosabbdokumentuma. • Útmutatástnyújt • Környezet felépítése • Test scenario • Coverage • Check

24. A verifikációteljességénekmérése Coverage gyűjtés • Hogyan kaphatunk visszajelzést a verifikáció teljességéről? • A kulcs állapotokra coverage-t gyűjtünk • Egyjelváltozása • Feldolgoznikívántadathossza • Címtartomány • És mégsokmindenmás… • A coverage –ra a cél 100%! • Regresszió

25. A verifikációteljességénekmérése Coverage gyűjtés • Coverage gyűjtés… • nélkültöbb 100 (1000) feltételmellettkelleneteszteketfuttatni, hogymegfelelőnekérezzük a verifikációteljességét • nélkülsohanemlehetünkarról meggyőződve, hogymennyiresikerültelérni a verifikációscéljainkat, mivelnincssemmilyenvisszajelzés • eseténbiztosaklehetünkabban, hogy elértük a célunkat futás1 futás2   HDL egy állapota BUG-os állapot   Nem “üzemi” állapot A teszt által bejárt állapot  “Kulcs” állapotok

26. A verifikációteljességénekmérése Automatizált check-ek • A check-ekellenőrzik a DUV működésétautomatikuasn • Azellenőriznikívántfunkciók a vPlan-ben vannakdefiniálva • A verifikálnikívántfunkciók • Azimplementálásmódját, azellenőríznikívántfunkciók check-ekrevalófelbontásáta verifikációsmérnökdönti el • Statikusésdinamikus check-ek • Statikus, amikor a check-ekfolyamatosanaktívak • A dinamikus check-ektesztenkéntkülönkapcsolhatóak

27. A verifikációteljességénekmérése Azautomatizált check-ekcsoportosítása • Négyfőfunkcionálisszempontszerintlehet a check-eketcsoportosítani • Kimenetek/bemenetek • Azadottbemenetigerjesztésre a megfelelőkiemenetiválaszérkezik (scoreboard) • Rendszerszemlélet • Milyenérvényes ill. értelmesgerjsztésekérkezhetnek a modultmagábanfoglalórendszertől • Belsőműködés • Néhánykritikusbelsőállapot ill. logikaellenőrzése • Protokol • Protokolteljesítése (timing checks)

28. A verifikációteljességénekmérése A lefedettségnövelése CDV (coverage driven verification) folyamata Coverage, check tervezése Specifikációolvasás Tervezésifázis Verifikációsterv (vplan) Verifikációskörnyezet Tesztek,Stimulusok vplan frissítése Környezetjavítása Constraint-ekújradefiniálása Eredményértelmezése Eredmények(coverage jelentés)

29. A verifikációteljességénekmérése A verifikációs project életciklusa Random tesztek futtatása Kezdő fázis Maradék corner-case-ek lefedése Lefedettség, a verifikációsorántalált bug-ok száma magas Random tesztekdebuggolásárafordítottenergia alacsony idő Néhányvariációkipróbálása Tesztekírása, automatizált random tesztek, coverage gyűjtés A nehezenelérhetőállapotoktesztelése

30. Összefoglalvanéhányszóban • A Verifikációteljességénekmérése • A verifikációsterv (vPlan) fontossága • A coverage szerepe a verifikációsikerében • Automatizált check-ek A következőrésztémája (opcionális) • Verifikációskoncepciók • Felosztás a design hierachiaalapján • Felosztás a verifikációskörnyezetfelépítésealapján

31. Verifikációskoncepciók ASIC-ekverifikációsszintjei • A verifikációsszintekkiválasztása • Nemkellmindenszinten • Komplexrendszerekesetébenkétszintenszokásverifikálni Comprehensive functional verification the complete industry cycle - szerző: Bruce Wile,John C. Goss,Wolfgang Roesner

32. Verifikációskoncepciók ASIC-ekverifikációsszintjei • Designer szint (macro) • Általábanaz RTL designer végzi • Egyszerű, a design-kód megfelel-e azalapvetőkövetelményeknek (lefordul-e, stb…) • Formálisverifikáció • HDL testbenchalapúegyszerűverifikáció • Modulszint • Komplexrendszereknélszükséges • Egylogikaiegységteljesfunkcionálisvizsgálata • Megléteelőfeltételeegymagasabbszintűverifikációnak (pl.: chip, system) Comprehensive functional verification the complete industry cycle - szerző: Bruce Wile,John C. Goss,Wolfgang Roesner

33. Verifikációskoncepciók ASIC-ekverifikációsszintjei • Az, hogymelyikszinteteketkellválasztanifügg… • A modul, ill. a rendszerbonyolultságától • A modulfontosságától, a rendszerbenbetöltöttszerepétől • A specifikácitól, hogytartalmaz-e külön a modulraleírást, vagy a modulfunkióitcsakrendszerszintenírja le Comprehensive functional verification the complete industry cycle - szerző: Bruce Wile,John C. Goss,Wolfgang Roesner

34. DUVDevice Under Verification ?= stimulus Reference Model Verifikációskoncepciók Black boxverifikáció • A koncepciójellemzői • Referenciamodella specifikációalapján • HDL megvalósításnemismert • Vizsgálata be/kimenetijelekalapján • Gate-level verifikációnál csak ez használható • Problémák • Hibásmegvalósításmellettlehet “működőképes” • Pl.: belső FIFO mélysége • Nehézmegtalálni a pontoshibát, csak a hatásaitérzékeljük

35. DUVDevice Under Verification stimulus Verifikációskoncepciók White boxverifikáció • Tulajdonságok • A HDL implementációismert (átlátszóstruktúra) • Előnyök: • Hártányok • A működésvizsgálata a HDL belsőjeleialapján • Könnyű a kívántfeltételeketmegteremteni (pl.: számlálóértéke) • Implementációfüggő – RTL update  testbenchváltoztatása • Nincsaktívreferencia (csakazírásosspecifikáció) • Csakazok a funkciókvannaktesztelve,amire a mérnökgondolt

36. DUVDevice Under Verification ?= stimulus Reference Model Verifikációskoncepciók Gray boxverifikáció • Tulajdonságok • Referenciamodell a specifikációalapján • A funkciók HDL megvalósításarészbenismert • Kívántfeltételeklétrehozása (pl.: számlálóértéke) • A funkcinálisműködésvizsgálata • Kimeneti- ésspeciálisesetben a belsőjelekalapján is • Gate level verifikációesetén a belsőjeleketnemhasználjuk (black box lesz)

37. Verifikációskoncepciók Melyiketválasszuk? BB, WB, GB? • Ideálisverifikáció • Black Box megközelítés • Teljesverifikáció • A logikamegfelelőenműködik a bemenetekösszeskombinációjára • A kimenetijelekellenőrzéseazösszesesetben • A teljesverifikációalkalmazásanempraktikusegykomplexrendszerfunkcionálisverifikációjánakmindenlépésében • Azelvekazonbenmindigirányadóak! Akkormelyikmegközelítéstkellválasztani? • Azt, amelyikazadottfeladatra a leginkábbmegfelelő • A legtöbbkörnyezettipikusan GB

38. Verifikációs koncepciók Referenciamodellés check-ek • Alapvetőmegfontolások • A felhasználtbelsőjelekhelyesértékét, ésazaztelőállítólogikátmindenképpentesztelnikell ?= stimulus Reference Model

39. Verifikációskoncepciók A verifikációskörnyezet • A verifikációskörnyezet • Szigorúmódszertan • Újrafelhasználhatóság • Verifikációskomponensek (modul, interfész) checker Referencia Modell Verifikációskörnyezet coverage ?=  DUV Interfészkomponens 1011001010

40. Kérdés? Most jönne: Modul szintű és rendszer szintű verifikáció. Idő?

41. Verifikációskoncepciók Modul vs. Top-level szintűverifikáció • Top-level (chip) szintűverifikációesetén • A DUV-otnem a környezethajtja meg, hanem a valósHDL • A DUV-otegykívántállapotbacsakindirektmódon (a meghajtó HDL modulonkeresztül) leheteljuttatni • Bonyolultabbtesztekreés, nagyobbrendszerismeretre van szükség • A DUV esetlegmármodulszintenverifikálva volt

42. Verifikációskoncepciók Modul szint checker Referencia Modell Verifikációskörnyezet coverage ?=  ?=  Referenciamodell Passzív interfészkomponens Chip szint DUV HDL modul(aktív) HDL modul DUV Aktív interfészkomponens 1011001010 1011001010

43. Verifikációskoncepciók Top level szintűverifikáció • Top-level (chip) szintűverifikációesetén • A szubmodulokviselkedésétkevésbékimerítőenvizsgáljuk • A lényeg a teljes chip működésénekvizsgálata (pin-ekmeghajtása) ?= ?= ?=  toplevel HDL DUV HDL DUV HDL HDL

44. Verifikációskoncepciók Rendszerszintűverifikáció • Rendszer (system level) szintűverifikációesetén • Kizárólag a rendszerszintűműködésvizsgálatáraöszpontosítunk • A lényeg, hogyhogyanműködikkét (vagytöbb) chip együtt ?= ?=  ?= ?= ?= toplevel1 toplevel2 HDL HDL DUV DUV HDL HDL DUV DUV HDL HDL HDL HDL

45. Verifikációskoncepciók Újrafelhasználhatóság (reuse) • A funkcionálisverifikációmódszertanánakegyikalapjaazújrafelhasználhatóság. • Lényege, hogyegymodulverifikációskörnyezetétpluszmunkanélkültudjukhasználniegymásik ASIC esetén is my_asic_1 my_asic_2 dma_env dma_env my_dma module my_dma module

46. Előretekintés Az e-verifikáció • Néhányszóaz e-verifikáció-ról • Alapjaaz e-nyelv (aspektusorientált) • StrukúrájátazeRM, oVM, uVMhatározza meg • Coding guideline • Mappaszerkezet • Elnevezésiszabályok, stb… • Az e-verifikációhoztartozó tool a Specman • Fejlesztője a Cadence • A Specmannemtartalmazza a szimulátort, használható • Modelsim (Mentor) • IES (Incisive Enterprise Simulator - Cadence)

47. Összefoglalvanéhányszóban Coverage (Metric) drivenfunctionalverification A következőrésztémája Formális verifikáció Balotai Péter

48. Formális verifikáció Formális verifikáció dióhéjban Mit verifikáljunk formálisan? Assertion-vezérelt szimuláció DUT inicializálása Automatkus check-ek PSL példák Cadence IEV tool áttekintés Miről lesz szó?

49. Formális verifikáció dióhéjban Verification • Mi is az a formális verifikáció? • Egy digitális rendszer helyes működésének vizsgálata formális matematikai módszerek segítségével, egy adott formális specifikációra való tekintettel. Simulation FormalVerification Assertion Driven Sim. Directed stimulus Constrained random st. Property checking Equivalence checking vektorok nincs szimuláció nincsenek vektorok

50. Formális verifikáció dióhéjban Alapja a property • Egyértelmű, félreérthetetlen kijelentés a digitális rendszer és annak környezete működéséről • Önmagában nincs gyak. értelme, de felhasználható, mint • Constraint: a környezet működésére vonatkozó szabály • Assertion: a DUT működésére vonatkozó szabály • Coverage: állapotok elérhetőségére vonatkozó megállapítás FIFO can’t be full and empty at the same time Empty must be asserted until a write occurs No read when empty FIFO clk Write Read Full Empty