Microsemi In-Circuit FPGA-debuggen

Productinformatie

Specificaties

• Apparaattype: Microsemi SmartFusion2 SoC FPGA
• Releasedatum: mei 2014
• Debugmogelijkheden: In-Circuit FPGA-debug, Embedded Logic Analyzer
• Maximale gegevensregistratiefrequentie: tot 100 MHz

Abstract
FPGA's zijn krachtige ontwerpelementen in embedded systemen met veel ontwerpvoordelen.tages, maar deze apparaten kunnen complexe ontwerpen hebben met complexe ontwerpproblemen die moeten worden gedebugged. Het opsporen van ontwerpproblemen zoals definitiefouten, systeeminteractieproblemen en systeemtimingfouten kan een uitdaging zijn. De opname van in-circuit debug-mogelijkheden in een FPGA kan de hardwaredebug aanzienlijk verbeteren en talloze uren aan frustratie voorkomen. Dit artikel beschrijft verschillende benaderingen van in-circuit debug voor FPGA's, identificeert belangrijke afwegingen en via een exampHet ontwerp, gericht op een Microsemi SmartFusion®2 SoC FPGA-apparaat, laat zien hoe nieuwe mogelijkheden kunnen worden gebruikt om debuggen en testen te versnellen.

Invoering

FPGA's zijn alomtegenwoordige en krachtige ontwerpelementen en worden nu in vrijwel elk ingebed systeem aangetroffen. Met de toenemende capaciteit, de opname van complexe on-chip functionele blokken en geavanceerde seriële interfaces kunnen deze apparaten ook complexe ontwerpproblemen hebben die moeten worden gedebugged. Het opsporen van problemen zoals functionele definitiefouten (op FPGA- of systeemniveau), functionele systeeminteractieproblemen, systeemtimingproblemen en signaalgetrouwheidsproblemen tussen IC's (zoals ruis, overspraak of reflecties) worden allemaal veel complexer bij het gebruik van geavanceerde FPGA's. Simulatie is zeker een grote hulp bij het identificeren van veel ontwerpproblemen, maar veel interacties in de echte wereld zullen pas aan het licht komen als het ontwerp in hardware is geïmplementeerd. Er zijn verschillende technieken ontwikkeld voor het debuggen van complexe ontwerpproblemen om het proces te vereenvoudigen. Een zorgvuldig begrip van elk van deze sleuteltechnieken, inclusief de verschillende geavantages en nadelentagDit is handig als u wilt weten welke techniek of combinatie van technieken geschikt is voor een bepaald ontwerp.
een exampHet FPGA-ontwerp, gericht op een Microsemi SmartFusion2 SoC FPGA-apparaat, kan worden gebruikt om enkele van de geavanceerde functies te demonstreren.tages en nadelentages van deze standaardtechnieken en de nieuwste in-circuit debug-mogelijkheden. Deze illustratieve example laat zien hoe deze verschillende technieken kunnen worden gebruikt om hardwareproblemen sneller te identificeren en op te lossen tijdens het debuggen van hardware.

Waarom is FPGA-debuggen een cruciaal aspect van systeemontwerp en -ontwikkeling?
FPGA's hebben twee hoofdgebruiksmodellen die ze onderscheiden van andere ontwerpelementen. FPGA's kunnen worden gebruikt in het productieproduct of kunnen worden gebruikt als een ontwikkelingsvoertuig om een ​​productieontwerpconcept te bewijzen of te prototypen. Wanneer ze worden gebruikt als productievoertuig, kunnen FPGA's een veel flexibeler doelwit zijn dan ASIC- of CPU-gebaseerde productievoertuigen. Dit is met name belangrijk voor een nieuw ontwerp, een ontwerp dat nog niet in hardware is geïmplementeerd. Ontwerpen met verschillende architecturale opties kunnen eenvoudig worden gemaakt en getest, zodat het optimale ontwerp wordt geïdentificeerd. FPGA's met on-chip processors (SoC FPGA's) maken het ook mogelijk om CPU-gebaseerde verwerking af te wisselen met hardware-ondersteunde FPGA-gebaseerde versnellingsfuncties. Deze voortagHiermee kunt u de tijd die nodig is voor ontwerp, validatie, testen en faalanalyse voor nieuwe productontwikkelingen aanzienlijk verkorten.
Wanneer FPGA wordt gebruikt voor het prototypen van een ontwerp, bijvoorbeeld voor een productie-ASIC, is FPGA-flexibiliteit een belangrijk voordeel. Een echt hardwareplatform, zelfs een dat niet op volle snelheid draait, maakt het veel gemakkelijker om gedetailleerde systeemprestatiemetingen, doorvoeranalysegegevens en architectuur-proof-of-conceptresultaten te verkrijgen. FPGA-ondersteuning voor geharde implementaties van industriestandaardbussen (zoals PCIe®, Gigabit Ethernet, XAUI, USB, CAN en andere) vereenvoudigt het testen dat met deze interfaces gepaard gaat. De nieuwste families van FPGA's met on-chip ARM-processors (SoC FPGA's) maken het eenvoudig om prototypes te maken van implementaties met ingebedde processors. Eerder ontwikkelde processorcode kan worden geporteerd naar het prototype en nieuwe code kan parallel aan de hardware-ontwerpinspanning worden gemaakt.

