Microsemi In-Circuit FPGA hibakeresés

Termékinformáció

Műszaki adatok

• Eszköz típusa: Microsemi SmartFusion2 SoC FPGA
• Megjelenés dátuma: 2014. május
• Hibakeresési lehetőségek: In-Circuit FPGA hibakeresés, beágyazott logikai elemző
• Maximális adatrögzítési frekvencia: 100 MHz-ig

Absztrakt
Az FPGA-k erőteljes tervezési elemek a beágyazott rendszerekben, számos tervezési előnnyeltages, de ezek az eszközök bonyolult kialakításúak lehetnek, bonyolult tervezési problémákkal, amelyek hibakeresést igényelnek. A tervezési problémák, például a definíciós hibák, a rendszerinterakciós problémák és a rendszeridőzítési hibák felkutatása kihívást jelenthet. Az áramkörön belüli hibakeresési képességek bevonása az FPGA-ba drámaian javíthatja a hardveres hibakeresést, és elkerülheti a többórás frusztrációt. Ez a cikk az FPGA-k áramkörön belüli hibakeresésének számos különböző megközelítését ismerteti, azonosítja a legfontosabb kompromisszumokat, és egy ex.ampA Microsemi SmartFusion®2 SoC FPGA eszközt célzó le design bemutatja, hogyan használhatók fel az új képességek a hibakeresés és a tesztelés felgyorsítására.

Bevezetés

Az FPGA-k átfogó és erőteljes tervezési elemek, és ma már szinte minden beágyazott rendszerben megtalálhatók. A kapacitás növekedésével, az összetett chipen belüli funkcionális blokkok és a fejlett soros interfészek beépítésével ezeknek az eszközöknek bonyolult tervezési problémái is adódhatnak, amelyek hibakeresést igényelnek. Az olyan problémák nyomon követése, mint a funkcionális definíciós hibák (FPGA vagy rendszer szinten), a funkcionális rendszer interakciós problémák, a rendszeridőzítési problémák és az IC-k közötti jelhűséggel kapcsolatos problémák (például zaj, áthallás vagy visszaverődés) mind sokkal bonyolultabbá válnak fejlett FPGA-k használatakor. A szimuláció minden bizonnyal nagy segítség számos tervezési probléma azonosításában, de sok valós interakció nem jelenik meg addig, amíg a tervezést nem implementálják a hardverben. A folyamat egyszerűsítése érdekében számos különböző technikát fejlesztettek ki az összetett tervezési problémák hibakeresésére. Ezen kulcstechnikák alapos megértése, beleértve a különféle advanokat istages és hátránytages hasznos, ha megfontoljuk, hogy melyik technika vagy technikák kombinációja alkalmas egy adott tervhez.
Egy voltampA Microsemi SmartFusion2 SoC FPGA eszközhöz készült FPGA kialakítás felhasználható néhány előny bemutatására.tages és hátránytage szabványos technikák, valamint a legújabb, áramkörön belüli hibakeresési lehetőségek. Ez a szemléltető plample fogja mutatni, hogyan használhatók ezek a különféle technikák a hardverhibakeresés során fellépő hardverproblémák azonosításának és kiküszöbölésének felgyorsítására.

Miért kritikus szempont az FPGA hibakeresés a rendszertervezésben és -fejlesztésben?
Az FPGA-knak két fő felhasználási modellje van, amelyek megkülönböztetik őket a többi tervezési elemtől. Az FPGA-k felhasználhatók a gyártási termékben vagy fejlesztési eszközként a gyártási tervezési koncepció bizonyítására vagy prototípusára. Ha sorozatgyártású járműként használják, az FPGA-k sokkal rugalmasabb célpontok lehetnek, mint az ASIC- vagy CPU-alapú sorozatgyártású járművek. Ez különösen fontos egy új dizájn esetében, amely még nem került hardverbe. A különböző építészeti lehetőségeket tartalmazó tervek könnyen létrehozhatók és tesztelhetők, így azonosítható az optimális terv. Az on-chip processzorokkal rendelkező FPGA-k (SoC FPGA-k) lehetővé teszik a CPU-alapú feldolgozás és a hardver által támogatott FPGA-alapú gyorsítási funkciók közötti kompromisszumot is. Ezek advantagdrasztikusan csökkentheti az új termékfejlesztések tervezéséhez, validálásához, teszteléséhez és hibaelemzéséhez szükséges időt.
Ha egy terv prototípusára, esetleg egy éles ASIC-re használják, az FPGA rugalmassága kulcsfontosságú előny. Egy tényleges hardverplatform, még az is, amelyik nem is fut teljes sebességgel, sokkal könnyebbé teszi a részletes rendszerteljesítmény-mutatók, az átviteli sebesség elemzési adatok és az architektúra koncepciójának bizonyítási eredményeinek megszerzését. Az ipari szabványos buszok (például PCIe®, Gigabit Ethernet, XAUI, USB, CAN és mások) megerősített megvalósításainak FPGA-támogatása leegyszerűsíti az ezen interfészekkel kapcsolatos tesztelést. A chipen belüli ARM processzorokkal (SoC FPGA-k) rendelkező FPGA-k legújabb családjai megkönnyítik a beágyazott processzorral rendelkező implementációk prototípusának elkészítését. A korábban kifejlesztett processzorkód portolható a prototípusba, és a hardvertervezéssel párhuzamosan új kód is létrehozható.

