Microsemi In-Circuit FPGA Debug

Produktinformation

Specifikationer

• Enhedstype: Microsemi SmartFusion2 SoC FPGA
• Udgivelsesdato: maj 2014
• Debugging-funktioner: In-Circuit FPGA Debug, Embedded Logic Analyzer
• Maksimal datafangstfrekvens: Op til 100MHz

Abstrakt
FPGA'er er kraftfulde designelementer i indlejrede systemer med mange designadvanertages, men disse enheder kan have komplekse designs med komplekse designproblemer, der skal fejlfindes. Det kan være en udfordring at spore designproblemer som definitionsfejl, systeminteraktionsproblemer og systemtimingsfejl. Inkluderingen af ​​in-circuit debug-funktioner i en FPGA kan forbedre hardwarefejlretningen dramatisk og undgå tæller af timers frustration. Dette papir beskriver flere forskellige tilgange til in-circuit debug for FPGA'er, identificerer vigtige afvejninger og gennem en f.ampDesignet, målrettet til en Microsemi SmartFusion®2 SoC FPGA-enhed, vil vise, hvordan nye muligheder kan bruges til at fremskynde fejlfinding og test.

Indledning

FPGA'er er gennemgående og kraftfulde designelementer og findes nu i stort set alle indlejrede systemer. Med stigende kapacitet, inklusion af komplekse on-chip funktionelle blokke og avancerede serielle grænseflader kan disse enheder også have komplekse designproblemer, der skal debugges. Sporing af problemer såsom funktionelle definitionsfejl (på FPGA eller systemniveau), funktionelle systeminteraktionsproblemer, systemtimingsproblemer og signaltroskabsproblemer mellem IC'er (som støj, krydstale eller refleksioner) bliver alt sammen meget mere komplekst, når du bruger avancerede FPGA'er. Simulering er bestemt en stor hjælp til at identificere mange designproblemer, men mange interaktioner i den virkelige verden dukker ikke op, før designet er implementeret i hardware. Flere forskellige teknikker til fejlretning af komplekse designproblemer er blevet udviklet for at forenkle processen. En omhyggelig forståelse af hver af disse nøgleteknikker, inklusive de forskellige advantages og disadvantages, er nyttig, når man overvejer, hvilken teknik eller kombination af teknikker, der er egnet til et bestemt design.
En eksample FPGA-design, målrettet til en Microsemi SmartFusion2 SoC FPGA-enhed, kan bruges til at demonstrere nogle af fordelenetages og disadvantages af disse standardteknikker såvel som de nyeste in-circuit debug-funktioner. Dette illustrative example vil vise, hvordan disse forskellige teknikker kan bruges til at fremskynde identifikation og eliminering af hardwareproblemer under hardwarefejlretning.

Hvorfor er FPGA-fejlretning et kritisk aspekt af systemdesign og -udvikling?
FPGA'er har to hovedbrugsmodeller, der adskiller dem fra andre designelementer. FPGA'er kan bruges i produktionsproduktet eller kan bruges som et udviklingsværktøj til at bevise eller prototype et produktionsdesignkoncept. Når de bruges som produktionskøretøj, kan FPGA'er være et meget mere fleksibelt mål end ASIC eller CPU-baserede produktionskøretøjer. Dette er især vigtigt for et nyt design, som endnu ikke er implementeret i hardware. Designs med forskellige arkitektoniske muligheder kan nemt skabes og testes, så det optimale design identificeres. FPGA'er med on-chip-processorer (SoC FPGA'er) gør det også muligt at afveje CPU-baseret behandling med hardware-assisteret FPGA-baserede accelerationsfunktioner. Disse advantages kan dramatisk reducere den tid, der kræves til design, validering, test og fejlanalyse for nye produktudviklinger.
Når det bruges til prototyping af et design, måske til en produktions-ASIC, er FPGA-fleksibilitet en vigtig fordel. En egentlig hardwareplatform, selv en der ikke kører med fuld hastighed, gør det meget nemmere at opnå detaljerede systemydelsesmålinger, data for gennemløbsanalyse og arkitekturbevis-af-koncept-resultater. FPGA-understøttelse af hærdede implementeringer af industristandard busser (såsom PCIe®, Gigabit Ethernet, XAUI, USB, CAN og andre) forenkler testningen forbundet med disse grænseflader. De nyeste familier af FPGA'er med on-chip ARM-processorer (SoC FPGA'er), gør det nemt at prototype implementeringer med indlejrede processorer. Tidligere udviklet processorkode kan porteres til prototypen, og ny kode kan oprettes parallelt med hardwaredesignindsatsen.

