Navodila za odpravljanje napak FPGA v vezju Microsemi

Vsebina skriti

1 Microsemi In-Circuit FPGA Debug

2 Informacije o izdelku

3 Uvod

4 Pogoste težave pri odpravljanju napak v načrtih FPGA

5 Preprost primer uporabe za odpravljanje napak

Microsemi In-Circuit FPGA Debug

Informacije o izdelku

Specifikacije

Vrsta naprave: Microsemi SmartFusion2 SoC FPGA

Datum izdaje: maj 2014
Zmogljivosti odpravljanja napak: odpravljanje napak v vezju FPGA, vgrajeni logični analizator

Največja frekvenca zajemanja podatkov: do 100MHz

Povzetek
FPGA so močni oblikovalski elementi v vgrajenih sistemih s številnimi oblikovalskimi napredkitages, vendar imajo te naprave lahko zapleteno zasnovo z zapletenimi težavami pri zasnovi, ki jih je treba odpraviti. Izsleditev težav z zasnovo, kot so napake v definiciji, težave s sistemsko interakcijo in sistemske časovne napake, je lahko izziv. Vključitev zmožnosti odpravljanja napak v vezju v FPGA lahko dramatično izboljša odpravljanje napak strojne opreme in se izogne neštetim uram frustracij. Ta članek opisuje več različnih pristopov k odpravljanju napak v vezju za FPGA, identificira ključne kompromise in prek exampLe design, namenjen za napravo Microsemi SmartFusion®2 SoC FPGA, bo pokazal, kako je mogoče uporabiti nove zmogljivosti za pospešitev odpravljanja napak in testiranja.

Uvod

FPGA so prodorni in zmogljivi elementi oblikovanja in jih zdaj najdemo v skoraj vsakem vgrajenem sistemu. Z naraščajočo zmogljivostjo, vključitvijo zapletenih funkcionalnih blokov na čipu in naprednih serijskih vmesnikov imajo lahko te naprave tudi zapletene težave pri načrtovanju, ki jih je treba odpraviti. Odkrivanje težav, kot so napake v funkcionalni definiciji (na ravni FPGA ali sistemske ravni), težave pri interakciji funkcionalnega sistema, težave s časovno razporeditvijo sistema in težave z zvestobo signala med IC-ji (kot so šum, presluh ali odboji), vse postane veliko bolj zapleteno pri uporabi naprednih FPGA. Simulacija je vsekakor v veliko pomoč pri prepoznavanju številnih težav pri načrtovanju, vendar se mnoge interakcije v resničnem svetu ne bodo pokazale, dokler načrt ni implementiran v strojno opremo. Za poenostavitev postopka je bilo razvitih več različnih tehnik za odpravljanje napak pri zapletenih konstrukcijskih težavah. Natančno razumevanje vsake od teh ključnih tehnik, vključno z različnimi naprednimitages in disadvantages, je uporabna pri odločanju, katera tehnika ali kombinacija tehnik je primerna za določen dizajn.
Bivšiampzasnovo FPGA, namenjeno napravi Microsemi SmartFusion2 SoC FPGA, je mogoče uporabiti za prikaz nekaterih naprednihtages in disadvantagteh standardnih tehnik kot tudi najnovejše zmožnosti odpravljanja napak v vezju. Ta ilustrativni exampLe bo pokazal, kako lahko te različne tehnike uporabimo za pospešitev prepoznavanja in odpravljanja težav s strojno opremo med odpravljanjem napak v strojni opremi.

Zakaj je odpravljanje napak FPGA kritičen vidik načrtovanja in razvoja sistema?
FPGA imajo dva glavna modela uporabe, ki jih razlikujeta od drugih elementov oblikovanja. FPGA se lahko uporabijo v proizvodnem izdelku ali pa se lahko uporabijo kot razvojno sredstvo za dokazovanje ali prototip koncepta proizvodnega načrta. Ko se uporabljajo kot proizvodno vozilo, so lahko FPGA veliko bolj prilagodljiva tarča kot proizvodna vozila ASIC ali CPE. To je še posebej pomembno za novo zasnovo, ki še ni bila implementirana v strojno opremo. Dizajne z različnimi arhitekturnimi možnostmi je mogoče preprosto ustvariti in preizkusiti, tako da se določi optimalna zasnova. FPGA s procesorji na čipu (SoC FPGA) omogočajo tudi kompromis med obdelavo, ki temelji na CPE, s funkcijami pospeševanja, ki temeljijo na strojni opremi FPGA. Ti naprednitages lahko dramatično zmanjša čas, potreben za načrtovanje, validacijo, testiranje in analizo napak za razvoj novih izdelkov.
Pri uporabi za izdelavo prototipov zasnove, morda za proizvodni ASIC, je prilagodljivost FPGA ključna prednost. Dejanska platforma strojne opreme, tudi tista, ki ne deluje s polno hitrostjo, omogoča veliko lažje pridobivanje podrobnih meritev delovanja sistema, podatkov o analizi prepustnosti in rezultatov dokazov o konceptu arhitekture. Podpora FPGA za utrjene izvedbe industrijskih standardnih vodil (kot so PCIe®, Gigabit Ethernet, XAUI, USB, CAN in drugi) poenostavlja testiranje, povezano s temi vmesniki. Najnovejše družine FPGA s procesorji ARM na čipu (SoC FPGA) olajšajo izdelavo prototipov z vgrajenimi procesorji. Prej razvito procesorsko kodo je mogoče prenesti v prototip in novo kodo ustvariti vzporedno z načrtovanjem strojne opreme.