A szabványos processzor és a szabványos interfész buszok kombinációja lehetővé teszi a rendelkezésre álló kódkönyvtárak, illesztőprogramok, funkcionális API-k, valós idejű operációs rendszerek és akár teljes operációs rendszerek nagy ökoszisztémájának kihasználását a működő prototípus sokkal gyorsabb létrehozásához. Ezenkívül, ha a terv megszilárdul, az FPGA prototípus használható kiterjedt szimulációs tesztkészletek rögzítésére (mind az ingerre, mind a válaszreakcióra), amelyek tükrözik a tényleges rendszeradatokat. Ezek az adatkészletek felbecsülhetetlen értékűek lehetnek az ASIC vagy más éles megvalósítás végső szimulációinak elkészítésében. Az advantagAz FPGA tervezési prototípusként való használata drámaian csökkentheti a tervezésre, az érvényesítésre, a tesztelésre és a hibaelemzésre fordított időt a végtermék megvalósításához.
Mindkét általános FPGA-használati modellben kulcsfontosságú előnyt jelent az FPGA tervezési célként való rugalmassága.tage. Ez azt jelenti, hogy sok tervezési változtatás és iteráció lenne a norma, és így a tervezési hibák gyors hibakeresésének képessége kritikus fontosságú lenne a lehető legtöbb tervezési lehetőség engedélyezéséhez. Hatékony hibakeresési képesség nélkül az advan nagy részetagAz FPGA tervezési rugalmasságát csökkenti a további hibakeresési idő. Szerencsére az FPGA-k további hardverszolgáltatásokat is biztosíthatnak, amelyek jelentősen leegyszerűsítik a valós idejű hibakeresést. Mielőtt megvizsgálnánk ezeket a képességeket, először nézzük meg azokat a leggyakoribb problémákat, amelyekkel egy FPGA-tervezés szembesülhet, így megfelelő háttérrel rendelkezünk a különböző hibakereső eszközök hatékonyságának és a kapcsolódó kompromisszumoknak a kiértékeléséhez.

Gyakori problémák az FPGA-tervek hibakeresése során

A modern FPGA-k által kínált kibővített képességek mellett a kapcsolódó megnövekedett összetettség megnehezíti a hibamentes tervek létrehozását. Valójában a becslések szerint a hibakeresés a beágyazott rendszer tervezési ciklusának 50%-át átveheti. Mivel a piacra jutáshoz szükséges idő továbbra is megszorítja a fejlesztési ciklust, a kezdeti rendszer hardveres hibakeresése utólagos gondolkodásra szorul – túl gyakran feltételezve, hogy az ellenőrzés (maga is nagy százaléktage) a rendszer első elindítása előtt minden hibát észlel. Nézzünk meg néhány gyakori rendszerproblémát, hogy jobban megértsük azokat a kihívásokat, amelyekkel egy tipikus tervezés szembesül a rendszer kezdeti bevezetése során.

A funkcionális definíciós hibákat kétszeresen nehéz megtalálni, mivel a tervező félreértett egy adott követelményt, így a hiba még akkor is figyelmen kívül hagyható, ha alaposan megvizsgáljuk a tervezés részleteit. Egy exampEgy általános funkcionális definíciós hiba az lenne, ha az állapotgép-átmenet nem a megfelelő állapotba kerül. A hibák interakciós problémaként is megjelenhetnek a rendszerfelületeken. Interfész késleltetés, plample, előfordulhat, hogy helytelenül van megadva, ami váratlan puffer túlcsordulást vagy alulcsordulást eredményezhet.
A rendszerszintű időzítési problémák a tervezési hibák másik nagyon gyakori forrásai. Különösen az aszinkron események gyakori hibaforrások, amikor a szinkronizálás vagy az időzítési tartományok keresztezése nincs gondosan figyelembe véve. Ha nagy sebességgel működik, az ilyen típusú hibák nagyon problematikusak lehetnek, és nagyon ritkán jelenhetnek meg, talán csak akkor, ha konkrét adatminták jelennek meg. Sok gyakori időzítési szabálysértés tartozik ebbe a kategóriába, és általában nagyon nehéz, ha nem lehetetlen szimulálni.

Az időzítés megsértése az integrált áramkörök közötti alacsony jelhűség következménye is lehet, különösen azokban a rendszerekben, ahol minden áramkörhöz több tápsín tartozik. Az alacsony jelhűség jelzajt, áthallást, visszaverődést, túlterhelést és elektromágneses interferencia (EMI) problémákat okozhat, amelyek gyakran időzítési megsértésként jelennek meg. Az áramellátással kapcsolatos problémák, mint például a tranziensek (különösen a rendszer indítása vagy leállítása során), a terhelésingadozások és a nagy teljesítménydisszipációs feszültségek szintén rejtélyes hibákhoz vezethetnek, amelyeket gyakran nem könnyű tápforrásra visszavezetni. Még akkor is, ha a tervezés teljesen megfelelő, a táblagyártási problémák hibákhoz vezethetnek. Hibás forrasztási csatlakozások és nem megfelelően rögzített csatlakozók, plample, hibaforrás lehet, és akár hőmérséklettől vagy a kártya helyétől is függhet. A fejlett FPGA-csomagolási technikák használata megnehezítheti a nyomtatott áramköri lapon lévő jelek szondázását, így a kívánt jelhez való hozzáférés gyakran problémás lehet. Gyakran sok tervezési probléma nem hoz létre azonnali hibát, és át kell terjednie a tervezésen, amíg a hiba ténylegesen meg nem jelenik. A kiindulási hiba visszakövetése a kiváltó okig gyakran frusztráló, nehéz és időigényes feladat lehet.

Plample, ha egyetlen bit is hibás a fordítási táblában, előfordulhat, hogy csak sok ciklussal később okoz hibát. A cikk későbbi részében tárgyalandó eszközök némelyike, amelyek dedikált in-circuit hibakereső hardvert használnak, kifejezetten arra irányulnak, hogy ezeket a „hibavadászatot” gyorsabbá és egyszerűbbé tegye. Mielőtt belemennénk ezeknek az eszközöknek a részleteibe, először nézzünk meg egy népszerű szoftver-alapú hibakeresési technika szimulációt, hogy jobban megértsük az előnyt.tages és hátránytagszimuláció használata hibakereséshez.