Denne kombination af en standardprocessor med standardgrænsefladebusser gør det muligt at udnytte det store økosystem af tilgængelige kodebiblioteker, drivere, funktionelle API'er, realtidsoperativsystemer og endda komplette operativsystemer til meget hurtigere at skabe en fungerende prototype. Derudover, når designet er størknet, kan FPGA-prototypen bruges til at fange omfattende simuleringstestsæt (for både stimulus og respons), der afspejler faktiske systemdata. Disse datasæt kan være uvurderlige til at skabe de endelige simuleringer til en ASIC eller anden produktionsimplementering. AdvanentagBrugen af ​​en FPGA som designprototype kan dramatisk reducere tiden til design, validering, testning og fejlanalyse for den endelige produktimplementering.
I begge disse almindelige FPGA-brugsmodeller er fleksibiliteten af ​​FPGA'en som et designmål en vigtig fordeltage. Dette betyder, at mange designændringer og iterationer ville være normen, og derfor ville evnen til hurtigt at debugge designfejl være afgørende for at muliggøre så mange designmuligheder som muligt. Uden en effektiv debug-funktion er meget af advantagFPGA-designfleksibiliteten vil blive formindsket af den ekstra debugging-tid, der kræves. Heldigvis kan FPGA'er også give yderligere hardwarefunktioner, der dramatisk forenkler realtidsfejlretning. Inden vi ser på disse muligheder, lad os først se på de mest almindelige typer problemer, som et FPGA-design kan blive konfronteret med, så vi har den rette baggrund til at evaluere effektiviteten og de tilhørende afvejninger af forskellige fejlfindingsværktøjer.

Almindelige problemer ved fejlretning af FPGA-design

Sammen med de udvidede muligheder, som moderne FPGA'er bringer, gør den tilhørende øgede kompleksitet det sværere at skabe fejlfrie designs. Faktisk er det blevet anslået, at fejlfinding kan tage over 50 % af den indlejrede systemdesigncyklus. Med time-to-market pres, der fortsætter med at presse udviklingscyklussen, er hardwarefejlretning af det oprindelige system henvist til en eftertanke – alt for ofte forudsat at verifikationen (selv en stor procentdel)tage i udviklingsplanen), vil fange alle fejlene før den første systemopstart. Lad os se på nogle få almindelige typer systemproblemer for bedre at forstå de udfordringer, et typisk design vil stå over for under den første systemoprettelse.

Funktionelle definitionsfejl kan være dobbelt svære at finde, da designeren har misforstået et bestemt krav, så fejlen kan overses, selv når man ser nøje på detaljerne i designet. En eksample af en almindelig funktionel definitionsfejl ville være, hvor en tilstandsmaskineovergang ikke ender i den rigtige tilstand. Fejl kan også dukke op i systemgrænseflader som et interaktionsproblem. Interface latency, f.eksample, kan være forkert specificeret, hvilket resulterer i et uventet bufferoverløb eller underløbstilstand.
Timingproblemer på systemniveau er en anden meget almindelig kilde til designfejl. Især asynkrone hændelser er en almindelig kilde til fejl, når synkronisering eller krydsende timing-domæneeffekter ikke overvejes nøje. Når du arbejder med hastighed, kan disse typer fejl være meget problematiske og kan dukke op meget sjældent, måske kun når specifikke datamønstre manifesterer sig. Mange almindelige tidsovertrædelser falder ind under denne kategori og er normalt meget svære, hvis ikke umulige at simulere.

Tidsovertrædelser kan også være resultatet af lav signalfidelitet mellem integrerede kredsløb, især i systemer med flere strømskinner for hvert kredsløb. Lav signalfidelitet kan resultere i signalstøj, krydstale, refleksioner, overbelastning og problemer med elektromagnetisk interferens (EMI), der ofte viser sig som timingovertrædelser. Strømforsyningsproblemer, såsom transienter (især under systemstart eller -nedlukning), belastningsvariationer og høje strømafledningsbelastninger kan også resultere i mystiske fejl, som ofte ikke let kan spores tilbage til en strømforsyningskilde. Selv når designet er helt korrekt, kan pladefabrikationsproblemer resultere i fejl. Defekte loddesamlinger og forkert fastgjorte stik, f.eksample, kan være kilden til fejl og kan endda være temperatur- eller kortets placering afhængig. Brugen af ​​avancerede FPGA-pakketeknikker kan gøre det svært at sondere signaler på printkortet til, så det kan ofte være problematisk at få adgang til et ønsket signal. Ofte skaber mange designproblemer ikke en umiddelbar fejl og skal bølge gennem designet, indtil fejlen faktisk viser sig. At spore startfejlen tilbage til hovedårsagen kan ofte være en frustrerende, vanskelig og tidskrævende opgave.

F.eksample, en enkelt bit forkert i en oversættelsestabel resulterer muligvis ikke i en fejl før mange cyklusser senere. Nogle af de værktøjer, vi vil diskutere senere i dette papir, som bruger dedikeret in-circuit debug-hardware, er specifikt rettet mod at gøre disse 'bug-jagter' hurtigere og nemmere. Før vi kommer ind på detaljerne i disse værktøjer, lad os først se på en populær softwarebaseret fejlfindingstekniksimulering for bedre at forstå fordelentages og disadvantages af at bruge simulering til debugging.