Deze combinatie van een standaardprocessor met standaardinterfacebussen maakt het mogelijk om het grote ecosysteem van beschikbare codebibliotheken, drivers, functionele API's, Real Time Operating Systems en zelfs volledige Operating Systems te benutten om veel sneller een werkend prototype te maken. Bovendien kan het FPGA-prototype, zodra het ontwerp is vastgelegd, worden gebruikt om uitgebreide simulatietestsets (voor zowel stimulus als respons) vast te leggen die werkelijke systeemgegevens weerspiegelen. Deze datasets kunnen van onschatbare waarde zijn bij het maken van de uiteindelijke simulaties voor een ASIC of andere productie-implementatie. De advantagDoor een FPGA als ontwerpprototype te gebruiken, kunt u de tijd die nodig is voor ontwerp, validatie, testen en faalanalyse voor de implementatie van het uiteindelijke product, aanzienlijk verkorten.
In beide veelvoorkomende FPGA-gebruiksmodellen is de flexibiliteit van de FPGA als ontwerpdoel een belangrijk voordeel.tage. Dit betekent dat veel ontwerpwijzigingen en iteraties de norm zouden zijn, en dus zou het vermogen om snel ontwerpfouten te debuggen cruciaal zijn om zoveel mogelijk ontwerpopties mogelijk te maken. Zonder een efficiënte debugmogelijkheid zou een groot deel van de vooruitgangtagDe flexibiliteit van FPGA-ontwerp wordt verminderd door de extra debugtijd die nodig is. Gelukkig kunnen FPGA's ook extra hardwarefuncties bieden die realtime debugging aanzienlijk vereenvoudigen. Voordat we naar deze mogelijkheden kijken, kijken we eerst naar de meest voorkomende soorten problemen waarmee een FPGA-ontwerp te maken kan krijgen, zodat we de juiste achtergrond hebben om de efficiëntie en de bijbehorende afwegingen van verschillende debugtools te evalueren.

Veelvoorkomende problemen bij het debuggen van FPGA-ontwerpen

Samen met de uitgebreide mogelijkheden die moderne FPGA's bieden, maakt de bijbehorende toegenomen complexiteit het moeilijker om foutloze ontwerpen te maken. Er is zelfs geschat dat debugging meer dan 50% van de ontwerpcyclus van een embedded systeem in beslag kan nemen. Nu de druk van de time-to-market de ontwikkelingscyclus blijft onder druk zetten, wordt hardwaredebugging van het oorspronkelijke systeem naar een bijzaak verwezen - maar al te vaak wordt ervan uitgegaan dat verificatie (zelf een groot percentagetage van het ontwikkelingsschema) zal alle bugs opvangen vóór de eerste systeemopstart. Laten we eens kijken naar een paar veelvoorkomende soorten systeemproblemen om de uitdagingen beter te begrijpen waarmee een typisch ontwerp te maken krijgt tijdens de eerste systeemopstart.

Fouten in functionele definities zijn dubbel zo moeilijk te vinden, omdat de ontwerper een bepaalde vereiste verkeerd heeft begrepen. De fout kan dus over het hoofd worden gezien, zelfs als u de details van het ontwerp zorgvuldig bekijkt. Een exampEen veelvoorkomende functionele definitiefout zou zijn dat een toestandsmachineovergang niet in de juiste toestand eindigt. Fouten kunnen ook in systeeminterfaces verschijnen als een interactieprobleem. Interfacelatentie, bijvoorbeeldample, kan onjuist zijn opgegeven, wat kan leiden tot een onverwachte bufferoverloop of -onderloop.
Timingproblemen op systeemniveau zijn een andere veelvoorkomende bron van ontwerpfouten. Asynchrone gebeurtenissen zijn in het bijzonder een veelvoorkomende bron van fouten wanneer synchronisatie of het overschrijden van timingdomeineffecten niet zorgvuldig worden overwogen. Bij het werken op snelheid kunnen dit soort fouten zeer problematisch zijn en kunnen ze zeer zelden voorkomen, misschien alleen wanneer specifieke gegevenspatronen zich manifesteren. Veelvoorkomende timingschendingen vallen in deze categorie en zijn meestal zeer moeilijk, zo niet onmogelijk, te simuleren.

Timing-overtredingen kunnen ook het gevolg zijn van een lage signaalgetrouwheid tussen geïntegreerde schakelingen, met name in systemen met meerdere voedingsrails voor elk circuit. Een lage signaalgetrouwheid kan leiden tot signaalruis, overspraak, reflecties, overbelasting en elektromagnetische interferentie (EMI)-problemen die zich vaak voordoen als timing-overtredingen. Problemen met de voeding, zoals transiënten (met name tijdens het opstarten of afsluiten van het systeem), belastingvariaties en hoge vermogensdissipatiespanningen kunnen ook leiden tot mysterieuze fouten, die vaak niet gemakkelijk te herleiden zijn tot een voedingsbron. Zelfs wanneer het ontwerp volledig correct is, kunnen problemen met de fabricage van het bord leiden tot fouten. Defecte soldeerverbindingen en onjuist bevestigde connectoren, bijvoorbeeldample, kan de bron van fouten zijn en kan zelfs afhankelijk zijn van de temperatuur of de locatie van het bord. Het gebruik van geavanceerde FPGA-verpakkingstechnieken kan het moeilijk maken om signalen op de printplaat te onderzoeken, dus alleen al toegang krijgen tot een gewenst signaal kan vaak problematisch zijn. Vaak veroorzaken veel ontwerpproblemen geen onmiddellijke fout en moeten ze door het ontwerp heen rimpelen totdat de fout zich daadwerkelijk manifesteert. Het traceren van de beginfout naar de hoofdoorzaak kan vaak een frustrerende, moeilijke en tijdrovende taak zijn.

Bijvoorbeeldample, een enkele bit fout in een vertaaltabel kan pas vele cycli later resulteren in een fout. Sommige van de tools die we later in dit artikel zullen bespreken, die speciale in-circuit debug hardware gebruiken, zijn specifiek gericht op het sneller en gemakkelijker maken van deze 'bug hunts'. Voordat we ingaan op de details van deze tools, laten we eerst een populaire software-gebaseerde debugging techniek simulatie bekijken om de geavantages en nadelentagVoorbeelden van het gebruik van simulatie voor foutopsporing.

