Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

© evosoft GmbH ASIC verifikáció I. 2011.11.28. © evosoft GmbH Bemutatkozás ASIC verifikáció Stubna Ágoston ASIC fejlesztő / verifikációs mérnök evosoft.

Hasonló előadás


Az előadások a következő témára: "© evosoft GmbH ASIC verifikáció I. 2011.11.28. © evosoft GmbH Bemutatkozás ASIC verifikáció Stubna Ágoston ASIC fejlesztő / verifikációs mérnök evosoft."— Előadás másolata:

1 © evosoft GmbH ASIC verifikáció I

2 © evosoft GmbH Bemutatkozás ASIC verifikáció Stubna Ágoston ASIC fejlesztő / verifikációs mérnök evosoft Hungary Kft. BME-VIK mikró / CAT (2008)

3 © evosoft GmbH Bemutatkozás

4 © evosoft GmbH Alapfogalmak (ismétlés) Modul szintű, constrained random, e-verifikáció A verifikációs szintek kivá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 © 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 Az ASIC tervezés lépései időrendben 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 - seed

6 © 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 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ó Példák…

7 © evosoft GmbH Tartalom Bevezetés a funkcionális verifikációba Verifikációs és szimulációs tool-ok Delta cycle Delta cycle - példa Verifikációs tool és szimulátor Kiegészítő módszerek Code coverage (szerepe, fajtái) Összeköttetések vizsgálata (formális verifikáció)

8 © 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 még nem feltétlenül jelenti azt, hogy képes vagy 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

9 © evosoft GmbH A verifikáció fogalma Verifikációs alapfogalmak Mi a “verifikáció” jelentése? Szótári jelentése: igazolás Gyakorlati jelenté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. Mit verifikálunk? Mi az RTL modell (pre-silicon) funkcionális viselkedését verifikáljuk. Ez a folyamat nem tesztelés (ami prototípus IC,-n FPGA-n történik – post- silicon) Mihez viszonyítva verifikálunk? A “golden reference”-hez képest: ez a specifikácó (szöveges dokumentum) * systemC 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

10 © 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

11 © 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) MP3 hallgatás 2) Kihúz, leáll a lejátszás 3) Rádió hallgatás 4) Kihúz, leáll az MP3, indul a rádió (kihangosítón) Miért van szükség a verifikációra?

12 © evosoft GmbH Miért van szükség a verifikációra? Verifikációs alapfogalmak Miért maradhattak ilyen hibák a termékben? A tesztelő / verifikációs mérnökök valószínűleg nem gondoltak a különféle állapotok pont ilyen együttállására, nem volt rá 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ó

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

14 © evosoft GmbH Mibe kerül egy bug? Verifikációs alapfogalmak A bug-os chip költségei A tervezési fázis elején olcsó a javítás (n x mérnök óra ára) Később, rendszer szintű tesztelésnél sok idő Prototípus IC-ben: respin (a maszkok ismételt legyártása) Piacra dobás után: milliók ($) (presztizs veszteség) VHDL-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)

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

16 © evosoft GmbH HDL (RTL) implementáció Funkcionális verifikáció ModulChip (top level) ModulChip (top level)Gate level System level Az ASIC tervezés lépései időrendben Verifikációs alapfogalmak Time to market – A fejlesztési időt redukálni kell A párhuzamosan végezhető folyamatokat időben el kell kezdeni A HDL implementáció és a funkcionális verifikáció sem egymást követő folyamatok A SystemC modellek bevezetésével a funkcionális verifikáció előbb elkezdődhet, mint a HDL implementáció A rendszer működésének koncepcióját lehet így vizsgálni Specifikáció SystemC modell HDL (RTL) implementáció Funkcionális verifikáció ModulChip (top level) Modul Chip (top level) Gate level System level Modell idő

17 © 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

18 © 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 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... DUV TB Stimulus Testbench TB Monitor Write (0xCAFE, 0x0101) Read(0x2011)

19 © evosoft GmbH Bug-ok felfedése írányított teszttel A verifikáció fajtái Í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öbb teszt HDL egy állapota Tesztelni kívánt állapot BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot

20 © evosoft GmbH Bug-ok felfedése random stimulussal A verifikáció fajtái 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” állapotok felfedése időigényes HDL egy állapota BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot futás1futás2

21 © evosoft GmbH Constrained random szimuláció A verifikáció fajtái 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ó 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)

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

23 © 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 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ött1 verifikációs tool testcase (TC) verifikációs környezet szabályok a < 64 b > 128 constrained solver DUV szabályok a > 5 b < 10 stimulus generálás

24 © evosoft GmbH Pszeudó-random generálás: seed futás seed futás seed seed Hogy tudunk megbizonyosodni hogy a felfedezett BUG-ot sikeresen javították? Újrafuttatjuk a tesztet A véletlen teszt hogyan tudja befutni ugyanazt az utat? Megoldás: kiindulópont a véletlenszám generátornak: seed Minden futtatott teszthez egy seed Ha a környezet nem változik, a seed ugyanazt az utat eredményezni A verifikáció fajtái

25 © 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

26 © evosoft GmbH A verifikációs terv (vPlan) A vPlan a verifikációs folyamat talán legfontosabb dokumentuma. Útmutatást nyújt A verifikációs környezet építéséhez Milyen forgatókönyvek mentén kell tesztelni (test scenario) A lefedettség méréséhez szükséges kulcs állapotok (coverage) megállapítása Milyen funkciókat kell feltétlenül ellenőrizni (check) A verifikációs terv nem állandó – folyamatosan változó dokumentum A verifikáció teljességének mérése

27 © evosoft GmbH Hogyan kaphatunk visszajelzést a verifikáció teljességéről? A kulcs állapotokra coverage-t gyűjtünk Megnézzük, hogy elértük-e az adott állapotot Mik lehetnek ezek az “állapotok”? Egy jel változása Feldolgozni kívánt adat hossza Cím tartomány És még sok minden más… Coverage gyűjtés A verifikáció teljességének mérése CC A coverage étékének a verifikáció végén 100%-osnak kell lennie Ezt nem egy teszt futtatásával kell elérni, hanem regresszióval A regresszió több teszt (tesztenként többszöri) futtatását jelenti A verifikációs tool az egész regresszió alatt gyűjti a coverage-t

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

29 © evosoft GmbH Automatizált check-ek A check-ek ellenőrzik a DUV működését Míg a testbench alapú verifikációnál a mérnök értelmezte a DUV gerjesztésre adott válaszát, addig itt… A kiértékelés automatikusan történik Az ellenőrizni kívánt funkciók a vPlan-ben vannak definiálva Nem minden egyes check külön-külön, hanem 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 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

30 © 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

31 © 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

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

33 © evosoft GmbH A következő rész témája 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 Verifikációs koncepciók Felosztás a design hierachia alapjánFelosztás a design hierachia alapján Felosztás a verifikációs környezet felépítése alapjánFelosztás a verifikációs környezet felépítése alapján Referencia modellReferencia modell Egyéb megfontolások, gyakorlai példákEgyéb megfontolások, gyakorlai példák Összefoglalva néhány szóban

34 © evosoft GmbH ASIC-ek verifikációs szintjei Verifikációs koncepciók A verifikációs szintek kiválasztása Nem kell minden szinten Komplex rendszerek esetében két szinten szokás verifikálni Comprehensive functional verification the complete industry cycle - szerző: Bruce Wile,John C. Goss,Wolfgang Roesner

35 © evosoft GmbH ASIC-ek verifikációs szintjei Verifikációs koncepciók Designer szint (macro) Általában az RTL designer végzi Egyszerű, a design-kód megfelel-e az alapvető követelményeknek (lefordul-e, stb…) Formális verifikáció HDL testbench alapú egyszerű verifikáció Modul szint Komplex rendszereknél szükséges Egy logikai egység teljes funkcionális vizsgálata Megléte előfeltétele egy magasabb szintű verifikációnak (pl.: chip, system) Comprehensive functional verification the complete industry cycle - szerző: Bruce Wile,John C. Goss,Wolfgang Roesner