Brug af simulering til fejlretning
Typisk i en designsimulering modelleres alle virkelige komponenter i og uden for designet matematisk som softwareprocesser, der udføres sekventielt på en standard CPU. At anvende en bred vifte af stimulus til designet og kontrollere det forventede output i forhold til det simulerede designs output, er en nem måde at fange de fleste åbenlyse designfejl. Et vindue, der viser en typisk simuleringskørsel, er vist i figur 1 nedenfor. Den klare fordeltage af simuleringsvers hardwarebaseret debugging er, at simulering kan udføres i softwaren - ingen egentlig hardwarebaseret design og testbench er nødvendig. Simulering kan hurtigt fange mange designfejl, især dem, der er forbundet med ukorrekte specifikationer, misforståelser af grænsefladekrav, funktionsfejl og mange andre "grove" fejltyper, der let detekteres gennem simple stimulusvektorer.

Simulering er især effektiv, når omfattende stimuluskombinationer er tilgængelige for designeren, og de resulterende output er velkendte. I disse tilfælde kan simulering lave en næsten udtømmende test af et design. Desværre har de fleste designs ikke nem adgang til omfattende testsuiter, og processen med at skabe dem kan være meget tidskrævende. At skabe en testsuite, der dækker 100 % af designet, er praktisk talt umuligt for store FPGA-baserede designs, og genveje skal bruges til at forsøge at dække de centrale elementer i designet. Et andet problem med simulering er, at det ikke er en implementering af den 'virkelige verden' og ikke kan fange asynkrone hændelser, systeminteraktioner med hastighed eller tidsovertrædelser. Endelig kan simuleringsprocessen være meget langsom, og hvis der kræves mange iterationer, bliver simulering hurtigt den mest tidskrævende og ofte den dyreste del af udviklingsprocessen.

Som et alternativ (eller måske bedre sagt, som en tilføjelse til simulering) fandt FPGA-designere ud af, at de kunne tilføje debug-hardware til FPGA-designet for at observere og kontrollere nøglesignaler i enheden. Disse teknikker udviklede sig oprindeligt som ad-hoc-tilgange, men har efterhånden udviklet sig til en standard hardware-fejlretningsstrategi. Denne brug af in-circuit debug-funktioner giver betydelige fordeletages til FPGA-baserede designs, og det næste afsnit vil udforske de tre mest almindelige strategier og deres forskellige fordeletages og disadvantages.

Fælles In-Circuit Debug Approaches for FPGA'er
De mest almindelige teknikker til implementering af in-circuit debug-funktioner i FPGA'er bruger enten en indlejret logisk analysator, eksternt testudstyr eller dedikeret signalsondehardware indlejret i FPGA-strukturen. Den indlejrede logiske analysator implementeres typisk ved hjælp af FPGA-stof og indsættes i designet. Den JTAG port bruges til at få adgang til analysatoren, og de opsamlede data kan vises på en pc. Når der bruges eksternt testudstyr, modificeres FPGA-designet, der testes, således at udvalgte interne FPGA-signaler dirigeres til udgangsben. Disse stifter kan så observeres gennem det eksterne testudstyr. Når der bruges dedikeret signalsondehardware, kan et bredt udvalg af interne signaler læses i realtid. Nogle sondeimplementeringer kan endda bruges til at skrive til register eller hukommelsesplaceringer, hvilket yderligere forbedrer fejlfindingsmulighederne. Lad os se mere detaljeret på advantages og disadvantages af hver af disse teknikker og se derefter på en exampdesign for at se, hvordan disse forskellige tilgange kan påvirke den samlede fejlretningstid.

In-Circuit FPGA Debug-Embedded Logic Analyzer
Konceptet med den indlejrede logikanalysator var et direkte resultat af de ad-hoc in-circuit debugging-funktioner, som designere implementerede, da FPGA'er blev brugt første gang. Indlejrede logiske analysatorer tilføjede nye muligheder og eliminerede kravet om, at designeren skulle udvikle deres egen analysator. De fleste FPGA'er tilbyder disse muligheder, og tredjeparter tilbyder standardanalysatorer (Identify®, fra Synopsys, er et populært eks.ample), der nemt kan interface med værktøjer på højere niveau for yderligere at forbedre produktiviteten.

Den logiske analysator-funktionalitet er indsat i designet ved at bruge FPGA-stof og indlejrede hukommelsesblokke som sporingsbuffere, som illustreret i figur 2. Der oprettes også udløsende ressourcer, så komplekse signalinteraktioner nemt kan vælges og fanges. Adgang til analysatoren til kontrol og dataoverførsel sker typisk gennem standard JTAG port for at forenkle grænsefladekrav. Opsamlede data kan vises på en pc ved hjælp af fælles viewing software og spejler typisk en logisk simulator bølgeform output viewing stil.