Szimuláció használata hibakereséshez
A tervezési szimulációk során jellemzően a tervezésen belüli és kívüli valós komponenseket matematikailag modellezzük szoftverfolyamatként, amelyet szekvenciálisan hajtanak végre egy szabványos CPU-n. Az ingerek széles skálájának alkalmazása a tervezésre, és a várt kimenet összehasonlítása a szimulált tervek kimenetével egyszerű módja a legnyilvánvalóbb tervezési hibák észlelésének. Az alábbi 1. ábrán egy tipikus szimulációs futtatást bemutató ablak látható. A világos advantagA hardver alapú hibakeresés szimulációs versei közül az, hogy a szimuláció a szoftverben is elvégezhető – nincs szükség tényleges hardver alapú tervezésre és tesztpadra. A szimuláció gyorsan elkaphat számos tervezési hibát, különösen azokat, amelyek a helytelen specifikációkkal, az interfész-követelmények félreértésével, a funkcióhibákkal és sok más „durva” típusú hibával kapcsolatosak, amelyeket egyszerű ingervektorok segítségével könnyen észlelhetünk.

A szimuláció különösen akkor hatékony, ha kiterjedt ingerkombinációk állnak a tervező rendelkezésére, és a kapott kimenetek jól ismertek. Ezekben az esetekben a szimuláció szinte kimerítő vizsgálatot végezhet a tervezésben. Sajnos a legtöbb tervnek nincs könnyű hozzáférése kiterjedt tesztkészletekhez, és a létrehozásuk folyamata nagyon időigényes lehet. A tervezés 100%-át lefedő tesztcsomag létrehozása gyakorlatilag lehetetlen nagy FPGA-alapú tervek esetén, és rövidítésekkel kell megpróbálni lefedni a tervezés kulcsfontosságú elemeit. A szimuláció másik nehézsége az, hogy nem „valódi világban” való megvalósítás, és nem képes elkapni az aszinkron eseményeket, a gyors rendszerinterakciókat vagy az időzítési hibákat. Végül a szimulációs folyamat nagyon lassú lehet, és ha sok iterációra van szükség, a szimuláció gyorsan válik a fejlesztési folyamat legidőigényesebb és gyakran legköltségesebb részévé.

Alternatív megoldásként (vagy talán jobban mondva, a szimuláció kiegészítéseként) az FPGA tervezők úgy találták, hogy az FPGA-tervezésbe hibakereső hardvert is adhatnak annak érdekében, hogy megfigyeljék és vezéreljék a kulcsjeleket az eszközön belül. Ezeket a technikákat eredetileg ad-hoc megközelítésként fejlesztették ki, de fokozatosan standard hardver hibakeresési stratégiává fejlődtek. Az áramkörön belüli hibakeresési képességek használata jelentős előnyöket kínáltages az FPGA-alapú tervekhez, a következő rész pedig a három leggyakoribb stratégiát és azok különféle előnyeit vizsgáljatages és hátránytages.

Általános In-Circuit hibakeresési módszerek FPGA-khoz
Az FPGA-kban az áramkörön belüli hibakeresési képességek megvalósításának leggyakoribb technikái beágyazott logikai elemzőt, külső tesztberendezést vagy az FPGA-szövetbe ágyazott dedikált jelszonda hardvert használnak. A beágyazott logikai elemzőt általában FPGA szövet használatával valósítják meg, és beillesztik a tervezésbe. A JTAG A port az analizátor elérésére szolgál, és a rögzített adatok PC-n megjeleníthetők. Külső tesztberendezés használata esetén a tesztelt FPGA-tervezés módosul, így a kiválasztott belső FPGA-jelek a kimeneti érintkezőkhöz kerülnek. Ezek a csapok azután megfigyelhetők a külső vizsgálóberendezésen keresztül. Dedikált jelszonda hardver használata esetén a belső jelek széles választéka olvasható valós időben. Egyes vizsgálómegvalósítások akár regiszterekbe vagy memóriahelyekre való írásra is használhatók, tovább javítva a hibakeresési képességeket. Nézzük meg részletesebben az advanttages és hátránytagmindegyik technikát, majd nézzen meg egy examptervezze meg, hogy megtudja, hogyan befolyásolhatják ezek a különböző megközelítések a teljes hibakeresési időt.

In-Circuit FPGA hibakeresési beágyazott logikai elemző
A beágyazott logikai elemző koncepciója az áramkörön belüli ad-hoc hibakeresési képességek közvetlen eredménye, amelyeket a tervezők az FPGA-k első használatakor implementáltak. A beágyazott logikai elemzők új képességeket adtak hozzá, és megszüntették azt a követelményt, hogy a tervezők saját analizátort fejlesszenek ki. A legtöbb FPGA kínálja ezeket a képességeket, a harmadik felek pedig szabványos analizátorokat kínálnak (az Identify®, a Synopsys egy népszerű ex.ample), amelyek könnyen kapcsolódhatnak magasabb szintű eszközökhöz a termelékenység további javítása érdekében.

A logikai elemző funkcionalitás be van illesztve a tervezésbe, FPGA szövetet és beágyazott memóriablokkokat használva nyomkövetési pufferként, amint azt a 2. ábra szemlélteti. A trigger erőforrásokat is létrehozzák, hogy az összetett jelkölcsönhatások könnyen kiválaszthatók és rögzíthetők. Az analizátorhoz való hozzáférés vezérléshez és adatátvitelhez általában a szabványos J-n keresztül történikTAG port az interfész követelmények egyszerűsítése érdekében. A rögzített adatok PC-n megjeleníthetők a közös használatával viewszoftverrel, és általában tükrözi a logikai szimulátor hullámforma kimenetét viewstílusban.