Ta kombinacija standardnega procesorja s standardnimi vmesniškimi vodili omogoča izkoriščanje velikega ekosistema razpoložljivih knjižnic kode, gonilnikov, funkcionalnih API-jev, operacijskih sistemov v realnem času in celo celotnih operacijskih sistemov za veliko hitrejšo izdelavo delujočega prototipa. Poleg tega se lahko prototip FPGA, ko je zasnova utrjena, uporabi za zajemanje obsežnih simulacijskih testnih nizov (tako za dražljaje kot za odzive), ki odražajo dejanske sistemske podatke. Ti nabori podatkov so lahko neprecenljivi pri ustvarjanju končnih simulacij za ASIC ali drugo produkcijsko implementacijo. PrednosttagUporaba FPGA kot oblikovalskega prototipa lahko dramatično zmanjša čas za načrtovanje, validacijo, testiranje in analizo napak za izvedbo končnega izdelka.
V obeh teh običajnih modelih uporabe FPGA je prilagodljivost FPGA kot cilj oblikovanja ključna prednosttage. To pomeni, da bi bile številne spremembe načrta in ponovitve norma, zato bi bila zmožnost hitrega odpravljanja napak pri načrtovanju ključnega pomena za omogočanje čim več možnosti načrtovanja. Brez učinkovite zmožnosti odpravljanja napak veliko napredkatagPrilagodljivost zasnove FPGA bo zmanjšana zaradi dodatnega potrebnega časa za odpravljanje napak. Na srečo lahko FPGA zagotovijo tudi dodatne funkcije strojne opreme, ki dramatično poenostavijo odpravljanje napak v realnem času. Preden si ogledamo te zmožnosti, si najprej poglejmo najpogostejše vrste težav, s katerimi se lahko sooča zasnova FPGA, da bomo imeli ustrezno ozadje za oceno učinkovitosti in povezanih kompromisov različnih orodij za odpravljanje napak.

Pogoste težave pri odpravljanju napak v načrtih FPGA

Skupaj z razširjenimi zmožnostmi, ki jih prinašajo sodobne FPGA, je s tem povezana večja kompleksnost težje ustvariti načrte brez napak. Pravzaprav je bilo ocenjeno, da lahko odpravljanje napak prevzame več kot 50 % cikla oblikovanja vgrajenega sistema. Ker pritiski glede časa za vstop na trg še naprej zožujejo razvojni cikel, je odpravljanje napak v strojni opremi začetnega sistema premišljeno – vse prepogosto ob predpostavki, da preverjanje (samo velik odstotektage razvojnega načrta), bo ujel vse hrošče pred začetnim zagonom sistema. Oglejmo si samo nekaj pogostih vrst sistemskih težav, da bomo bolje razumeli izzive, s katerimi se bo soočila tipična zasnova med začetnim dvigom sistema.

Napake v funkcionalni definiciji je lahko dvojno težko najti, ker je načrtovalec napačno razumel določeno zahtevo, tako da je napako mogoče spregledati, tudi če natančno preučujemo podrobnosti zasnove. Bivšaampnapaka običajne funkcionalne definicije bi bila, če prehod državnega stroja ne konča v pravem stanju. Napake se lahko pojavijo tudi v sistemskih vmesnikih kot težava med interakcijo. Zakasnitev vmesnika, nprample, je morda nepravilno podana, kar povzroči nepričakovano prekoračitev ali premajhno stanje medpomnilnika.
Težave s časovnim razporedom na sistemski ravni so še en zelo pogost vir napak pri načrtovanju. Zlasti asinhroni dogodki so pogost vir napak, ko učinki sinhronizacije ali križanja časovne domene niso skrbno upoštevani. Pri hitrem delovanju so te vrste napak lahko zelo problematične in se lahko pojavijo zelo redko, morda samo takrat, ko se pokažejo specifični vzorci podatkov. V to kategorijo sodi veliko običajnih časovnih kršitev in jih je običajno zelo težko, če ne celo nemogoče simulirati.

Kršitve časovne razporeditve so lahko tudi posledica nizke zvestobe signala med integriranimi vezji, zlasti v sistemih z več napajalnimi vodili za vsako vezje. Nizka zvestoba signala lahko povzroči šum signala, preslušavanje, odboje, prekomerno obremenitev in težave z elektromagnetnimi motnjami (EMI), ki se pogosto pokažejo kot časovne kršitve. Težave z oskrbo z električno energijo, kot so prehodni pojavi (zlasti med zagonom ali zaustavitvijo sistema), variacije obremenitve in velike obremenitve zaradi izgube moči, lahko povzročijo tudi skrivnostne napake, ki jih pogosto ni enostavno izslediti nazaj do vira napajanja. Tudi če je načrt popolnoma pravilen, lahko težave pri izdelavi plošče povzročijo napake. Napačni spajkalni spoji in nepravilno pritrjeni konektorji, nprample, je lahko vir napak in je lahko celo odvisna od temperature ali lokacije plošče. Uporaba naprednih tehnik pakiranja FPGA lahko oteži preizkušanje signalov na tiskanem vezju, zato je lahko samo dostop do želenega signala pogosto problematičen. Pogosto številne težave z zasnovo ne povzročijo takojšnje napake in se morajo širiti po zasnovi, dokler se napaka dejansko ne pokaže. Iskanje napake pri zagonu nazaj do temeljnega vzroka je lahko pogosto frustrirajoča, težka in dolgotrajna naloga.