Advanentages af denne tilgang er, at der ikke bruges yderligere FPGA I/O-ben, kun standard JTAG signaler. De indlejrede logiske analyser IP-kerner er normalt relativt billige og kan i nogle tilfælde være en mulighed for eksisterende FPGA-syntese eller simuleringsværktøjer. I nogle tilfælde kan den indlejrede logiske analysator også give yderligere output på ubrugte I/O'er, hvis det er mere bekvemt. En af ulempernetagGrunden til denne tilgang er, at der kræves en stor mængde FPGA-ressourcer. Hvis der anvendes sporingsbuffere, vil dette især reducere antallet af tilgængelige blokhukommelser. Hvis der er behov for en bred buffer, vil dette også være en afvejning mod hukommelsesdybde (da brugen af ​​en bredere hukommelse resulterer i mindre hukommelsesdybde) - en stor ulempetage ved brug af mindre enheder. Måske er den største ulempe ved denne teknik, at hver gang der foretages en justering af sondeplacering, er det nødvendigt at omkompilere og omprogrammere designet. Når du bruger en stor enhed, kan denne proces tage en betydelig mængde tid. På grund af den måde, signalproberne er placeret i designet, kan det være vanskeligt at korrelere signaltimingsforhold. Derudover er forsinkelserne mellem signalsonderne ikke konsistente, og timing-forhold er derfor vanskelige at sammenligne. Dette er en særlig vanskelighed, når man sammenligner asynkrone signaler eller signaler fra forskellige tidsdomæner.

In-Circuit FPGA Debug – Eksternt testudstyr
Brugen af ​​in-circuit debug-kode i forbindelse med eksternt testudstyr var en naturlig udvikling, da en ekstern logisk analysator allerede var tilgængelig til systemtest. Ved at oprette en simpel fejlretningskode til at identificere og vælge interne testsignaler og anvende dem på FPGA I/O'er, som vist i figur 3, var det muligt at udnytte analysatorens avancerede muligheder (såsom store sporingsbuffere, komplekse udløsningssekvenser og flere viewing options) for at skabe enkle, men kraftfulde fejlretningsmiljøer. Mere komplekse in-circuit-funktioner til avancerede triggermuligheder kan minimere antallet af nødvendige udgange. F.eksampDet kan være uoverkommeligt at vælge specifikke adresser på en bred bus, hvis eksterne ben var påkrævet.
Brug af intern FPGA-logik reducerer I/O-kravene dramatisk og kan endda lede efter specifikke adressemønstre (måske en opkalds- og retursekvens) til fejlretning af mere komplekse problemer. Hvis en fælles brugergrænseflade er tilgængelig, kan dette forenkle indlæringskurven og forbedre produktiviteten.

AdvanentagGrunden til denne tilgang er, at den udnytter omkostningerne ved det eksterne testudstyr, og der er således ingen ekstra værktøjsomkostninger. Nogle debug-kredsløbs-IP-kerner er tilgængelige fra udstyrsproducenter eller FPGA-producenter og kan være meget lave omkostninger eller endda gratis. Mængden af ​​FPGA-ressourcer, der kræves for at implementere signaludvælgelseslogikken, er meget lille, og da sporingsfunktionen udføres ved hjælp af den eksterne logikanalysator, er der ikke behov for blokhukommelser. Da valglogik er billig, kan et stort antal kanaler med bred triggering også understøttes. Den logiske analysator kan fungere i både en timing-tilstand og en tilstandstilstand, som hjælper med at isolere nogle timing-problemer.
DisadvantagDenne tilgang kan omfatte behovet for at købe en logisk analysator, hvis den ikke allerede er allokeret til projektet. Denne ulempetage kan være nok til at fraråde denne tilgang i mange tilfælde. Bemærk dog, at nogle billige logiske analyser er ved at blive tilgængelige, som bruger pc'en eller en tablet til visning, hvilket gør denne mulighed meget mere omkostningseffektiv til simple debug-krav.
Antallet af forbrugte FPGA-ben kan være en anden ulempetage, og hvis brede busser skal overholdes, er der behov for betydelig planlægning for boardlayout og tilføjelse af debug-stik. Dette krav er oftest svært at forudsige tidligt i designfasen og en anden uønsket kompleksitet. I lighed med den indlejrede logiske analysemetode kræver den eksterne teststrategi omkompilering og omprogrammering af et design, når hvert nyt eksperiment er nødvendigt.

Den fælles ulempetages af disse to teknikker – brugen af ​​on-chip-ressourcer (som også kan påvirke designets timing-ydeevne og skabe yderligere debugging-krav) behovet for at omkompilere og omprogrammere designet (som kan tilføje timer eller endda dage til fejlretningsplanen), den forudgående planlægning, der kræves for at identificere sandsynlige testscenarier, og brugen af ​​yderligere chip I/O-ressourcer skabte et behov for en tilgang. Et svar var tilføjelsen af ​​dedikeret debug-logik i FPGA-strukturen på nogle enheder. In-circuit debug ved hjælp af hardwareprober var resultatet.

In-Circuit FPGA Debug – Hardwareprober
Brugen af ​​hardwareprober forenkler dramatisk in-circuit debug-teknikker for FPGA'er. Denne teknik implementeret som en Live Probe-funktion på SmartFusion2®SoC FPGA- og IGLOO®2 FPGA-enheder, tilføjer dedikerede probelinjer til FPGA-strukturen for at observere output fra enhver logisk elementregisterbit. Som vist i blokdiagrammet i figur 4 er hardwareprober tilgængelige i to probekanaler A og B.

Udvalgte registerudgange (probepunkter), som den, der er hentet nederst i figuren, dirigeres over de to probekanaler og kan, hvis de er valgt, anvendes til enten A- eller B-kanalen. Disse kanalsignaler i realtid kan derefter sendes til dedikerede Probe A- og Probe B-ben på enheden. Probe A- og Probe B-signalerne kan også dirigeres internt til en indbygget logisk analysator.

