Funkční ověření - Functional verification

v automatizace elektronického designu, funkční ověření je úkolem ověřit, že logický design odpovídá specifikaci. Funkční ověření se v každodenních podmínkách pokouší odpovědět na otázku „Dělá tento navrhovaný design to, co je zamýšleno?“ Jedná se o složitý úkol a vyžaduje většinu času a úsilí u většiny velkých projektů návrhu elektronických systémů. Funkční ověření je součástí komplexnějšího ověření návrhu, která kromě funkčního ověření zohledňuje nefunkční aspekty, jako je načasování, rozložení a výkon.

Funkční ověření je velmi obtížné kvůli velkému množství možných testovacích případů, které existují i ​​v jednoduchém designu. Často existuje více než 10 ^ 80 možných testů ke komplexnímu ověření návrhu - což je číslo, kterého je nemožné dosáhnout za celý život. Toto úsilí je ekvivalentní s ověření programu, a je NP-tvrdé nebo ještě hůř - a nenašlo se žádné řešení, které by ve všech případech fungovalo dobře. Může však být napaden mnoha metodami. Žádný z nich není dokonalý, ale každý může být za určitých okolností nápomocný:

  • Logická simulace simuluje logiku před vytvořením.
  • Zrychlení simulace aplikuje speciální hardware na problém logické simulace.
  • Emulace vytváří verzi systému pomocí programovatelné logiky. To je drahé a stále mnohem pomalejší než skutečný hardware, ale řádově rychlejší než simulace. Lze jej použít například k zavedení operačního systému z procesoru.
  • Formální ověření pokusy matematicky dokázat, že jsou splněny určité požadavky (vyjádřené i formálně) nebo že nemůže dojít k určitému nežádoucímu chování (například uváznutí).
  • Inteligentní ověření používá automatizaci k přizpůsobení testovacího stolu změnám v úroveň přenosu registru kód.
  • HDL specifické verze žmolky a další heuristiky se používají k hledání běžných problémů.

Ověření na základě simulace (nazývané také „dynamické ověření ') je široce používán pro „simulaci“ návrhu, protože tato metoda se velmi snadno zvětšuje. Je poskytován stimul k procvičení každého řádku v kódu HDL. Zkušební stolice je postavena tak, aby funkčně ověřila návrh poskytnutím smysluplných scénářů ke kontrole, že vzhledem k určitému vstupu funguje návrh podle specifikace.

Simulační prostředí se obvykle skládá z několika typů komponent:

  • The generátor generuje vstupní vektory, které se používají k hledání anomálií, které existují mezi záměrem (specifikace) a implementací (kód HDL). Tento typ generátoru využívá NP-úplný typ SAT solveru, který může být výpočetně nákladný. Mezi další typy generátorů patří ručně vytvořené vektory, generátory založené na grafech (GBM), vlastní generátory. Moderní generátory vytvářejí řízené a náhodné podněty, které jsou statisticky řízeny k ověření náhodných částí návrhu. Náhodnost je důležitá pro dosažení vysoké distribuce v obrovském prostoru dostupných vstupních podnětů. Za tímto účelem uživatelé těchto generátorů záměrně nedostatečně specifikují požadavky na generované testy. Úkolem generátoru je tuto mezeru náhodně vyplnit. Tento mechanismus umožňuje generátoru vytvářet vstupy, které odhalují chyby, které uživatel přímo nevyhledává. Generátory také zkreslují podněty k návrhům rohových případů, aby dále zdůraznily logiku. Předpětí a náhodnost slouží různým cílům a dochází mezi nimi ke kompromisům, proto mají různé generátory jinou kombinaci těchto charakteristik. Protože vstup pro návrh musí být platný (legální) a mělo by být zachováno mnoho cílů (například předpětí), mnoho generátorů používá problém spokojenosti s omezením (CSP) technika k řešení složitých požadavků na testování. Modelovány jsou legálnost vstupů designu a arzenál předpětí. Generátory založené na modelu používají tento model k vytvoření správných podnětů pro návrh cíle.
  • The Řidiči převést podněty produkované generátorem do skutečných vstupů pro ověřovaný návrh. Generátory vytvářejí vstupy na vysoké úrovni abstrakce, jmenovitě jako transakce nebo jazyk sestavení. Ovladače převádějí tento vstup na skutečné vstupy návrhu, jak jsou definovány ve specifikaci rozhraní návrhu.
  • The simulátor produkuje výstupy návrhu na základě aktuálního stavu návrhu (stav klopných obvodů) a vložených vstupů. Simulátor má popis návrhového síťového seznamu. Tento popis je vytvořen syntézou HDL do seznamu sítí na nízké úrovni brány.
  • The monitor převede stav návrhu a jeho výstupů na úroveň abstrakce transakce, aby mohl být uložen v databázi „score-boards“, kterou lze později zkontrolovat.
  • Kontrola ověří, že obsah „tabulí s výsledky“ je legální. Existují případy, kdy generátor vytváří kromě vstupů také očekávané výsledky. V těchto případech musí kontrola ověřit, že skutečné výsledky odpovídají očekávaným.
  • Správce rozhodčího řízení spravuje všechny výše uvedené komponenty společně.

Odlišný Dosah jsou definovány metriky k posouzení, že návrh byl adekvátně uplatněn. Patří mezi ně funkční pokrytí (byly uplatněny všechny funkce designu?), Pokrytí prohlášení (byla uplatněna každá řada HDL?) A pokrytí větví (byl použit každý směr každé větve?).

Nástroje

Viz také

Reference