asic verifikáció i . 2011.11.28

66
© evosoft GmbH ASIC verifikáció I. 2011.11.28

Upload: posy

Post on 29-Jan-2016

22 views

Category:

Documents


0 download

DESCRIPTION

ASIC verifikáció I . 2011.11.28. Bemutatkozás. 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. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

ASIC verifikáció I.2011.11.28

Page 2: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

BemutatkozásBemutatkozás

ASIC verifikáció

Stubna ÁgostonASIC fejlesztő / verifikációs mérnök

evosoft Hungary [email protected]

BME-VIK mikró / CAT (2008)

Page 3: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

Bemutatkozás

Page 4: ASIC  verifikáció I . 2011.11.28

© 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

Page 5: ASIC  verifikáció I . 2011.11.28

© 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

Page 6: ASIC  verifikáció I . 2011.11.28

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

Page 7: ASIC  verifikáció I . 2011.11.28

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

Page 8: ASIC  verifikáció I . 2011.11.28

© 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

Page 9: ASIC  verifikáció I . 2011.11.28

© 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

Page 10: ASIC  verifikáció I . 2011.11.28

© 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

Page 11: ASIC  verifikáció I . 2011.11.28

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

Page 12: ASIC  verifikáció I . 2011.11.28

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

Page 13: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

A verifikáció szerepe az ASIC fejlesztés folyamatában

Verifikációs alapfogalmak

SpecificationSpecification

HDL implementation & Verification

HDL implementation & Verification

SynthesisSynthesis

LayoutLayout

ProductionProduction

Testing & ValidationTesting & Validation

„Olcsó”

„Drága”

30%70%

Design

Verification

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.

Page 14: ASIC  verifikáció I . 2011.11.28

© 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 chip rendszer megrendelő

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)

Page 15: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

A verifikáció helye az ASIC fejlesztés folyamatában

Verifikációs alapfogalmak

KoncepcióKoncepció

SpecifikációSpecifikáció

HDL (RTL) leírásHDL (RTL) leírás

Tape outTape out

SziliciumSzilicium

ellenőrzés

FUNKCIONÁLISVERIFIKÁCIÓ

Azt írtad le amit kigondolta(to)k?

Azt kódoltad le (HDL), amit leírtak?

ellenőrzésA tape-out úgy működik

ahogy kell (HDL)?

ellenőrzésA 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

Page 16: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

HDL (RTL) implementáció

Funkcionális verifikáció

Modul Chip (top level)

Modul Chip (top level) Gate levelSystem 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ó

Modul Chip (top level)

Modul Chip (top level) Gate levelSystem level

Modell

idő

Page 17: ASIC  verifikáció I . 2011.11.28

© 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án

Összefoglalva néhány szóban

Page 18: ASIC  verifikáció I . 2011.11.28

© 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

TBStimulus

Testbench

TBMonitor

Write (0xCAFE, 0x0101)Read(0x2011)

Page 19: ASIC  verifikáció I . 2011.11.28

© 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 állapotBUG-os állapotNem “üzemi” állapot

A teszt által bejárt állapot

Page 20: ASIC  verifikáció I . 2011.11.28

© 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 állapotNem “üzemi” állapot

A teszt által bejárt állapot

futás1 futás2

Page 21: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

Constrained random szimuláció

A verifikáció fajtái

HDL egy állapota

BUG-os állapotNem “üzemi” állapot

A teszt által bejárt állapot

futás1futás2

Állapotok egy tartományaegy 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)

Page 22: ASIC  verifikáció I . 2011.11.28

© 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

CHDL egy állapota

BUG-os állapotNem “üzemi” állapot

A teszt által bejárt állapot

tesztAfutás1

tesztAfutás2

Állapotok egy tartományaegy tesztre

Corner case

tesztBfutás2

tesztBfutás1

tesztCfutás2

tesztCfutás1

direktteszt

C

Kulcs állapotok

Page 23: ASIC  verifikáció I . 2011.11.28

© 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óskörnyezet

szabályoka < 64b > 128

constrainedsolver DUV0101011010

0101100101

szabályoka > 5b < 10

stimulusgenerálás

Page 24: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

Pszeudó-random generálás: seed

futásseed123456

futásseed789101

seed123456

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

Page 25: ASIC  verifikáció I . 2011.11.28

© 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• vPlan• Coverage• Check-ek

Összefoglalva néhány szóban

Page 26: ASIC  verifikáció I . 2011.11.28

© 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

Page 27: ASIC  verifikáció I . 2011.11.28

© 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éseC C

• 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

Page 28: ASIC  verifikáció I . 2011.11.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 állapotNem “üzemi” állapot

A teszt által bejárt állapot

futás1 futás2

“Kulcs” állapotok

Page 29: ASIC  verifikáció I . 2011.11.28

© 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

Page 30: ASIC  verifikáció I . 2011.11.28

© 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

Page 31: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

A lefedettség növelése

CDV (coverage driven verification) folyamata

Tervezésifázis

Eredményértelmezése