Na primerample en sam bit, ki je napačen v prevajalski tabeli, lahko povzroči napako šele čez veliko ciklov. Nekatera orodja, o katerih bomo razpravljali pozneje v tem dokumentu, ki uporabljajo namensko strojno opremo za odpravljanje napak v vezju, so posebej namenjena hitrejšemu in lažjemu "iskanju hroščev". Preden se lotimo podrobnosti teh orodij, si najprej oglejmo priljubljeno simulacijo tehnike odpravljanja napak, ki temelji na programski opremi, da bi bolje razumeli napredektages in disadvantaguporabe simulacije za odpravljanje napak.

Uporaba simulacije za odpravljanje napak
Običajno so v simulaciji zasnove vse resnične komponente znotraj in zunaj zasnove matematično modelirane kot procesi programske opreme, ki se izvajajo zaporedno na standardnem CPE. Uporaba širokega razpona dražljajev za načrtovanje in preverjanje pričakovanega rezultata v primerjavi z rezultatom simuliranega dizajna je preprost način za odkrivanje najbolj očitnih napak pri načrtovanju. Okno, ki prikazuje tipičen potek simulacije, je prikazano na sliki 1 spodaj. Jasen napredektagOd simulacije v primerjavi z odpravljanjem napak na podlagi strojne opreme je simulacija mogoča v programski opremi – dejanska zasnova na podlagi strojne opreme in preskusna naprava nista potrebna. Simulacija lahko hitro odkrije številne napake pri načrtovanju, zlasti tiste, povezane z nepravilnimi specifikacijami, nerazumevanjem zahtev vmesnika, napakami v delovanju in številnimi drugimi "grobimi" vrstami napak, ki jih zlahka zaznamo s preprostimi vektorji dražljajev.

Simulacija je še posebej učinkovita, ko so načrtovalcu na voljo obsežne kombinacije dražljajev in so posledični rezultati dobro znani. V teh primerih lahko simulacija izvede skoraj izčrpen preizkus zasnove. Na žalost večina modelov nima preprostega dostopa do obsežnih testnih zbirk in postopek njihovega ustvarjanja je lahko zelo zamuden. Ustvarjanje nabora testov, ki pokriva 100 % zasnove, je praktično nemogoče za velike zasnove, ki temeljijo na FPGA, zato je treba uporabiti bližnjice, da poskusite pokriti ključne elemente zasnove. Druga težava s simulacijo je, da ni implementacija v "resničnem svetu" in ne more ujeti asinhronih dogodkov, sistemskih interakcij pri hitri hitrosti ali časovnih kršitev. Nazadnje, proces simulacije je lahko zelo počasen in če je potrebnih veliko iteracij, simulacija hitro postane najbolj zamuden in pogosto najdražji del razvojnega procesa.

Kot alternativo (ali morda bolje rečeno kot dodatek k simulaciji) so oblikovalci FPGA ugotovili, da bi lahko v zasnovo FPGA dodali strojno opremo za odpravljanje napak, da bi opazovali in nadzorovali ključne signale v napravi. Te tehnike so se prvotno razvile kot ad hoc pristopi, vendar so se postopoma razvile v standardno strategijo odpravljanja napak strojne opreme. Ta uporaba zmožnosti odpravljanja napak v vezju ponuja pomemben napredektages za modele, ki temeljijo na FPGA, naslednji razdelek pa bo raziskal tri najpogostejše strategije in njihove različne prednosti.tages in disadvantages.

Pogosti pristopi za odpravljanje napak v vezju za FPGA
Najpogostejše tehnike za implementacijo zmožnosti odpravljanja napak v vezju v FPGA uporabljajo bodisi vgrajeni logični analizator, zunanjo preskusno opremo ali namensko strojno opremo za sondiranje signala, vdelano v strukturo FPGA. Vgrajeni logični analizator je običajno implementiran z uporabo tkanine FPGA in je vstavljen v zasnovo. JTAG vrata se uporabljajo za dostop do analizatorja in zajete podatke je mogoče prikazati na osebnem računalniku. Ko se uporablja zunanja preskusna oprema, se testirana zasnova FPGA spremeni tako, da se izbrani notranji signali FPGA usmerijo na izhodne zatiče. Te zatiče lahko nato opazujete prek zunanje preskusne opreme. Ko se uporablja namenska strojna oprema za sondiranje signala, je mogoče v realnem času prebrati širok izbor notranjih signalov. Nekatere implementacije sonde je mogoče celo uporabiti za pisanje v register ali pomnilniške lokacije, kar dodatno izboljša zmožnosti odpravljanja napak. Oglejmo si podrobneje advantages in disadvantagvsake od teh tehnik in si nato oglejte exampDa bi videli, kako lahko ti različni pristopi vplivajo na skupni čas odpravljanja napak.

In-Circuit FPGA Debug-Embedded Logic Analyzer
Koncept vgrajenega logičnega analizatorja je bil neposreden rezultat ad-hoc zmožnosti odpravljanja napak v vezju, ki so jih načrtovalci implementirali, ko so bili prvič uporabljeni FPGA. Vgrajeni logični analizatorji so dodali nove zmožnosti in odpravili zahtevo, da načrtovalec razvije lasten analizator. Večina FPGA ponuja te zmožnosti, tretje osebe pa ponujajo standardne analizatorje (Identify®, podjetja Synopsys, je eden izmed priljubljenihample), ki se zlahka poveže z orodji višje ravni za nadaljnje izboljšanje produktivnosti.

Funkcionalnost logičnega analizatorja je vstavljena v zasnovo z uporabo tkanine FPGA in vdelanih pomnilniških blokov kot medpomnilnikov za sledenje, kot je prikazano na sliki 2. Ustvarjeni so tudi prožilni viri, tako da je mogoče preprosto izbrati in zajeti kompleksne interakcije signalov. Dostop do analizatorja za nadzor in prenos podatkov se običajno izvaja prek standarda JTAG vrata za poenostavitev zahtev vmesnika. Zajete podatke je mogoče prikazati na osebnem računalniku s pomočjo skupnega viewprogramsko opremo in običajno zrcali izhod valovne oblike logičnega simulatorja viewing slog.

