asic verifikáció i . 201 3 . 11.18

© evosoft GmbH

ASIC verifikáció I.2013.11.18

© evosoft GmbH

Bemutatkozás

© 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

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

© 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

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

© 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


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

© evosoft GmbH


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:

© evosoft GmbH

A verifikációs feladat

Miért van szükség a verifikációra? Egy másik példa:

DMA RAM

start

Mem. write

Mem. write

Mem. write

final

Data IF

?

data

requestgrant

address

write

request

grant

write

© evosoft GmbH

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


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

© evosoft GmbH

Mibe kerül egy bug?


• A bug-os chip költségei

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)

Gyártási költség:Néhány millió $

© evosoft GmbH

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


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

© 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

© 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

TBStimulus

Testbench

TBMonitor

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...

© evosoft GmbH

Bug-ok felfedése írányított teszttel


Írányított teszt

HDL egy állapota

Tesztelni kívánt állapotBUG-os állapotNem “ü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

Bug-ok felfedése random stimulussal


Random teszt

HDL egy állapota

BUG-os állapotNem “üzemi” állapot


futás1 futá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

© evosoft GmbH

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)

HDL egy állapota



futás1futás2

Állapotok egy tartományaegy tesztre

Constrained random szimuláció

© evosoft GmbH

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.

C

CHDL egy állapota



tesztAfutás1

tesztAfutás2

Állapotok egy tartományaegy tesztre

Corner case

tesztBfutás2

tesztBfutás1

tesztCfutás2

tesztCfutás1

direktteszt

C

Kulcs állapotok

© evosoft GmbH

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

verifikációs tool

testcase (TC)verifikációskörnyezet

szabályoka < 64b > 128

constrainedsolver DUV0101011010

0101100101

szabályoka > 5b < 10

stimulusgenerá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

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


© evosoft GmbH


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


© 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

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

© evosoft GmbH

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

HDL egy állapota



futás1 futás2

“Kulcs” állapotok

© 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


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


© 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


© 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


© 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án• Felosztás a verifikációs környezet felépítése alapján


© 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

© evosoft GmbH



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

© evosoft GmbH



• 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


© evosoft GmbH

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

DUVDevice 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

© evosoft GmbH

White box verifikáció


• Tulajdonságok• A HDL implementáció ismert (átlátszó struktúra)

• Előnyök:

• Hártányok


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

© evosoft GmbH

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)


Reference Model

?=stimulus

© evosoft GmbH

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

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!

© evosoft GmbH

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

Reference Model

stimulus?=

© evosoft GmbH


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)

DUV

Verifikációs környezet

Interfész komponens

Referencia Modell

1011001010

?=

checker

coverage

© evosoft GmbH

Kérdés?

Most jönne: Modul szintű és rendszer szintű verifikáció.Idő?

© evosoft GmbH


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

Modul szint


DUV

Referenciamodell Passzív interfész

komponens

1011001010

?=

HDL modul(aktív)

HDL modul

DUV

Verifikációs környezet

Aktív interfész komponens

Referencia Modell

1011001010

?=

checker

coverage

Chip szint

© evosoft GmbH


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

HDLDUV

HDL HDL

?=?=

© evosoft GmbH


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

?= ?=

© evosoft GmbH

my_asic_1

dma_env

my_asic_2


Ú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

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

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

© 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

Directedstimulus

Constrainedrandom st.

vektorok nincs szimulációnincsenek vektorok

Propertychecking

Equivalencechecking


AssertionDriven Sim.

© evosoft GmbH


• 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

WriteRead

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

© evosoft GmbH

Terminológia

000

100

001

010

101 110 111

011

• Á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

© 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

0 1 2 3 4 5 6 7

Exploring…

Mélység (crank)

Kezdeti állapot

Átmérő

Új állapotok

© 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


• 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


• Constraint-ek nélkül: minden teljesen random

Write1

Read1 Read2

clk

WriteRead

Full

EmptyFIFO

clk

Read

Write

Full

Empty

!hibás működés

Empty until write

© evosoft GmbH


• Constraint-ek használata: életszerű gerjesztés

Write1

Read1 Read2

clk

WriteRead

Full

EmptyFIFO

clk

Read

Write

Full

Empty

No read when empty

Write1

Empty until write

© 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

• A reset jelet deaktiváljukforce rst_n 0run 4init –load –currentconstraint –add –pin rst_n 1 –resetprove/search

clk1

rst_n

FF-ok állapota betöltve=

Kezdeti állapot a formaltool 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

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

Köszönjük a figyelmet!

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

evosoft Hungary [email protected]

Balotai PéterASIC fejlesztő / verifikációs mérnök

evosoft Hungary [email protected]

asic verifikáció i . 201 3 . 11.18

Documents