Bemærk, at probestifternes timingkarakteristika er regelmæssige og har ubetydelig afvigelse fra et probepunkt til et andet, hvilket gør det meget lettere at sammenligne timingkarakteristika for realtidssignalerne. Data kan fanges ved op til 100MHz, hvilket gør det passende for de fleste måldesigns.
Måske vigtigst af alt kan sondepunktsplaceringerne, eftersom de ikke er udvalgt som en del af det implementerede design (de vælges gennem dedikeret hardware, mens designet kører på FPGA), hurtigt ændres ved blot at sende udvalgsdataene til enheden. Ingen designrekompilere og omprogrammering er nødvendig.
For at forenkle brugen af ​​Live Probe-kapaciteten endnu mere, har det tilhørende debug-softwareværktøj adgang til alle sondesignalplaceringerne gennem en automatisk genereret debug file. Som vist i figur 5 kan signalnavnet vælges fra signallisten og anvendes på den ønskede kanal. Dette kan gøres, selv mens designet kører, så sonderingsaktiviteten i designet er problemfri og meget effektiv.

I mange tilfælde kan hardwareprobe-kapaciteten, ligesom Live Probe, bruges sammen med den tidligere beskrevne indlejrede logikanalysator og de eksterne testteknikker.

Som vist i figur 6 gør Live Probe-evnen til at vælge signaler 'on the fly' det muligt hurtigt og nemt at ændre signalerne under observation uden at skulle kompilere designet igen. En ekstern logisk analysator eller skop kan nemt observere de probede signaler, som vist i øverste højre del af figuren på de dedikerede probeudgangsben. Alternativt (eller måske endda som supplement til) kan den interne logiske analysator (ILA Identify-blokken, vist på figuren) bruges til at observere probestifterne. Probesignalerne kan opfanges af ILA'en og observeres på bølgeformvinduet. Probeplaceringer kan ændres uden behov for at rekompilere måldesignet.
Bemærk, at de yderligere muligheder for triggering og sporing kan bruges til at forbedre probefunktionaliteten, hvilket gør det nemt at få øje på selv komplekse designproblemer.

Yderligere hardwarefejlfindingsfunktioner er også tilgængelige på SmartFusion2 SoC FPGA- og IGLOO2 FPGA-enhederne. En af disse egenskaber, kaldet Active Probe, kan dynamisk og asynkront læse eller skrive til enhver logisk elementregisterbit. En skrevet værdi består i en enkelt clock-cyklus, så normal drift kan fortsætte, hvilket gør det til et meget værdifuldt fejlfindingsværktøj. Active Probe er af særlig interesse, hvis der ønskes en hurtig observation af et internt signal (måske blot for at kontrollere, at det er aktivt eller i den ønskede tilstand, som et nulstillingssignal), eller hvis der er behov for hurtigt at teste en logisk funktion ved at skrive til et sondepunkt
(måske for at starte en tilstandsmaskineovergang ved hurtigt at indstille en inputværdi for at isolere et kontrolflowproblem).

En anden debug-funktion, der leveres af Microsemi, er Memory Debug. Denne funktion giver designeren mulighed for dynamisk og asynkront at læse eller skrive til en valgt FPGA-stof SRAM-blok. Som illustreret på skærmbilledet af fejlretningsværktøjet (Figur 7), når fanen Hukommelsesblokke er valgt, kan brugeren vælge den ønskede hukommelse, der skal læses, udføre et snapshot-fangst af hukommelsen, ændre hukommelsesværdier og derefter skrive værdierne tilbage til enheden. Dette kan være særligt nyttigt til kontrol eller indstilling af databuffere, der bruges i kommunikationsporte til beregningsorienteret scratch-pad eller endda til kode udført af en indlejret CPU. Fejlretning af komplekse dataafhængige fejl er betydeligt hurtigere og nemmere, når hukommelser kan observeres og kontrolleres så hurtigt.

Når først et design er fejlrettet, kan det være ønskeligt at deaktivere hardwarefejlretningsfunktionerne for at beskytte følsomme oplysninger. En angriber kan bruge de samme faciliteter til at udlæse kritisk information eller ændre systemindstillinger, der kan give nem adgang til følsomme dele af systemet. Microsemi har tilføjet funktioner, der giver designeren mulighed for at sikre enheden, efter at fejlretningen er afsluttet. F.eksample, adgang til Live Probe og Active Probe kan låses for fuldstændigt at deaktivere funktionen som et muligt angrebsmiddel (det eliminerer endda muligheden for probeaktivitet, der skaber mønstre i forsyningsstrømmen, som kan bruges til at forsøge at observere sondedata indirekte). Alternativt kan adgangen til udvalgte dele af designet låses ude for at forhindre adgang til netop disse sektioner. Dette kan være praktisk, hvis kun en del af designet skal være sikkert, hvilket gør resten af ​​designet stadig tilgængeligt til felttest eller fejlanalyse.