NapredektagBistvo tega pristopa je, da se ne uporabljajo dodatni I/O zatiči FPGA, ampak samo standardni JTAG signali. Jedra IP vgrajenega logičnega analizatorja so običajno razmeroma poceni in so v nekaterih primerih lahko možnost za obstoječo sintezo FPGA ali orodja za simulacijo. V nekaterih primerih lahko vgrajeni logični analizator zagotovi tudi dodatne izhode na neuporabljenih V/I, če je bolj priročno. Ena od slabostitagPri tem pristopu je potrebna velika količina virov FPGA. Zlasti, če se uporabljajo medpomnilniki sledenja, bo to zmanjšalo število razpoložljivih pomnilnikov blokov. Če je potreben širok medpomnilnik, bo to tudi kompromis glede globine pomnilnika (ker uporaba širšega pomnilnika povzroči manjšo globino pomnilnika) – velika pomanjkljivosttage pri uporabi manjših naprav. Morda je največja pomanjkljivost te tehnike ta, da je treba vsakič, ko se izvede prilagoditev namestitve sonde, znova prevesti in reprogramirati načrt. Pri uporabi velike naprave lahko ta postopek traja precej časa. Zaradi načina, na katerega so signalne sonde nameščene v zasnovi, je lahko težko povezati razmerja med signalom. Poleg tega zakasnitve med signalnimi sondami niso dosledne, zato je časovna razmerja težko primerjati. To je posebna težava pri primerjavi asinhronih signalov ali signalov iz različnih časovnih domen.

Odpravljanje napak FPGA v vezju – zunanja preskusna oprema
Uporaba kode za odpravljanje napak v vezju v povezavi z zunanjo preskusno opremo je bila naravni razvoj, ko je bil zunanji logični analizator že na voljo za testiranje sistema. Z ustvarjanjem preproste kode za odpravljanje napak za identifikacijo in izbiro internih preskusnih signalov ter njihovo uporabo na V/I FPGA, kot je prikazano na sliki 3, je bilo mogoče izkoristiti napredne zmogljivosti analizatorjev (kot so veliki medpomnilniki sledenja, kompleksna zaporedja proženja in več viewing možnosti), da ustvarite preprosta, a zmogljiva okolja za odpravljanje napak. Bolj zapletene zmogljivosti v vezju za napredne možnosti proženja lahko zmanjšajo število potrebnih izhodov. Na primerample, bi bilo lahko izbiranje določenih naslovov na širokem vodilu previsoka, če bi bili potrebni zunanji zatiči.
Uporaba notranje logike FPGA dramatično zmanjša zahteve glede V/I in lahko celo išče posebne vzorce naslovov (morda zaporedje klicev in povratkov) za odpravljanje napak pri bolj zapletenih težavah. Če je na voljo skupni uporabniški vmesnik, lahko to poenostavi krivuljo učenja in izboljša produktivnost.

NapredektagEdina stvar tega pristopa je, da izkorišča stroške zunanje testne opreme in zato ni dodatnih stroškov orodja. Nekatera jedra IP za odpravljanje napak so na voljo pri proizvajalcih opreme ali proizvajalcih FPGA in so lahko zelo poceni ali celo brezplačna. Količina virov FPGA, potrebnih za implementacijo logike izbire signala, je zelo majhna in ker se funkcija sledenja izvaja z uporabo zunanjega logičnega analizatorja, blokovni pomnilniki niso potrebni. Ker je izbirna logika poceni, je mogoče podpreti tudi veliko število kanalov s širokim proženjem. Logični analizator lahko deluje tako v časovnem načinu kot v stanju stanja, kar pomaga izolirati nekatere težave s časovnim usmerjanjem.
SlabosttagElementi tega pristopa lahko vključujejo potrebo po nakupu logičnega analizatorja, če ta še ni dodeljen projektu. Ta pomanjkljivosttage je lahko dovolj, da v mnogih primerih odvrne ta pristop. Upoštevajte pa, da postajajo na voljo nekatere možnosti nizkocenovnega logičnega analizatorja, ki za prikaz uporabljajo osebni računalnik ali tablico, zaradi česar je ta možnost veliko bolj stroškovno učinkovita za preproste zahteve za odpravljanje napak.
Število porabljenih zatičev FPGA je lahko še ena pomanjkljivosttage in če je treba upoštevati široka vodila, je potrebno precejšnje načrtovanje za postavitev plošče in dodajanje konektorjev za odpravljanje napak. To zahtevo je večinoma težko predvideti zgodaj v fazi načrtovanja in je še ena neželena zapletenost. Podobno kot pristop vgrajenega logičnega analizatorja zahteva strategija zunanjega testiranja ponovno prevajanje in reprogramiranje zasnove, ko je potreben vsak nov poskus.

Skupna pomanjkljivosttages teh dveh tehnik – uporaba virov na čipu (ki lahko prav tako vplivajo na časovno zmogljivost zasnove in ustvarijo dodatne zahteve za odpravljanje napak), potreba po ponovnem prevajanju in ponovnem programiranju zasnove (kar lahko doda ure ali celo dneve urniku odpravljanja napak), vnaprejšnje načrtovanje, potrebno za identifikacijo verjetnih testnih scenarijev, in uporaba dodatnih V/I virov čipa je ustvarilo potrebo po pristopu brez teh pomanjkljivosti. Eden od odgovorov je bil dodatek namenske logike za odpravljanje napak v strukturo FPGA na nekaterih napravah. Rezultat je bilo odpravljanje napak v vezju z uporabo sond strojne opreme.

