Az fpga ellenőrzése

Az FPGA ellenőrzése. Mi ez? 6

15.07.15 12:53 •
x0n •
# 262693 •
Habrahabr •
15 •
4448

- ugyanaz, mint Forbes, csak jobb.

A sors akaratával évek óta foglalkozom az FPGA konfigurációk ellenőrzésével. És kezdettől fogva elcsodálkoztam a számtalan információval kapcsolatban.

Ha nem minden, akkor sokan hallottak már az FPGA-ról. Talán néhányan még szorosan együtt dolgoztak velük, de úgy gondolom, hogy kevesebb ember találkozott az FPGA-k projektjeinek ellenőrzésével. Ma beszélni fogok az ellenőrzésről.

Az FPGA funkcionális ellenőrzése az FPGA-konfiguráció hibáinak keresése és rögzítése (további firmware). Meg fogja mondani, hogy mi szükség van az ellenőrzésre az FPGA hibakeresés szakaszában a "vas" -on, mindez javítható. Lehetséges, de rendkívül nehéz.

Először is a "mirigyben" a funkcionális hibák keresése eléggé munkaigényes és időigényes folyamat. Ez késedelmet okoz a projekt befejezésében. Egy meglehetősen komoly projekt esetén a hibakeresés hetekig és hónapokig tarthat. Az ellenőrzés azonban lehetővé teszi, hogy megtalálja és javítsa a legtöbb funkcionális hibát a modell szakaszában.

Azt fogja mondani, hogy egy tapasztalt FPGA fejlesztő nem tesz hibákat, vagy rendkívül kevésnek teszi őket? Ő csinálja! És elég sok.

Az ellenőrzés lehetővé teszi, hogy ne csak az aktuális hibákat, hanem esetleges hibákat is felismerje, amelyek a jövőbeli projektekben megjelenhetnek.

Az ellenőrzés feltételesen megosztható az alábbi lépésekre:

TK fejlesztése;
Ellenőrzési terv kidolgozása;
Karbantartás fejlesztése;
tesztelése;

1. A TOR fejlesztése ellenőrzés céljából

Mint tudják - a TK fejlesztésének kompetens megközelítése sok problémát kiküszöböl a projekt során. Az ellenőrzési TOR-nek leírnia kell az egység teljes és átfogó funkció- és képesség-készletét, amelyet ellenőrizni kell. Ideális esetben az ellenőrző feladatot az ellenőrző csoport csapatának kell megírnia. Ez rendkívül fontos, különösen a tesztelésben részt vevő hitelesítő kevés tapasztalatával. A TOR-nek a következő elemeket kell tartalmaznia:
• azon blokkok felsorolása, amelyek a projekt részét képezik, és amelynek munkáját ellenőrizni kell;
• az összes működési mód, függvények, projekt-lehetőségek felsorolása, amelyek ellenőrzést igényelnek;
• a más projektekből újrahasznosítható funkciók és karbantartási osztályok felsorolása (például a számlák számának kiszámítására vagy az adatátviteli interfészek kezelésére szolgáló funkciókészlet).

Természetesen a TK írásának meg kell kezdődnie, miután megkapta a projektre vonatkozó összes szükséges információt.

2. Az ellenőrzési terv kidolgozása

A tervezési folyamat talán a legfontosabb és legelhagyatottabb funkcionális ellenőrzés. A hitelesítési terv létrehozását a stratégiák és taktikák kidolgozása határozza meg a projekt megkezdése előtt történő munkavégzéshez. Az ellenőrzési terv egy útmutató a projektcsapat számára. Az illetékes ellenőrzési terv nélkül a csapatok gyakran választanak hibás módon.

Az ellenőrzési terv tartalmazza az összes teszt részletes leírását.

Az ellenőrzési terv az FPGA-ellenőrző csoport fő dokumentuma. Az összes későbbi munka e dokumentumon alapul. A Synopsys és a Cadence rendszernek minden "idegen szörnyet" ajánlott a TO fejlődésének megkezdése előtt egy hitelesítési tervvel kezdeni. Valójában az ellenőrzési terv részletesebb TK-t nyújt az ellenőrzéshez.

Az egyes vizsgálatok részletes leírásában fel kell tüntetni az összes szükséges programozható paramétert, az aktuális működési módot, a bemenetet, a kimenetet és a referenciaadatokat.

3. A karbantartás fejlesztése

Nem szabad megfeledkeznünk arról, hogy az FPGA-konfiguráció fejlesztése és az MRO fejlesztése párhuzamosan kell megkezdődni és végrehajtani. Ez a sorrend optimális a projekt fejlesztésének minimális időtartama szempontjából, mivel az ellenőrzési folyamatok az egész projekt fejlesztési idejének több mint 70% -át veszik igénybe.

Az előző lépésekből származó információk alapján megkezdheti a tesztkörnyezet létrehozását (további IT). Rendszerint olyan verziókhoz fejlesztett programozási nyelvek írása, amelyeknek rendelkezésére áll minden szükséges eszköz. A Verilog rendszer az egyik legmegfelelőbb nyelv. Ez a nyelv nagyon hasonló a C ++ -hoz, a kapszulázáshoz, a polimorfizmushoz, az örökléshez.

A tesztkörnyezet kialakítása során nagyon ajánlott, hogy ne feledkezzünk meg az "újrafelhasználhatóságról". Ha nincsenek megfelelő funkciók, akkor írja le őket a lehetséges jövőbeli felhasználás fényében. Ha vannak olyan funkciók, akkor használja. Szükséges a karbantartás megszervezése, hogy minden teszt módosítható legyen anélkül, hogy más tesztek károsodhatnak. Ez a jövőben meg fogja menteni a problémákat, mert mint a tesztelés folyamán, még mindig meg kell adnia néhány változtatást a TO kódban.