Gebruik van simulatie voor foutopsporing
Normaal gesproken worden in een ontwerpsimulatie alle real-life componenten binnen en buiten het ontwerp wiskundig gemodelleerd als softwareprocessen die sequentieel worden uitgevoerd op een standaard CPU. Het toepassen van een breed scala aan stimulus op het ontwerp en het controleren van de verwachte output ten opzichte van de output van het gesimuleerde ontwerp, is een eenvoudige manier om de meest voor de hand liggende ontwerpfouten te ontdekken. Een venster met een typische simulatierun is te zien in Figuur 1 hieronder. De duidelijke advantagHet verschil tussen simulatie en hardware-based debugging is dat simulatie in de software kan worden uitgevoerd. Er is geen daadwerkelijk hardware-based design en testbench nodig. Simulatie kan snel veel ontwerpfouten detecteren, met name die welke verband houden met onjuiste specificaties, misverstanden over interfacevereisten, functiefouten en veel andere 'grove' soorten fouten die gemakkelijk kunnen worden gedetecteerd door middel van eenvoudige stimulusvectoren.

Simulatie is vooral effectief wanneer uitgebreide stimuluscombinaties beschikbaar zijn voor de ontwerper en de resulterende uitkomsten bekend zijn. In deze gevallen kan simulatie een bijna uitputtende test van een ontwerp uitvoeren. Helaas hebben de meeste ontwerpen geen gemakkelijke toegang tot uitgebreide testsuites en kan het proces om ze te maken erg tijdrovend zijn. Het maken van een testsuite die 100% van het ontwerp bestrijkt, is vrijwel onmogelijk voor grote FPGA-gebaseerde ontwerpen en er moeten snelkoppelingen worden gebruikt om de belangrijkste elementen van het ontwerp te proberen te bestrijken. Een andere moeilijkheid met simulatie is dat het geen 'real world'-implementatie is en geen asynchrone gebeurtenissen, snelle systeeminteracties of timingschendingen kan opvangen. Ten slotte kan het simulatieproces erg traag zijn en als er veel iteraties nodig zijn, wordt simulatie al snel het meest tijdrovende en vaak het meest kostbare deel van het ontwikkelingsproces.

Als alternatief (of misschien beter gezegd, als aanvulling op simulatie) ontdekten FPGA-ontwerpers dat ze debughardware konden toevoegen aan het FPGA-ontwerp om belangrijke signalen binnen het apparaat te observeren en te controleren. Deze technieken zijn oorspronkelijk ontwikkeld als ad-hoc-benaderingen, maar hebben zich geleidelijk ontwikkeld tot een standaard hardware-debugstrategie. Dit gebruik van in-circuit debugmogelijkheden biedt aanzienlijke voordetages voor FPGA-gebaseerde ontwerpen en in het volgende gedeelte worden de drie meest voorkomende strategieën en hun verschillende voordelen onderzocht.tages en nadelentagen.

Veelvoorkomende in-circuit debug-benaderingen voor FPGA's
De meest voorkomende technieken voor het implementeren van in-circuit debug-mogelijkheden in FPGA's gebruiken een embedded logic analyzer, externe testapparatuur of speciale signaalprobehardware die is ingebed in de FPGA-fabric. De embedded logic analyzer wordt doorgaans geïmplementeerd met behulp van FPGA-fabric en wordt in het ontwerp ingevoegd. De JTAG poort wordt gebruikt om toegang te krijgen tot de analyzer en de vastgelegde gegevens kunnen worden weergegeven op een pc. Wanneer externe testapparatuur wordt gebruikt, wordt het te testen FPGA-ontwerp aangepast, zodat geselecteerde interne FPGA-signalen naar uitvoerpinnen worden geleid. Deze pinnen kunnen vervolgens worden waargenomen via de externe testapparatuur. Wanneer speciale signaalsondehardware wordt gebruikt, kan een brede selectie van interne signalen in realtime worden gelezen. Sommige sonde-implementaties kunnen zelfs worden gebruikt om naar register- of geheugenlocaties te schrijven, wat de debugmogelijkheden verder verbetert. Laten we de geavantages en nadelentagvan elk van deze technieken en bekijk vervolgens een voorbeeldample design om te zien hoe deze verschillende benaderingen de totale debugtijd kunnen beïnvloeden.

In-Circuit FPGA Debug-Ingebedde Logica Analyzer
Het concept van de embedded logic analyzer was een direct resultaat van de ad-hoc in-circuit debugging-mogelijkheden die ontwerpers implementeerden toen FPGA's voor het eerst werden gebruikt. Embedded logic analyzers voegden nieuwe mogelijkheden toe en elimineerden de vereiste voor de ontwerper om hun eigen analyzer te ontwikkelen. De meeste FPGA's bieden deze mogelijkheden en derden bieden standaard analyzers (Identify®, van Synopsys, is een populaire example) die eenvoudig kunnen worden gekoppeld aan hulpmiddelen op een hoger niveau om de productiviteit verder te verbeteren.

De functionaliteit van de logic analyzer is in het ontwerp ingevoegd, met behulp van FPGA-fabric en ingebedde geheugenblokken als tracebuffers, zoals geïllustreerd in Afbeelding 2. Triggering resources zijn ook gecreëerd, zodat complexe signaalinteracties eenvoudig kunnen worden geselecteerd en vastgelegd. Toegang tot de analyzer voor controle en gegevensoverdracht wordt doorgaans gedaan via de standaard JTAG poort om interfacevereisten te vereenvoudigen. Vastgelegde gegevens kunnen op een pc worden weergegeven met behulp van algemene viewsoftware en weerspiegelt doorgaans de uitvoer van een logische simulatorgolfvorm viewstijl.