In-Circuit Debug Comparison Chart
Nu hvor en detaljeret vedrview af de tre vigtigste in-circuit hardware-fejlretningsteknikker er blevet beskrevet et oversigtsdiagram, som vist i figur 8, som beskriver de forskellige advantages og disadvantages af hver metode. Husk at nogle teknikker kan bruges sammen (Live Probe og Internal Logic Analyzer (ILA), som Synopsys Identify, f.eks.ample), kan vi se de vigtigste styrker og svagheder ved hver teknik. Samlingen af ​​in-circuit hardware debug-funktioner (Live Probe, Active Probe og Memory Debug – samlet kaldet SmartDebug), er svagest i forhold til de andre teknikker, når det kommer til antallet af tilgængelige prober (en rød cirkel) og er svagere end de bedste (gul cirkel), når optagelseshastigheden betragtes (eksternt testudstyr kan være hurtigere).
ILA-baserede teknikker, som Synopsys Identify, er svagest sammenlignet med de andre teknikker, og når FPGA-ressourcekrav tages i betragtning. Eksternt testudstyr-baserede teknikker er svagest i forhold til en række overvejelser, hvor omkostninger, designtidspåvirkning og probebevægelsesoverhead (på grund af behovet for at omkompilere designet) de mest byrdefulde. Måske er den optimale løsning en kombination af SmartDebug og en af ​​de andre teknikker, så antallet af kanalers svaghed i SmartDebug kan afbødes og sondepunktets bevægelse ulempe.tages af de andre teknikker reduceres også.

Signalklassifikationer
Der kan skelnes mellem nogle af de mest almindelige typer signaler, og dette kan hjælpe, når man planlægger en fejlretningstilgang. F.eksampl, signaler, der ikke ændrer sig andet end under systemstart, såsom systemnulstilling, bloknulstilling eller initialiseringsregistre, kan klassificeres som statiske signaler. Disse typer signaler tilgås mest effektivt gennem en facilitet, der nemt kan observere og kontrollere signalet uden at skulle bruge en lang genkompileringscyklus. Active Probe er en fremragende facilitet til debugging af statiske signaler. Tilsvarende kan signaler, der ændrer sig hyppigere, men stadig er statiske i langt størstedelen af ​​tiden, klassificeres som pseudo-statiske og debugges også mest effektivt ved hjælp af Active Probe. Signaler, der skifter hyppigt, ligesom ursignaler, kan klassificeres som dynamiske og er ikke så let tilgængelige via Active Probe. Live Probe er et bedre valg til at observere disse signaler.

Enkelt fejlretningsbrug

Nu hvor vi har en bedre forståelse af de forskellige in-circuit debug muligheder, lad os se på et simpelt design f.eks.ampfor at se, hvordan disse teknikker fungerer. Figur 9 viser et simpelt FPGA-design i en SmartFusion2 SoC FPGA-enhed. Microcontroller Subsystem (MSS) nulstilles af CoreSF2Reset Soft IP-blokken. Indgangene til denne blok er Power On Reset, en User Fabric Reset og en ekstern nulstilling. Udgangene er en nulstilling til User Fabric, en MSS-nulstilling og en M3-nulstilling. Fejlsymptomerne er, at der ikke er nogen aktivitet på I/O'erne, selvom enheden afslutter POR-tilstanden. De tre forskellige muligheder for fejlretning af denne fejl er også illustreret i figuren: Den blå boks (mærket ETE) er til metoden med eksternt testudstyr; den grønne boks (mærket ILA) er til metoden Internal Logic Analyzer; og den orange boks (mærket AP) er til Active Probe-metoden. Vi vil antage, at de potentielle grundårsager til fejlen er ukorrekt hævdede nulstillingsinput til CoreSF2Reset Soft IP-blokken.

Lad os nu se på fejlretningsprocessen for tre af de tidligere beskrevne in-circuit metoder.

Eksternt testudstyr
Ved brug af denne metode antages det, at testudstyret er tilgængeligt og ikke anvendes af et højere prioriteret projekt. Derudover er det vigtigt at have planlagt på forhånd, så nogle FPGA I/O'er er tilgængelige og nemt kan tilsluttes testudstyret. At have en header på printkortet f.eksample, ville være meget nyttigt og minimere tid brugt på at forsøge at identificere og oprette forbindelse til en 'sandsynlig mistænkt' eller den potentielle kortslutning af stifter under sondering. Designet skal genkompileres for at vælge de signaler, vi ønsker at undersøge. Forhåbentlig vil vi ikke "skrælle løget tilbage" og skal vælge yderligere signaler til yderligere undersøgelse, da vores indledende undersøgelse ofte kun resulterer i flere spørgsmål. Under alle omstændigheder kan omkompilerings- og omprogrammeringsprocessen tage en betydelig mængde tid, og hvis det resulterer i timingovertrædelser, er et redesign påkrævet (vi er alle bekendt med, hvor frustrerende det kan være, hvor frustrerende at prøve at løse timing-lukningsproblemer, især når du foretager designændringerne for at finde en designfejl – hele processen kan tage fra minutter til timer)! Det er også vigtigt at huske, at hvis designet ikke har nogen gratis bruger-I/O'er, kan denne metode ikke implementeres. Desuden er denne metode strukturelt påtrængende for designet - og timing-relaterede fejl kan forsvinde eller dukke op igen mellem iterationerne.