Verifikációskörnyezet

Verifikációsterv (vplan)

Eredmények(coverage jelentés)

Tesztek,Stimulusok

Specifikáció olvasás

Coverage, check

tervezése

vplan frissítése Környezetjavítása

Constraint-ekújradefiniálása

A verifikáció teljességének mérése

Page 32: ASIC  verifikáció I . 2011.11.28

© 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

Page 33: ASIC  verifikáció I . 2011.11.28

© 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án• Felosztás a verifikációs környezet felépítése alapján• Referencia modell• Egyéb megfontolások, gyakorlai példák

Összefoglalva néhány szóban

Page 34: ASIC  verifikáció I . 2011.11.28

© 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

Page 35: ASIC  verifikáció I . 2011.11.28

© 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

Page 36: ASIC  verifikáció I . 2011.11.28

© 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

Page 37: ASIC  verifikáció I . 2011.11.28

© 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

DUVDevice Under Verification

Reference Model

?=stimulus

Page 38: ASIC  verifikáció I . 2011.11.28

© 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

DUVDevice Under Verification

stimulus

Page 39: ASIC  verifikáció I . 2011.11.28

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

DUVDevice Under Verification

Reference Model

?=stimulus

Page 40: ASIC  verifikáció I . 2011.11.28

© 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

Page 41: ASIC  verifikáció I . 2011.11.28

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

Page 42: ASIC  verifikáció I . 2011.11.28

© 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

1011001010

?=

checker

coverage

Page 43: ASIC  verifikáció I . 2011.11.28

© 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

Referenciamodell

Verifikációs környezet

Interfész komponens

1011001010

?=

checkercoverage

HDL modul(aktív)

HDL modul

Page 44: ASIC  verifikáció I . 2011.11.28

© 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

HDLDUV

HDL HDL

?=?=

Page 45: ASIC  verifikáció I . 2011.11.28

© 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

HDLDUV

HDL HDL

?=?=

toplevel2

DUVHDL

HDLDUV

HDL HDL

?= ?=

Page 46: ASIC  verifikáció I . 2011.11.28

© 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

BUS Memóriaread

write

data

Page 47: ASIC  verifikáció I . 2011.11.28

© 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

Page 48: ASIC  verifikáció I . 2011.11.28

© 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

Page 49: ASIC  verifikáció I . 2011.11.28

© 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

Page 50: ASIC  verifikáció I . 2011.11.28

© 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

Page 51: ASIC  verifikáció I . 2011.11.28

© 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

Page 52: ASIC  verifikáció I . 2011.11.28

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

my_dmamodule

Page 53: ASIC  verifikáció I . 2011.11.28

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

Összefoglalva néhány szóban

Page 54: ASIC  verifikáció I . 2011.11.28

© 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

de

lta

1d

elt

a2

de

lta

1d

elt

a2

de

lta

3

de

lta

1

de

lta

1

10 20 30 40 50szimulációs idő [ns]

rhu

zam

os

foly

am

ato

kd

elta

cyc

le

vhdl jelfrissítése

függvénykiértékelés

Page 55: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

Delta cycle - példa

Verifikáció & szimuláció

http://www.vhdl-online.de/tutorial/englisch/t_151.htm

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)

Y A jel jelenlegi értéke (változatlan)

X B jel jelenlegi értéke (új)

Z X jel jelenlegi értéke (változatlan)

Jel A jel jövőbeni értéke (future value)

Y A jel jelenlegi értéke (változatlan)

X B jel jelenlegi értéke (változatlan)

Z X 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

Page 56: ASIC  verifikáció I . 2011.11.28

© 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ásaConstraint solverRandom generátorStimulus előállítás

RTL fordítása

Szimuláció futtatásaDelta cycle-k feldolgozása

Időbeli kifejezésekkiértékelése,Check-ek futása,Coverage gyüjtés

Szimulációvége

Szimuláció futtatásaDelta cycle-k feldolgozása

t=0ns t=N ns Szimulációs idő

callback

Page 57: ASIC  verifikáció I . 2011.11.28

© 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 coverage• Connectivity check (formális verifikáció)

Összefoglalva néhány szóban

Page 58: ASIC  verifikáció I . 2011.11.28

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

Page 59: ASIC  verifikáció I . 2011.11.28

© 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

Page 60: ASIC  verifikáció I . 2011.11.28

© 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 C D

B

Page 61: ASIC  verifikáció I . 2011.11.28

© 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

CPU DMA Status &Control

GPIO

BUS

pin

Page 62: ASIC  verifikáció I . 2011.11.28

© 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

Page 63: ASIC  verifikáció I . 2011.11.28

© 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óban

• Equivalence check• e-Verifikáció• …

Összefoglalva néhány szóban

Page 64: ASIC  verifikáció I . 2011.11.28

© 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

Page 65: ASIC  verifikáció I . 2011.11.28

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

Page 66: ASIC  verifikáció I . 2011.11.28

© evosoft GmbH

Köszönöm a figyelmet!