Mikrosemi In-Circuit FPGA feilsøking

Produktinformasjon

Spesifikasjoner

• Enhetstype: Microsemi SmartFusion2 SoC FPGA
• Utgivelsesdato: mai 2014
• Feilsøkingsfunksjoner: In-Circuit FPGA Debug, Embedded Logic Analyzer
• Maksimal datafangstfrekvens: Opptil 100MHz

Abstrakt
FPGAer er kraftige designelementer i innebygde systemer med mange designadvanertages, men disse enhetene kan ha komplekse design med komplekse designproblemer som må feilsøkes. Å spore opp designproblemer som definisjonsfeil, systeminteraksjonsproblemer og systemtidsfeil kan være en utfordring. Inkludering av in-circuit debug-funksjoner i en FPGA kan dramatisk forbedre maskinvarefeilsøking, og unngå grevetimer med frustrasjon. Denne artikkelen beskriver flere forskjellige tilnærminger til in-circuit debug for FPGAer, identifiserer viktige avveininger og gjennom en eks.ampDesignet, målrettet for en Microsemi SmartFusion®2 SoC FPGA-enhet, vil vise hvordan nye funksjoner kan brukes for å øke hastigheten på feilsøking og testing.

Introduksjon

FPGA-er er gjennomgripende og kraftige designelementer og finnes nå i praktisk talt alle innebygde systemer. Med økende kapasitet, inkludering av komplekse funksjonsblokker på brikken og avanserte serielle grensesnitt kan disse enhetene også ha komplekse designproblemer som må feilsøkes. Å spore opp problemer som funksjonelle definisjonsfeil (på FPGA- eller systemnivå), funksjonelle systeminteraksjonsproblemer, systemtidsproblemer og signaltrohetsproblemer mellom IC-er (som støy, krysstale eller refleksjoner) blir alt mye mer komplekst når du bruker avanserte FPGA-er. Simulering er absolutt en stor hjelp til å identifisere mange designproblemer, men mange virkelige interaksjoner vil ikke dukke opp før designet er implementert i maskinvare. Flere forskjellige teknikker for å feilsøke komplekse designproblemer er utviklet for å forenkle prosessen. En nøye forståelse av hver av disse nøkkelteknikkene, inkludert de forskjellige advanenetages og disadvantages, er nyttig når du vurderer hvilken teknikk eller kombinasjon av teknikker som passer for et bestemt design.
En eksample FPGA-design, målrettet for en Microsemi SmartFusion2 SoC FPGA-enhet, kan brukes til å demonstrere noen av fordelenetages og disadvantages av disse standardteknikkene så vel som de nyeste in-circuit debug-funksjonene. Dette illustrerende eksample vil vise hvordan disse ulike teknikkene kan brukes for å øke hastigheten på identifisering og eliminering av maskinvareproblemer under maskinvarefeilsøking.

Hvorfor er FPGA-feilsøking et kritisk aspekt ved systemdesign og utvikling?
FPGA-er har to hovedbruksmodeller som skiller dem fra andre designelementer. FPGA-er kan brukes i produksjonsproduktet eller kan brukes som et utviklingsverktøy for å bevise eller prototyper et produksjonsdesignkonsept. Når de brukes som produksjonskjøretøy, kan FPGA-er være et mye mer fleksibelt mål enn ASIC eller CPU-baserte produksjonskjøretøyer. Dette er spesielt viktig for en ny design, en som ikke har blitt implementert i maskinvare ennå. Design med forskjellige arkitektoniske alternativer kan enkelt lages og testes slik at det optimale designet identifiseres. FPGAer med on-chip prosessorer (SoC FPGAs) gjør det også mulig å bytte ut CPU-basert prosessering med maskinvareassisterte FPGA-baserte akselerasjonsfunksjoner. Disse advantages kan dramatisk redusere tiden som kreves for design, validering, testing og feilanalyse for nye produktutviklinger.
Når det brukes til prototyping av et design, kanskje for en produksjons-ASIC, er FPGA-fleksibilitet en viktig fordel. En faktisk maskinvareplattform, selv en som ikke kjører i full hastighet, gjør det mye enklere å få detaljerte systemytelsesmålinger, data for gjennomstrømningsanalyse og arkitekturbevis-på-konsept-resultater. FPGA-støtte for herdede implementeringer av industristandard busser (som PCIe®, Gigabit Ethernet, XAUI, USB, CAN og andre) forenkler testingen knyttet til disse grensesnittene. De nyeste familiene av FPGA-er med on-chip ARM-prosessorer (SoC FPGAs), gjør det enkelt å prototype implementeringer med innebygde prosessorer. Tidligere utviklet prosessorkode kan porteres til prototypen og ny kode lages parallelt med maskinvaredesignarbeidet.