De voortagDe voordelen van deze aanpak zijn dat er geen extra FPGA I/O-pinnen worden gebruikt, alleen de standaard JTAG signalen. De IP-cores van de embedded logic analyzer zijn doorgaans relatief goedkoop en kunnen in sommige gevallen een optie zijn voor bestaande FPGA-synthese- of simulatietools. In sommige gevallen kan de embedded logic analyzer ook extra outputs leveren op ongebruikte I/O's, als dat handiger is. Een van de nadelentagHet nadeel van deze aanpak is dat er een grote hoeveelheid FPGA-bronnen nodig is. Met name als trace buffers worden gebruikt, zal dit het aantal beschikbare blokgeheugens verminderen. Als er een brede buffer nodig is, zal dit ook een afweging zijn tegen geheugendiepte (aangezien het gebruik van een breder geheugen resulteert in een ondiepere geheugendiepte) - een groot nadeeltage bij gebruik van kleinere apparaten. Het grootste nadeel van deze techniek is misschien wel dat elke keer dat een aanpassing aan de plaatsing van de probe wordt gemaakt, het nodig is om het ontwerp opnieuw te compileren en te herprogrammeren. Bij gebruik van een groot apparaat kan dit proces veel tijd kosten. Vanwege de manier waarop de signaalprobes in het ontwerp worden geplaatst, kan het moeilijk zijn om signaaltimingrelaties te correleren. Bovendien zijn de vertragingen tussen signaalprobes niet consistent en zijn timingrelaties dus moeilijk te vergelijken. Dit is een bijzonder probleem bij het vergelijken van asynchrone signalen of signalen uit verschillende tijdsdomeinen.

In-Circuit FPGA-debuggen – externe testapparatuur
Het gebruik van in-circuit debug-code in combinatie met externe testapparatuur was een natuurlijke ontwikkeling toen een externe logic analyzer al beschikbaar was voor systeemtesten. Door wat eenvoudige debug-code te maken om interne testsignalen te identificeren en selecteren en deze toe te passen op FPGA I/O's, zoals weergegeven in Afbeelding 3, was het mogelijk om de geavanceerde mogelijkheden van de analyzer te benutten (zoals grote trace buffers, complexe triggersequenties en meerdere viewing-opties) om eenvoudige maar krachtige debugomgevingen te creëren. Complexere in-circuit-mogelijkheden voor geavanceerde triggeropties kunnen het aantal benodigde uitgangen minimaliseren. Voor exampHet selecteren van specifieke adressen op een brede bus kan bijvoorbeeld lastig zijn als er externe pinnen nodig zijn.
Het gebruik van interne FPGA-logica reduceert de I/O-vereisten drastisch en kan zelfs zoeken naar specifieke adrespatronen (misschien een call-and-return-sequentie) voor het debuggen van complexere problemen. Als er een gemeenschappelijke gebruikersinterface beschikbaar is, kan dit de leercurve vereenvoudigen en de productiviteit verbeteren.

De voortagHet voordeel van deze aanpak is dat het de kosten van de externe testapparatuur benut en er dus geen extra gereedschapskosten zijn. Sommige debugcircuit-IP-cores zijn verkrijgbaar bij apparatuurfabrikanten of FPGA-fabrikanten en kunnen zeer goedkoop of zelfs gratis zijn. De hoeveelheid FPGA-bronnen die nodig is om de signaalselectielogica te implementeren, is zeer klein en omdat de trace-functie wordt uitgevoerd met behulp van de externe logische analysator, zijn er geen blokgeheugens nodig. Omdat selectielogica goedkoop is, kan ook een groot aantal kanalen met brede triggering worden ondersteund. De logische analysator kan werken in zowel een timingmodus als een statusmodus, wat helpt om enkele timingproblemen te isoleren.
het nadeeltagEen van de nadelen van deze aanpak kan de noodzaak zijn om een ​​logic analyzer aan te schaffen, als er nog geen aan het project is toegewezen. Dit nadeeltage kan in veel gevallen voldoende zijn om deze aanpak te ontmoedigen. Merk echter op dat er een aantal goedkope logic analyzer-opties beschikbaar komen die de pc of een tablet gebruiken voor weergave, waardoor deze optie veel kosteneffectiever is voor eenvoudige debugvereisten.
Het aantal verbruikte FPGA-pinnen kan een ander nadeel zijntage en als brede bussen moeten worden geobserveerd, is er een aanzienlijke planning voor de lay-out van het bord en de toevoeging van debugconnectoren nodig. Deze vereiste is vaak moeilijk te voorspellen in de vroege ontwerpfase en een andere ongewenste complexiteit. Vergelijkbaar met de embedded logic analyzer-benadering vereist de externe teststrategie het opnieuw compileren en herprogrammeren van een ontwerp, wanneer elk nieuw experiment nodig is.

Het veelvoorkomende nadeeltages van deze twee technieken—het gebruik van on-chip resources (die ook de timingprestaties van het ontwerp kunnen beïnvloeden en extra debugvereisten kunnen creëren) de noodzaak om het ontwerp opnieuw te compileren en te herprogrammeren (wat uren of zelfs dagen aan het debugschema kan toevoegen) de voorafgaande planning die nodig is voor het identificeren van waarschijnlijke testscenario's en het gebruik van extra chip I/O-resources creëerden een behoefte aan een aanpak zonder deze nadelen. Een reactie was de toevoeging van speciale debuglogica aan de FPGA-fabric op sommige apparaten. In-circuit debuggen met behulp van hardwareprobes was het resultaat.

In-Circuit FPGA-debuggen – Hardware-sondes
Het gebruik van hardwareprobes vereenvoudigt in-circuit debugtechnieken voor FPGA's aanzienlijk. Deze techniek, geïmplementeerd als een Live Probe-functie op SmartFusion2®SoC FPGA- en IGLOO®2 FPGA-apparaten, voegt speciale probelijnen toe aan de FPGA-fabric om de uitvoer van elke logische elementregisterbit te observeren. Zoals weergegeven in het blokdiagram in Afbeelding 4, zijn hardwareprobes beschikbaar in twee probekanalen A en B.

