ASIC verifikáció I . 2011.11.28

1. ASIC verifikációI. 2011.11.28

3. Bemutatkozás

4. 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

5. Bevezetésa funkcionálisverifikációba Tartalom • Verifikációsalapfogalmak • A verifikációfogalma • A tesztelésés a verifikációköztikülönbség • Miért van szükség a verifikációra? • A verifikációszerepeaz ASIC fejlesztésfolyamatában • Mibekerülegy bug? • A verifikációhelyeaz ASIC fejlesztésfolyamatában • Az ASIC tervezéslépéseiidőrendben • A verifikációfajtái • HDL testbenchalapúverifikáció • Bug-ok felfedéseirányítottteszttel • Bug-ok felfedéserandumstimulussal • Constrained random szimuláció • Tipikusmegközelítés • A verifikációskörnyezetfelépítése constrained random stimulus esetén • Pszeud-random generálás - seed

6. Bevezetés a funkcionálisverifikációba Tartalom • A verifikációteljességénekmérése • A verifikációsterv (vPan) • Coverage gyűjtés • Automatizált check-ek • Azautomatizált check-ekcsoportosítása • A lefedettségnövelése • A verifikációsprojektéletciklusa • A verifikációskoncepciók • ASIC-ekverifikációsszintjei • Black box verifikáció • White box verifikáció • Gray box verifikáció • Melyiketválasszuk? BB,WB, GB? • A verifikációskörnyezet • Modul vs. rendszerszintűverifikáció • Példák…

7. Bevezetés a funkcionálisverifikációba Tartalom • Verifikációsésszimulációs tool-ok • Delta cycle • Delta cycle - példa • Verifikációs tool ésszimulátor • Kiegészítőmódszerek • Code coverage (szerepe, fajtái) • Összeköttetésekvizsgálata (formálisverifikáció)

8. Bevezető Mottó A hibakereséskétszerolyannehézfeladat, mint maga a kódmegírása. Így, ha a lehetőlegjobbtudásodszerintírtad meg a kódot, azmégnemfeltétlenüljelentiazt, hogyképesvagyfelfedni 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

9. Verifikációsalapfogalmak A verifikációfogalma • Mi a “verifikáció” jelentése? • Szótárijelentése: igazolás • Gyakorlatijelentése: Az a folyamat, melynek során a mérnökök megbizonyosodnak arról, hogy a modul képes ellátni specifikált funkcióit. • Mitverifikálunk? • Miaz RTL modell (pre-silicon) funkcionálisviselkedésétverifikáljuk. Ez a folyamatnemtesztelés (amiprototípus IC,-n FPGA-n történik – post-silicon) • Mihezviszonyítvaverifikálunk? • A “golden reference”-hezképest: ez a specifikácó (szövegesdokumentum) * systemC • Mibiztosítja, hogy a specifikációhibátlan? • A specifikációnemhibátlan • Többszemtöbbetlát: architect != designer != verifikációs mérnök

10. Verifikációsalapfogalmak A tesztelésés a verifikációközikü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

11. Verifikációsalapfogalmak Miért van szükség a verifikációra? Milyentípusúhibákatkell(ene) a verifikációnakfelfedeznie? • Ha a telefonom ASIC lenne… • I. Példa: • Rádió/MP3 hallgatásközben a fülhallgatókihúzásaleállítja a lejátszást • 1) MP3 hallgatás • 2) Kihúz, leáll a lejátszás • 3) Rádióhallgatás • 4) Kihúz, leállaz MP3, indul a rádió (kihangosítón) • II. Példa: • Ha Rádió/MP3 hallgatásközbencsörög a telefon, a fülhallgatóugyanelnémul, de azéppenjátszottmédiátrákeveri a csengőhangra (kihangosítón)

12. Verifikációsalapfogalmak Miért van szükség a verifikációra? • Miértmaradhattakilyenhibák a termékben? • A tesztelő / verifikációsmérnökökvalószínűlegnemgondoltak a különféleállapotokpontilyenegyüttállására, nem volt ráteszt • Hogylehetolyaneseményeketletesztelni, amiklétezésétnem is sejtjük? • Ne a mérnöknekkelljenkitalálniaazösszesverifikálandóesetet • Szükség van egybizonyosfokúautomatizációra • A megoldás a random verifikáció

13. Verifikációsalapfogalmak A verifikációszerepeaz ASIC 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 Nagyon fontos, hiszen a gyártás drága, és a kész chip-ben talált hiba respin-nel jár.