Az advantagEnnek a megközelítésnek az a lényege, hogy nem használnak további FPGA I/O érintkezőket, csak a szabványos JTAG jeleket. A beágyazott logikai elemző IP magjai általában viszonylag olcsók, és bizonyos esetekben a meglévő FPGA-szintézis vagy szimulációs eszközök opciói lehetnek. Egyes esetekben a beágyazott logikai analizátor további kimeneteket is biztosíthat a nem használt I/O-kon, ha ez kényelmesebb. Az egyik hátránytagEnnek a megközelítésnek az a lényege, hogy nagy mennyiségű FPGA-erőforrásra van szükség. Különösen, ha nyomkövetési puffereket használnak, ez csökkenti a rendelkezésre álló blokkmemóriák számát. Ha széles pufferre van szükség, ez is kompromisszumot jelent a memóriamélységgel szemben (mivel a szélesebb memória használata kisebb memóriamélységet eredményez) – ez nagy hátránytage kisebb eszközök használatakor. Ennek a technikának talán az a legnagyobb hátránya, hogy minden alkalommal, amikor a szonda elhelyezését módosítják, újra kell fordítani és újra kell programozni a tervezést. Nagyméretű készülék használata esetén ez a folyamat jelentős időt vehet igénybe. A jelszondák elrendezésének módja miatt nehéz lehet a jelidőzítési kapcsolatokat korrelálni. Ezenkívül a jelszondák közötti késések nem konzisztensek, és így az időzítési kapcsolatokat nehéz összehasonlítani. Ez különösen nagy nehézséget jelent az aszinkron jelek vagy a különböző időtartományokból származó jelek összehasonlításakor.

In-Circuit FPGA hibakeresés – Külső tesztberendezés
Az áramkörön belüli hibakereső kód használata külső tesztberendezésekkel együtt természetes fejlemény volt, amikor egy külső logikai elemző már elérhető volt a rendszer teszteléséhez. Néhány egyszerű hibakereső kód létrehozásával a belső tesztjelek azonosítására és kiválasztására, valamint az FPGA I/O-kra való alkalmazására, ahogy a 3. ábra mutatja, lehetővé vált az analizátor fejlett képességeinek (például nagy nyomkövetési pufferek, összetett triggerelési szekvenciák és többszörös) kihasználása. viewopciók) egyszerű, de hatékony hibakereső környezetek létrehozásához. A fejlett triggerelési opciók összetettebb áramköri képességei minimalizálhatják a szükséges kimenetek számát. Plample, konkrét címek kiválasztása egy széles buszon túlzó lehet, ha külső érintkezőkre lenne szükség.
A belső FPGA-logika használata jelentősen csökkenti az I/O-követelményeket, és akár meghatározott címminták (esetleg hívási és visszatérési sorrend) keresése is lehetséges az összetettebb problémák hibakereséséhez. Ha elérhető egy közös felhasználói felület, ez leegyszerűsítheti a tanulási görbét és javíthatja a termelékenységet.

Az advantagEnnek a megközelítésnek az a lényege, hogy kihasználja a külső vizsgálóberendezés költségeit, és így nincs több eszközköltség. Néhány hibakereső áramkör IP mag beszerezhető a berendezésgyártóktól vagy az FPGA gyártóktól, és nagyon alacsony költséggel vagy akár ingyenesen is megvásárolható. A jelkiválasztási logika megvalósításához szükséges FPGA erőforrások mennyisége nagyon kicsi, és mivel a nyomkövetési funkció külső logikai elemzővel történik, nincs szükség blokkmemóriákra. Mivel a kijelölési logika olcsó, nagyszámú csatorna széles kioldással is támogatható. A logikai elemző időzítési módban és állapot módban is működhet, ami segít elkülöníteni bizonyos időzítési problémákat.
A hátránytagEz a megközelítés magában foglalhatja egy logikai elemző beszerzésének szükségességét, ha az még nincs hozzárendelve a projekthez. Ezt a hátrányttagEz sok esetben elegendő lehet ahhoz, hogy elriassza ezt a megközelítést. Ne feledje azonban, hogy elérhetővé válik néhány olcsó logikai elemző opció, amely a számítógépet vagy a táblagépet használja a megjelenítéshez, így ez az opció sokkal költséghatékonyabb az egyszerű hibakeresési követelményekhez.
További hátrány lehet az elfogyasztott FPGA tűk számatage és ha széles buszokat kell figyelni, akkor jelentős tervezésre van szükség a kártyaelrendezéshez és a hibakereső csatlakozók hozzáadásához. Ezt a követelményt a legtöbbször nehéz előre megjósolni a tervezési fázis korai szakaszában, és egy másik nem kívánt bonyolultság. A beágyazott logikai elemző megközelítéshez hasonlóan a külső tesztelési stratégia is megköveteli a terv újrafordítását és újraprogramozását, amikor minden új kísérletre van szükség.

A közös hátránytagE két technika közül a chipen belüli erőforrások használata (amely a tervezés időzítési teljesítményét is befolyásolhatja, és további hibakeresési követelményeket támaszthat), a tervezés újrafordításának és újraprogramozásának szükségessége (amely órákkal vagy akár napokkal bővítheti a hibakeresési ütemtervet), a valószínű tesztelési forgatókönyvek azonosításához szükséges előzetes tervezés, valamint a további chip I/O erőforrások használata nélkülözhetetlen megközelítést igényelt. Az egyik válasz az volt, hogy egyes eszközökön dedikált hibakeresési logikát adtak az FPGA-szövethez. Az eredmény az áramkörön belüli hibakeresés hardveres próbák segítségével.

In-Circuit FPGA hibakeresés – Hardverpróbák
A hardveres vizsgálók használata drámaian leegyszerűsíti az FPGA-k áramköri hibakeresési technikáit. Ez a SmartFusion2®SoC FPGA és IGLOO®2 FPGA eszközök Live Probe funkciójaként megvalósított technika dedikált vizsgálóvonalakat ad az FPGA szövethez, hogy megfigyelje bármely logikai elem regiszterbitjének kimenetét. A 4. ábra blokkdiagramja szerint a hardveres szondák két A és B szondacsatornában állnak rendelkezésre.