Intern logikanalysator
Ved at bruge denne metode skal ILA'en indsættes i designet ved hjælp af stofressourcer og skal derefter genkompileres. Bemærk, at hvis ILA allerede er blevet instansieret, er de signaler, vi ønsker at undersøge, muligvis ikke blevet instrumenteret, hvilket også ville kræve en genkompilering. Denne proces risikerer at ændre det originale design og overtræde tidsbegrænsninger. Hvis timingen overholdes, skal designet omprogrammeres og geninitialiseres. Hele denne proces kan tage adskillige minutter eller endda timer, hvis genkompileringstider er lange, og der er behov for flere gennemløb. Denne fremgangsmåde er strukturelt påtrængende og kan resultere i lignende problemer som dem, der er beskrevet, når du bruger ovenstående metode.

Aktiv sonde
Ved at bruge denne metode kan den aktive sonde pege på kilden til de forskellige nulstillingssignaler, som alle er hentet fra registerudgange (som det er almindeligt i enhver god digital designpraksis). Signalerne vælges et ad gangen fra en Active Probe-menu vist i figur 10 nedenfor. De valgte signalværdier kan læses og vises i Active Probe-datavinduet. Eventuelle fejlpåstande er let at identificere. Denne test kan udføres med det samme uden behov for at rekompilere og omprogrammere enheden og er ikke strukturelt eller proceduremæssigt påtrængende. Hele processen tager kun et par sekunder. Denne metode kan også skabe kontrollerbarhed (ændre værdier asynkront), hvilket de to andre metoder ikke tillader. I denne særlige example, kan nulstillingssignalet, der stammer fra et register, let undersøges og opdages at blive holdt i aktiv tilstand.

Momentan omskiftning af nulstillingssignalet kan opnås ved asynkron manipulation af registeret, der genererer hvilesignalerne.

Mere kompleks fejlretningsbrug
Ovenstående design var meget enkelt og er nyttigt som en introduktion til brugen af ​​de beskrevne designteknikker, men et mere komplekst exampden er måske endnu mere illustrativ. Mange gange er interessesignalet ikke et statisk signal, som det var i vores simple eksample men er dynamisk. Et almindeligt dynamisk signal er et mellem-ur, måske brugt til at timing af et håndtryk til en seriel grænseflade. Figur 11 viser et sådant design med brugerens Soft IP-kerne, i dette tilfælde en brugerdefineret seriel grænseflade forbundet til systemets APB-bussen. Fejlsymptomerne er, at der ikke er nogen aktivitet på brugerens brugerdefinerede serielle grænseflade, og at når en APB-busmaster udsteder en transaktion for at få adgang til den serielle grænseflade, går den ind i en undtagelsestilstand, der indikerer et forkert håndtryk. Disse forhold ser ud til at udelukke en statisk årsag, såsom et forkert nulstillingssignal, da transaktionstilstandsmaskinen ikke ser ud til at fungere med den forventede hastighed og dermed forårsager undtagelsen. Grundårsagen menes at være clockfrekvensgeneratoren i brugerens IP-kerne.

Hvis den ikke kører med den korrekte frekvens, vil de beskrevne fejl resultere.

I denne situation er det sandsynligvis en bedre strategi at erstatte Active Probe-tilgangen med Live Probe. Dette er illustreret i ovenstående figur af den orangefarvede LP-boks ved hjælp af JTAG signal for valg af sondekilde.

Eksternt testudstyr
For dette tilfælde er metodikken meget lig den tidligere beskrevne simple example. Brugerens ursignal bringes ud til testpunktet (forhåbentlig på en header), og en tidskrævende omkompilering er nødvendig. Det kan også være nyttigt at få et referencesignal frem, måske et systemur, der bruges til at clocke brugerens IP som et sammenligningssignal. Vi vil igen blive udsat for behovet for at omkompilere og omprogrammere, så hele processen kan tage en betydelig mængde tid.

Intern logikanalysator
Denne sag minder meget om den simple example. ILA'en skal indsættes, eller det ønskede signal skal defineres, og en omkompilerings- og omprogrammeringscyklus skal udføres. Alle de tidligere beskrevne problemer resulterer stadig i en betydelig debug-cyklustid. Der er dog en ekstra kompleksitet. Uret, der driver ILA'en, skal være synkront og ideelt set meget hurtigere i forhold til det ur, der skal observeres fra brugerens Soft IP-kerne. Hvis disse ure er asynkrone eller ikke har de korrekte timingforhold, vil datafangst være uforudsigeligt og en mulig kilde til forvirring for fejlretningsprocessen.
Bemærk, at hvis brugerens Soft IP-ur ikke genereres on-chip (måske er det gendannet fra den serielle grænseflade), kan designeren være nødt til at tilføje et ur-modul for at generere et hurtigere ILA-ur ved hjælp af yderligere ressourcer og muligvis skabe en timing-overtrædelse.

Live sonde
Ved at bruge denne metode kan Live Probe hurtigt pege på kilden til brugeruret og enhver anden urkilde fra et register for at forfølge årsagen til fejlen. Live-sonden vil vise de valgte signaludgange i realtid, og ethvert tidsforhold mellem signalerne er således meget lettere at bestemme. Hele processen tager kun et par sekunder.

