© evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra1 evosoft Hungary Kft. Bevezetés a verifikáció világába 2014. November.

Az előadások a következő témára: "© evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra1 evosoft Hungary Kft. Bevezetés a verifikáció világába 2014. November."— Előadás másolata:

1 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra1 evosoft Hungary Kft. Bevezetés a verifikáció világába 2014. November 19.

2 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra2 Agenda Alapfogalmak A verifikáció fajtái Teljességének mérése Koncepciók

3 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra3 Tartalom Alapfogalmak A verifikáció fogalmai Miért van szükség a verifikációra? A verifikáció szerepe és helye az ASIC fejlesztés folyamatában Példa A verifikáció fajtái HDL testbench alapú verifikáció - Bug-ok felfedése irányított teszttel Bug-ok felfedése random stimulussal - Constrained random szimuláció Tipikus megközelítés - Pszeudó-random generálás

4 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra4 Tartalom A verifikáció teljességének mérése A verifikációs terv (vPan) Coverage gyűjtés Automatizált check-ek Koncepciók Black box White box Gray box Melyiket válasszuk? – It depends...

5 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra5 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 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra6 Alapfogalmak Mi a verifikáció? A vizsgálata annak, hogy a dizájn a specifikációban megadott célokat és funkciókat megvalósítja, a megszabott kritérumokat betartva Mit verifikálunk? Az HDL leírás (pre-silicon) funkcionális viselkedését verifikáljuk Mihez viszonyítva verifikálunk? A referencia minden esetben a specifikáció (a funkcionális leírás) Mi biztosítja, hogy a specifikáció hibátlan? Több szem többet lát: architect != designer != verifikációs mérnök Eltérő területek egyetértése, funkciókban és kritériumokban (SW, HW)

7 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra7 Miért van szükség a verifikációra? Mert hibák maradhatnak a termékben... A tesztelő mérnökök az úgynevezett Use case viselkedésre fókuszálnak, nem tudnak minden szélsőséges állapot együttállásra gondolni, ezekre így nincs teszt Hogy lehet olyan eseményeket letesztelni, amik létezését nem is sejtjük? Megoldás: Egész állapottér vizsgálat Szükség van egy bizonyos fokú automatizációra és állapottér szűkítésre

8 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra8 A verifikáció szerepe és helye az ASIC fejlesztés folyamatában A verifikáció az ASIC fejlesztés életéből hozzávetőlegesen 70%-ot tesz ki (sok) Az ASIC fejlesztés lépései között is szükséges (HDL fejlesztés lépései) Célszerűen gyártás előtt (itt olcsó) Specification HDL implementation & Verification Synthesis Layout Production Testing & Validation „Olcsó” Koncepció Specifikáció HDL (RTL) leírás Tape out Szilicium

9 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra9 Példa Példa I.: Rádió/MP3 hallgatás közben a fülhallgató kihúzása leállítja a lejátszást, a fejhallgató visszadugása elindítja a lejátszást. Mindkettő elindul? Példa II.: 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). Ez helyes működés?

10 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra10 A verifikáció fajtái A felosztás a szimulációban alkalmazott gerjeszések (stimulusok) fajtái alapján történik A cél az, hogy az állapotteret „valahogy” bejárjuk HDL Testbench alapú Dizájn és a verifikációs környezet is HDL (as u did already) Irányított tesztek (bonyolult dizájn  bonyolult tesztek) Use case irányú Random stimulus alapú Az állapottér felosztásra kerül A Corner case-ek jobban kizárhatóak Tipikus – Constrain random Jól felosztott állapottér tartományok Corner case-ek is jól fedhetőek Pseudo random stimulus használat 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

11 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra11 A verifikáció teljességének mérése – vPlan Verifikációs terv készítése (vPlan) A verifikáció legfontosabb dokumentuma (a verifikáció folyamata során változik) Ami a vPlanben nincs benne az nem kerül verifikálásra Az ASIC fejlesztésében résztvevő összes területtel közösen kell elkészíteni a vPlant

12 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra12 A verifikáció teljességének mérése – Coverage Coverage Az állapottér egy részhalmazának vagy adott állapot bejárásának a mérése Cél a 100%-os állapottér lefedettség (a vPlanben szabjuk meg a lényeges állapotteret) vPlanben vannak definiálva az adott funkciókhoz HDL egy állapota BUG-os állapot Nem “üzemi” állapot A teszt által bejárt állapot futás1futás2    “Kulcs” állapotok

13 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra13 A verifikáció teljességének mérése – Check A check-ek ellenőrzik a dizájn működését folyamatosan Az ellenőrizni kívánt funkciók a vPlan-ben vannak definiálva Az implementálás módját, az ellenőrízni kívánt funkciók check-ekre való felbontását a verifikációs mérnök dönti el! Négy fő funkcionális szempont szerint lehet a check-eket csoportosítani Kimenetek/bemenetek Rendszerszemlélet Belső működés Protokol

14 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra14 Verifikációs koncepciók K 3 fő koncepció az adott lehetőségek függvényében Black Box: A dizájn „fekete doboz”, funkciója csak külső stimulussal ellenőrizhető. A legkedveltebb és egyben legnehezebb módszer (komplex referencia modell) White Box: A dizájn „áttetsző”, minden belső jel/érték elérhető és/vagy simulálható Egyszerű, ugyanakkor belső változtatás hatására a referencia modell is változik Grey Box: A fenti kettő egyvelege, a lehető leggyorsabb verifikáció érdekében Komplex dizájnok esetében célszerűen alkalmazandó

15 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra15 Your powerful partner

16 © evosoft Hungary Kft. 2014 | XYZ – Prezentáció címe V1.0 Csak belső használatra16 Kapcsolat evosoft Hungary Kft. 1117 – Budapest Kaposvár utca 14-18. Telefon: +36 (1) 38-16400 Telefax: +36 (1) 38-16101 Kapcsolattartó