A kiválasztott regiszterkimenetek (szondapontok), mint az ábra alján található, a két vizsgálócsatorna fölé kerülnek, és ha kiválasztják, az A vagy a B csatornára is alkalmazhatók. Ezeket a valós idejű csatornajeleket ezután el lehet küldeni az eszköz dedikált Probe A és Probe B érintkezőire. A Probe A és Probe B jelek belsőleg is továbbíthatók egy beágyazott logikai analizátorhoz.

Megjegyzendő, hogy a szonda tűinek időzítési jellemzői szabályosak, és elhanyagolható eltérésük van egyik szondapontról a másikra, ami sokkal könnyebbé teszi a valós idejű jelek időzítési jellemzőinek összehasonlítását. Az adatok akár 100 MHz-en is rögzíthetők, így a legtöbb céltervhez megfelelő.
Talán a legfontosabb a szondapontok helye, mivel ezeket nem a megvalósított terv részeként választják ki (dedikált hardveren választják ki, miközben a terv fut az FPGA-n), gyorsan megváltoztathatók a kiválasztási adatoknak az eszközre való elküldésével. Nincs szükség tervezési újrafordításra és újraprogramozásra.
A Live Probe funkció használatának még egyszerűbbé tétele érdekében a kapcsolódó hibakereső szoftvereszköz hozzáfér az összes szondajel helyéhez egy automatikusan generált hibakeresésen keresztül. file. Az 5. ábrán látható módon a jel neve kiválasztható a jellistából, és a kívánt csatornára alkalmazható. Ez még a tervezés futása közben is megtehető, így a tervezésen belüli tapintási tevékenység zökkenőmentes és nagyon hatékony.

Sok esetben a hardveres vizsgálóképesség, mint például a Live Probe, a korábban leírt beágyazott logikai elemzővel és a külső vizsgálati technikákkal együtt használható.

Amint a 6. ábrán látható, a Live Probe képessége a jelek „menet közben” kiválasztására teszi lehetővé a megfigyelt jelek gyors és egyszerű megváltoztatását anélkül, hogy a tervezést újra kellene fordítani. Egy külső logikai analizátor vagy távcső könnyen megfigyelheti a szondázott jeleket, amint az az ábra jobb felső részén látható a dedikált szondakimeneti érintkezőkön. Alternatív megoldásként (vagy esetleg kiegészítésként) a belső logikai analizátor (az ábrán látható ILA Identify blokk) is használható a szonda érintkezőinek megfigyelésére. A szonda jeleit az ILA rögzítheti és megfigyelheti a hullámforma ablakban. A szonda helye a célterv újrafordítása nélkül módosítható.
Vegye figyelembe, hogy a további triggerelési és nyomkövetési képességek a szonda funkcionalitásának javítására használhatók, így még az összetett tervezési problémák is könnyen felismerhetők.

További hardveres hibakeresési lehetőségek is elérhetők a SmartFusion2 SoC FPGA és IGLOO2 FPGA eszközökön. Ezen képességek egyike, az úgynevezett Active Probe, dinamikusan és aszinkron módon képes olvasni vagy írni bármely logikai elem regiszterbitjére. Az írott érték egyetlen óraciklusig megmarad, így a normál működés folytatódhat, így ez egy nagyon értékes hibakereső eszköz. Az Active Probe különösen érdekes, ha egy belső jel gyors megfigyelésére van szükség (talán egyszerűen csak azért, hogy ellenőrizze, hogy az aktív vagy a kívánt állapotban van-e, mint például egy reset jel), vagy ha szükség van egy logikai funkció gyors tesztelésére egy tapintópontba írva.
(talán állapotgép-átmenet kezdeményezése egy bemeneti érték gyors beállításával a vezérlési áramlási probléma elkülönítésére).

Egy másik, a Microsemi által biztosított hibakeresési lehetőség a Memory Debug. Ez a funkció lehetővé teszi a tervező számára, hogy dinamikusan és aszinkron módon olvasson vagy írjon egy kiválasztott FPGA szövet SRAM blokkot. Amint azt a hibakereső eszköz képernyőképe (7. ábra) mutatja, a Memóriablokkok fül kiválasztásakor a felhasználó kiválaszthatja az olvasni kívánt memóriát, pillanatfelvételt készíthet a memóriáról, módosíthatja a memóriaértékeket, majd visszaírhatja az értékeket az eszközre. Ez különösen hasznos lehet a kommunikációs portokban használt adatpufferek ellenőrzéséhez vagy beállításához a számítás-orientált scratch-padhoz vagy akár a beágyazott CPU által végrehajtott kódhoz. Az összetett adatfüggő hibák hibakeresése lényegesen gyorsabb és egyszerűbb, ha az emlékek ilyen gyorsan megfigyelhetők és vezérelhetők.

A terv hibakeresése után kívánatos lehet a hardver hibakeresési képességeinek kikapcsolása az érzékeny információk védelme érdekében. A támadó ugyanezeket a lehetőségeket használhatja kritikus információk kiolvasására vagy rendszerbeállítások módosítására, amelyek lehetővé teszik a rendszer érzékeny részeihez való könnyű hozzáférést. A Microsemi olyan funkciókkal bővült, amelyek lehetővé teszik a tervező számára, hogy biztonságossá tegye az eszközt a hibakeresés befejezése után. PlampLe, a Live Probe és az Active Probe hozzáférés zárolható a funkció, mint lehetséges támadási eszköz teljes letiltásához (még annak a lehetőségét is kiküszöböli, hogy a szonda tevékenysége olyan mintákat hozzon létre a tápáramban, amely felhasználható a szonda adatok közvetett megfigyelésére). Alternatív megoldásként a terv kiválasztott részeihez való hozzáférést letilthatja, hogy megakadályozza a hozzáférést csak ezekhez a szakaszokhoz. Ez kényelmes lehet, ha a tervnek csak egy részét kell biztonságossá tenni, így a terv többi része továbbra is elérhető a helyszíni tesztelés vagy hibaelemzés során.