Denne kombinasjonen av en standard prosessor med standard grensesnittbusser gjør det mulig å utnytte det store økosystemet av tilgjengelige kodebiblioteker, drivere, funksjonelle APIer, sanntidsoperativsystemer og til og med komplette operativsystemer for mye raskere å lage en fungerende prototype. I tillegg, når designet er størknet, kan FPGA-prototypen brukes til å fange opp omfattende simuleringstestsett (for både stimulus og respons) som gjenspeiler faktiske systemdata. Disse datasettene kan være uvurderlige for å lage de endelige simuleringene for en ASIC eller annen produksjonsimplementering. AdvanentagBruk av en FPGA som en designprototype kan dramatisk redusere tiden for design, validering, testing og feilanalyse for den endelige produktimplementeringen.
I begge disse vanlige FPGA-bruksmodellene er fleksibiliteten til FPGA som designmål en viktig fordeltage. Dette betyr at mange designendringer og iterasjoner vil være normen, og derfor vil muligheten til å raskt feilsøke designfeil være avgjørende for å muliggjøre så mange designalternativer som mulig. Uten en effektiv feilsøkingsevne mye av advantagFPGA-designfleksibiliteten vil bli redusert av den ekstra feilsøkingstiden som kreves. Heldigvis kan FPGA-er også gi ekstra maskinvarefunksjoner som dramatisk forenkler sanntidsfeilsøking. Før vi ser på disse egenskapene, la oss først se på de vanligste typene problemer en FPGA-design kan stå overfor, slik at vi har den riktige bakgrunnen for å evaluere effektiviteten og de tilhørende avveiningene til ulike feilsøkingsverktøy.

Vanlige problemer ved feilsøking av FPGA-design

Sammen med de utvidede mulighetene som moderne FPGA-er bringer, gjør den tilhørende økte kompleksiteten det vanskeligere å lage feilfrie design. Faktisk har det blitt anslått at feilsøking kan ta over 50 % av designsyklusen for det innebygde systemet. Med tid-til-marked-press som fortsetter å presse utviklingssyklusen, blir maskinvarefeilsøking av det opprinnelige systemet henvist til en ettertanke – alt for ofte forutsatt at verifiseringen (selv en stor prosentandeltage av utviklingsplanen), vil fange opp alle feilene før første systemoppstart. La oss se på noen få vanlige typer systemproblemer for å bedre forstå utfordringene et typisk design vil møte under den første systemoppstarten.

Funksjonelle definisjonsfeil kan være dobbelt vanskelig å finne siden designeren har misforstått et bestemt krav, så feilen kan overses selv når man ser nøye på detaljene i designet. En eksample av en vanlig funksjonell definisjonsfeil vil være der en tilstandsmaskinovergang ikke ender opp i riktig tilstand. Feil kan også dukke opp i systemgrensesnitt som et interaksjonsproblem. Grensesnittforsinkelse, f.eksample, kan være feil spesifisert, noe som resulterer i et uventet bufferoverløp eller underflyttilstand.
Tidsproblemer på systemnivå er en annen svært vanlig kilde til designfeil. Spesielt asynkrone hendelser er en vanlig kilde til feil når synkronisering eller kryssende tidsdomeneeffekter ikke vurderes nøye. Når du opererer med hastighet, kan disse typene feil være svært problematiske og kan dukke opp svært sjelden, kanskje bare når spesifikke datamønstre manifesterer seg. Mange vanlige tidsbrudd faller inn under denne kategorien og er vanligvis svært vanskelige, om ikke umulige å simulere.

Tidsbrudd kan også være et resultat av lav signalkvalitet mellom integrerte kretser, spesielt i systemer med flere strømskinner for hver krets. Lav signalkvalitet kan resultere i signalstøy, krysstale, refleksjoner, overbelastning og problemer med elektromagnetisk interferens (EMI) som ofte viser seg som tidsbrudd. Strømforsyningsproblemer, som transienter (spesielt under oppstart eller avslutning av systemet), lastvariasjoner og høye strømtapsspenninger kan også resultere i mystiske feil, som ofte ikke lett kan spores tilbake til en strømforsyningskilde. Selv når designet er helt riktig, kan problemer med brettfabrikasjon resultere i feil. Defekte loddeforbindelser og feil festede koblinger, f.eksample, kan være kilden til feil og kan til og med være avhengig av temperatur eller bordplassering. Bruk av avanserte FPGA-pakketeknikker kan gjøre det vanskelig å sondere signaler på kretskortet til, så bare det å få tilgang til et ønsket signal kan ofte være problematisk. Ofte skaper ikke mange designproblemer en umiddelbar feil og må bølge gjennom designet før feilen faktisk viser seg. Å spore startfeilen tilbake til rotårsaken kan ofte være en frustrerende, vanskelig og tidkrevende oppgave.

For eksample, en enkelt bit feil i en oversettelsestabell kan ikke resultere i en feil før mange sykluser senere. Noen av verktøyene vi vil diskutere senere i denne artikkelen, som bruker dedikert in-circuit debug-maskinvare, er spesifikt rettet mot å gjøre disse 'bug-jaktene' raskere og enklere. Før vi går inn på detaljene i disse verktøyene, la oss først se på en populær programvarebasert feilsøkingsteknikksimulering for å bedre forstå fordelentages og disadvantages av å bruke simulering for feilsøking.

