Transcript Verifikáció I. (EvoSoft Hungary)

ASIC verifikáció I.
2013.11.18
© evosoft GmbH
Bemutatkozás
© evosoft GmbH
Bevezetés a funkcionális verifikációba
Tartalom
• 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
© evosoft GmbH
Bevezetés a funkcionális verifikációba
Tartalom
• 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ó
© evosoft GmbH
Bevezető
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
© evosoft GmbH
Verifikációs alapfogalmak
Mi a verifikáció?
•
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
Mihez viszonyítva verifikálunk?
•
A specifikáció a referencia
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
© evosoft GmbH
Verifikációs alapfogalmak
A tesztelés és a verifikáció közi különbség
Verifikáció
Teszt
•
•
•
•
•
•
•
Gyártás előtt, nem darabonként
RTL leíráson
Gate level netlistán
Tervezési hibák felfedezése
Gyártás után, minden darabon
Elkészült ASIC-en
Gyártási hibák kiszűrése
© evosoft GmbH
A verifikációs feladat
Miért van szükség a verifikációra?
•
Mert hibák maradhatnak a termékben
• 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ó
© evosoft GmbH
Verifikációs alapfogalmak
Miért van szükség a verifikációra? Egy példa:
Milyen típusú hibákat kell(ene) a
verifikációnak felfedeznie?
•
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)
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)
© evosoft GmbH
A verifikációs feladat
Miért van szükség a verifikációra? Egy másik példa:
DMA
RAM
data
start
Data IF
address
Mem. write
request
grant
write
Mem. write
?
Mem. write
final
request
grant
write
© evosoft GmbH
Verifikációs alapfogalmak
A verifikáció helye az ASIC fejlesztés folyamatában
A verifikáció az ASIC tervezés 70%-át teszi ki
Időben
• Költségben
•
Specification
HDL implementation
& Verification
70%
30%
Design
„Olcsó”
Synthesis
Verification
Layout
„Drága”
Production
Testing & Validation
© evosoft GmbH
Verifikációs alapfogalmak
Mibe kerül egy bug?
Gyártási költség:
Néhány millió $
•A bug-os chip költségei
magas
Funkcionális verifikáció
Egy bug
javításának
költsége
Talált bug-ok
száma
alacsony
Tesztelés
szintjei
(később)
VHDL-modul
chip
rendszer
megrendelő
idő
© evosoft GmbH
Verifikációs alapfogalmak
A verifikáció helye az ASIC fejlesztés folyamatában
Hogyan bizonyosodunk meg a működés helyességéről?
•
Ellenőrzés (verifikáció) több ponton
Koncepció
ellenőrzés
Azt írtad le amit kigondolta(to)k?
FUNKCIONÁLIS
VERIFIKÁCIÓ
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?
Specifikáció
HDL (RTL) leírás
Tape out
Szilicium
© evosoft GmbH
Összefoglalva néhány szóban
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 következő rész témája
A Verifikáció fajtái
•
Felosztás a szimulációban alkalmazott gerjeszések
(stimulusok) fajtái alapján
© evosoft GmbH
A verifikáció fajtái
HDL testbench alapú verifikáció
• DUV és a verifikációs környezet is HDL
Teljesen zárt környezet (a testbench modulnak nincsenek portjai)
•
Testbench
Write (0xCAFE, 0x0101)
Read(0x2011)
TB
Stimulus
DUV
TB
Monitor
•
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...
© evosoft GmbH
A verifikáció fajtái
Bug-ok felfedése írányított teszttel
Í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
© evosoft GmbH
A verifikáció fajtái
Bug-ok felfedése random stimulussal
Random teszt
futás1
futás2
HDL egy állapota
BUG-os állapot
Nem “üzemi” állapot
A teszt által bejárt állapot
•
•
•
•
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
© evosoft GmbH
A verifikáció fajtái
Constrained random szimuláció
Constrained random szimuláció
futás2
futás1
HDL egy állapota
BUG-os állapot
Nem “üzemi” állapot
A teszt által bejárt állapot
Állapotok egy tartománya
egy tesztre
• 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)
© evosoft GmbH
A verifikáció fajtái
Tipikus megközelítés
• 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.
tesztB
futás1
tesztB
futás2
tesztA
futás2
tesztA
futás1
direkt
teszt
Corner
case
C
C
HDL egy állapota
BUG-os állapot
Nem “üzemi” állapot
A teszt által bejárt állapot
Állapotok egy tartománya
egy tesztre
tesztC
futás1
tesztC
futás2
Kulcs állapotok
© evosoft GmbH
A verifikáció fajtái
A verifikációs környezet felé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 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
verifikációs tool
szabályok
a < 64
b > 128
verifikációs
környezet
constrained
solver
stimulus
generálás
0101011010
0101100101
DUV
szabályok
a>5
b < 10
testcase (TC)
© evosoft GmbH
A verifikáció fajtái
Pszeudó-random generálás: seed
Hogy tudunk megbizonyosodni hogy a felfedezett BUG-ot
sikeresen javították?
futás futás
seed seed
123456 789101
seed
123456
© evosoft GmbH
Összefoglalva néhány szóban
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 következő rész témája
A Verifikáció teljességének mérése
•
•
•
vPlan
Coverage
Check-ek
© evosoft GmbH
A verifikáció teljességének mérése
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
© evosoft GmbH
A verifikáció teljességének mérése
Coverage gyűjtés
Hogyan kaphatunk visszajelzést a verifikáció teljességéről?
A kulcs állapotokra coverage-t gyűjtünk
•
•
•
•
Egy jel változása
Feldolgozni kívánt adat hossza
Cím tartomány
És még sok minden más…
• A coverage –ra a cél 100%!
• Regresszió
© evosoft GmbH
A verifikáció teljességének mérése
Coverage gyűjtés
• 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
futás1
futás2