Razhroščevanje FPGA v vezju – sonde strojne opreme
Uporaba sond strojne opreme dramatično poenostavi tehnike odpravljanja napak v vezju za FPGA. Ta tehnika, implementirana kot funkcija Live Probe na napravah SmartFusion2®SoC FPGA in IGLOO®2 FPGA, dodaja namenske sondne linije v strukturo FPGA za opazovanje izhoda katerega koli bita registra logičnega elementa. Kot je prikazano v blokovnem diagramu na sliki 4, so sonde strojne opreme na voljo v dveh kanalih sonde A in B.

Izbrani registrski izhodi (točke sonde), kot je tisti na dnu slike, so usmerjeni nad oba kanala sonde in če so izbrani, se lahko uporabijo za kanal A ali B. Ti kanalski signali v realnem času se lahko nato pošljejo na namenske zatiče sonde A in sonde B na napravi. Signale sonde A in sonde B je mogoče interno usmeriti na vgrajeni logični analizator.

Upoštevajte, da so časovne značilnosti zatičev sonde pravilne in imajo zanemarljivo odstopanje od ene sondne točke do druge, zaradi česar je veliko lažje primerjati časovne značilnosti signalov v realnem času. Podatke je mogoče zajeti pri frekvenci do 100MHz, kar je primerno za večino ciljnih modelov.
Morda je najpomembnejše, da se lokacije sondnih točk, ker niso izbrane kot del implementiranega načrta (izberejo jih namenska strojna oprema, medtem ko se načrt izvaja na FPGA), lahko hitro spremenijo s preprostim pošiljanjem izbirnih podatkov v napravo. Nobeno ponovno prevajanje in reprogramiranje načrta ni potrebno.
Za še večjo poenostavitev uporabe zmogljivosti Live Probe ima povezano programsko orodje za odpravljanje napak dostop do vseh lokacij signala sonde prek samodejno ustvarjenega odpravljanja napak file. Kot je prikazano na sliki 5, lahko ime signala izberete s seznama signalov in ga uporabite za želeni kanal. To je mogoče storiti tudi med izvajanjem zasnove, tako da je dejavnost sondiranja znotraj zasnove brezhibna in zelo učinkovita.

V mnogih primerih je zmožnost sondiranja strojne opreme, kot je Live Probe, mogoče uporabiti v povezavi s prej opisanim vgrajenim logičnim analizatorjem in zunanjimi preskusnimi tehnikami.

Kot je prikazano na sliki 6, zmožnost Live Probe za izbiro signalov 'sproti' omogoča hitro in enostavno spreminjanje opazovanih signalov, ne da bi bilo treba znova prevesti načrt. Zunanji logični analizator ali daljnogled lahko zlahka opazuje testirane signale, kot je prikazano v zgornjem desnem delu slike na namenskih izhodnih zatičih sonde. Alternativno (ali morda celo poleg) se lahko za opazovanje zatičev sonde uporabi notranji logični analizator (blok Identify ILA, prikazan na sliki). Signale sonde lahko zajame ILA in opazuje v oknu valovne oblike. Lokacije sond je mogoče spremeniti brez potrebe po ponovnem prevajanju ciljne zasnove.
Upoštevajte, da je mogoče dodatne zmožnosti za proženje in sledenje uporabiti za izboljšanje funkcionalnosti sonde, kar olajša odkrivanje celo zapletenih konstrukcijskih težav.

Dodatne zmožnosti odpravljanja napak strojne opreme so na voljo tudi na napravah SmartFusion2 SoC FPGA in IGLOO2 FPGA. Ena od teh zmogljivosti, imenovana Active Probe, lahko dinamično in asinhrono bere ali piše v kateri koli bit registra logičnega elementa. Zapisana vrednost se ohrani za en takt, tako da se lahko normalno delovanje nadaljuje, zaradi česar je zelo dragoceno orodje za odpravljanje napak. Aktivna sonda je še posebej zanimiva, če je zaželeno hitro opazovanje notranjega signala (morda preprosto za preverjanje, ali je aktiven ali v želenem stanju, kot je signal za ponastavitev) ali če je treba hitro preizkusiti logično funkcijo s pisanjem na točko sonde.
(morda za začetek prehoda državnega stroja s hitro nastavitvijo vhodne vrednosti za izolacijo težave s krmilnim tokom).

Druga zmožnost odpravljanja napak, ki jo ponuja Microsemi, je Memory Debug. Ta funkcija oblikovalcu omogoča dinamično in asinhrono branje ali pisanje v izbrani blok SRAM FPGA. Kot je prikazano na posnetku zaslona orodja za odpravljanje napak (slika 7), ko je izbran zavihek Memory Blocks, lahko uporabnik izbere želeni pomnilnik za branje, izvede zajem posnetka pomnilnika, spremeni vrednosti pomnilnika in nato vrednosti zapiše nazaj v napravo. To je lahko še posebej uporabno za preverjanje ali nastavitev podatkovnih medpomnilnikov, ki se uporabljajo v komunikacijskih vratih za računalniško usmerjeno beležko ali celo za kodo, ki jo izvaja vgrajeni CPE. Razhroščevanje zapletenih napak, odvisnih od podatkov, je bistveno hitrejše in lažje, če je spomine mogoče opazovati in nadzorovati tako hitro.