Geselecteerde registeruitgangen (probe points), zoals degene die onderaan de afbeelding is gesourced, worden boven de twee probekanalen gerouteerd en kunnen, indien geselecteerd, worden toegepast op kanaal A of B. Deze realtime kanaalsignalen kunnen vervolgens worden verzonden naar speciale Probe A- en Probe B-pinnen op het apparaat. De Probe A- en Probe B-signalen kunnen ook intern worden gerouteerd naar een embedded logic analyzer.

Let op dat de timingkarakteristieken van de probe-pinnen regelmatig zijn en een verwaarloosbare afwijking hebben van het ene probe-punt naar het andere, waardoor het veel gemakkelijker is om timingkarakteristieken van de realtime signalen te vergelijken. Gegevens kunnen worden vastgelegd tot 100 MHz, waardoor het geschikt is voor de meeste doelontwerpen.
Misschien wel het belangrijkste is dat de probe point-locaties, aangezien ze niet worden geselecteerd als onderdeel van het geïmplementeerde ontwerp (ze worden geselecteerd via speciale hardware terwijl het ontwerp op de FPGA draait), snel kunnen worden gewijzigd door simpelweg de selectiegegevens naar het apparaat te sturen. Er is geen hercompilatie en herprogrammering van het ontwerp nodig.
Om het gebruik van de Live Probe-mogelijkheid nog verder te vereenvoudigen, heeft de bijbehorende debug-softwaretool toegang tot alle locaties van de probe-signalen via een automatisch gegenereerde debug-tool. file. Zoals weergegeven in Figuur 5, kan de signaalnaam worden geselecteerd uit de signaallijst en worden toegepast op het gewenste kanaal. Dit kan zelfs worden gedaan terwijl het ontwerp wordt uitgevoerd, zodat de onderzoeksactiviteit binnen het ontwerp naadloos en zeer efficiënt verloopt.

In veel gevallen kan de hardware-probefunctie, zoals Live Probe, worden gebruikt in combinatie met de eerder beschreven embedded logic analyzer en de externe testtechnieken.

Zoals weergegeven in Afbeelding 6, maakt de Live Probe-mogelijkheid om signalen 'on the fly' te selecteren het mogelijk om snel en eenvoudig de signalen die worden geobserveerd te wijzigen zonder het ontwerp opnieuw te hoeven compileren. Een externe logische analysator of scope kan de geprobeerde signalen eenvoudig observeren, zoals geïllustreerd in het rechterbovengedeelte van de afbeelding op de speciale probe-uitgangspinnen. Als alternatief (of misschien zelfs als aanvulling op) de interne logische analysator (het ILA Identify-blok, weergegeven in de afbeelding) kan worden gebruikt om de probe-pinnen te observeren. De probe-signalen kunnen worden vastgelegd door de ILA en worden geobserveerd op het golfvormvenster. Probe-locaties kunnen worden gewijzigd zonder dat het doelontwerp opnieuw hoeft te worden gecompileerd.
Houd er rekening mee dat de extra mogelijkheden voor triggering en tracering kunnen worden gebruikt om de functionaliteit van de sonde te verbeteren, waardoor zelfs complexe ontwerpproblemen eenvoudig kunnen worden opgespoord.

Extra hardware debug-mogelijkheden zijn ook beschikbaar op de SmartFusion2 SoC FPGA en IGLOO2 FPGA-apparaten. Een van deze mogelijkheden, genaamd Active Probe, kan dynamisch en asynchroon lezen of schrijven naar elke logische elementregisterbit. Een geschreven waarde blijft één klokcyclus bestaan, zodat de normale werking kan worden voortgezet, wat het een zeer waardevolle debuggingtool maakt. Active Probe is met name interessant als een snelle observatie van een intern signaal gewenst is (misschien gewoon om te controleren of het actief is of in de gewenste staat, zoals een resetsignaal), of als er behoefte is om snel een logische functie te testen door naar een probepunt te schrijven
(misschien om een ​​toestandsautomaatovergang te initiëren door snel een invoerwaarde in te stellen om een ​​besturingsstroomprobleem te isoleren).

Een andere debugmogelijkheid die Microsemi biedt, is Memory Debug. Met deze functie kan de ontwerper dynamisch en asynchroon lezen of schrijven naar een geselecteerd FPGA-fabric SRAM-blok. Zoals geïllustreerd in de schermafbeelding van de Debug Tool (Afbeelding 7), kan de gebruiker, wanneer het tabblad Memory Blocks is geselecteerd, het gewenste geheugen selecteren om te lezen, een momentopname van het geheugen uitvoeren, geheugenwaarden wijzigen en de waarden vervolgens terugschrijven naar het apparaat. Dit kan met name handig zijn voor het controleren of instellen van gegevensbuffers die worden gebruikt in communicatiepoorten voor rekengeoriënteerde scratch-pad of zelfs voor code die wordt uitgevoerd door een embedded CPU. Het debuggen van complexe gegevensafhankelijke fouten gaat aanzienlijk sneller en gemakkelijker wanneer geheugens zo snel kunnen worden waargenomen en beheerd.

Zodra een ontwerp is gedebugged, kan het wenselijk zijn om de hardware debug-mogelijkheden uit te schakelen om gevoelige informatie te beschermen. Een aanvaller zou deze faciliteiten kunnen gebruiken om kritieke informatie uit te lezen of systeeminstellingen te wijzigen die gemakkelijke toegang tot gevoelige delen van het systeem mogelijk maken. Microsemi heeft functies toegevoegd waarmee de ontwerper het apparaat kan beveiligen nadat de debug is voltooid. Bijvoorbeeldample, toegang tot Live Probe en Active Probe kan worden vergrendeld om de functie volledig uit te schakelen als een mogelijk aanvalsmiddel (het elimineert zelfs de mogelijkheid van probe-activiteit die patronen in de voedingsstroom creëert die kunnen worden gebruikt om probe-gegevens indirect te observeren). Als alternatief kan toegang tot geselecteerde delen van het ontwerp worden vergrendeld om toegang tot alleen die secties te voorkomen. Dit kan handig zijn als slechts een deel van het ontwerp beveiligd hoeft te zijn, waardoor de rest van het ontwerp nog steeds toegankelijk is voor veldtesten of foutanalyse.