Bruk av simulering for feilsøking
Vanligvis i en designsimulering modelleres alle virkelige komponenter i og utenfor designet matematisk som programvareprosesser som utføres sekvensielt på en standard CPU. Å bruke et bredt spekter av stimulans til designet og sjekke forventet utgang mot simulert designutgang, er en enkel måte å fange opp de mest åpenbare designfeilene. Et vindu som viser en typisk simuleringskjøring er gitt i figur 1 nedenfor. Den klare fordelentage av simuleringsvers maskinvarebasert feilsøking er at simulering kan gjøres i programvaren – ingen faktisk maskinvarebasert design og testbenk er nødvendig. Simulering kan raskt fange opp mange designfeil, spesielt de som er forbundet med feil spesifikasjoner, misforståelse av grensesnittkrav, funksjonsfeil og mange andre "grove" typer feil som lett oppdages gjennom enkle stimulusvektorer.

Simulering er spesielt effektiv når omfattende stimuluskombinasjoner er tilgjengelige for designeren og de resulterende utgangene er velkjente. I disse tilfellene kan simulering gjøre en nesten uttømmende test av et design. Dessverre har de fleste design ikke enkel tilgang til omfattende testsuiter, og prosessen med å lage dem kan være svært tidkrevende. Å lage en testpakke som dekker 100 % av designet er praktisk talt umulig for store FPGA-baserte design, og snarveier må brukes for å prøve å dekke nøkkelelementene i designet. En annen vanskelighet med simulering er at det ikke er en "virkelig verden"-implementering og ikke kan fange opp asynkrone hendelser, systeminteraksjoner i hastighet eller tidsbrudd. Til slutt kan simuleringsprosessen være veldig langsom, og hvis mange iterasjoner kreves, blir simuleringen raskt den mest tidkrevende, og ofte den mest kostbare delen av utviklingsprosessen.

Som et alternativ (eller kanskje bedre sagt, som et tillegg til simulering) fant FPGA-designere at de kunne legge til feilsøkingsmaskinvare i FPGA-designet for å observere og kontrollere nøkkelsignaler i enheten. Disse teknikkene utviklet opprinnelig som ad-hoc-tilnærminger, men har gradvis utviklet seg til en standard maskinvarefeilsøkingsstrategi. Denne bruken av in-circuit debug-funksjoner gir betydelig fordeltages for FPGA-baserte design, og den neste delen vil utforske de tre vanligste strategiene og deres ulike fordelertages og disadvantages.

Vanlige In-Circuit Debug Approaches for FPGAer
De vanligste teknikkene for å implementere in-circuit debug-funksjoner i FPGA-er bruker enten en innebygd logikkanalysator, eksternt testutstyr eller dedikert signalprobe-maskinvare innebygd i FPGA-stoffet. Den innebygde logiske analysatoren er vanligvis implementert ved hjelp av FPGA-stoff og settes inn i designet. JTAG porten brukes for å få tilgang til analysatoren, og de fangede dataene kan vises på en PC. Når eksternt testutstyr brukes, modifiseres FPGA-designet som testes slik at utvalgte interne FPGA-signaler rutes til utgangspinner. Disse pinnene kan deretter observeres gjennom det eksterne testutstyret. Når dedikert signalprobe-maskinvare brukes, kan et bredt utvalg av interne signaler leses i sanntid. Noen probeimplementeringer kan til og med brukes til å skrive til register eller minneplasseringer, noe som ytterligere forbedrer feilsøkingsmulighetene. La oss se mer detaljert på advantages og disadvantages av hver av disse teknikkene og se deretter på en eksampdesign for å se hvordan disse forskjellige tilnærmingene kan påvirke den totale feilsøkingstiden.

In-Circuit FPGA Debug-Embedded Logic Analyzer
Konseptet med den innebygde logikkanalysatoren var et direkte resultat av ad-hoc in-circuit debugging-funksjonene som designere implementerte da FPGA-er først ble brukt. Innebygde logikkanalysatorer la til nye muligheter og eliminerte kravet til designeren om å utvikle sin egen analysator. De fleste FPGA-er tilbyr disse egenskapene, og tredjeparter tilbyr standardanalysatorer (Identify®, fra Synopsys, er et populært eks.ample) som enkelt kan kommunisere med verktøy på høyere nivå for å forbedre produktiviteten ytterligere.

Den logiske analysatorfunksjonaliteten er satt inn i designet, ved å bruke FPGA-stoff og innebygde minneblokker som sporingsbuffere, som illustrert i figur 2. Utløsende ressurser opprettes også slik at komplekse signalinteraksjoner enkelt kan velges og fanges opp. Tilgang til analysatoren for kontroll og dataoverføring gjøres vanligvis gjennom standard JTAG port for å forenkle grensesnittkravene. Innfangede data kan vises på en PC ved hjelp av felles viewprogramvare og speiler vanligvis en logisk simulatorbølgeformutgang viewing stil.