Ko je zasnova odpravljena, je morda zaželeno izklopiti zmožnosti odpravljanja napak strojne opreme, da zaščitimo občutljive podatke. Napadalec bi lahko uporabil te iste zmogljivosti za branje kritičnih informacij ali spreminjanje sistemskih nastavitev, ki bi lahko omogočile enostaven dostop do občutljivih delov sistema. Microsemi je dodal funkcije, ki oblikovalcu omogočajo zaščito naprave po končanem odpravljanju napak. Na primerample, lahko dostop do Live Probe in Active Probe zaklenete, da popolnoma onemogočite funkcijo kot možno sredstvo napada (odpravlja celo možnost, da bi aktivnost sonde ustvarila kakršne koli vzorce v napajalnem toku, ki bi se lahko uporabili za poskus in posredno opazovanje podatkov sonde). Druga možnost je, da se dostop do izbranih delov zasnove lahko zaklene, da se prepreči dostop samo do teh delov. To je lahko priročno, če mora biti samo del zasnove varen, tako da je preostali del zasnove še vedno dostopen za testiranje na terenu ali analizo napak.

Primerjalna tabela za odpravljanje napak v vezju
Zdaj, ko je podroben review Od treh glavnih tehnik odpravljanja napak strojne opreme v vezju je bil ustvarjen povzetek, kot je prikazano na sliki 8, ki podrobno opisuje različne naprednetages in disadvantagvsake metode. Ne pozabite, da je nekatere tehnike mogoče uporabiti skupaj (Live Probe in Internal Logic Analyzer (ILA), npr. Synopsys Identify, npr.ample), lahko vidimo ključne prednosti in slabosti vsake tehnike. Zbirka zmožnosti odpravljanja napak strojne opreme v vezju (Live Probe, Active Probe in Memory Debug – skupaj imenovane SmartDebug) je najšibkejša v primerjavi z drugimi tehnikami, ko gre za skupno število razpoložljivih sond (rdeč krog) in je šibkejša od najboljše (rumen krog), ko se upošteva hitrost zajema (zunanja preskusna oprema je lahko hitrejša).
Tehnike, ki temeljijo na ILA, kot je Synopsys Identify, so najšibkejše v primerjavi z drugimi tehnikami in pri upoštevanju zahtev po virih FPGA. Tehnike, ki temeljijo na zunanji preskusni opremi, so najšibkejše glede na številne vidike, pri čemer so stroški, vpliv na časovno razporeditev zasnove in stroški premikov sonde (zaradi potrebe po ponovnem prevajanju zasnove) najtežji. Morda je optimalna rešitev kombinacija SmartDebug-a in ene od drugih tehnik, tako da je mogoče zmanjšati število kanalov pri SmartDebug-u in pomanjkljivost premikanja sondne točke.tagtudi drugih tehnik.

Klasifikacije signalov
Koristno je mogoče razlikovati med nekaterimi najpogostejšimi vrstami signalov, kar je lahko v pomoč pri načrtovanju pristopa odpravljanja napak. Na primerample, lahko signale, ki se ne spremenijo razen med zagonom sistema, kot so ponastavitev sistema, ponastavitev bloka ali inicializacijski registri, razvrstimo med statične signale. Do teh vrst signalov je najučinkoviteje dostopati prek pripomočka, ki lahko zlahka opazuje in nadzoruje signal, ne da bi bil potreben dolg cikel ponovnega prevajanja. Active Probe je odličen pripomoček za razhroščevanje statičnih signalov. Podobno lahko signale, ki se pogosteje spreminjajo, vendar so še vedno statični veliko večino časa, razvrstimo kot psevdostatične in jih je najučinkoviteje odpraviti z uporabo aktivne sonde. Signale, ki se pogosto spreminjajo, kot so signali ure, je mogoče razvrstiti kot dinamične in do njih prek aktivne sonde ni tako enostavno dostopati. Live Probe je boljša izbira za opazovanje teh signalov.

Preprost primer uporabe za odpravljanje napak

Zdaj, ko bolje razumemo različne možnosti odpravljanja napak v vezju, si poglejmo preprosto zasnovo npr.ampda vidimo, kako delujejo te tehnike. Slika 9 prikazuje preprosto zasnovo FPGA v napravi SmartFusion2 SoC FPGA. Podsistem mikrokrmilnika (MSS) ponastavi blok IP CoreSF2Reset Soft. Vhodi v ta blok so ponastavitev ob vklopu, ponastavitev uporabniške strukture in zunanja ponastavitev. Izhodi so ponastavitev na User Fabric, ponastavitev MSS in ponastavitev M3. Simptomi napake so, da na V/I ni dejavnosti, čeprav naprava uspešno zapusti stanje POR. Na sliki so prikazane tudi tri različne možnosti za odpravljanje napak pri tej napaki: Modro polje (označeno z ETE) je za metodo zunanje preskusne opreme; zeleno polje (označeno z ILA) je za metodo notranjega logičnega analizatorja; in oranžno polje (označeno z AP) je za metodo Active Probe. Predvidevamo, da so morebitni temeljni vzroki napake nepravilno potrjeni vhodi za ponastavitev v blok IP CoreSF2Reset Soft.

Oglejmo si zdaj postopek odpravljanja napak za tri od prej opisanih metod v vezju.