In-Circuit Debug összehasonlító táblázat
Most, hogy egy részletes review a három fő áramkörön belüli hardver hibakeresési technikából egy összefoglaló táblázat készült, amint az a 8. ábrán látható, amely részletezi a különféle előnyöket.tages és hátránytages az egyes módszerek. Emlékezzünk arra, hogy egyes technikák együtt is használhatók (Live Probe és Internal Logic Analyzer (ILA), például a Synopsys Identify, pl.ample), láthatjuk az egyes technikák legfontosabb erősségeit és gyengeségeit. Az áramkörön belüli hardveres hibakeresési képességek gyűjteménye (Live Probe, Active Probe és Memory Debug – gyűjtőnéven SmartDebug) a többi technikához képest a leggyengébb a rendelkezésre álló összes vizsgálószám tekintetében (piros kör), és gyengébb a legjobbnál (sárga kör), ha a rögzítési sebességet vesszük figyelembe (a külső tesztberendezés gyorsabb is lehet).
Az ILA-alapú technikák, mint például a Synopsys Identify, a leggyengébbek a többi technikához képest, és ha figyelembe vesszük az FPGA erőforrásigényét. A külső tesztberendezésen alapuló technikák számos megfontolásból a leggyengébbek, a költségek, a tervezési időzítés hatása és a szonda mozgásának többlete (a terv újrafordításának szükségessége miatt) a legmegterhelőbb. Talán az optimális megoldás a SmartDebug és egy másik technika kombinációja, így a SmartDebug csatornaszám-gyengesége mérsékelhető és a szondapont mozgásának hátránya.taga többi technikát is csökkentik.

A jelek osztályozása
Hasznos különbséget lehet tenni a leggyakoribb jeltípusok között, és ez segíthet a hibakeresési megközelítés megtervezésekor. PlampAzok a jelek, amelyek a rendszerindításon kívül nem változnak, mint például a rendszer visszaállítása, a blokk visszaállítása vagy az inicializálási regiszterek, statikus jelek közé sorolhatók. Az ilyen típusú jelek a leghatékonyabban egy olyan eszközön keresztül érhetők el, amely könnyen megfigyelheti és vezérli a jelet, anélkül, hogy hosszú újrafordítási ciklusra lenne szükség. Az Active Probe kiváló lehetőség statikus jelek hibakeresésére. Hasonlóképpen, azok a jelek, amelyek gyakrabban változnak, de az idő túlnyomó részében még mindig statikusak, pszeudostatikusnak minősíthetők, és az Active Probe segítségével a leghatékonyabban hibakereshetők. A gyakran változó jelek, mint az órajelek, dinamikusnak minősíthetők, és nem érhetők el olyan könnyen az Active Probe-on keresztül. A Live Probe jobb választás ezeknek a jeleknek a megfigyelésére.

Egyszerű hibakeresési használati eset

Most, hogy jobban megértjük a különféle in-circuit hibakeresési lehetőségeket, nézzünk meg egy egyszerű tervezési példát.amphogy lássuk, hogyan működnek ezek a technikák. A 9. ábra egy egyszerű FPGA-tervet mutat egy SmartFusion2 SoC FPGA-eszközben. A mikrovezérlő alrendszert (MSS) a CoreSF2Reset Soft IP blokk alaphelyzetbe állítja. Ennek a blokknak a bemenetei a Power On Reset, a User Fabric Reset és a External Reset. A kimenetek a felhasználói szövet visszaállítása, az MSS alaphelyzetbe állítása és az M3 alaphelyzetbe állítása. A hibatünetek az, hogy nincs tevékenység az I/O-kon annak ellenére, hogy az eszköz sikeresen kilép a POR állapotból. A hiba elhárításának három különböző lehetőségét az ábra is szemlélteti: A kék doboz (ETE felirattal) a Külső tesztberendezés módszerre vonatkozik; a zöld doboz (ILA felirattal) az Internal Logic Analyzer módszerhez tartozik; a narancssárga doboz (AP felirattal) pedig az Active Probe metódusé. Feltételezzük, hogy a hiba lehetséges kiváltó okai a CoreSF2Reset Soft IP blokk hibásan érvényesített visszaállítási bemenetei.

Most nézzük meg a hibakeresési folyamatot a korábban leírt, áramkörön belüli módszerek közül háromnál.

Külső tesztberendezés
Ennél a módszernél feltételezzük, hogy a tesztberendezés elérhető, és nem egy magasabb prioritású projekt használja. Ezenkívül fontos előre megtervezni, hogy néhány FPGA I/O elérhető legyen, és könnyen csatlakoztatható legyen a tesztberendezéshez. Ha van egy fejléc a NYÁK-on pl.ample, nagyon hasznos lenne, és minimálisra csökkentené a „valószínű gyanúsított” azonosítására és a hozzá való csatlakozásra fordított időt, vagy a tűk lehetséges rövidzárlatát a szondázás során. A tervet újra kell fordítani, hogy kiválaszthassuk a vizsgálni kívánt jeleket. Remélhetőleg nem „hámozzuk vissza a hagymát”, és további jeleket kell kiválasztanunk a további vizsgálathoz, mivel az első vizsgálatunk gyakran csak több kérdést vet fel. Mindenesetre az újrafordítási és újraprogramozási folyamat jelentős időt vehet igénybe, és ha időzítési szabálysértéseket okoz, újratervezésre van szükség (mindannyian ismerjük, milyen frusztráló lehet az időzítési zárási problémák megoldása, különösen akkor, ha a tervezési hibákat keresve módosítja a tervezést – a teljes folyamat percektől órákig tarthat)! Azt is fontos megjegyezni, hogy ha a tervnek nincsenek szabad felhasználói I/O-i, akkor ez a módszer nem implementálható. Ezenkívül ez a módszer szerkezetileg tolakodó a tervezésben – és az időzítéssel kapcsolatos hibák eltűnhetnek vagy újra megjelenhetnek az iterációk között.