14. Verifikációsalapfogalmak Mibekerülegy bug? • A bug-os chip költségei • A tervezésifáziselejénolcsó a javítás (n x mérnökóraára) • Később, rendszerszintűtesztelésnélsokidő • Prototípus IC-ben: respin (a maszkok ismételt legyártása) • Piacradobásután: milliók ($) (presztizs veszteség) 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ő

15. 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

16. Verifikációsalapfogalmak Az ASIC tervezéslépéseiidőrendben • Time to market – A fejlesztésiidőtredukálnikell • A párhuzamosanvégezhetőfolyamatokatidőben el kellkezdeni • A HDL implementációés a funkcionálisverifikációsemegymástkövetőfolyamatok • A SystemCmodellekbevezetésével a funkcionálisverifikációelőbbelkezdődhet, mint a HDL implementáció • A rendszerműködésénekkoncepciójátlehetígyvizsgálni Specifikáció HDL (RTL) implementáció SystemC modell HDL (RTL) implementáció Modul Chip (top level) Modul Chip (top level) Funkcionális verifikáció Funkcionális verifikáció Modul Chip (top level) Gate level Modul Chip (top level) Gate level System level System level Modell idő

17. Összefoglalvanéhányszóban • Verifikációsalapfogalmak • A verifikációés a tesztelésköztikülönbségfontossága • A verifikációrésze a flow-ban 70% • A bug-ok javításiköltségenőazidőelőrehaladtával • Többhelyenkellellenőrízni, ezekközülcsakegy a funkcionálisverifikáció A következőrésztémája • A Verifikációfajtái • Felosztás a szimulációbanalkalmazottgerjeszések(stimulusok) fajtáialapján

18. 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úlsok corner case-t kelllefedni • a HDL nyelvnemmagas szintű tesztelésre való • stb...

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

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

21. A verifikációfajtái Constrained random szimuláció • Constrained random szimuláció • 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 • Ki lehetzárni a nemüzemiállapotokat(use case) futás2 futás1 HDL egy állapota BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot Állapotok egy tartományaegy tesztre

22. 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

23. 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ött1

24. A verifikációfajtái Pszeudó-random generálás: seed • Hogytudunkmegbizonyosodnihogy a felfedezett BUG-otsikeresenjavították? • Újrafuttatjuk a tesztet • A véletlenteszthogyantudjabefutniugyanaztazutat? • Megoldás: kiindulópont a véletlenszámgenerátornak: seed • Minden futtatottteszthezegy seed • Ha a környezetnemváltozik, a seed ugyanaztazutateredményezni futásseed123456 futásseed789101 seed123456

25. Ö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

26. A verifikációteljességénekmérése A verifikációsterv (vPlan) • A vPlan a verifikációsfolyamattalánlegfontosabbdokumentuma. • Útmutatástnyújt • A verifikációskörnyezetépítéséhez • Milyenforgatókönyvekmenténkelltesztelni (test scenario) • A lefedettségméréséhezszükségeskulcsállapotok (coverage)megállapítása • Milyenfunkciókatkellfeltétlenülellenőrizni (check) • A verifikációstervnemállandó – folyamatosanváltozódokumentum

27. A verifikációteljességénekmérése C C Coverage gyűjtés • Hogyan kaphatunk visszajelzést a verifikáció teljességéről? • A kulcs állapotokra coverage-t gyűjtünk • Megnézzük, hogyelértük-e azadottállapotot • Miklehetnekezekaz “állapotok”? • Egyjelváltozása • Feldolgoznikívántadathossza • Címtartomány • Ésmégsokmindenmás… • A coverage étékének a verifikációvégén 100%-osnakkelllennie • Eztnemegytesztfuttatásávalkellelérni, hanemregresszióval • A regressziótöbbteszt (tesztenkénttöbbszöri) futtatásátjelenti • A verifikációs tool azegészregresszióalattgyűjti a coverage-t

28. 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

29. A verifikációteljességénekmérése Automatizált check-ek • A check-ekellenőrzik a DUV működését • Míg a testbenchalapúverifikációnál a mérnökértelmezte a DUV gerjesztésreadottválaszát, addigitt… • A kiértékelésautomatikusantörténik • Azellenőriznikívántfunkciók a vPlan-ben vannakdefiniálva • Nemmindenegyes check külön-külön, hanem • A verifikálnikívántfunkciók • Azimplementálásmódját, azellenőríznikívántfunkciók check-ekrevalófelbontás a 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

30. 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)

31. 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)

32. 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