Zunanja preskusna oprema
Pri uporabi te metode se predpostavlja, da je testna oprema na voljo in da je projekt z višjo prednostjo ne uporablja. Poleg tega je pomembno načrtovati vnaprej, tako da so nekateri V/I FPGA na voljo in jih je mogoče enostavno povezati s preskusno opremo. Imeti glavo na PCB nprample, bi bilo zelo koristno in zmanjšalo čas, porabljen za identifikacijo in povezovanje z "verjetnim osumljencem" ali morebitnim kratkim stikom med zatiči med sondiranjem. Zasnovo bo treba znova prevesti, da izberemo signale, ki jih želimo raziskati. Upajmo, da ne bomo 'lupili čebule' in morali izbrati dodatne signale za nadaljnjo preiskavo, saj naša začetna preiskava pogosto povzroči le več vprašanj. V vsakem primeru lahko postopek ponovnega prevajanja in ponovnega programiranja traja precej časa, in če povzroči kršitve časovnega načrtovanja, je potrebna prenova (vsi vemo, kako frustrirajoče je lahko reševanje težav z zapiranjem časovnega razporeda, zlasti ko spreminjate načrt, da bi našli napako v načrtu – celoten postopek lahko traja od minut do ur)! Pomembno si je tudi zapomniti, da če načrt nima brezplačnih uporabniških V/I, te metode ni mogoče implementirati. Poleg tega je ta metoda strukturno moteča pri načrtovanju – in hrošči, povezani s časom, lahko izginejo ali se znova pojavijo med ponovitvami.

Notranji logični analizator
S to metodo je treba ILA vstaviti v načrt z uporabo virov tkanine, nato pa ga je treba znova prevesti. Upoštevajte, da če je bil primerek ILA že ustvarjen, signali, ki jih želimo raziskati, morda niso bili opremljeni z instrumenti, kar bi prav tako zahtevalo ponovno prevajanje. Ta postopek tvega spremembo prvotne zasnove in kršitev časovnih omejitev. Če je čas izpolnjen, je treba načrt ponovno programirati in ponovno inicializirati. Ta celoten postopek lahko traja nekaj minut ali celo ur, če so časi ponovnega prevajanja dolgi in so potrebni številni prehodi. Ta pristop je strukturno vsiljiv in lahko povzroči podobne težave, kot so opisane pri uporabi zgornje metode.

Aktivna sonda
S to metodo je mogoče aktivno sondo usmeriti na vir različnih signalov ponastavitve, ki so vsi pridobljeni iz izhodov registra (kot je običajno v kateri koli dobri praksi digitalnega načrtovanja). Signali so izbrani enega za drugim v meniju Active Probe, prikazanem na sliki 10 spodaj. Izbrane vrednosti signala je mogoče prebrati in so prikazane v podatkovnem oknu Active Probe. Vse napačne trditve je enostavno prepoznati. Ta preizkus je mogoče izvesti takoj brez potrebe po ponovnem prevajanju in ponovnem programiranju naprave in ni strukturno ali proceduralno vsiljiv. Celoten postopek traja le nekaj sekund. Ta metoda lahko ustvari tudi možnost nadzora (asinhrono spreminjanje vrednosti), ki je drugi dve metodi ne dovolita. V tem posebnem example, signal za ponastavitev, ki ga izvira iz registra, je mogoče zlahka preizkusiti in ugotoviti, da je v aktivnem stanju.

Trenutni preklop signala za ponastavitev je mogoče doseči z asinhrono manipulacijo registra, ki generira preostale signale.

Bolj zapleten primer uporabe za odpravljanje napak
Zgornja zasnova je bila zelo preprosta in je uporabna kot uvod v uporabo opisanih tehnik oblikovanja, bolj zapletena pa je nprample je morda še bolj ilustrativno. Velikokrat signal zanimanja ni statičen signal, kot je bil v našem preprostem bivšemample vendar je dinamičen. Pogost dinamični signal je vmesna ura, ki se morda uporablja za merjenje časa rokovanja za serijski vmesnik. Slika 11 prikazuje takšno zasnovo z uporabniškim jedrom Soft IP, v tem primeru serijskim vmesnikom po meri, povezanim s sistemskim vodilom APB. Simptomi napake so, da ni dejavnosti na uporabniškem serijskem vmesniku po meri in da ko glavni vodila APB izda transakcijo za dostop do serijskega vmesnika, preide v izjemno stanje, ki kaže na nepravilno rokovanje. Zdi se, da ti pogoji izključujejo statični vzrok, kot je napačen signal ponastavitve, saj se zdi, da stroj stanja transakcije ne deluje s pričakovano hitrostjo in tako povzroči izjemo. Glavni vzrok naj bi bil generator taktne frekvence v jedru IP uporabnika.

Če ne deluje s pravilno frekvenco, bi prišlo do opisanih napak.

V tej situaciji je verjetno boljša strategija zamenjati pristop Active Probe z Live Probe. To je na zgornji sliki prikazano z oranžno obarvano škatlo LP z uporabo JTAG signal za izbiro vira sonde.

Zunanja preskusna oprema
V tem primeru je metodologija zelo podobna prej opisanemu preprostemu primeruample. Signal uporabniške ure se prikaže na testni točki (upajmo, da v glavi) in potrebno je zamudno ponovno prevajanje. Prav tako je lahko koristno, če prikažete referenčni signal, morda sistemsko uro, ki se uporablja za merjenje IP-ja uporabnika kot primerjalni signal. Ponovno bomo morali znova prevesti in programirati, tako da lahko celoten postopek traja precej časa.

Notranji logični analizator
Ta primer je zelo podoben preprostemu example. Vstaviti je treba ILA ali definirati želeni signal ter izvesti cikel ponovnega prevajanja in ponovnega programiranja. Vse prej opisane težave še vedno povzročajo precejšen čas cikla odpravljanja napak. Vendar obstaja dodatna zapletenost. Ura, ki poganja ILA, mora biti sinhrona in v idealnem primeru veliko hitrejša glede na uro, ki jo je treba opazovati iz uporabniškega jedra Soft IP. Če so te ure asinhrone ali nimajo pravilnih časovnih razmerij, bo zajem podatkov nepredvidljiv in možen vir zmede za postopek odpravljanja napak.
Upoštevajte, da če uporabniška ura mehkega IP ni ustvarjena na čipu (morda je obnovljena iz serijskega vmesnika), bo načrtovalec morda moral dodati modul ure za generiranje hitrejše ure ILA z uporabo dodatnih virov in morebitnim povzročanjem časovne kršitve.