Belső logikai elemző
Ezzel a módszerrel az ILA-t be kell illeszteni a tervbe szöveti erőforrások segítségével, majd újra kell fordítani. Megjegyzendő, hogy ha az ILA már példányosítva van, akkor előfordulhat, hogy a vizsgálni kívánt jelek nincsenek műszerezve, ami szintén újrafordítást igényel. Ez a folyamat azt kockáztatja, hogy megváltozik az eredeti terv, és megsérti az időzítési korlátozásokat. Ha az időzítés teljesül, a tervezést újra kell programozni és újra kell inicializálni. Ez az egész folyamat több percet vagy akár órákat is igénybe vehet, ha az újrafordítási idők hosszúak, és több lépésre van szükség. Ez a megközelítés szerkezetileg tolakodó, és hasonló problémákhoz vezethet, mint a fenti módszer használatakor.

Aktív szonda
Ezzel a módszerrel az Active Probe a különböző resetjelek forrására irányítható, amelyek mindegyike regiszterkimenetekből származik (ahogy ez minden jó digitális tervezési gyakorlatban megszokott). A jelek egyenként kerülnek kiválasztásra az alábbi 10. ábrán látható Active Probe menüből. A kiválasztott jelértékek leolvashatók és megjelennek az Active Probe adatablakban. Minden téves állítás könnyen azonosítható. Ez a teszt azonnal elvégezhető az eszköz újrafordítása és újraprogramozása nélkül, és nem strukturálisan vagy eljárásilag tolakodó. Az egész folyamat mindössze néhány másodpercet vesz igénybe. Ez a módszer vezérelhetőséget is létrehozhat (az értékek aszinkron megváltoztatása), amit a másik két módszer nem tesz lehetővé. Ebben a konkrét exampLe, a regiszterből származó visszaállítási jel könnyen ellenőrizhető és aktív állapotban tartható.

A visszaállító jel pillanatnyi átkapcsolása a többi jelet generáló regiszter aszinkron manipulálásával érhető el.

Összetettebb hibakeresési használati eset
A fenti tervezés nagyon egyszerű volt, és hasznos bevezetőként a leírt tervezési technikák használatába, de egy összetettebb példaample talán még szemléletesebb. Sokszor az érdeklődés jelzése nem statikus jel, mint az egyszerű példánkban voltampde dinamikus. Egy gyakori dinamikus jel egy közbenső óra, amelyet talán soros interfész kézfogásának időzítésére használnak. A 11. ábra egy ilyen kialakítást mutat be a felhasználói Soft IP maggal, ebben az esetben egy egyedi soros interfésszel, amely a rendszer APB buszához csatlakozik. A hibatünetek az, hogy nincs tevékenység a felhasználói egyéni soros interfészen, és amikor egy APB-busz-mester tranzakciót ad ki a soros interfész eléréséhez, kivételes állapotba kerül, ami helytelen kézfogást jelez. Úgy tűnik, hogy ezek a feltételek kizárnak egy statikus okot, például egy helytelen visszaállítási jelet, mivel úgy tűnik, hogy a tranzakció állapotú gépe nem a várt sebességgel működik, és így kivételt okoz. A kiváltó ok a felhasználói IP magon belüli órajel-frekvencia-generátornak tekinthető.

Ha nem a megfelelő frekvencián fut, akkor a leírt hibák lépnek fel.

Ebben a helyzetben valószínűleg jobb stratégia az Active Probe megközelítést a Live Probe-ra cserélni. Ezt szemlélteti a fenti ábrán a narancssárga színű LP doboz, a JTAG jel a szondaforrás kiválasztásához.

Külső tesztberendezés
Ebben az esetben a módszertan nagyon hasonlít a korábban leírt egyszerű példáhozample. A felhasználói órajel kikerül a tesztpontra (remélhetőleg fejlécen), és időigényes újrafordításra van szükség. Hasznos lehet egy referenciajel előhívása is, esetleg egy rendszeróra, amelyet összehasonlító jelként használnak a felhasználók IP-címének ütemezésére. Ismét szükségünk lesz újrafordításra és újraprogramozásra, így a teljes folyamat jelentős időt vehet igénybe.

Belső logikai elemző
Ez az eset nagyon hasonlít az egyszerű example. Az ILA-t be kell illeszteni, vagy meg kell határozni a kívánt jelet, és végre kell hajtani egy újrafordítási és újraprogramozási ciklust. Az összes korábban leírt probléma továbbra is jelentős hibakeresési ciklusidőt eredményez. Van azonban egy további bonyolultság is. Az ILA-t vezérlő órának szinkronnak kell lennie, és ideális esetben sokkal gyorsabbnak kell lennie a felhasználói Soft IP-magból megfigyelhető órához képest. Ha ezek az órák aszinkronok, vagy nem rendelkeznek a megfelelő időzítési kapcsolatokkal, az adatrögzítés kiszámíthatatlan, és zavart okozhat a hibakeresési folyamatban.
Vegye figyelembe, hogy ha a felhasználó Soft IP órája nem a chipen generálódik (talán a soros interfészről van visszaállítva), akkor előfordulhat, hogy a tervezőnek egy óramodult kell hozzáadnia egy gyorsabb ILA óra létrehozásához, további erőforrások felhasználásával, és esetleg időzítési szabálysértést okozva.