Vergelijkingstabel voor in-circuit debuggen
Nu een gedetailleerde review van de drie belangrijkste in-circuit hardware debug technieken zijn beschreven is een samenvattend diagram gemaakt, zoals weergegeven in Figuur 8, waarin de verschillende geavanceerde technieken gedetailleerd worden beschreventages en nadelentages van elke methode. Onthoud dat sommige technieken in combinatie kunnen worden gebruikt (Live Probe en Internal Logic Analyzer (ILA), zoals Synopsys Identify, bijvoorbeeldample), kunnen we de belangrijkste sterke en zwakke punten van elke techniek zien. De verzameling in-circuit hardware debug-mogelijkheden (Live Probe, Active Probe en Memory Debug—gezamenlijk SmartDebug genoemd), zijn het zwakst in vergelijking met de andere technieken als het gaat om het aantal totale beschikbare probes (een rode cirkel) en zijn zwakker dan de beste (gele cirkel) als de vastlegsnelheid in aanmerking wordt genomen (externe testapparatuur kan sneller zijn).
ILA-gebaseerde technieken, zoals Synopsys Identify, zijn het zwakst in vergelijking met de andere technieken en wanneer FPGA-resourcevereisten in overweging worden genomen. Externe testapparatuur-gebaseerde technieken zijn het zwakst in een aantal overwegingen, waarbij kosten, impact op ontwerptiming en overhead van probe-beweging (vanwege de noodzaak om het ontwerp opnieuw te compileren) het meest belastend zijn. Misschien is de optimale oplossing een combinatie van SmartDebug en een van de andere technieken, zodat de zwakte van SmartDebug in het aantal kanalen kan worden verzacht en het nadeel van probe-puntbewegingtagOok de effecten van de andere technieken werden verminderd.

Signaalclassificaties
Er kan een nuttig onderscheid worden gemaakt tussen enkele van de meest voorkomende typen signalen en dit kan helpen bij het plannen van een debugging-aanpak. Bijvoorbeeldample, signalen die niet veranderen behalve tijdens het opstarten van het systeem, zoals systeemreset, blokreset of initialisatieregisters kunnen worden geclassificeerd als statische signalen. Deze typen signalen worden het meest efficiënt benaderd via een faciliteit die het signaal gemakkelijk kan observeren en besturen, zonder dat er een lange hercompilatiecyclus nodig is. Active Probe is een uitstekende faciliteit voor het debuggen van statische signalen. Evenzo kunnen signalen die vaker veranderen maar nog steeds statisch zijn voor het overgrote deel van de tijd, worden geclassificeerd als pseudostatisch en worden ook het meest effectief gedebugged met Active Probe. Signalen die vaak veranderen, zoals kloksignalen, kunnen worden geclassificeerd als dynamisch en zijn niet zo gemakkelijk toegankelijk via Active Probe. Live Probe is een betere keuze voor het observeren van deze signalen.

Eenvoudig debug-gebruiksscenario

Nu we de verschillende in-circuit debug-opties beter begrijpen, gaan we eens kijken naar een eenvoudig ontwerpvoorbeeld.ample om te zien hoe deze technieken presteren. Afbeelding 9 toont een eenvoudig FPGA-ontwerp in een SmartFusion2 SoC FPGA-apparaat. Het Microcontroller Subsystem (MSS) wordt gereset door het CoreSF2Reset Soft IP-blok. De invoer voor dit blok is de Power On Reset, een User Fabric Reset en een External Reset. De uitvoer is een reset naar de User Fabric, een MSS-reset en een M3-reset. De foutsymptomen zijn dat er geen activiteit is op de I/O's, ook al verlaat het apparaat de POR-status met succes. De drie verschillende opties voor het debuggen van deze fout worden ook in de afbeelding geïllustreerd: het blauwe vak (met het label ETE) is voor de External Test Equipment-methode; het groene vak (met het label ILA) is voor de Internal Logic Analyzer-methode; en het oranje vak (met het label AP) is voor de Active Probe-methode. We gaan ervan uit dat de mogelijke hoofdoorzaken van de fout onjuist bevestigde reset-invoeren zijn voor het CoreSF2Reset Soft IP-blok.

Laten we nu eens kijken naar het debugproces voor drie van de eerder beschreven in-circuitmethoden.

Externe testapparatuur
Met deze methode wordt ervan uitgegaan dat de testapparatuur beschikbaar is en niet wordt gebruikt door een project met een hogere prioriteit. Daarnaast is het belangrijk om vooruit te plannen, zodat sommige FPGA I/O's beschikbaar zijn en eenvoudig kunnen worden aangesloten op de testapparatuur. Een header op de PCB hebben voor example, zou erg nuttig zijn en de tijd minimaliseren die besteed wordt aan het identificeren en verbinden van een 'waarschijnlijke verdachte' of de mogelijke kortsluiting van pinnen tijdens het peilen. Het ontwerp moet opnieuw worden gecompileerd om de signalen te selecteren die we willen onderzoeken. Hopelijk hoeven we niet 'de ui af te pellen' en hoeven we geen extra signalen te selecteren voor verder onderzoek, aangezien ons eerste onderzoek vaak alleen maar resulteert in meer vragen. Hoe dan ook, het proces van opnieuw compileren en herprogrammeren kan veel tijd kosten, en als het resulteert in timingschendingen is een herontwerp vereist (we weten allemaal hoe frustrerend het kan zijn om timingclosureproblemen op te lossen, met name wanneer je de ontwerpwijzigingen doorvoert om een ​​ontwerpbug te vinden - het hele proces kan minuten tot uren duren)! Het is ook belangrijk om te onthouden dat als het ontwerp geen vrije gebruikers-I/O's heeft, deze methode niet kan worden geïmplementeerd. Bovendien is deze methode structureel indringend voor het ontwerp - en timinggerelateerde bugs kunnen verdwijnen of opnieuw verschijnen tussen iteraties.