HDL egy állapota
BUG-os állapot
Nem “üzemi” állapot
A teszt által bejárt állapot
“Kulcs” állapotok
© evosoft GmbH
A verifikáció teljességének mérése
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
© evosoft GmbH
A verifikáció teljességének mérése
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)
© evosoft GmbH
A verifikáció teljességének mérése
A lefedettség növelése
CDV (coverage driven verification) folyamata
Specifikáció
olvasás
Tervezési
fázis
Coverage,
check
tervezése
Verifikációs
terv (vplan)
vplan frissítése
Környezet
javítása
Eredmény
értelmezése
Verifikációs
környezet
Tesztek,
Stimulusok
Constraint-ek
újradefiniálása
Eredmények
(coverage jelentés)
© evosoft GmbH
A verifikáció teljességének mérése
A verifikációs project életciklusa
Kezdő
fázis
Random tesztek
futtatása
Maradék cornercase-ek lefedése
Lefedettség, a
verifikáció során
talált bug-ok
száma
magas
Random tesztek
debuggolására
fordított energia
alacsony
idő
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
© evosoft GmbH
Összefoglalva néhány szóban
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
A következő rész témája (opcionális)
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
© evosoft GmbH
Verifikációs koncepciók
ASIC-ek verifikációs szintjei
• 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
© evosoft GmbH
Verifikációs koncepciók
ASIC-ek verifikációs szintjei
• 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
© evosoft GmbH
Verifikációs koncepciók
ASIC-ek verifikációs szintjei
• 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
© evosoft GmbH
Verifikációs koncepciók
Black box verifikáció
• 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
• 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
stimulus
?
=
Reference Model
© evosoft GmbH
Verifikációs koncepciók
White box verifikáció
• 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
stimulus
DUV
Device Under Verification
© evosoft GmbH
Verifikációs koncepciók
Gray box verifikáció
• 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
stimulus
?
=
Reference Model
© evosoft GmbH
Verifikációs koncepciók
Melyiket válasszuk? BB, WB, GB?
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
© evosoft GmbH
Verifikációs koncepciók
Referencia modell és check-ek
Alapvető megfontolások
• A felhasznált belső jelek helyes értékét, és az azt előállító
logikát mindenképpen tesztelni kell
?
=
stimulus
Reference Model
© evosoft GmbH
Verifikációs koncepciók
A verifikációs környezet
• A verifikációs környezet
• Szigorú módszertan
• Újra felhasználhatóság
• Verifikációs komponensek (modul, interfész)
checker
Referencia
Modell
coverage