AdvanentagGrunnene til denne tilnærmingen er at ingen ekstra FPGA I/O-pinner brukes, bare standard JTAG signaler. De innebygde logikkanalysatorens IP-kjerner er vanligvis relativt rimelige og kan i noen tilfeller være et alternativ til eksisterende FPGA-syntese eller simuleringsverktøy. I noen tilfeller kan den innebygde logiske analysatoren også gi ekstra utganger på ubrukte I/O-er, hvis det er mer praktisk. En av ulempenetagGrunnen til denne tilnærmingen er at det kreves en stor mengde FPGA-ressurser. Spesielt hvis sporingsbuffere brukes vil dette redusere antall tilgjengelige blokkminner. Hvis en bred buffer er nødvendig, vil dette også være en avveining mot minnedybde (siden bruk av et bredere minne resulterer i mindre minnedybde) - en stor ulempetage når du bruker mindre enheter. Den kanskje største ulempen med denne teknikken er at hver gang en justering av sondeplassering gjøres, er det nødvendig å rekompilere og omprogrammere designet. Når du bruker en stor enhet, kan denne prosessen ta betydelig tid. På grunn av måten signalprobene er plassert i designet kan det være vanskelig å korrelere signaltidsforhold. I tillegg er forsinkelsene mellom signalprobene ikke konsistente, og dermed er tidsforhold vanskelig å sammenligne. Dette er en spesiell vanskelighet når man sammenligner asynkrone signaler eller signaler fra forskjellige tidsdomener.

In-Circuit FPGA Debug – Eksternt testutstyr
Bruken av in-circuit debug-kode i forbindelse med eksternt testutstyr var en naturlig utvikling da en ekstern logikkanalysator allerede var tilgjengelig for systemtesting. Ved å lage en enkel feilsøkingskode for å identifisere og velge interne testsignaler og bruke dem på FPGA I/O-er, som vist i figur 3, var det mulig å utnytte analysatorens avanserte funksjoner (som store sporingsbuffere, komplekse utløsende sekvenser og flere viewing options) for å lage enkle, men kraftige feilsøkingsmiljøer. Mer komplekse in-circuit-funksjoner for avanserte utløsningsalternativer kan minimere antall utganger som trengs. For eksample, å velge spesifikke adresser på en bred buss kan være uoverkommelig hvis eksterne pinner var nødvendig.
Bruk av intern FPGA-logikk reduserer I/O-kravene dramatisk og kan til og med se etter spesifikke adressemønstre (kanskje en anrops- og retursekvens) for å feilsøke mer komplekse problemer. Hvis et felles brukergrensesnitt er tilgjengelig, kan dette forenkle læringskurven og forbedre produktiviteten.

AdvanentagGrunnen til denne tilnærmingen er at den utnytter kostnadene for det eksterne testutstyret, og dermed er det ingen ekstra verktøykostnad. Noen feilsøkingskretser IP-kjerner er tilgjengelige fra utstyrsprodusenter eller FPGA-produsenter, og kan være svært lave kostnader eller til og med gratis. Mengden FPGA-ressurser som kreves for å implementere signalvalglogikken er svært liten, og siden sporingsfunksjonen gjøres ved hjelp av den eksterne logikkanalysatoren, er det ikke nødvendig med blokkminner. Siden valglogikk er billig, kan et stort antall kanaler med bred utløsning også støttes. Den logiske analysatoren kan fungere i både en tidsmodus og en tilstandsmodus som hjelper til med å isolere noen tidsproblemer.
DisadvanentagEs av denne tilnærmingen kan inkludere behovet for å kjøpe en logikkanalysator, hvis en ikke allerede er allokert til prosjektet. Denne ulempentage kan være nok til å fraråde denne tilnærmingen i mange tilfeller. Vær imidlertid oppmerksom på at noen rimelige logikkanalysatoralternativer blir tilgjengelige som bruker PC-en eller et nettbrett til visning, noe som gjør dette alternativet mye mer kostnadseffektivt for enkle feilsøkingskrav.
Antallet FPGA-pinner som forbrukes kan være en annen ulempetage og hvis brede busser må observeres, er det nødvendig med betydelig planlegging for kortlayout og tillegg av feilsøkingskoblinger. Dette kravet er oftest vanskelig å forutsi tidlig i designfasen og en annen uønsket kompleksitet. I likhet med den innebygde logikkanalysatortilnærmingen krever den eksterne teststrategien rekompilering og omprogrammering av et design, når hvert nytt eksperiment er nødvendig.

Den vanlige ulempentages av disse to teknikkene – bruken av on-chip-ressurser (som også kan påvirke designens timing-ytelse og skape ytterligere feilsøkingskrav) behovet for å rekompilere og omprogrammere designet (som kan legge til timer eller til og med dager til feilsøkingsplanen), den forhåndsplanleggingen som kreves for å identifisere sannsynlige testscenarier, og bruken av ytterligere brikke-I/O-ressurser skapte et behov for en tilnærming. Ett svar var tillegget av dedikert feilsøkingslogikk i FPGA-stoffet på noen enheter. In-circuit debug ved hjelp av maskinvareprober var resultatet.

In-Circuit FPGA Debug – Maskinvareprober
Bruken av maskinvareprober forenkler dramatisk feilsøkingsteknikker for FPGA-er. Denne teknikken implementert som en Live Probe-funksjon på SmartFusion2®SoC FPGA- og IGLOO®2 FPGA-enheter, legger til dedikerte probelinjer til FPGA-stoffet for å observere utgangen fra en hvilken som helst logisk elementregisterbit. Som vist i blokkskjemaet i figur 4, er maskinvareprober tilgjengelige i to probekanaler A og B.