Interne logische analysator
Met deze methode moet de ILA in het ontwerp worden ingevoegd met behulp van fabric-resources en moet deze vervolgens opnieuw worden gecompileerd. Houd er rekening mee dat als de ILA al is geïnstantieerd, de signalen die we willen onderzoeken mogelijk niet zijn geïnstrumenteerd, wat ook een hercompilatie zou vereisen. Dit proces riskeert het oorspronkelijke ontwerp te veranderen en timingbeperkingen te schenden. Als de timing wordt gehaald, moet het ontwerp opnieuw worden geprogrammeerd en opnieuw worden geïnitialiseerd. Dit hele proces kan enkele minuten of zelfs uren duren als de hercompilatietijden lang zijn en er meerdere passes nodig zijn. Deze aanpak is structureel intrusief en kan resulteren in soortgelijke problemen als die beschreven bij het gebruik van de bovenstaande methode.

Actieve sonde
Met deze methode kan de Active Probe worden gericht op de bron van de verschillende resetsignalen, die allemaal afkomstig zijn van registeruitgangen (zoals gebruikelijk is in elke goede digitale ontwerppraktijk). De signalen worden één voor één geselecteerd in een Active Probe-menu dat wordt weergegeven in Afbeelding 10 hieronder. De geselecteerde signaalwaarden kunnen worden gelezen en worden weergegeven in het Active Probe-gegevensvenster. Eventuele onjuiste beweringen worden eenvoudig geïdentificeerd. Deze test kan onmiddellijk worden uitgevoerd zonder dat het apparaat opnieuw hoeft te worden gecompileerd en geprogrammeerd en is niet structureel of procedureel intrusief. Het hele proces duurt slechts enkele seconden. Deze methode kan ook controleerbaarheid creëren (waarden asynchroon wijzigen) wat de andere twee methoden niet toestaan. In deze specifieke exampZo kan het resetsignaal dat door een register wordt gegenereerd, eenvoudig worden onderzocht en kan worden vastgesteld dat het in een actieve toestand verkeert.

Het tijdelijk omschakelen van het resetsignaal kan worden bereikt door het register dat de rustsignalen genereert, asynchroon te manipuleren.

Complexere debug-gebruikscase
Het bovenstaande ontwerp was heel eenvoudig en is nuttig als introductie tot het gebruik van de beschreven ontwerptechnieken, maar een complexere example zou nog illustratiever kunnen zijn. Vaak is het signaal van interesse geen statisch signaal zoals het was in onze simpele example maar is dynamisch. Een veelvoorkomend dynamisch signaal is een tussenliggende klok, die mogelijk wordt gebruikt voor het timen van een handshake voor een seriële interface. Afbeelding 11 toont zo'n ontwerp met de Soft IP-kern van de gebruiker, in dit geval een aangepaste seriële interface die is aangesloten op de APB-bus van het systeem. De symptomen van de fout zijn dat er geen activiteit is op de aangepaste seriële interface van de gebruiker en dat wanneer een APB-busmaster een transactie uitgeeft om toegang te krijgen tot de seriële interface, deze in een uitzonderingsconditie terechtkomt die een onjuiste handshake aangeeft. Deze condities lijken een statische oorzaak uit te sluiten, zoals een onjuist resetsignaal, omdat de transactiestatusmachine niet lijkt te werken met de verwachte snelheid en dus de uitzondering veroorzaakt. De hoofdoorzaak wordt verondersteld de klokfrequentiegenerator in de IP-kern van de gebruiker te zijn.

Als de frequentie niet correct is, ontstaan ​​de beschreven fouten.

In deze situatie is het waarschijnlijk een betere strategie om de Active Probe-benadering te vervangen door de Live Probe. Dit wordt in de bovenstaande afbeelding geïllustreerd door de oranje LP-box, met behulp van de JTAG Signaal voor de selectie van de sondebron.

Externe testapparatuur
Voor dit geval is de methodologie zeer vergelijkbaar met de eerder beschreven eenvoudige example. Het gebruikerskloksignaal wordt naar het testpunt gebracht (hopelijk op een header) en een tijdrovende hercompilatie is nodig. Het kan ook nuttig zijn om een ​​referentiesignaal te brengen, misschien een systeemklok die wordt gebruikt om het IP van de gebruiker te klokken als een vergelijkingssignaal. We zullen opnieuw worden onderworpen aan de noodzaak om te hercompileren en herprogrammeren, dus het hele proces kan een aanzienlijke hoeveelheid tijd in beslag nemen.

Interne logische analysator
Deze zaak lijkt erg op het eenvoudige voorbeeld.ample. De ILA moet worden ingevoegd, of het gewenste signaal moet worden gedefinieerd, en een hercompilatie- en herprogrammeercyclus moet worden uitgevoerd. Alle eerder beschreven problemen resulteren nog steeds in een aanzienlijke debugcyclustijd. Er is echter een extra complexiteit. De klok die de ILA aanstuurt, moet synchroon zijn en idealiter veel sneller ten opzichte van de klok die moet worden waargenomen vanaf de Soft IP-core van de gebruiker. Als deze klokken asynchroon zijn of niet de juiste timingrelaties hebben, is de gegevensvastlegging onvoorspelbaar en een mogelijke bron van verwarring voor het debugproces.
Houd er rekening mee dat als de Soft IP-klok van de gebruiker niet op de chip wordt gegenereerd (maar mogelijk wordt deze hersteld via de seriële interface), de ontwerper mogelijk een klokmodule moet toevoegen om een ​​snellere ILA-klok te genereren met behulp van extra bronnen, wat mogelijk een timingschending veroorzaakt.