36 © evosoft GmbH ASIC-ek verifikációs szintjei Verifikációs koncepciók Az, hogy melyik szinteteket kell választani függ… A modul, ill. a rendszer bonyolultságától A modul fontosságától, a rendszerben betöltött szerepétől A specifikácitól, hogy tartalmaz-e külön a modulra leírást, vagy a modul funkióit csak rendszer szinten írja le Comprehensive functional verification the complete industry cycle - szerző: Bruce Wile,John C. Goss,Wolfgang Roesner

37 © evosoft GmbH Black box verifikáció Verifikációs koncepciók A koncepció jellemzői Referencia modell specifikáció alapján történő implementálása A funkciók HDL megvalósítása nem ismert Működés megfelelőségének vizsgálata a be/kimeneti jelek alapján Gate-level verifikációnál csak ez használható Problémák 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 DUV Device Under Verification Reference Model ?=?= stimulus

38 © 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: 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) Hártányok 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 DUV Device Under Verification stimulus

39 © 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

40 © evosoft GmbH Melyiket válasszuk? BB, WB, GB? Verifikációs koncepciók Ideális verifikáció Black Box megközelítés Teljes verifikáció A logika megfelelően működik a bemenetek összes kombinációjára A kimeneti jelek ellenőrzése az összes esetben A teljes verifikáció alkalmazása nem praktikus egy komplex rendszer funkcionális verifikációjának minden lépésében Az elvek azonben mindig irányadóak! Akkor melyik megközelítést kell választani? Azt, amelyik az adott feladatra a leginkább megfelelő A legtöbb környezet tipikusan GB

41 © 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 ?=?=

42 © evosoft GmbH Verifikációs koncepciók A verifikációs környezet A verifikációs környezet… Felépítse szigorú módszertant követ (eRM, OVM, UVM) Az újra felhasználhatóság, újrahasznosítás elvén kell, hogy működjön Verifikációs komponenseket (verification component - uVC) tartalmaz (modul, interfész) DUV Verifikációs környezet Interfész komponens Referencia Modell ?=  checker coverage

43 © evosoft GmbH Verifikációs koncepciók Modul vs. rendszer szintű verifikáció Top-level (chip) szintű verifikáció esetén A DUV-ot nem a környezet hajtja meg, hanem a valós HDL A DUV-ot egy kívánt állapotba csak indirekt módon (a meghajtó HDL modulon keresztül) lehet eljuttatni Bonyolultabb tesztekre és, nagyobb rendszerismeretre van szükség A DUV esetleg már modul szinten verifikálva volt DUV Referencia modell Verifikációs környezet Interfész komponens ?=  checker coverage HDL modul (aktív) HDL modul

44 © evosoft GmbH Verifikációs koncepciók Modul vs. rendszer szintű verifikáció Top-level (chip) szintű verifikáció esetén A szubmodulok viselkedését kevésbé kimerítően vizsgáljuk A lényeg a teljes chip működésének vizsgálata (pin-ek meghajtása) toplevel DUV ?= HDL DUV HDL ?= 

45 © evosoft GmbH Verifikációs koncepciók Modul vs. rendszer szintű verifikáció Rendszer (system level) szintű verifikáció esetén Kizárólag a rendszer szintű működés vizsgálatára öszpontosítunk A lényeg, hogy hogyan működik két (vagy több) chip együtt toplevel1 DUV ?= HDL DUV HDL ?=   toplevel2 DUV HDL DUV HDL ?=

46 © evosoft GmbH A helyes megközelítés kivá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 IDP JA JC BUSMemória read write data

47 © evosoft GmbH Példa 1 1)Megközelítés Random verifikáció Modul szint Black box A verifikáció sikeressége függ attól, hogy A megfelelő kulcsállapotokat sikerült-e definiálni Sikeresen tudtuk-e a check-eket implementá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 modul minden funkcióját teszteltük, de a belső jelek bizonyos kombinácija a tesztek alatt nem ált elő (irányított teszt kellhet) IDP ?= Ref.m Koncepció értékelése A helyes megközelítés kiválasztása

48 © evosoft GmbH 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 Értékelés: Mi van, ha a write „beragad” A felhasznált belső jelek helyes működését mindig verifikálni kell! IDP JA JC read write data Ref.m ?= A helyes megközelítés kiválasztása