4. Vizsgálat

Ebben a szakaszban a hitelesítőnek szorosan együtt kell működnie a fejlesztővel. A tesztek során hibákat észlelnek, és észlelik azokat. Ha nem, akkor azt jelenti, hogy a TO hibásan működik. A hiba észlelése után meg kell adnia a fejlesztőnek a hibát. Ezután a javítás után a hitelesítőnek újra végre kell hajtania a tesztet, és győződjön meg róla, hogy a hiba megszűnt.

Ideális esetben a hibakereső rendszerek használata lenne a hitelesítő és a fejlesztő közötti kommunikáció. Ez lehetővé teszi, hogy később nyomon kövesse azokat a problémákat, amelyek gyakran találkoznak egy adott projektben vagy egy adott fejlesztővel. És ugyanakkor bizonyíték lesz arra, hogy a hitelesítő nem pazarolja kenyerét semmiért.

Gondolom, hozzá kell tenni, hogy nem minden fejlesztő, és nem mindig ismeri el hibáit. Ebben az esetben a TK-ra kell hivatkozni, amelyben egyértelműen ismertetni kell a projekt munkáját.

Segíthet és pénzt küldhet a fejlesztéshez

És kezdettől fogva elcsodálkoztam a számtalan információval kapcsolatban.
Nem értek egyet.

FPGA Firmware a szoftver (bár lehet azzal érvelni, de ebben az összefüggésben az összehasonlítás megfelelő), így annak ellenőrzését hasonló ellenőrzést minden más szoftver. Számos cikk, könyv, módszertan stb. Található a szoftver tesztelésénél.

Azonban a firmware egy "szokatlan" program, és árnyalata van annak, hogyan kell tesztelni. És itt nem segítenek könyveket, mint «SystemVerilog az ellenőrzés» és «írás testbenches segítségével systemverilog», valamint a helyszínek, mint testbench.in, és az ilyen ellenőrzési módszereket, mint UVM, ami kiélezte RTL.

Véleményem szerint van információ a hálózatban :)

Nekem úgy tűnik, hasznosabb lesz a közösség számára, hogy bemutassa a testbench-jét (vagy annak egy részét), megmondja, hogy mi, hogyan és miért teszel, mert a valóságban egy nagy komoly projektben nagyon gyakran nem értenek egyet az interneten található könyvek és cikkek tippjeivel)

Akkor az én hibám. A fejemben "orosz nyelvű információt" írtam, de egyszerűen "információ" -nak írták. Természetesen van elég angol nyelvű irodalom, de a "rendszeres" szoftverek teszteléséhez szakirodalommal összehasonlítva az információ rendkívül szűkös.

Először megadja a definíciót:
Az FPGA-k funkcionális ellenőrzése a hibák keresése és kijavítása
És akkor:
mert az ellenőrzési folyamatokat és a hibaellenőrzést
Ezek közül egyik sem igaz.
Az ellenőrzés nem a hibák keresése és megszüntetése, hanem a termék működésének a TOR szerinti megfelelőségének igazolása.

Az igazolás a végterméknek az előre meghatározott referencia követelményeknek való megfelelését igazolja. Egyszerű szavakkal - a terméket a követelményeknek megfelelően hoztuk létre.
Figyelembe veszi a termék minőségét.

Az érvényesítés az a folyamat, amely bizonyítja, hogy egy adott külső fogyasztó vagy felhasználó, egy termék, szolgáltatás vagy rendszer követelményei teljesülnek.
Egyszerű szavakkal - a megfelelő termékeket hoztuk létre a megfelelő követelményeknek megfelelően. A termékgyártás folyamatának minõségét figyelembe veszik.

mert az ellenőrzési folyamatokat és a hibaellenőrzést
Ezt korrigáltam.
Az FPGA működésének ellenőrzése a hibák keresése és rögzítése
Itt szeretném ezt a definíciót érthetőbb szavakkal leírni, a lényeget közvetíteni.

Az ellenőrzés nem a hibák keresése és megszüntetése, hanem a termék működésének a TOR szerinti megfelelőségének igazolása.
Véleményem szerint a "bizonyíték" szó nem megfelelő. Vagyis, mint hitelesítő, kaptam egy terméket, és be kell bizonyítanom, hogy a termék megfelelően működik? Tehát nem jó. A hitelesítőnek ellenőriznie kell a termék TK megfelelőségét, és ha a termék nem egyezik meg, akkor mondja meg azt, aki ki fogja javítani.

És kezdettől fogva elcsodálkoztam a számtalan információval kapcsolatban.
Nem értek egyet.

Az FPGA firmware szoftver (bár itt érvelhetünk, de ebben az összefüggésben az összehasonlítás megfelelő), ezért az ellenőrzés hasonló bármely más szoftver ellenőrzéséhez. Számos cikk, könyv, módszertan stb. Található a szoftver tesztelésénél.

Véleményem szerint van információ a hálózatban :)

Az igazolás a végterméknek az előre meghatározott referencia követelményeknek való megfelelőségét igazolja. Egyszerű szavakkal - a terméket a követelményeknek megfelelően hoztuk létre.
Figyelembe veszi a termék minőségét.

mert az ellenőrzési folyamatokat és a hibaellenőrzést
Ezt korrigáltam.
Az FPGA-k funkcionális ellenőrzése a hibák keresése és kijavítása
Itt szeretném ezt a definíciót érthetőbb szavakkal leírni, a lényeget közvetíteni.

előző ◈ a következő