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. 2013.11.18. © evosoft GmbH Bemutatkozás.

Hasonló előadás


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

1 © evosoft GmbH ASIC verifikáció I

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 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 © 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 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) 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 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 futás seed seed 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 következő rész témája (opcionális) 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 Összefoglalva néhány szóban

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

32 © 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ó Comprehensive functional verification the complete industry cycle - szerző: Bruce Wile,John C. Goss,Wolfgang Roesner 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)

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

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

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

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

37 © 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 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 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!

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

39 © evosoft GmbH Verifikációs koncepciók A verifikációs környezet Szigorú módszertan Újra felhasználhatóság Verifikációs komponensek (modul, interfész) DUV Verifikációs környezet Interfész komponens Referencia Modell ?=  checker coverage

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

41 © evosoft GmbH Verifikációs koncepciók Modul vs. Top-level 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

42 © evosoft GmbH Modul szint Verifikációs koncepciók DUV Referencia modell Passzív interfész komponens ?=  HDL modul (aktív) HDL modul DUV Verifikációs környezet Aktív interfész komponens Referencia Modell ?=  checker coverage Chip szint

43 © evosoft GmbH Verifikációs koncepciók Top level 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 ?= 

44 © evosoft GmbH Verifikációs koncepciók 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 ?=

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

46 © 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)

47 © evosoft GmbH A következő rész témája Coverage (Metric) driven functional verification Formális verifikáció Balotai Péter Összefoglalva néhány szóban

48 © evosoft GmbH 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 © evosoft GmbH 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. Verification Simulation Formal Verification Directed stimulus Constrained random st. vektoroknincs szimuláció nincsenek vektorok Property checking Equivalence checking Formális verifikáció dióhéjban Assertion Driven Sim.

50 © evosoft GmbH 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 clk Write Read Full Empty No read when empty FIFO can’t be full and empty at the same time Empty must be asserted until a write occurs FIFO

51 © evosoft GmbH Terminológia Állapottér: 8 Elérhető: 5 Átmérő: 3 Elérhető állapotok száma és az átmérő függ a kezdeti állapottól Verifikációs komplexitás függ a DUT-tól és a property-ktől Egy assertion PASS állapotú, ha minden elérhető állapotban igaz

52 © evosoft GmbH Állapottér formális vizsgálata Nincs új elérhető állapot → a teljes elérhető állapottér felderített Assertion PASS: a használt constraint-ek mellett nincs olyan állapot, amiben az assertion-ben leírt formális állítás ne lenne igaz Assertion FAIL: létezik egy állapot, amiben a DUT megsérti a formális követelményt → ellenpélda az aktuális állapottól vissza a kezdeti állapotig (legrövidebb) Assertion EXPLORED: az aktuális mélységig nem derítettük fel a teljes állapotteret, de nem találtunk olyan állapotot, amiben a formális követelményt megsértené a DUT Exploring… Mélység (crank) Kezdeti állapot Átmérő Új állapotok

53 © evosoft GmbH Mit verifikáljunk formálisan? Kihívások: DUT komplexitása Méret: összefügg az állapotok számával és a bemenetekkel Átmérő: számlálók esetén óriási az állapottér A specifikáció (property-k) minősége Nem teljes Hibás Túl nagy megkötés a bemenetekre (constraint-ek) A formális verifikáció relatíve kis design-okra jó Előnyök: Nem kell hozzá testbench Gyorsan el lehet kezdeni a tesztelést Szimulációval nehezen megtalálható hibák gyors felfedése

54 © evosoft GmbH Assertion-vezérelt szimuláció Random stimulus a constraint-ek alapján Mindez testbench nélkül Tesztek nélkül Formal AnalysisAssertion-Driven Simulation Matematikai módszerekSzimuláció Szélességi bejárásLineáris StatikusDinamikus provesearch IFV + IEVIEV

55 © evosoft GmbH Assertion-vezérelt szimuláció Constraint-ek nélkül: minden teljesen random Write1 Read1Read2 clk Write Read Full Empty FIFO clk Read Write Full Empty ! hibás működés Empty until write

56 © evosoft GmbH Assertion-vezérelt szimuláció Constraint-ek használata: életszerű gerjesztés Write1 Read1Read2 clk Write Read Full Empty FIFO clk Read Write Full Empty No read when empty Write1 Empty until write

57 © evosoft GmbH Assertion-vezérelt szimuláció előnyei Szimulációs környezet testbench nélkül Constraint-ek felhasználhatók, mint assertion-ök integráláskor Stimulus generálás property-ből: vizualizáció segíti a hibakeresést elősegíti a DUT működésének intuitív megértését

58 © evosoft GmbH DUT inicializálása Időegység: crank Órajel setup: TCL parancs clock –add clk1 –initial 0 –offset 2 –width 1 –period 3 A reset jelet deaktiváljuk force rst_n 0 run 4 init –load –current constraint –add –pin rst_n 1 –reset prove/search clk1 rst_n FF-ok állapota betöltve = Kezdeti állapot a formal tool számára

59 © evosoft GmbH Automatikus check-ek Deadcode check: elérhető egyáltalán a kódrészlet? FSM check-ek: elérhető minden állapot? És az állapotátmenetek? (rajz) Busz check-ek: több modul hajthatja → X Toggle check: minden bit megmozgatható? Range overflow check: tömbműveletek esetén előfordulhat? Az automatikus check-ek RTL hibákat fedhetnek fel Megmutathatják, ha túl sok a megkötés értékekre, kombinációkra

60 © evosoft GmbH Formális nyelvek

61 © evosoft GmbH PSL példák Property property p_addr_nonzero = always (addr > 0); Assertion output_no_underflow : assert never (read && clk); a_pin_GPIO8_Y1 : assert always ( (logic1) -> (( GPIO8_Y1 ) = ( SPI_S_IN ))); Constraint alternate_b_0 : assume always (GPIO_MODE_0( 1 downto 0) = "10"); Cover request_with_done : cover {grant; busy[*]; done && clk);

62 © evosoft GmbH IEV tool

63 © evosoft GmbH Köszönjük a figyelmet! Stubna Ágoston ASIC fejlesztő / verifikációs mérnök evosoft Hungary Kft. Balotai Péter ASIC fejlesztő / verifikációs mérnök evosoft Hungary Kft.


Letölteni ppt "© evosoft GmbH ASIC verifikáció I. 2013.11.18. © evosoft GmbH Bemutatkozás."

Hasonló előadás


Google Hirdetések