49 © evosoft GmbH Példa 3 (példa 2 jó megoldása) Random verifikáció Modul szint Gray box A jó megoldás: A felhasznált belső jelek működésének alapos ellenőrzése ?= IDP JA JC read write data Ref.m ?= A helyes megközelítés kiválasztása

50 © evosoft GmbH 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 IDPBUS Mem. ?= A helyes megközelítés kiválasztása

51 © evosoft GmbH Példa 5 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 Modul szintű verifikációs komponensek használata BUS Mem. ?= IDP A helyes megközelítés kiválasztása

52 © evosoft GmbH my_asic_1 dma_env my_asic_2 Verifikációs koncepciók Újra felhasználhatóság (reuse) A funkcionális verifikáció módszertanának egyik alapja az újra felhasználhatóság. Lényege, hogy egy modul verifikációs környezetét plusz munka nélkül tudjuk használni egy másik ASIC esetén is dma_env my_dma module my_dma module

53 © evosoft GmbH A következő rész témája Verifikációs koncepiók Black box, white box, gray box – ezek előnyei, hátrányai Verifikációs szintek A környezet felépítésének áttekintése Reuse Verifikációs és szimulátor tool-ok Néhány alapfogalomNéhány alapfogalom Összefoglalva néhány szóban

54 © evosoft GmbH Delta cycle Verifikáció & szimuláció Egy szimulációs ciklus két fázisból áll vhdl jelek értéknek frissítése vhdl folyamatok kiértékelése A szimulációs idő egy pontján több frissítés ill. kiértékelés történhet delta cycle a delta cycle-k száma nem befolyásolja a szimulációs időt a szimuláció futásának idejére hatással van (mennyi ideig fut a teszt) delta cycle-k sorrendje Időben párhuzamos folyamatok esetén nem ismert delta1 delta2 delta1 delta2 delta3 delta szimulációs idő [ns] Párhuzamos folyamatok delta cycle vhdl jel frissítése függvény kiértékelés

55 © evosoft GmbH Delta cycle - példa Verifikáció & szimuláció library IEEE; use IEEE.Std_Logic_1164.all; entity DELTA is port (A, B : in std_ulogic; Y, Z : out std_ulogic); end DELTA; architecture EXAMPLE of DELTA is signal X : std_ulogic; begin process (A, B, X) begin Y <= A; X <= B; Z <= X; end process; end EXAMPLE; Jel A jel jövőbeni értéke (future value) YA jel jelenlegi értéke (változatlan) XB jel jelenlegi értéke (új) ZX jel jelenlegi értéke (változatlan) Jel A jel jövőbeni értéke (future value) YA jel jelenlegi értéke (változatlan) XB jel jelenlegi értéke (változatlan) ZX jel jelenlegi értéke (új – B új értéke) B jel változik [első delta cycle] Jelek értékeinek frissítése X jel változik [második delta cycle] Jelek értékeinek frissítése

56 © evosoft GmbH Verifikációs tool és szimulátor Verifikáció & szimuláció A verifikációs környezet szolgáltatja a stimulust a HDL számára Előbbit a verifikációs tool (Specman) futattja Utóbbit a szimulátor (pl.: ModelSim, NCSim) futtatja A vezérlést egyszer a verifikációs szoftvernek, máskor a szimulátornak kell átadni Szimulátor (IES, Modelsim) Verifikációs tool (Specman) Környezet fordítása Constraint solver Random generátor Stimulus előállítás RTL fordítása Szimuláció futtatása Delta cycle-k feldolgozása Időbeli kifejezések kiértékelése, Check-ek futása, Coverage gyüjtés Szimuláció vége Szimuláció futtatása Delta cycle-k feldolgozása t=0nst=N nsSzimulációs idő callback

57 © evosoft GmbH A következő rész témája Verifikációs és szimlátor tool-ok Szimulációs idő Delta cycle Verifikációs tool és szimulátor együttműködés Kiegészítő módszerek Code coverageCode coverage Connectivity check (formális verifikáció)Connectivity check (formális verifikáció) Összefoglalva néhány szóban