Utvalgte registerutganger (probepunkter), som den som er hentet nederst på figuren, rutes over de to probekanalene og kan, hvis valgt, brukes til enten A- eller B-kanalen. Disse sanntidskanalsignalene kan deretter sendes til dedikerte Probe A- og Probe B-pinner på enheten. Probe A- og Probe B-signalene kan også rutes internt til en innebygd logikkanalysator.

Legg merke til at tidskarakteristikkene til sondepinnene er regelmessige og har ubetydelig avvik fra ett sondepunkt til et annet, noe som gjør det mye lettere å sammenligne tidskarakteristikkene til sanntidssignalene. Data kan fanges opp med opptil 100MHz, noe som gjør det passende for de fleste måldesignene.
Kanskje det viktigste er at sondepunktplasseringene, siden de ikke er valgt som en del av det implementerte designet (de er valgt gjennom dedikert maskinvare mens designet kjører på FPGA), raskt kan endres ved ganske enkelt å sende utvalgsdataene til enheten. Ingen designrekompilering og omprogrammering er nødvendig.
For å forenkle bruken av Live Probe-funksjonen enda mer, har det tilknyttede debug-programvareverktøyet tilgang til alle sondesignalplasseringene gjennom en automatisk generert debug file. Som vist i figur 5, kan signalnavnet velges fra signallisten og brukes på ønsket kanal. Dette kan gjøres selv mens designet kjører, slik at sonderingsaktiviteten i designet er sømløs og veldig effektiv.

I mange tilfeller kan maskinvareprobefunksjonen, som Live Probe, brukes sammen med den tidligere beskrevne innebygde logikkanalysatoren og de eksterne testteknikkene.

Som vist i figur 6, gjør Live Probe-evnen til å velge signaler "on the fly" det mulig å raskt og enkelt endre signalene under observasjon uten å måtte rekompilere designet. En ekstern logisk analysator eller skop kan enkelt observere de sonderte signalene, som illustrert i øvre høyre del av figuren på de dedikerte probeutgangspinnene. Alternativt (eller kanskje til og med i tillegg til) kan den interne logikkanalysatoren (ILA Identify-blokken, vist på figuren) brukes til å observere probepinnene. Probesignalene kan fanges opp av ILA og observeres på bølgeformvinduet. Probeplasseringer kan endres uten behov for å rekompilere måldesignet.
Merk at tilleggsmulighetene for utløsning og sporing kan brukes til å forbedre probefunksjonaliteten, noe som gjør det enkelt å oppdage selv komplekse designproblemer.

Ytterligere maskinvarefeilsøkingsfunksjoner er også tilgjengelig på SmartFusion2 SoC FPGA- og IGLOO2 FPGA-enheter. En av disse egenskapene, kalt Active Probe, kan dynamisk og asynkront lese eller skrive til en hvilken som helst logisk elementregisterbit. En skrevet verdi vedvarer i en enkelt klokkesyklus slik at normal drift kan fortsette, noe som gjør det til et svært verdifullt feilsøkingsverktøy. Active Probe er av spesiell interesse hvis en rask observasjon av et internt signal er ønsket (kanskje ganske enkelt for å sjekke at det er aktivt eller i ønsket tilstand, som et tilbakestillingssignal), eller hvis det er behov for å raskt teste en logisk funksjon ved å skrive til et sondepunkt
(kanskje for å starte en tilstandsmaskinovergang ved å raskt sette en inngangsverdi for å isolere et kontrollflytproblem).

En annen feilsøkingsfunksjon levert av Microsemi er Memory Debug. Denne funksjonen lar designeren dynamisk og asynkront lese eller skrive til en valgt FPGA-stoff SRAM-blokk. Som illustrert i skjermbildet av feilsøkingsverktøyet (Figur 7), når fanen Minneblokker er valgt, kan brukeren velge ønsket minne som skal leses, utføre et øyeblikksbilde av minnet, endre minneverdier og deretter skrive verdiene tilbake til enheten. Dette kan være spesielt nyttig for å sjekke eller sette databuffere som brukes i kommunikasjonsporter for beregningsorientert skrapelodd eller til og med for kode utført av en innebygd CPU. Å feilsøke komplekse dataavhengige feil er betydelig raskere og enklere når minner kan observeres og kontrolleres så raskt.

Når et design er feilsøkt, kan det være ønskelig å slå av funksjonene for maskinvarefeilsøking for å beskytte sensitiv informasjon. En angriper kan bruke de samme fasilitetene til å lese ut kritisk informasjon eller endre systeminnstillinger som kan gi enkel tilgang til sensitive deler av systemet. Microsemi har lagt til funksjoner som lar designeren sikre enheten etter at feilsøkingen er fullført. For eksamples, tilgang til Live Probe og Active Probe kan låses for å fullstendig deaktivere funksjonen som et mulig angrepsmiddel (det eliminerer til og med muligheten for probeaktivitet som skaper mønstre i forsyningsstrømmen som kan brukes til å prøve å observere sondedata indirekte). Alternativt kan tilgang til utvalgte deler av designet låses ute for å hindre tilgang til nettopp disse delene. Dette kan være praktisk hvis bare en del av designet trenger å være sikkert, slik at resten av designet fortsatt er tilgjengelig for felttesting eller feilanalyse.