Live-sonde
Met deze methode kan de Live Probe snel worden gewezen op de bron van de gebruikersklok en elke andere klokbron van een register om de hoofdoorzaak van de fout te achterhalen. De Live Probe toont de geselecteerde signaaluitgangen in realtime en elke timingrelatie tussen de signalen is daardoor veel gemakkelijker te bepalen. Het hele proces duurt slechts een paar seconden.

Andere debugfuncties voor seriële interfaces
Het is ook belangrijk om erop te wijzen dat er veel extra debugmogelijkheden zijn in SmartFusion2 SoC FPGA- en IGLOO2 FPGA-apparaten die kunnen worden gebruikt op seriële interfaces, zoals die in de vorige example ontwerp waarbij fouten nog ingewikkelder zijn. SERDES Debug, bijvoorbeeldample, biedt specifieke debugmogelijkheden voor de speciale snelle seriële interfaces. Enkele van de SERDES Debug-functies omvatten PMA-testondersteuning (zoals PRBS-patroongeneratie en loopback-testen), ondersteuning voor meerdere SERDES-testconfiguraties met register-level herconfiguratie om het gebruik van de volledige ontwerpstroom om configuratiewijzigingen door te voeren te vermijden, en tekstrapporten met geconfigureerde protocollen, SERDES-configuratieregisters en Lane-configuratieregisters. Deze functies maken SERDES-debuggen veel eenvoudiger en kunnen worden gebruikt in combinatie met Live Probe en Active Probe om het debuggen van complexe circuits verder te versnellen.
De eerder beschreven Memory Debug-tool kan ook worden gebruikt in combinatie met SERDES Debug om testen te versnellen. Omdat geheugenbuffers snel en eenvoudig kunnen worden geïnspecteerd en gewijzigd met Memory Debug, is het mogelijk om snel 'testpakketten' te maken en loopback- of inter-systeemcommunicatieresultaten te observeren. De ontwerper kan deze mogelijkheden benutten en zo de behoefte aan gespecialiseerde 'testharnassen' minimaliseren die extra FPGA-fabric verbruiken en die de chiptiming kunnen beïnvloeden.

Conclusie
In dit artikel zijn verschillende benaderingen voor het implementeren van in-circuit debug voor FPGA's en SoC FPGA's gedetailleerd beschreven: het gebruik van een Integrated Logic Analyzer, het gebruik van externe testapparatuur en het gebruik van speciale probecircuits die zijn geïntegreerd in de FPGA-fabric. De toevoeging van gespecialiseerde en speciale probecircuits, zoals Active Probe en Live Probe die door Microsemi worden aangeboden op SmartFusion2 SoC FPGA- en IGLOO2 FPGA-apparaten, bleek het debugproces aanzienlijk te versnellen en te vereenvoudigen. Het vermogen om de selectie van interne signalen snel te wijzigen (zonder de noodzaak om een ​​zeer tijdrovende hercompilatie- en herprogrammeringscyclus uit te voeren) en het vermogen om interne signalen te proben (zonder de noodzaak om FPGA-fabric te gebruiken en mogelijk timingschendingen te introduceren) bleken een groot voordeel te zijn.tages bij het debuggen van FPGA-ontwerpen. Daarnaast werd het gebruik van meerdere methodologieën beschreven, die samen kunnen werken om een ​​nog uitgebreidere debug-mogelijkheid te bieden. Tot slot werden twee exampEr werden debug-use cases gegeven om de afwegingen tussen de beschreven methoden te illustreren.

Meer informatie

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

Microsemi Corporation (Nasdaq: MSCC) biedt een uitgebreid portfolio van halfgeleider- en systeemoplossingen voor communicatie, defensie en veiligheid, lucht- en ruimtevaart en industriële markten. Producten omvatten hoogwaardige en stralingsbestendige geïntegreerde circuits met gemengd signaal, FPGA's, SoC's en ASIC's; producten voor energiebeheer; timing- en synchronisatieapparatuur en nauwkeurige tijdoplossingen, die de wereldstandaard voor tijd bepalen; apparaten voor spraakverwerking; RF-oplossingen; discrete componenten; beveiligingstechnologieën en schaalbare anti-tamper-producten; Power-over-Ethernet IC's en midspans; evenals aangepaste ontwerpmogelijkheden en -services. Microsemi heeft het hoofdkantoor in Aliso Viejo, Californië, en heeft wereldwijd ongeveer 3,400 werknemers. Meer informatie vindt u op www.microsemi.com.

© 2014 Microsemi Corporation. Alle rechten voorbehouden. Microsemi en het Microsemi-logo zijn handelsmerken van Microsemi Corporation. Alle andere handelsmerken en dienstmerken zijn het eigendom van hun respectieve eigenaars.

Microsemi-hoofdkantoor

• Een Enterprise, Aliso Viejo CA 92656 VS
• Binnenin de VS: +1 800-713-4113
• Buiten de VS: +1 949-380-6100
• Verkoop: +1 949-380-6136
• Fax: +1 949-215-4996
• E-mailadres: sales.support@microsemi.com

Veelgestelde vragen

• V: Wat is de maximale gegevensregistratiefrequentie van het apparaat?
  A: Het apparaat ondersteunt gegevensregistratie tot 100 MHz, geschikt voor de meeste doelontwerpen.
• V: Moet ik het ontwerp opnieuw compileren als ik probecircuits gebruik voor foutopsporing?
  A: Nee, de locaties van de meetpunten kunnen snel worden gewijzigd zonder dat het ontwerp opnieuw hoeft te worden gecompileerd of geprogrammeerd.

Documenten / Bronnen

Microsemi In-Circuit FPGA-debuggen [pdf] Instructies In-Circuit FPGA-debuggen, FPGA-debuggen, debuggen

Referenties

• Gebruiksaanwijzing