Élő szonda
Ezzel a módszerrel a Live Probe gyorsan rámutathat a felhasználói óra forrására és bármely más óraforrásra egy regiszterből, hogy felderítse a hiba kiváltó okát. A Live Probe valós időben mutatja a kiválasztott jelkimeneteket, így a jelek közötti időbeli kapcsolat sokkal könnyebben meghatározható. Az egész folyamat mindössze néhány másodpercet vesz igénybe.

Egyéb hibakeresési szolgáltatások soros interfészekhez
Azt is fontos kiemelni, hogy a SmartFusion2 SoC FPGA és IGLOO2 FPGA eszközökben számos további hibakeresési lehetőség található, amelyek soros interfészeken használhatók, mint például az előző ex.ample design, ahol a hibák még bonyolultabbak. SERDES Debug, plample, speciális hibakeresési lehetőségeket biztosít a dedikált nagy sebességű soros interfészek számára. A SERDES Debug egyes szolgáltatásai közé tartozik a PMA teszt támogatás (például PRBS minta generálása és visszacsatolási tesztelés), több SERDES tesztkonfiguráció támogatása regiszterszintű újrakonfigurálással, hogy elkerülhető legyen a teljes tervezési folyamat a konfiguráció módosításához, valamint szöveges jelentések, amelyek bemutatják a konfigurált protokollokat, a SERDES konfigurációs regisztereket és a sávkonfigurációs regisztereket. Ezek a funkciók sokkal könnyebbé teszik a SERDES hibakeresést, és a Live Probe és az Active Probe funkcióval együtt használhatók az összetett áramkörök hibakeresésének további felgyorsítására.
A korábban leírt Memory Debug eszköz a SERDES Debug-gal együtt is használható a tesztelés felgyorsítására. Mivel a memóriapufferek gyorsan és egyszerűen ellenőrizhetők és módosíthatók a Memory Debug segítségével, lehetőség nyílik gyors "tesztcsomagok" létrehozására és a visszahurkolási vagy rendszerközi kommunikáció eredményeinek megfigyelésére. A tervező kihasználhatja ezeket a képességeket, és így minimálisra csökkentheti a speciális „teszt kábelkötegek” szükségességét, amelyek további FPGA-szövetet fogyasztanak, és befolyásolhatják a chip időzítését.

Következtetés
Ez a cikk részletesen ismerteti az FPGA-k és SoC FPGA-k áramkörön belüli hibakeresésének megvalósításának számos különböző megközelítését – az integrált logikai elemző használatát, a külső tesztberendezések használatát, valamint az FPGA-szövetbe integrált, dedikált vizsgálóáramkörök használatát. A speciális és dedikált vizsgáló áramkörök, például a Microsemi által a SmartFusion2 SoC FPGA és IGLOO2 FPGA eszközökön kínált Active Probe és Live Probe hozzáadása jelentősen felgyorsítja és leegyszerűsíti a hibakeresési folyamatot. A belső jelek kiválasztásának gyors módosításának képessége (anélkül, hogy nagyon időigényes újrafordítási és újraprogramozási ciklust kellett volna végrehajtani), valamint a belső jelek vizsgálatának képessége (anélkül, hogy szükség lenne az FPGA-szövet használatára és potenciálisan időzítési hibák bevezetésére) jelentős előnynek bizonyult.tages az FPGA tervek hibakeresésekor. Ezenkívül ismertették több módszertan használatát is, amelyek együttesen még átfogóbb hibakeresési képességet biztosítanak. Végül két example debug használati eseteket adtunk a leírt módszerek közötti kompromisszumok szemléltetésére.

További információért

1. IGLOO2 FPGA-k
2. SmartFusion2 SoC FPGA-k

A Microsemi Corporation (Nasdaq: MSCC) félvezető- és rendszermegoldások átfogó portfólióját kínálja a kommunikációs, védelmi és biztonsági, repülési és ipari piacokhoz. A termékek közé tartoznak a nagy teljesítményű és sugárzásálló analóg vegyes jelű integrált áramkörök, FPGA-k, SoC-k és ASIC-k; energiagazdálkodási termékek; időzítő és szinkronizáló eszközök és precíz időmegoldások, amelyek a világ időmércéjét állítják fel; Hangfeldolgozó eszközök; RF megoldások; diszkrét alkatrészek; biztonsági technológiák és méretezhető anti-tamper termékek; Power-over-Ethernet IC-k és midspans; valamint egyedi tervezési képességek és szolgáltatások. A Microsemi központja a kaliforniai Aliso Viejoban található, és világszerte körülbelül 3,400 alkalmazottat foglalkoztat. További információ: www.microsemi.com.

© 2014 Microsemi Corporation. Minden jog fenntartva. A Microsemi és a Microsemi logó a Microsemi Corporation védjegyei. Minden egyéb védjegy és szolgáltatási védjegy a megfelelő tulajdonosok tulajdona.

Microsemi vállalati központ

• Egy Enterprise, Aliso Viejo CA 92656 USA
• Belül USA: +1 800-713-4113
• Kívül USA: +1 949-380-6100
• Értékesítés: +1 949-380-6136
• Fax: +1 949-215-4996
• Email: sales.support@microsemi.com

GYIK

• K: Mekkora az eszköz maximális adatrögzítési gyakorisága?
  V: Az eszköz 100 MHz-ig támogatja az adatrögzítést, amely a legtöbb céltervezéshez alkalmas.
• K: Újra kell fordítanom a tervet, ha vizsgáló áramköröket használok hibakereséshez?
  V: Nem, a szondapontok helye gyorsan megváltoztatható anélkül, hogy a tervezés újrafordítása vagy újraprogramozása szükséges lenne.

Dokumentumok / Források

Microsemi In-Circuit FPGA hibakeresés [pdfUtasítások In-Circuit FPGA Debug, FPGA Debug, Debug

Hivatkozások

• Felhasználói kézikönyv