Sammenligningsdiagram for In-Circuit Debug
Nå som en detaljert vedrview av de tre viktigste maskinvarefeilsøkingsteknikkene i kretsløpet har blitt beskrevet et sammendragsdiagram, som vist i figur 8, som viser detaljer om de forskjellige advanene.tages og disadvantages av hver metode. Husk at noen teknikker kan brukes sammen (Live Probe og Internal Logic Analyzer (ILA), som Synopsys Identify, f.eks.ample), kan vi se de viktigste styrkene og svakhetene ved hver teknikk. Samlingen av in-circuit hardware debug-funksjoner (Live Probe, Active Probe og Memory Debug – samlet kalt SmartDebug), er svakest sammenlignet med de andre teknikkene når det kommer til antall tilgjengelige prober (en rød sirkel) og er svakere enn de beste (gul sirkel) når fangsthastigheten vurderes (eksternt testutstyr kan være raskere).
ILA-baserte teknikker, som Synopsys Identify, er svakest sammenlignet med de andre teknikkene og når FPGA-ressurskrav vurderes. Eksternt testutstyrsbaserte teknikker er svakest i forhold til en rekke hensyn, med kostnad, tidsinnvirkning på design og overhead for sondebevegelse (på grunn av behovet for å rekompilere designet) de mest tyngende. Kanskje den optimale løsningen er en kombinasjon av SmartDebug og en av de andre teknikkene, slik at antall kanalers svakhet til SmartDebug kan reduseres og sondepunktbevegelsen ulempetages av de andre teknikkene redusert også.

Signalklassifiseringer
Et nyttig skille kan gjøres mellom noen av de vanligste typene signaler, og dette kan hjelpe når du planlegger en feilsøkingstilnærming. For eksampsignaler som ikke endres annet enn under oppstart av systemet, som systemtilbakestilling, tilbakestilling av blokkering eller initialiseringsregistre, kan klassifiseres som statiske signaler. Disse typene signaler er mest effektivt tilgjengelige gjennom et anlegg som enkelt kan observere og kontrollere signalet, uten å trenge en lang rekompileringssyklus. Active Probe er et utmerket anlegg for feilsøking av statiske signaler. Tilsvarende kan signaler som endres oftere, men som fortsatt er statiske i det store flertallet av tiden, klassifiseres som pseudo-statiske og debugges også mest effektivt ved hjelp av Active Probe. Signaler som endres ofte, som klokkesignaler, kan klassifiseres som dynamiske og er ikke like lett tilgjengelige gjennom Active Probe. Live Probe er et bedre valg for å observere disse signalene.

Enkelt feilsøkingsbruk

Nå som vi har en bedre forståelse av de forskjellige feilsøkingsalternativene i kretsløpet, la oss se på et enkelt designeks.ampfor å se hvordan disse teknikkene fungerer. Figur 9 viser en enkel FPGA-design i en SmartFusion2 SoC FPGA-enhet. Microcontroller Subsystem (MSS) tilbakestilles av CoreSF2Reset Soft IP-blokken. Inngangene til denne blokken er Power On Reset, en User Fabric Reset og en ekstern tilbakestilling. Utgangene er en tilbakestilling til brukerstoffet, en MSS-tilbakestilling og en M3-tilbakestilling. Feilsymptomene er at det ikke er aktivitet på I/O-ene selv om enheten avslutter POR-tilstanden. De tre forskjellige alternativene for å feilsøke denne feilen er også illustrert i figuren: Den blå boksen (merket ETE) er for metoden for eksternt testutstyr; den grønne boksen (merket ILA) er for Internal Logic Analyzer-metoden; og den oransje boksen (merket AP) er for Active Probe-metoden. Vi vil anta at de potensielle grunnårsakene til feilen er feilaktige påståtte tilbakestillingsinnganger til CoreSF2Reset Soft IP-blokken.

La oss nå se på feilsøkingsprosessen for tre av de tidligere beskrevne in-circuit-metodene.

Eksternt testutstyr
Ved bruk av denne metoden forutsettes det at testutstyret er tilgjengelig og ikke brukes av et høyere prioritert prosjekt. I tillegg er det viktig å ha planlagt på forhånd slik at noen FPGA I/O er tilgjengelige og enkelt kan kobles til testutstyret. Å ha en header på PCB for eksample, ville være svært nyttig og minimere tiden brukt på å prøve å identifisere og koble til en "sannsynlig mistenkt" eller potensiell kortslutning av pinner under sondering. Designet må kompileres på nytt for å velge signalene vi ønsker å undersøke. Forhåpentligvis kommer vi ikke til å "skalle tilbake løken" og trenger å velge ytterligere signaler for videre undersøkelse, siden vår første undersøkelse ofte bare resulterer i flere spørsmål. Uansett kan rekompilerings- og omprogrammeringsprosessen ta en betydelig mengde tid, og hvis det resulterer i tidsbrudd, kreves en redesign (vi er alle kjent med hvor frustrerende å prøve å løse problemer med timing av stengning kan være, spesielt når du gjør designendringene for å finne en designfeil – hele prosessen kan ta fra minutter til timer)! Det er også viktig å huske at hvis designet ikke har noen gratis bruker-I/O-er, kan denne metoden ikke implementeres. Dessuten er denne metoden strukturelt påtrengende for designet – og tidsrelaterte feil kan forsvinne eller dukke opp igjen mellom iterasjonene.