?=
DUV
Verifikációs
környezet
Interfész
komponens
10110
01010
© evosoft GmbH
Kérdés?
Most jönne: Modul szintű és rendszer szintű verifikáció.
Idő?
© 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
© evosoft GmbH
Verifikációs koncepciók
checker
Referencia
Modell
coverage

?=
Verifikációs
környezet
Modul szint
DUV
Aktív interfész
komponens
10110
01010

Referencia
modell
Chip szint
HDL modul
(aktív)
DUV
?=
Passzív interfész
komponens
HDL modul
10110
01010
© 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
HDL
DUV
HDL
HDL
© 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
?=
?= ?=
?=
toplevel2
DUV
HDL
DUV
HDL
HDL
DUV
HDL
DUV
HDL
HDL
HDL
HDL
© evosoft GmbH
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
my_asic_1
my_asic_2
dma_env
my_dma
module
my_dma
module
© evosoft GmbH
Előretekintés
Az e-verifikáció
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)
© evosoft GmbH
Összefoglalva néhány szóban
Coverage (Metric) driven functional verification
A következő rész témája
Formális verifikáció
Balotai Péter
© evosoft GmbH
Formális verifikáció
Miről lesz szó?
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
© evosoft GmbH
Formális verifikáció dióhéjban
Verification
Simulation
Directed
stimulus
Constrained
random st.
Formal Verification
Assertion
Driven Sim.
vektorok
Property
checking
Equivalence
checking
nincs szimuláció
nincsenek vektorok
• 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.
© 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
No read when
empty
FIFO can’t be full
and empty at the
same time
clk
Write
Read
Empty must be
asserted until a
write occurs
Full
FIFO
Empty
© evosoft GmbH
Terminológia
• Állapottér: 8
• Elérhető: 5
• Átmérő: 3
000
001
100
010
011
101
110
111
• 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
© 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
Exploring…
Új állapotok
• 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)
Kezdeti
állapot
0 1
2
3 4
5
6 7
Átmérő
• 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
Mélység (crank)
© 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
© evosoft GmbH
Assertion-vezérelt szimuláció
• Random stimulus a constraint-ek alapján
• Mindez testbench nélkül
• Tesztek nélkül
Formal Analysis
Assertion-Driven Simulation
Matematikai módszerek
Szimuláció
Szélességi bejárás
Lineáris
Statikus
Dinamikus
prove
search
IFV + IEV
IEV
© evosoft GmbH
Assertion-vezérelt szimuláció
• Constraint-ek nélkül: minden teljesen random
clk
Full
FIFO
Write
Read
Empty
Empty until write
clk
Write
Read
Full
Write1
Read1
Read2
!
hibás működés
Empty
© evosoft GmbH
Assertion-vezérelt szimuláció
• Constraint-ek használata: életszerű gerjesztés
clk
Full
FIFO
Write
Read
Empty
No read when
empty
Empty until write
clk
Write
Read
Write1
Write1
Read1
Read2
Full
Empty
© 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
© 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
clk1
• A reset jelet deaktiváljuk
force rst_n 0
run 4
init –load –current
constraint –add –pin rst_n 1 –reset
prove/search
rst_n
FF-ok állapota betöltve
=
Kezdeti állapot a formal
tool számára
© 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
© evosoft GmbH
Formális nyelvek
© evosoft GmbH
PSL példák
• Property
property p_addr_nonzero = always (addr > 0);
• Assertion
output_no_underflow : assert never (read && empty) @(posedge 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 && req} @(posedge clk);
© evosoft GmbH
IEV tool
© evosoft GmbH
Köszönjük a figyelmet!
Stubna Ágoston
Balotai Péter
ASIC fejlesztő / verifikációs mérnök
ASIC fejlesztő / verifikációs mérnök
evosoft Hungary Kft.
[email protected]
evosoft Hungary Kft.
[email protected]
© evosoft GmbH