Živa sonda
S to metodo je mogoče Live Probe hitro usmeriti na vir uporabniške ure in katerega koli drugega vira ure iz registra, da se odkrije glavni vzrok napake. Sonda v živo bo prikazala izbrane signalne izhode v realnem času in morebitno časovno razmerje med signali je tako veliko lažje določiti. Celoten postopek traja le nekaj sekund.

Druge funkcije za odpravljanje napak za serijske vmesnike
Pomembno je tudi poudariti, da obstaja veliko dodatnih zmožnosti odpravljanja napak v napravah SmartFusion2 SoC FPGA in IGLOO2 FPGA, ki jih je mogoče uporabiti na serijskih vmesnikih, kot je tisti v prejšnjemample design, kjer so napake še bolj zapletene. SERDES Debug, nprample, ponuja posebne zmožnosti odpravljanja napak za namenske serijske vmesnike visoke hitrosti. Nekatere funkcije SERDES Debug vključujejo podporo za testiranje PMA (kot je generiranje vzorcev PRBS in testiranje povratne zanke), podporo za več testnih konfiguracij SERDES z rekonfiguracijo na ravni registra, da se izognete uporabi celotnega toka načrtovanja za spreminjanje konfiguracije, in besedilna poročila, ki prikazujejo konfigurirane protokole, konfiguracijske registre SERDES in registre konfiguracije Lane. Te funkcije olajšajo razhroščevanje SERDES in se lahko uporabljajo v povezavi z Live Probe in Active Probe za dodatno pospešitev razhroščevanja kompleksnih vezij.
Prej opisano orodje za odpravljanje napak v pomnilniku je mogoče uporabiti tudi v povezavi s SERDES Debug za pospešitev testiranja. Ker je medpomnilniške vmesne pomnilnike mogoče hitro in preprosto pregledati in spremeniti z Memory Debug, je mogoče hitro ustvariti 'testne pakete' in opazovati rezultate povratne zanke ali medsistemske komunikacije. Načrtovalec lahko izkoristi te zmožnosti in tako zmanjša potrebo po specializiranih 'preizkusnih pasovih', ki porabijo dodatno tkanino FPGA in lahko vplivajo na časovno razporeditev čipov.

Zaključek
V tem dokumentu je podrobno opisano več različnih pristopov k izvajanju odpravljanja napak v vezju za FPGA in SoC FPGA – uporaba integriranega logičnega analizatorja, uporaba zunanje preskusne opreme in uporaba namenskih sondnih vezij, integriranih v strukturo FPGA. Dodatek specializiranih in namenskih sondnih vezij, kot sta Active Probe in Live Probe, ki jih ponuja Microsemi na napravah SmartFusion2 SoC FPGA in IGLOO2 FPGA, je pokazal, da znatno pospeši in poenostavi postopek odpravljanja napak. Zmožnost hitrega spreminjanja izbire notranjih signalov (brez potrebe po izvajanju zelo zamudnega cikla ponovnega prevajanja in ponovnega programiranja) in zmožnost sondiranja notranjih signalov (brez potrebe po uporabi tkanine FPGA in morebitnega uvajanja časovnih kršitev) sta se izkazali za velik napredek.tages pri odpravljanju napak v načrtih FPGA. Poleg tega je bila opisana uporaba več metodologij, ki lahko skupaj zagotavljajo še bolj celovito zmožnost odpravljanja napak. Končno dva exampPrimeri uporabe le debug so bili podani za ponazoritev kompromisov med opisanimi metodami.

Če želite izvedeti več

IGLOO2 FPGA
SmartFusion2 SoC FPGA

Microsemi Corporation (Nasdaq: MSCC) ponuja obsežen portfelj polprevodniških in sistemskih rešitev za komunikacijske, obrambne in varnostne, vesoljske in industrijske trge. Izdelki vključujejo visoko zmogljiva in proti sevanju odporna analogna integrirana vezja z mešanimi signali, FPGA, SoC in ASIC; izdelki za upravljanje porabe energije; naprave za merjenje časa in sinhronizacijo ter rešitve za natančen čas, ki postavljajo svetovni standard za čas; naprave za obdelavo govora; RF rešitve; diskretne komponente; varnostne tehnologije in razširljivo zaščito proti tamper izdelki; IC-ji in srednji razponi za napajanje prek omrežja Ethernet; kot tudi zmogljivosti in storitve oblikovanja po meri. Microsemi ima sedež v Aliso Viejo v Kaliforniji in ima približno 3,400 zaposlenih po vsem svetu. Več o tem na www.microsemi.com.

Sedež podjetja Microsemi

ena Enterprise, Aliso Viejo CA 92656 ZDA

Znotraj ZDA: +1 800-713-4113
Zunaj ZDA: +1 949-380-6100
Prodaja: +1 949-380-6136

faks: +1 949-215-4996
E-pošta: sales.support@microsemi.com

pogosta vprašanja

V: Kakšna je največja frekvenca zajemanja podatkov naprave?
O: Naprava podpira zajem podatkov pri frekvenci do 100MHz, kar je primerno za večino ciljnih modelov.

V: Ali moram znova prevesti načrt, ko uporabljam sondna vezja za odpravljanje napak?
O: Ne, lokacije sondnih točk je mogoče hitro spremeniti brez potrebe po ponovnem prevajanju načrta ali ponovnem programiranju.