Andre fejlfindingsfunktioner til serielle grænseflader
Det er også vigtigt at påpege, at der er mange yderligere debug-funktioner i SmartFusion2 SoC FPGA- og IGLOO2 FPGA-enheder, der kan bruges på serielle grænseflader, som den i det forrige eks.ample design, hvor fejl er endnu mere komplicerede. SERDES Debug, f.eksample, giver specifikke debug-funktioner til de dedikerede højhastigheds serielle grænseflader. Nogle af SERDES Debug-funktionerne inkluderer PMA-testunderstøttelse (såsom PRBS-mønstergenerering og loopback-test) understøttelse af flere SERDES-testkonfigurationer med omkonfiguration på registerniveau for at undgå brugen af ​​det fulde designflow til at foretage konfigurationsændringer, og tekstrapporter, der viser konfigurerede protokoller, SERDES-konfigurationsregistre og vognbanekonfigurationsregistre. Disse funktioner gør SERDES debug meget nemmere og kan bruges sammen med Live Probe og Active Probe til yderligere at fremskynde fejlretning af komplekse kredsløb.
Det tidligere beskrevne Memory Debug-værktøj kan også bruges sammen med SERDES Debug to speed test. Da hukommelsesbuffere hurtigt og nemt kan inspiceres og ændres med Memory Debug, er det muligt hurtigt at oprette 'testpakker' og observere loopback eller inter-system kommunikationsresultater. Designeren kan udnytte disse muligheder og dermed minimere behovet for specialiserede 'testseler', der forbruger yderligere FPGA-stof, og som kan påvirke chiptiming.

Konklusion
Denne artikel har detaljeret beskrevet flere forskellige tilgange til implementering af in-circuit debug for FPGA'er og SoC FPGA'er - brugen af ​​en Integrated Logic Analyzer, brugen af ​​eksternt testudstyr og brugen af ​​dedikerede probekredsløb integreret i FPGA-stoffet. Tilføjelsen af ​​specialiserede og dedikerede sondekredsløb, såsom Active Probe og Live Probe, der tilbydes af Microsemi på SmartFusion2 SoC FPGA- og IGLOO2 FPGA-enheder, viste sig at fremskynde og forenkle fejlretningsprocessen betydeligt. Evnen til hurtigt at ændre valget af interne signaler (uden behov for at udføre en meget tidskrævende omkompilerings- og omprogrammeringscyklus) og evnen til at sondere interne signaler (uden behov for at bruge FPGA-struktur og potentielt introducere tidsovertrædelser) viste sig at være en stor fordeltages når debugging FPGA designs. Derudover blev brugen af ​​flere metoder, som kan arbejde sammen for at give en endnu mere omfattende fejlretningsfunktion, beskrevet. Endelig to exampLe debug use cases blev givet for at illustrere afvejningen mellem de beskrevne metoder.

For at lære mere

1. IGLOO2 FPGA'er
2. SmartFusion2 SoC FPGA'er

Microsemi Corporation (Nasdaq: MSCC) tilbyder en omfattende portefølje af halvleder- og systemløsninger til kommunikation, forsvar og sikkerhed, rumfart og industrielle markeder. Produkterne omfatter højtydende og strålingshærdede analoge blandede signal-integrerede kredsløb, FPGA'er, SoC'er og ASIC'er; strømstyring produkter; timing- og synkroniseringsenheder og præcise tidsløsninger, der sætter verdens standard for tid; stemmebehandlingsudstyr; RF-løsninger; diskrete komponenter; sikkerhedsteknologier og skalerbar anti-tamper produkter; Power-over-Ethernet IC'er og midspans; samt brugerdefinerede designmuligheder og tjenester. Microsemi har hovedkvarter i Aliso Viejo, Californien, og har cirka 3,400 ansatte globalt. Lær mere på www.microsemi.com.

© 2014 Microsemi Corporation. Alle rettigheder forbeholdes. Microsemi og Microsemi-logoet er varemærker tilhørende Microsemi Corporation. Alle andre varemærker og servicemærker tilhører deres respektive ejere.

Microsemi Corporate hovedkvarter

• En Enterprise, Aliso Viejo CA 92656 USA
• Inden for USA: +1 800-713-4113
• Uden for USA: +1 949-380-6100
• Salg: +1 949-380-6136
• Fax: +1 949-215-4996
• E-mail: sales.support@microsemi.com

FAQ

• Q: Hvad er den maksimale datafangstfrekvens for enheden?
  A: Enheden understøtter datafangst ved op til 100MHz, velegnet til de fleste måldesigns.
• Spørgsmål: Behøver jeg at omkompilere designet, når jeg bruger sondekredsløb til debugging?
  A: Nej, sondepunktsplaceringer kan hurtigt ændres uden at kræve designgenkompilering eller omprogrammering.

Dokumenter/ressourcer

Microsemi In-Circuit FPGA Debug [pdf] Instruktioner In-Circuit FPGA Debug, FPGA Debug, Debug

Referencer

• Brugermanual