Intern logikkanalysator
Ved å bruke denne metoden må ILA settes inn i designet ved hjelp av stoffressurser, og må deretter kompileres på nytt. Merk at hvis ILA allerede er instansiert, kan det hende at signalene vi ønsker å undersøke ikke har blitt instrumentert, noe som også vil kreve en rekompilering. Denne prosessen risikerer å endre det opprinnelige designet og bryte tidsbegrensninger. Hvis timingen er oppfylt, må designet omprogrammeres og initialiseres på nytt. Hele denne prosessen kan ta flere minutter eller til og med timer hvis rekompileringstidene er lange og det er behov for flere pass. Denne tilnærmingen er strukturelt påtrengende og kan føre til lignende problemer som de som er beskrevet ved bruk av metoden ovenfor.

Aktiv sonde
Ved å bruke denne metoden kan den aktive sonden pekes til kilden til de forskjellige tilbakestillingssignalene, som alle er hentet fra registerutganger (som er vanlig i enhver god digital designpraksis). Signalene velges ett om gangen fra en Active Probe-meny vist i figur 10 nedenfor. De valgte signalverdiene kan leses og vises i Active Probe-datavinduet. Eventuelle feilpåstander er lett å identifisere. Denne testen kan gjøres umiddelbart uten behov for å rekompilere og omprogrammere enheten og er ikke strukturelt eller prosedyremessig påtrengende. Hele prosessen tar bare noen få sekunder. Denne metoden kan også skape kontrollerbarhet (endre verdier asynkront) som de to andre metodene ikke tillater. I denne spesielle eksample, kan tilbakestillingssignalet fra et register lett undersøkes og oppdages å holdes i aktiv tilstand.

Kortvarig veksling av tilbakestillingssignalet kan oppnås ved asynkron å manipulere registeret som genererer hvilesignalene.

Mer kompleks feilsøkingsbruk
Ovennevnte design var veldig enkelt og er nyttig som en introduksjon til bruk av de beskrevne designteknikkene, men et mer komplekst eksample kan være enda mer illustrerende. Mange ganger er interessesignalet ikke et statisk signal slik det var i vår enkle eksample men er dynamisk. Et vanlig dynamisk signal er en mellomklokke, kanskje brukt for å time et håndtrykk for et seriell grensesnitt. Figur 11 viser en slik design med brukerens Soft IP-kjerne, i dette tilfellet et tilpasset seriell grensesnitt koblet til systemets APB-bussen. Feilsymptomene er at det ikke er aktivitet på brukerens tilpassede serielle grensesnitt, og at når en APB-bussmaster utsteder en transaksjon for å få tilgang til det serielle grensesnittet, går den inn i en unntakstilstand som indikerer et feil håndtrykk. Disse forholdene ser ut til å utelukke en statisk årsak, som et feil tilbakestillingssignal, siden transaksjonstilstandsmaskinen ser ut til å ikke fungere med forventet hastighet og dermed forårsaker unntaket. Grunnårsaken antas å være klokkefrekvensgeneratoren i brukerens IP-kjerne.

Hvis den ikke kjører med riktig frekvens, vil de beskrevne feilene oppstå.

I denne situasjonen er det sannsynligvis en bedre strategi å erstatte Active Probe-tilnærmingen med Live Probe. Dette er illustrert i figuren ovenfor ved den oransje fargede LP-boksen, med JTAG signal for valg av sondekilde.

Eksternt testutstyr
For dette tilfellet er metodikken veldig lik den tidligere beskrevne enkle eksample. Brukerklokkesignalet bringes ut til testpunktet (forhåpentligvis på en header) og en tidkrevende rekompilering er nødvendig. Det kan også være nyttig å få frem et referansesignal, kanskje en systemklokke som brukes til å klokke brukerens IP som et sammenligningssignal. Vi vil igjen bli utsatt for behovet for å rekompilere og omprogrammere slik at hele prosessen kan ta en betydelig mengde tid.

Intern logikkanalysator
Denne saken er veldig lik den enkle eksample. ILAen må settes inn, eller det ønskede signalet defineres, og en rekompilerings- og omprogrammeringssyklus utføres. Alle de tidligere beskrevne problemene resulterer fortsatt i en betydelig feilsøkingssyklustid. Det er imidlertid en ekstra kompleksitet. Klokken som driver ILA må være synkron, og ideelt sett mye raskere med hensyn til klokken som skal observeres fra brukerens Soft IP-kjerne. Hvis disse klokkene er asynkrone, eller ikke har de riktige tidsforholdene, vil datafangst være uforutsigbar og en mulig kilde til forvirring for feilsøkingsprosessen.
Merk at hvis brukerens Soft IP-klokke ikke genereres på brikken (kanskje den gjenopprettes fra det serielle grensesnittet) kan designeren trenge å legge til en klokkemodul for å generere en raskere ILA-klokke ved å bruke ekstra ressurser og muligens skape et tidsbrudd.