33. Ö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 • Verifikációskoncepciók • Felosztás a design hierachiaalapján • Felosztás a verifikációskörnyezetfelépítésealapján • Referenciamodell • Egyébmegfontolások, gyakorlaipéldák

34. 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

35. 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

36. 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

37. DUVDevice Under Verification ?= stimulus Reference Model Verifikációskoncepciók Black boxverifikáció • A koncepciójellemzői • Referenciamodellspecifikációalapján történő implementálása • A funkciók HDL megvalósításanemismert • Működésmegfelelőségénekvizsgálata a 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

38. 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: • A működésvizsgálata a HDL belsőjeleialapján • Könnyű a kívántfeltételeketmegteremteni (pl.: számlálóértéke) • Hártányok • Implementációfüggő – RTL update  testbenchváltoztatása • Nincsaktívreferencia (csakazírásosspecifikáció) • Csakazok a funkciókvannaktesztelve,amire a mérnökgondolt

39. 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)

40. 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

41. 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

42. Verifikációskoncepciók A verifikációskörnyezet • A verifikációskörnyezet… • Felépítseszigorúmódszertantkövet (eRM, OVM, UVM) • Azújrafelhasználhatóság, újrahasznosításelvénkell, hogyműködjön • Verifikációskomponenseket (verification component - uVC) tartalmaz (modul, interfész) checker Referencia Modell Verifikációskörnyezet coverage ?=  DUV Interfészkomponens 1011001010

43. Verifikációskoncepciók Modul vs. rendszerszintűverifikáció • Top-level (chip) szintűverifikációesetén • A DUV-otnem a környezethajtja meg, hanem a valós HDL • 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 checker Verifikációskörnyezet coverage ?=  Referenciamodell Interfészkomponens HDL modul(aktív) HDL modul DUV 1011001010

44. Verifikációskoncepciók Modul vs. rendszerszintű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

45. Verifikációskoncepciók Modul vs. 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

46. A helyesmegközelítéskiválasztása Példák a különböző koncepciókra • Module: Incoming Data Processor (IDP) • Tartalmaz két szubmodult • Job Analyzer (JA) • A busz-ról érkezett csomagot dolgozza fel • Kinyeri az adatod, címet (stb…) • Job Controller (JC) • Levezényli a memória írást ill. olvasást • A kettő közötti kapcsolatot vezérlő jelek teremtik meg • read jel logikai 1értéke: olvasás indítása • write jel logikai 1 értéke: írás indítása BUS IDP Memória read JA JC write data

47. A helyesmegközelítéskiválasztása Példa 1 • Megközelítés • Random verifikáció • Modul szint • Black box Ref.m ?= IDP • Koncepció értékelése • A verifikáció sikeressége függ attól, hogy • A megfelelő kulcsállapotokat sikerült-e definiálni • Sikeresentudtuk-e a check-eketimplementálni • A tesztek során mennyire sikerült megvalósítani a teszt forgatókönyveket (TC-k) • Hibalehetőségek • Valamilyen funkciót kihagytunk a tesztből (előző pontok nem teljesültek) • A modulmindenfunkciójátteszteltük, de a belsőjelekbizonyoskombinácija a tesztekalattnemáltelő (irányítotttesztkellhet)

48. A helyesmegközelítéskiválasztása Példa 2 • Random verifikáció • Modul szint • Gray box • Tegyük fel, hogy a read és a write jelek előállítása a referencia modellel bonyolult. Ezért úgy döntünk, hogy figyeljük a modul belső jeleit. • Check-ünk: • Ha a read aktív és az IDP a megfelelő címre ír, akkor OK. • Ha a write aktív és az IDP a beérkezett adatot a megfelelő címre írja, akkor OK Ref.m ?= IDP read Értékelés: JA JC write • Mi van, ha a write „beragad” • A felhasznált belső jelek helyes működését mindig verifikálni kell! data ?=

49. A helyesmegközelítéskiválasztása Példa 3 (példa 2 jómegoldása) • Random verifikáció • Modul szint • Gray box • A jó megoldás:A felhasználtbelsőjelekműködésénekalaposellenőrzése Ref.m ?= IDP read ?= JA JC write ?= data

50. A helyesmegközelítéskiválasztása Példa 4 • Random verifikáció • Szint: Rendszer / Chip (ezen a példán a BUS nélkül) • Adat-út tesztek • Beírunk a memóriába • Visszaolvassuk az adatot • Egyszerűbb moduloknál alkalmazható • Komplexebbek esetén a modul szintű verifikáció elvárt lépés • Előző példa problémája: hibás FSM, beragadt jel ?= Mem. BUS IDP