58 © evosoft GmbH Code coverage Kiegészítő módszerek A code coverage szerepe A HDL kód lefedettségét méri A verifikációs tesztek futása alatt Visszajelzést ad a Fejlesztő mérnöknek A verifikáció státuszáról Hogy melyek azok a jelek, amik sohan em változtak a verifikáció alatt (lehet implementációs hiba) A verifikációs mérnöknek  Hogy melyik nagyobb egységeket nem érte még el a verifikáció

59 © evosoft GmbH Code coverage Kiegészítő módszerek Block Coverage - Megmondja hogy melyik egységeket sikerült stimulálni a szimuláció során. Az egység (block) egy if-else közötti kódrész. Branch coverage – Precízebb visszajelzést ad, mint a “block coverage”, mivel egy feltétel ágait külön értékeli. 100%-os a coverage ha egy feltétel összes ágán végigfutottunk a szimuláció során. Statement Coverage – Egy block-on belüli egyes feltételekről ad információt (a feltételek által meghatározozz összes esetből hány %-ot fedtünk le) A code coverage fajtái A code coverage nem a HDL működését ellenőrzi, nem a funkcionalitás lefedettségét méri, hanem arról ad információt, hogy a HDL kód melyik részeit mozgatta meg a teszt Ezek alapján a code coverage következő típusait különböztetjük meg

60 © evosoft GmbH Code coverage Kiegészítő módszerek Expression Coverage – Az kiértékelt logika műveletek (OR, AND, NOR, NAND) számát mutatja meg %-ban. Toggle Coverage – Megmondja, hogy az összes jel hány százaléka változott FSM Coverage – A véges állapotgép állapotainak, illetve az állapotokhoz vezető utak lefedettségéről ad visszajelzést A A C C D D B B

61 © evosoft GmbH Az összeköttetések ellenőrzése Kiegészítő módszerek Az összeköttetések ellenőrzése (connectivity check) Szimuláció alapú megközeltés Az összes adat-út tesztelése Az összes státusz és vezérló jel megmozgatása Minden jel megmozgatása nagyon időigényes CPUDMA Status & Control GPIO BUS pin

62 © evosoft GmbH Az összeköttetések ellenőrzése Kiegészítő módszerek 2) Megközelítés: Formális verifikáció A HDL modulok bekötését lehet vele ellenőrizni Szükség van a portok helyes összekötésének leírására Áltlában nincs összesítve, a specifikációból kell kibogózni Top level (chip level) esetén célszerű alkalmazni, amikor meglehetősen sok vezérlő ill. státusz jel (sideband signal) bekötésére kell figyelnie a top levelt implementáló mérnöknek Csak a jelek helyes bekötését ellenőrizzük, a működést nem, így a conectivity check rövid időn belül képes lefutni

63 © evosoft GmbH A következő rész témája Kiegészítő módszerek Code coverage definíciója és fajtái Összekötések ellenőrzése Alapvető különbségek a formális és a funkciónális verifikációs eszközök között Kitekintés Lapfogalmak pár szóbanLapfogalmak pár szóban Equivalence checkEquivalence check e-Verifikációe-Verifikáció … Összefoglalva néhány szóban

64 © evosoft GmbH Equivalence checking Kitekintés Equivalence checking Formális verifikáció csoportjába tartozik Nem szimuláció alapú Két modellt hasonlít össze, amelyeknek egyeznik kell Például: Gate level vs. HDL Szintetizált kód úgy működik-e, mint a HDL modell Clock-tree integrálása nem vitt-e hibákat a rendszerbe

65 © evosoft GmbH Az e-verifikáció Előretekintés Néhány szó az e-verifikáció-ról Alapja az e-nyelv (aspektus orientált) Strukúráját az eRM, oVM, uVM határozza meg Coding guideline Mappa szerkezet Elnevezési szabályok, stb… Az e-verifikációhoz tartozó tool a Specman Fejlesztője a Cadence A Specman nem tartalmazza a szimulátort, használható Modelsim (Mentor) IES (Incisive Enterprise Simulator - Cadence)

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


Letölteni ppt "© evosoft GmbH ASIC verifikáció I. 2011.11.28. © evosoft GmbH Bemutatkozás ASIC verifikáció Stubna Ágoston ASIC fejlesztő / verifikációs mérnök evosoft."

Hasonló előadás


Google Hirdetések