Live sonde
Ved å bruke denne metoden kan Live Probe raskt pekes til kilden til brukerklokken og enhver annen klokkekilde fra et register for å finne årsaken til feilen. Live Probe vil vise de valgte signalutgangene i sanntid, og ethvert tidsforhold mellom signalene er dermed mye lettere å bestemme. Hele prosessen tar bare noen få sekunder.

Andre feilsøkingsfunksjoner for serielle grensesnitt
Det er også viktig å påpeke at det er mange ekstra feilsøkingsmuligheter i SmartFusion2 SoC FPGA- og IGLOO2 FPGA-enheter som kan brukes på serielle grensesnitt, som den i forrige eks.ampLe design hvor feil er enda mer kompliserte. SERDES Debug, for eksample, gir spesifikke feilsøkingsfunksjoner for de dedikerte høyhastighets serielle grensesnittene. Noen av SERDES Debug-funksjonene inkluderer PMA-teststøtte (som PRBS-mønstergenerering og loopback-testing) støtte for flere SERDES-testkonfigurasjoner med rekonfigurasjon på registernivå for å unngå bruk av hele designflyten for å gjøre konfigurasjonsendringer, og tekstrapporter som viser konfigurerte protokoller, SERDES-konfigurasjonsregistre og Lane-konfigurasjonsregistre. Disse funksjonene gjør SERDES feilsøking mye enklere og kan brukes sammen med Live Probe og Active Probe for å øke hastigheten på feilsøking av komplekse kretser.
Det tidligere beskrevne Memory Debug-verktøyet kan også brukes sammen med SERDES Debug to speed-testing. Siden minnebuffere raskt og enkelt kan inspiseres og endres med Memory Debug, er det mulig å raskt lage "testpakker" og observere loopback eller inter-system kommunikasjonsresultater. Designeren kan utnytte disse egenskapene og dermed minimere behovet for spesialiserte "testseler" som bruker ekstra FPGA-stoff og som kan påvirke chip-timing.

Konklusjon
Denne artikkelen har beskrevet i detalj flere forskjellige tilnærminger for å implementere in-circuit debug for FPGA-er og SoC FPGA-er - bruken av en Integrated Logic Analyzer, bruken av eksternt testutstyr og bruken av dedikerte probekretser integrert i FPGA-stoffet. Tillegget av spesialiserte og dedikerte probekretser, som Active Probe og Live Probe som tilbys av Microsemi på SmartFusion2 SoC FPGA- og IGLOO2 FPGA-enheter, ble vist å øke hastigheten og forenkle feilsøkingsprosessen betydelig. Muligheten til å raskt endre utvalget av interne signaler (uten å måtte utføre en svært tidkrevende rekompilerings- og omprogrammeringssyklus), og muligheten til å undersøke interne signaler (uten behov for å bruke FPGA-stoff og potensielt introdusere tidsbrudd) ble vist å være store fordelertages ved feilsøking av FPGA-design. I tillegg ble bruken av flere metoder, som kan fungere sammen for å gi en enda mer omfattende feilsøkingsfunksjon, beskrevet. Til slutt to eksampLe debug use cases ble gitt for å illustrere avveiningene mellom de beskrevne metodene.

For å lære mer

1. IGLOO2 FPGA-er
2. SmartFusion2 SoC FPGAer

Microsemi Corporation (Nasdaq: MSCC) tilbyr en omfattende portefølje av halvleder- og systemløsninger for kommunikasjon, forsvar og sikkerhet, romfart og industrielle markeder. Produktene inkluderer høyytelses og strålingsherdede analoge integrerte kretser med blandede signaler, FPGA-er, SoC-er og ASIC-er; strømstyring produkter; timing- og synkroniseringsenheter og presise tidsløsninger, setter verdens standard for tid; stemmebehandling enheter; RF-løsninger; diskrete komponenter; sikkerhetsteknologier og skalerbar anti-tamper produkter; Power-over-Ethernet ICer og midspans; samt tilpassede designfunksjoner og tjenester. Microsemi har hovedkontor i Aliso Viejo, California, og har omtrent 3,400 ansatte globalt. Lær mer på www.microsemi.com.

© 2014 Microsemi Corporation. Alle rettigheter forbeholdt. Microsemi og Microsemi-logoen er varemerker for Microsemi Corporation. Alle andre varemerker og tjenestemerker tilhører sine respektive eiere.

Microsemi Corporate Headquarters

• En Enterprise, Aliso Viejo CA 92656 USA
• Innenfor USA: +1 800-713-4113
• Utenfor USA: +1 949-380-6100
• Salg: +1 949-380-6136
• Faks: +1 949-215-4996
• E-post: sales.support@microsemi.com

FAQ

• Spørsmål: Hva er den maksimale datafangstfrekvensen til enheten?
  A: Enheten støtter datafangst på opptil 100MHz, egnet for de fleste måldesign.
• Spørsmål: Må jeg rekompilere designet når jeg bruker sondekretser for feilsøking?
  A: Nei, sondepunktplasseringer kan raskt endres uten å kreve designrekompilering eller omprogrammering.

Dokumenter / Ressurser

Mikrosemi In-Circuit FPGA feilsøking [pdf] Instruksjoner In-Circuit FPGA Debug, FPGA Debug, Debug

Referanser

• Brukerhåndbok