Microsemi In-Circuit FPGA-Debug

Produktinformationen

Technische Daten

• Gerätetyp: Microsemi SmartFusion2 SoC FPGA
• Erscheinungsdatum: Mai 2014
• Debugging-Funktionen: In-Circuit-FPGA-Debug, eingebetteter Logikanalysator
• Maximale Datenerfassungsfrequenz: Bis zu 100 MHz

Abstrakt
FPGAs sind leistungsstarke Designelemente in eingebetteten Systemen mit vielen DesignvorteilentagDiese Geräte können jedoch komplexe Designs mit komplexen Designproblemen aufweisen, die behoben werden müssen. Das Aufspüren von Designproblemen wie Definitionsfehlern, Systeminteraktionsproblemen und System-Timing-Fehlern kann eine Herausforderung sein. Die Integration von In-Circuit-Debug-Funktionen in ein FPGA kann das Hardware-Debugging erheblich verbessern und viele frustrierende Stunden vermeiden. Dieses Dokument beschreibt verschiedene Ansätze zum In-Circuit-Debugging für FPGAs, identifiziert wichtige Kompromisse und zeigt anhand eines BeispielsampDas für ein Microsemi SmartFusion®2 SoC FPGA-Gerät konzipierte Design zeigt, wie neue Funktionen zum Beschleunigen von Debugging und Tests genutzt werden können.

Einführung

FPGAs sind weit verbreitete und leistungsstarke Designelemente und finden sich heute in nahezu jedem eingebetteten System. Mit zunehmender Kapazität, der Integration komplexer On-Chip-Funktionsblöcke und fortschrittlicher serieller Schnittstellen können diese Bausteine ​​auch komplexe Designprobleme aufweisen, die behoben werden müssen. Die Suche nach Problemen wie Funktionsdefinitionsfehlern (auf FPGA- oder Systemebene), Problemen mit der funktionalen Systeminteraktion, Problemen mit dem Systemtiming und Problemen mit der Signaltreue zwischen ICs (wie Rauschen, Übersprechen oder Reflexionen) wird bei Verwendung fortschrittlicher FPGAs deutlich komplexer. Simulation ist sicherlich eine große Hilfe bei der Identifizierung vieler Designprobleme, aber viele Interaktionen in der realen Welt werden erst sichtbar, wenn das Design in Hardware implementiert ist. Um den Prozess zu vereinfachen, wurden verschiedene Techniken zum Debuggen komplexer Designprobleme entwickelt. Ein sorgfältiges Verständnis jeder dieser Schlüsseltechniken, einschließlich der verschiedenen fortschrittlichentages und NachteiletagDies ist nützlich, wenn man überlegt, welche Technik oder Kombination von Techniken für ein bestimmtes Design geeignet ist.
Ein ExampDas FPGA-Design, das für ein Microsemi SmartFusion2 SoC FPGA-Gerät vorgesehen ist, kann verwendet werden, um einige der Vorteile zu demonstrierentages und Nachteiletages dieser Standardtechniken sowie die neuesten In-Circuit-Debug-Funktionen. Dieses illustrative BeispielampIn diesem Artikel wird gezeigt, wie diese verschiedenen Techniken verwendet werden können, um die Identifizierung und Beseitigung von Hardwareproblemen beim Hardware-Debugging zu beschleunigen.

Warum ist das FPGA-Debugging ein kritischer Aspekt bei Systemdesign und -entwicklung?
FPGAs unterscheiden sich in zwei Hauptanwendungsmodellen von anderen Designelementen. Sie können im Serienprodukt oder als Entwicklungsplattform eingesetzt werden, um ein Produktionsdesignkonzept zu testen oder zu prototypisieren. Als Produktionsplattform bieten FPGAs deutlich mehr Flexibilität als ASIC- oder CPU-basierte Serienplattformen. Dies ist insbesondere für neue Designs wichtig, die noch nicht in Hardware implementiert sind. Designs mit unterschiedlichen Architekturoptionen lassen sich einfach erstellen und testen, sodass das optimale Design gefunden wird. FPGAs mit On-Chip-Prozessoren (SoC-FPGAs) ermöglichen zudem den Austausch von CPU-basierter Verarbeitung mit hardwaregestützten FPGA-basierten Beschleunigungsfunktionen. Diese VorteiletagSie können den Zeitaufwand für Design, Validierung, Tests und Fehleranalyse bei der Entwicklung neuer Produkte drastisch reduzieren.
Beim Prototyping eines Designs, beispielsweise für einen ASIC in der Produktion, ist die Flexibilität von FPGAs ein entscheidender Vorteil. Eine echte Hardwareplattform, selbst wenn sie nicht mit voller Geschwindigkeit läuft, erleichtert die Erfassung detaillierter Systemleistungsmesswerte, Durchsatzanalysedaten und Proof-of-Concept-Ergebnisse der Architektur erheblich. Die FPGA-Unterstützung für gehärtete Implementierungen von Industriestandardbussen (wie PCIe®, Gigabit Ethernet, XAUI, USB, CAN und andere) vereinfacht die Tests dieser Schnittstellen. Die neuesten FPGA-Familien mit On-Chip-ARM-Prozessoren (SoC-FPGAs) erleichtern die Prototypisierung von Implementierungen mit eingebetteten Prozessoren. Bereits entwickelter Prozessorcode kann auf den Prototyp portiert und neuer Code parallel zum Hardware-Design erstellt werden.

Die Kombination eines Standardprozessors mit Standard-Schnittstellenbussen ermöglicht die Nutzung des umfangreichen Ökosystems an verfügbaren Codebibliotheken, Treibern, funktionalen APIs, Echtzeitbetriebssystemen und sogar vollständigen Betriebssystemen, um deutlich schneller einen funktionierenden Prototyp zu erstellen. Sobald das Design feststeht, kann der FPGA-Prototyp zudem zur Erfassung umfangreicher Simulationstests (sowohl für Stimulus als auch für Response) genutzt werden, die die tatsächlichen Systemdaten widerspiegeln. Diese Datensätze können für die Erstellung der finalen Simulationen für einen ASIC oder eine andere Produktionsimplementierung von unschätzbarem Wert sein. Der VorteiltagDie Verwendung eines FPGA als Designprototyp kann den Zeitaufwand für Design, Validierung, Tests und Fehleranalyse für die endgültige Produktimplementierung drastisch reduzieren.
In beiden gängigen FPGA-Nutzungsmodellen ist die Flexibilität des FPGA als Designziel ein entscheidender VorteiltagDies bedeutet, dass viele Designänderungen und Iterationen die Norm wären. Daher wäre die Fähigkeit, Designfehler schnell zu beheben, entscheidend, um möglichst viele Designoptionen zu ermöglichen. Ohne eine effiziente Debug-Funktion wäre ein Großteil der VorteiletagDie Flexibilität des FPGA-Designs wird durch den zusätzlichen Debugging-Zeitaufwand eingeschränkt. Glücklicherweise bieten FPGAs zusätzliche Hardwarefunktionen, die das Echtzeit-Debugging erheblich vereinfachen. Bevor wir uns diese Funktionen ansehen, betrachten wir zunächst die häufigsten Probleme, die bei einem FPGA-Design auftreten können, um die Effizienz und die damit verbundenen Nachteile verschiedener Debugging-Tools zu bewerten.

Häufige Probleme beim Debuggen von FPGA-Designs

Neben den erweiterten Funktionen moderner FPGAs erschwert die damit verbundene erhöhte Komplexität die Erstellung fehlerfreier Designs. Schätzungen zufolge kann das Debuggen über 50 % des Designzyklus eingebetteter Systeme in Anspruch nehmen. Da der Zeitdruck bis zur Markteinführung den Entwicklungszyklus weiter verkürzt, wird das Hardware-Debugging des ursprünglichen Systems nachträglich vernachlässigt – allzu oft wird angenommen, dass die Verifizierung (die selbst einen großen Anteil daran hat)tage des Entwicklungsplans) werden alle Fehler vor der ersten Systeminbetriebnahme erkannt. Sehen wir uns einige häufige Systemprobleme an, um die Herausforderungen zu verstehen, denen ein typisches Design bei der ersten Systeminbetriebnahme gegenübersteht.

Funktionsdefinitionsfehler können doppelt schwer zu finden sein, da der Designer eine bestimmte Anforderung missverstanden hat, sodass der Fehler selbst bei sorgfältiger Betrachtung der Designdetails übersehen werden kann. Ein BeispielampEin typischer Fehler in der Funktionsdefinition ist, dass ein Zustandsübergang nicht im richtigen Zustand endet. Fehler können auch in Systemschnittstellen als Interaktionsproblem auftreten. Schnittstellenlatenz zum Beispielample, könnte falsch angegeben sein, was zu einem unerwarteten Pufferüberlauf oder -unterlauf führen kann.
Timing-Probleme auf Systemebene sind eine weitere häufige Ursache für Designfehler. Insbesondere asynchrone Ereignisse sind eine häufige Fehlerquelle, wenn Synchronisations- oder Timing-Domänen-übergreifende Effekte nicht sorgfältig berücksichtigt werden. Bei hohen Geschwindigkeiten können diese Fehlerarten sehr problematisch sein und nur sehr selten auftreten, möglicherweise nur bei Auftreten bestimmter Datenmuster. Viele gängige Timing-Verstöße fallen in diese Kategorie und sind in der Regel sehr schwierig, wenn nicht gar unmöglich zu simulieren.

Timing-Verstöße können auch auf eine geringe Signaltreue zwischen integrierten Schaltkreisen zurückzuführen sein, insbesondere in Systemen mit mehreren Stromschienen pro Schaltkreis. Eine geringe Signaltreue kann zu Signalrauschen, Übersprechen, Reflexionen, Überlastung und elektromagnetischen Störungen (EMI) führen, die sich oft als Timing-Verstöße äußern. Stromversorgungsprobleme wie Transienten (insbesondere beim Systemstart oder -abschaltung), Lastschwankungen und hohe Verlustleistungsbelastungen können ebenfalls zu rätselhaften Fehlern führen, die oft nicht einfach auf eine Stromversorgungsquelle zurückgeführt werden können. Selbst bei einem absolut korrekten Design können Probleme bei der Platinenherstellung zu Fehlern führen. Fehlerhafte Lötstellen und unsachgemäß angeschlossene Steckverbinder beispielsweiseampe, kann die Fehlerquelle sein und kann sogar temperatur- oder plattenabhängig sein. Der Einsatz fortschrittlicher FPGA-Verpackungstechniken kann das Prüfen von Signalen auf der Leiterplatte erschweren, sodass allein der Zugriff auf ein gewünschtes Signal oft problematisch sein kann. Viele Designprobleme verursachen oft keinen unmittelbaren Fehler und müssen sich durch das Design ziehen, bis der Fehler tatsächlich auftritt. Die Rückverfolgung des anfänglichen Fehlers zur Ursache kann oft frustrierend, schwierig und zeitaufwändig sein.

Zum BeispielampEin einzelnes fehlerhaftes Bit in einer Übersetzungstabelle kann erst viele Zyklen später zu einem Fehler führen. Einige der Tools, die wir später in diesem Dokument besprechen und die dedizierte In-Circuit-Debug-Hardware verwenden, zielen speziell darauf ab, diese Fehlersuche zu beschleunigen und zu vereinfachen. Bevor wir auf die Details dieser Tools eingehen, betrachten wir zunächst die Simulation einer beliebten softwarebasierten Debugging-Technik, um die Vorteile besser zu verstehen.tages und NachteiletagVorteile der Verwendung von Simulationen zum Debuggen.

Einsatz der Simulation zum Debuggen
Typischerweise werden in einer Designsimulation alle realen Komponenten innerhalb und außerhalb des Entwurfs mathematisch als Softwareprozesse modelliert, die sequenziell auf einer Standard-CPU ausgeführt werden. Die Anwendung einer breiten Palette von Stimuli auf den Entwurf und der Vergleich der erwarteten Ergebnisse mit den Ergebnissen des simulierten Entwurfs ist eine einfache Möglichkeit, die meisten offensichtlichen Entwurfsfehler zu erkennen. Abbildung 1 unten zeigt ein Fenster mit einem typischen Simulationslauf. Der klare VorteiltagDer Vorteil von Simulation gegenüber hardwarebasiertem Debugging liegt darin, dass die Simulation direkt in der Software erfolgen kann – es sind kein hardwarebasiertes Design und keine Testumgebung erforderlich. Simulation kann viele Designfehler schnell aufdecken, insbesondere solche, die auf falsche Spezifikationen, Missverständnisse bei Schnittstellenanforderungen, Funktionsfehler und viele andere schwerwiegende Fehler zurückzuführen sind, die durch einfache Stimulusvektoren leicht erkannt werden können.

Simulation ist besonders effektiv, wenn dem Entwickler umfangreiche Stimuluskombinationen zur Verfügung stehen und die resultierenden Ergebnisse bekannt sind. In diesen Fällen kann die Simulation einen nahezu erschöpfenden Test eines Designs durchführen. Leider haben die meisten Designs keinen einfachen Zugriff auf umfangreiche Test-Suiten, und deren Erstellung kann sehr zeitaufwändig sein. Bei großen FPGA-basierten Designs ist die Erstellung einer Test-Suite, die 100 % des Designs abdeckt, praktisch unmöglich. Daher müssen Abkürzungen gewählt werden, um die wichtigsten Elemente des Designs abzudecken. Eine weitere Schwierigkeit bei der Simulation besteht darin, dass sie keine „realistische“ Implementierung darstellt und keine asynchronen Ereignisse, Systeminteraktionen bei hoher Geschwindigkeit oder Zeitverletzungen erfassen kann. Schließlich kann der Simulationsprozess sehr langsam sein, und wenn viele Iterationen erforderlich sind, wird die Simulation schnell zum zeitaufwändigsten und oft auch teuersten Teil des Entwicklungsprozesses.

Alternativ (oder besser gesagt als Ergänzung zur Simulation) konnten FPGA-Entwickler Debug-Hardware in das FPGA-Design integrieren, um wichtige Signale im Gerät zu beobachten und zu steuern. Diese Techniken wurden ursprünglich als Ad-hoc-Ansätze entwickelt, haben sich aber allmählich zu einer Standard-Hardware-Debug-Strategie entwickelt. Die Nutzung von In-Circuit-Debug-Funktionen bietet erhebliche Vorteile.tages für FPGA-basierte Designs und der nächste Abschnitt wird die drei häufigsten Strategien und ihre verschiedenen Vorteile untersuchentages und Nachteiletages.

Gängige In-Circuit-Debug-Ansätze für FPGAs
Die gängigsten Techniken zur Implementierung von In-Circuit-Debug-Funktionen in FPGAs verwenden entweder einen eingebetteten Logikanalysator, externe Testgeräte oder dedizierte, in die FPGA-Struktur eingebettete Signalprüfhardware. Der eingebettete Logikanalysator wird typischerweise in der FPGA-Struktur implementiert und in das Design integriert. Der JTAG Der Port dient dem Zugriff auf den Analysator, und die erfassten Daten können auf einem PC angezeigt werden. Bei Verwendung externer Testgeräte wird das zu testende FPGA-Design so modifiziert, dass ausgewählte interne FPGA-Signale an Ausgangspins weitergeleitet werden. Diese Pins können dann über das externe Testgerät beobachtet werden. Mit dedizierter Signalsonden-Hardware kann eine große Auswahl interner Signale in Echtzeit gelesen werden. Einige Sondenimplementierungen können sogar zum Schreiben in Register oder Speicherbereiche verwendet werden, was die Debug-Funktionen weiter verbessert. Sehen wir uns die Vorteile genauer an.tages und Nachteiletages jeder dieser Techniken und schauen Sie sich dann ein Beispiel anample-Design, um zu sehen, wie sich diese unterschiedlichen Ansätze auf die Gesamt-Debugging-Zeit auswirken können.

In-Circuit FPGA Debug-Embedded Logic Analyzer
Das Konzept des eingebetteten Logikanalysators war eine direkte Folge der Ad-hoc-Debugging-Funktionen im Schaltkreis, die Entwickler mit der Einführung von FPGAs implementierten. Eingebettete Logikanalysatoren boten neue Funktionen und machten die Entwicklung eines eigenen Analysators überflüssig. Die meisten FPGAs bieten diese Funktionen, und Drittanbieter bieten Standardanalysatoren an (Identify® von Synopsys ist ein beliebtes Beispiel).ample), das problemlos mit Tools höherer Ebene verbunden werden kann, um die Produktivität weiter zu verbessern.

Die Logikanalysator-Funktionalität wird in das Design integriert, wobei FPGA-Struktur und eingebettete Speicherblöcke als Trace-Puffer verwendet werden, wie in Abbildung 2 dargestellt. Außerdem werden Trigger-Ressourcen erstellt, damit komplexe Signalinteraktionen einfach ausgewählt und erfasst werden können. Der Zugriff auf den Analysator zur Steuerung und Datenübertragung erfolgt typischerweise über den Standard-JTAG Port zur Vereinfachung der Schnittstellenanforderungen. Erfasste Daten können auf einem PC mit gängigen viewing-Software und spiegelt typischerweise eine Logiksimulator-Wellenformausgabe viewing-Stil.

Der VorteiltagVorteile dieses Ansatzes sind, dass keine zusätzlichen FPGA-E/A-Pins verwendet werden, sondern nur die Standard-JTAG Signale. Die IP-Cores des eingebetteten Logikanalysators sind in der Regel relativ kostengünstig und können in einigen Fällen eine Alternative zu bestehenden FPGA-Synthese- oder Simulationstools darstellen. In einigen Fällen kann der eingebettete Logikanalysator auch zusätzliche Ausgänge für ungenutzte I/Os bereitstellen, falls dies praktischer ist. Einer der NachteiletagDieser Ansatz erfordert einen hohen FPGA-Ressourcenbedarf. Insbesondere bei Verwendung von Trace-Puffer reduziert sich dadurch die Anzahl der verfügbaren Blockspeicher. Ein breiter Puffer bedeutet zudem einen Kompromiss mit der Speichertiefe (da ein breiterer Speicher zu einer geringeren Speichertiefe führt) – ein großer Nachteil.tage bei der Verwendung kleinerer Geräte. Der vielleicht größte Nachteil dieser Technik besteht darin, dass bei jeder Anpassung der Sondenplatzierung das Design neu kompiliert und programmiert werden muss. Bei großen Geräten kann dieser Vorgang sehr zeitaufwändig sein. Aufgrund der Platzierung der Signalsonden im Design kann es schwierig sein, die zeitlichen Beziehungen der Signale zu korrelieren. Zudem sind die Verzögerungen zwischen den Signalsonden nicht konsistent, sodass zeitliche Beziehungen schwer zu vergleichen sind. Dies ist insbesondere beim Vergleich asynchroner Signale oder Signale aus unterschiedlichen Zeitbereichen problematisch.

In-Circuit FPGA Debug – Externe Testgeräte
Die Verwendung von In-Circuit-Debug-Code in Verbindung mit externen Testgeräten war eine naheliegende Entwicklung, da bereits ein externer Logikanalysator für Systemtests verfügbar war. Durch die Erstellung eines einfachen Debug-Codes zur Identifizierung und Auswahl interner Testsignale und deren Anwendung auf FPGA-I/Os (siehe Abbildung 3) konnten die erweiterten Funktionen des Analysators (wie große Trace-Puffer, komplexe Triggersequenzen und mehrere viewing-Optionen), um einfache, aber leistungsstarke Debug-Umgebungen zu erstellen. Komplexere In-Circuit-Funktionen für erweiterte Triggeroptionen können die Anzahl der benötigten Ausgänge minimieren. Zum BeispielampBeispielsweise könnte die Auswahl bestimmter Adressen auf einem breiten Bus unerschwinglich sein, wenn externe Pins erforderlich wären.
Die Verwendung interner FPGA-Logik reduziert den I/O-Bedarf erheblich und ermöglicht sogar die Suche nach spezifischen Adressmustern (beispielsweise einer Aufruf- und Rückgabesequenz) zur Fehlerbehebung bei komplexeren Problemen. Eine gemeinsame Benutzeroberfläche vereinfacht den Lernprozess und steigert die Produktivität.

Der VorteiltagDer Vorteil dieses Ansatzes liegt darin, dass die Kosten für externe Testgeräte reduziert werden und somit keine zusätzlichen Werkzeugkosten entstehen. Einige Debug-Schaltkreis-IP-Cores sind bei Geräteherstellern oder FPGA-Herstellern erhältlich und können sehr günstig oder sogar kostenlos sein. Die für die Implementierung der Signalauswahllogik benötigten FPGA-Ressourcen sind sehr gering, und da die Trace-Funktion über den externen Logikanalysator erfolgt, werden keine Blockspeicher benötigt. Da die Auswahllogik kostengünstig ist, kann auch eine große Anzahl von Kanälen mit breiter Triggerung unterstützt werden. Der Logikanalysator kann sowohl im Timing- als auch im State-Modus arbeiten, was zur Isolierung einiger Timing-Probleme beiträgt.
Der NachteiltagZu den Nachteilen dieses Ansatzes kann die Notwendigkeit gehören, einen Logikanalysator zu kaufen, falls dieser nicht bereits für das Projekt vorgesehen ist. Dieser NachteiltagDies kann in vielen Fällen ausreichen, um von diesem Ansatz abzuraten. Beachten Sie jedoch, dass zunehmend kostengünstige Logikanalysatoren verfügbar werden, die einen PC oder ein Tablet zur Anzeige verwenden. Dies macht diese Option für einfache Debug-Anforderungen deutlich kostengünstiger.
Die Anzahl der verbrauchten FPGA-Pins kann ein weiterer Nachteil seintagWenn breite Busse beobachtet werden müssen, ist eine umfangreiche Planung des Platinenlayouts und die Hinzufügung von Debug-Anschlüssen erforderlich. Diese Anforderung ist in der frühen Entwurfsphase meist schwer vorhersehbar und stellt eine weitere unerwünschte Komplexität dar. Ähnlich wie beim eingebetteten Logikanalysator erfordert die externe Teststrategie die Neukompilierung und Neuprogrammierung eines Designs, wenn jedes neue Experiment erforderlich ist.

Der gemeinsame NachteiltagDie Nachteile dieser beiden Techniken – die Nutzung von On-Chip-Ressourcen (die sich auch auf die Timing-Performance des Designs auswirken und zusätzliche Debugging-Anforderungen schaffen können), die Notwendigkeit der Neukompilierung und Neuprogrammierung des Designs (was den Debug-Zeitplan um Stunden oder sogar Tage verlängern kann), die erforderliche Vorabplanung zur Identifizierung wahrscheinlicher Testszenarien und die Nutzung zusätzlicher Chip-E/A-Ressourcen – erforderten einen Ansatz ohne diese Nachteile. Eine Reaktion darauf war die Integration dedizierter Debug-Logik in die FPGA-Struktur einiger Geräte. Das Ergebnis war In-Circuit-Debugging mit Hardware-Sonden.

In-Circuit-FPGA-Debug – Hardware-Sonden
Der Einsatz von Hardware-Probes vereinfacht die In-Circuit-Debugging-Techniken für FPGAs erheblich. Diese Technik, implementiert als Live-Probe-Funktion auf SmartFusion2®SoC FPGA- und IGLOO®2 FPGA-Bausteinen, fügt der FPGA-Struktur dedizierte Probe-Leitungen hinzu, um die Ausgabe jedes Logikelement-Registerbits zu beobachten. Wie im Blockdiagramm in Abbildung 4 dargestellt, sind Hardware-Probes in zwei Probe-Kanälen A und B verfügbar.

Ausgewählte Registerausgänge (Sondenpunkte), wie der unten in der Abbildung dargestellte, werden über die beiden Sondenkanäle geführt und können, falls ausgewählt, entweder auf Kanal A oder Kanal B angewendet werden. Diese Echtzeit-Kanalsignale können dann an dedizierte Sonden-A- und Sonden-B-Pins des Geräts gesendet werden. Die Sonden-A- und Sonden-B-Signale können auch intern an einen eingebetteten Logikanalysator weitergeleitet werden.

Beachten Sie, dass die zeitlichen Eigenschaften der Prüfstifte regelmäßig sind und von einem Prüfpunkt zum anderen nur geringfügig abweichen. Dies erleichtert den Vergleich der zeitlichen Eigenschaften der Echtzeitsignale erheblich. Daten können mit bis zu 100 MHz erfasst werden, was für die meisten Zieldesigns geeignet ist.
Der vielleicht wichtigste Aspekt ist, dass die Positionen der Prüfpunkte, da sie nicht im implementierten Design ausgewählt werden (sie werden über dedizierte Hardware ausgewählt, während das Design auf dem FPGA ausgeführt wird), schnell geändert werden können, indem die Auswahldaten einfach an das Gerät gesendet werden. Eine Neukompilierung und Neuprogrammierung des Designs ist nicht erforderlich.
Um die Nutzung der Live Probe-Funktion noch weiter zu vereinfachen, hat das zugehörige Debug-Softwaretool Zugriff auf alle Sondensignalpositionen über ein automatisch generiertes Debug fileWie in Abbildung 5 dargestellt, kann der Signalname aus der Signalliste ausgewählt und dem gewünschten Kanal zugewiesen werden. Dies ist sogar während der Designausführung möglich, sodass die Prüfaktivität innerhalb des Designs nahtlos und sehr effizient abläuft.

In vielen Fällen kann die Hardware-Probe-Funktion, wie Live Probe, in Verbindung mit dem zuvor beschriebenen eingebetteten Logikanalysator und den externen Testtechniken verwendet werden.

Wie in Abbildung 6 dargestellt, ermöglicht die Live-Probe-Funktion zur Signalauswahl im laufenden Betrieb einen schnellen und einfachen Wechsel der beobachteten Signale, ohne dass das Design neu kompiliert werden muss. Ein externer Logikanalysator oder Oszilloskop kann die untersuchten Signale problemlos beobachten, wie oben rechts in der Abbildung an den dedizierten Ausgangspins der Sonde dargestellt. Alternativ (oder auch zusätzlich) kann der interne Logikanalysator (der ILA-Identification-Block, siehe Abbildung) zur Beobachtung der Sondenpins verwendet werden. Die Sondensignale können vom ILA erfasst und im Wellenformfenster dargestellt werden. Sondenpositionen können geändert werden, ohne dass das Zieldesign neu kompiliert werden muss.
Beachten Sie, dass die zusätzlichen Funktionen zum Auslösen und Verfolgen zur Verbesserung der Sondenfunktionalität verwendet werden können, sodass selbst komplexe Designprobleme leicht erkannt werden können.

Zusätzliche Hardware-Debug-Funktionen sind auch auf den SmartFusion2 SoC FPGA- und IGLOO2 FPGA-Bausteinen verfügbar. Eine dieser Funktionen, Active Probe, ermöglicht das dynamische und asynchrone Lesen und Schreiben von Registerbits von Logikelementen. Ein geschriebener Wert bleibt für einen Taktzyklus erhalten, sodass der normale Betrieb fortgesetzt werden kann. Dies macht Active Probe zu einem äußerst wertvollen Debugging-Tool. Active Probe ist besonders interessant, wenn eine schnelle Beobachtung eines internen Signals gewünscht ist (beispielsweise um zu überprüfen, ob es aktiv ist oder sich im gewünschten Zustand befindet, z. B. ein Reset-Signal) oder wenn eine Logikfunktion durch Schreiben an einen Prüfpunkt schnell getestet werden muss.
(vielleicht um einen Zustandsmaschinenübergang einzuleiten, indem schnell ein Eingabewert festgelegt wird, um ein Kontrollflussproblem zu isolieren).

Eine weitere Debug-Funktion von Microsemi ist Memory Debug. Diese Funktion ermöglicht dem Entwickler das dynamische und asynchrone Lesen oder Schreiben in einen ausgewählten FPGA-Fabric-SRAM-Block. Wie im Screenshot des Debug-Tools (Abbildung 7) dargestellt, kann der Benutzer über die Registerkarte „Speicherblöcke“ den gewünschten Speicher zum Lesen auswählen, einen Snapshot des Speichers erstellen, Speicherwerte ändern und diese anschließend auf das Gerät zurückschreiben. Dies ist besonders nützlich für die Überprüfung oder Einstellung von Datenpuffern in Kommunikationsanschlüssen für berechnungsorientiertes Scratchpad oder sogar für Code, der von einer eingebetteten CPU ausgeführt wird. Das Debuggen komplexer datenabhängiger Fehler ist deutlich schneller und einfacher, wenn Speicher so schnell beobachtet und gesteuert werden können.

Nach dem Debuggen eines Designs kann es sinnvoll sein, die Hardware-Debug-Funktionen zu deaktivieren, um sensible Informationen zu schützen. Ein Angreifer könnte diese Funktionen nutzen, um kritische Informationen auszulesen oder Systemeinstellungen zu ändern, die einen einfachen Zugriff auf sensible Systembereiche ermöglichen. Microsemi hat Funktionen hinzugefügt, die es dem Entwickler ermöglichen, das Gerät nach Abschluss des Debuggens zu sichern. Zum Beispiel:ampDer Zugriff auf Live Probe und Active Probe kann gesperrt werden, um die Funktion als mögliche Angriffsmöglichkeit vollständig zu deaktivieren (sogar die Möglichkeit, dass durch die Sondenaktivität Muster im Versorgungsstrom entstehen, die zur indirekten Beobachtung der Sondendaten genutzt werden könnten, wird ausgeschlossen). Alternativ kann der Zugriff auf ausgewählte Bereiche des Designs gesperrt werden, um den Zugriff nur auf diese Bereiche zu verhindern. Dies ist praktisch, wenn nur ein Teil des Designs gesichert werden muss, während der Rest des Designs für Feldtests oder Fehleranalysen weiterhin zugänglich bleibt.

Vergleichstabelle für In-Circuit-Debugging
Nun, da eine detaillierteview Die drei wichtigsten In-Circuit-Hardware-Debug-Techniken wurden beschrieben. Ein Übersichtsdiagramm, wie in Abbildung 8 dargestellt, wurde erstellt, das die verschiedenen Vorteile detailliert beschreibt.tages und Nachteiletages jeder Methode. Bedenken Sie, dass einige Techniken in Verbindung verwendet werden können (Live Probe und Internal Logic Analyzer (ILA), wie z. B. Synopsys Identifyampe) können wir die wichtigsten Stärken und Schwächen jeder Technik erkennen. Die Sammlung von In-Circuit-Hardware-Debug-Funktionen (Live Probe, Active Probe und Memory Debug – zusammenfassend als SmartDebug bezeichnet) ist im Vergleich zu den anderen Techniken am schwächsten, wenn es um die Anzahl der insgesamt verfügbaren Sonden geht (roter Kreis), und ist schwächer als die besten (gelber Kreis), wenn man die Erfassungsgeschwindigkeit berücksichtigt (externe Testgeräte können schneller sein).
ILA-basierte Techniken wie Synopsys Identify sind im Vergleich zu den anderen Techniken und unter Berücksichtigung des FPGA-Ressourcenbedarfs am schwächsten. Techniken auf Basis externer Testgeräte sind in vielerlei Hinsicht am schwächsten, wobei Kosten, Auswirkungen auf die Designzeit und der Aufwand für die Sondenbewegung (aufgrund der Notwendigkeit der Neukompilierung des Designs) am aufwendigsten sind. Die optimale Lösung ist möglicherweise eine Kombination aus SmartDebug und einer der anderen Techniken, um die Schwächen von SmartDebug hinsichtlich der Kanalanzahl zu mildern und die Nachteile der Sondenpunktbewegung zu minimieren.tagAuch die Kosten der anderen Techniken wurden reduziert.

Signalklassifizierungen
Eine nützliche Unterscheidung zwischen einigen der häufigsten Signaltypen kann bei der Planung eines Debugging-Ansatzes hilfreich sein. Zum BeispielampSignale, die sich außer beim Systemstart nicht ändern, wie Systemreset, Blockreset oder Initialisierungsregister, können als statische Signale klassifiziert werden. Der Zugriff auf diese Signaltypen erfolgt am effizientesten über eine Funktion, die das Signal einfach beobachten und steuern kann, ohne dass ein langer Neukompilierungszyklus erforderlich ist. Active Probe eignet sich hervorragend zum Debuggen statischer Signale. Ebenso können Signale, die sich häufiger ändern, aber die meiste Zeit statisch bleiben, als pseudostatisch klassifiziert werden und auch hier am effektivsten mit Active Probe debuggt werden. Signale, die sich häufig ändern, wie Taktsignale, können als dynamisch klassifiziert werden und sind mit Active Probe nicht so einfach zugänglich. Live Probe ist zur Beobachtung dieser Signale die bessere Wahl.

Einfacher Debug-Anwendungsfall

Nachdem wir nun ein besseres Verständnis der verschiedenen In-Circuit-Debug-Optionen haben, schauen wir uns ein einfaches Designbeispiel anample, um zu sehen, wie diese Techniken funktionieren. Abbildung 9 zeigt ein einfaches FPGA-Design in einem SmartFusion2 SoC FPGA-Gerät. Das Mikrocontroller-Subsystem (MSS) wird durch den CoreSF2Reset Soft IP-Block zurückgesetzt. Die Eingaben für diesen Block sind der Power On Reset, ein User Fabric Reset und ein External Reset. Die Ausgaben sind ein Reset auf das User Fabric, ein MSS-Reset und ein M3-Reset. Die Fehlersymptome bestehen darin, dass an den E/As keine Aktivität stattfindet, obwohl das Gerät den POR-Zustand erfolgreich verlässt. Die drei verschiedenen Optionen zum Debuggen dieses Fehlers sind ebenfalls in der Abbildung dargestellt: Das blaue Kästchen (beschriftet mit ETE) steht für die Methode des externen Testgeräts; das grüne Kästchen (beschriftet mit ILA) steht für die Methode des internen Logikanalysators; und das orange Kästchen (beschriftet mit AP) steht für die Methode des aktiven Testens. Wir gehen davon aus, dass die potenziellen Grundursachen des Fehlers falsch aktivierte Reset-Eingänge des CoreSF2Reset Soft IP-Blocks sind.

Sehen wir uns nun den Debug-Prozess für drei der zuvor beschriebenen In-Circuit-Methoden an.

Externe Testgeräte
Bei dieser Methode wird davon ausgegangen, dass die Testgeräte verfügbar sind und nicht von einem Projekt mit höherer Priorität verwendet werden. Darüber hinaus ist es wichtig, im Voraus zu planen, damit einige FPGA-E/As verfügbar sind und problemlos an die Testgeräte angeschlossen werden können. Beispielsweise kann ein Header auf der Leiterplatte vorhanden sein.ample wäre sehr hilfreich und würde den Zeitaufwand für die Identifizierung und Verbindung eines „wahrscheinlich verdächtigen“ oder den möglichen Kurzschluss von Pins während der Prüfung minimieren. Das Design muss neu kompiliert werden, um die zu untersuchenden Signale auszuwählen. Hoffentlich müssen wir nicht „die Zwiebel schälen“ und zusätzliche Signale für weitere Untersuchungen auswählen, da unsere erste Untersuchung oft nur weitere Fragen aufwirft. In jedem Fall kann der Neukompilierungs- und Neuprogrammierungsprozess sehr zeitaufwändig sein, und wenn er zu Timing-Verstößen führt, ist ein neues Design erforderlich (wir alle wissen, wie frustrierend die Lösung von Timing-Closure-Problemen sein kann, insbesondere wenn man Designänderungen vornimmt, um einen Designfehler zu finden – der gesamte Prozess kann Minuten bis Stunden dauern)! Es ist auch wichtig zu bedenken, dass diese Methode nicht implementiert werden kann, wenn das Design keine freien Benutzer-E/As hat. Darüber hinaus greift diese Methode strukturell in das Design ein – und Timing-bezogene Fehler können zwischen den Iterationen verschwinden oder wieder auftreten.

Interner Logikanalysator
Bei dieser Methode muss der ILA mithilfe von Fabric-Ressourcen in das Design eingefügt und anschließend neu kompiliert werden. Beachten Sie, dass die zu untersuchenden Signale möglicherweise nicht instrumentiert wurden, wenn der ILA bereits instanziiert wurde, was ebenfalls eine Neukompilierung erforderlich machen würde. Dieser Prozess birgt das Risiko, das ursprüngliche Design zu verändern und Zeitvorgaben zu verletzen. Wird das Timing eingehalten, muss das Design neu programmiert und initialisiert werden. Dieser gesamte Prozess kann mehrere Minuten oder sogar Stunden dauern, wenn die Neukompilierungszeiten lang sind und mehrere Durchläufe erforderlich sind. Dieser Ansatz ist strukturell invasiv und kann zu ähnlichen Problemen führen wie die oben beschriebenen.

Aktive Sonde
Mit dieser Methode kann die aktive Sonde auf die Quelle der verschiedenen Reset-Signale ausgerichtet werden, die alle von Registerausgängen stammen (wie es in jeder guten digitalen Designpraxis üblich ist). Die Signale werden einzeln aus einem Menü der aktiven Sonde ausgewählt (siehe Abbildung 10 unten). Die ausgewählten Signalwerte können gelesen und im Datenfenster der aktiven Sonde angezeigt werden. Fehlaussagen lassen sich leicht identifizieren. Dieser Test kann sofort durchgeführt werden, ohne dass das Gerät neu kompiliert und programmiert werden muss, und ist weder strukturell noch verfahrenstechnisch intrusiv. Der gesamte Vorgang dauert nur wenige Sekunden. Diese Methode ermöglicht auch eine Steuerbarkeit (asynchrone Wertänderung), die mit den beiden anderen Methoden nicht möglich ist. In diesem speziellen BeispielampDas heißt, das von einem Register stammende Reset-Signal kann leicht geprüft werden und es kann festgestellt werden, dass es sich im aktiven Zustand befindet.

Ein kurzzeitiges Umschalten des Rücksetzsignals kann durch asynchrone Manipulation des Registers erreicht werden, das die Restsignale erzeugt.

Komplexerer Debug-Anwendungsfall
Das obige Design war sehr einfach und ist als Einführung in die Verwendung der beschriebenen Designtechniken nützlich, aber ein komplexeres Beispielample könnte noch anschaulicher sein. Oft ist das Signal von Interesse kein statisches Signal wie in unserem einfachen Beispielample, ist aber dynamisch. Ein gängiges dynamisches Signal ist ein Zwischentakt, der beispielsweise zur Taktung eines Handshakes für eine serielle Schnittstelle verwendet wird. Abbildung 11 zeigt ein solches Design mit dem Soft-IP-Core des Benutzers, in diesem Fall einer benutzerdefinierten seriellen Schnittstelle, die an den APB-Bus des Systems angeschlossen ist. Die Fehlersymptome sind, dass auf der benutzerdefinierten seriellen Schnittstelle des Benutzers keine Aktivität stattfindet und dass ein APB-Bus-Master, wenn er eine Transaktion zum Zugriff auf die serielle Schnittstelle ausgibt, in einen Ausnahmezustand gerät, der auf einen fehlerhaften Handshake hinweist. Diese Bedingungen scheinen eine statische Ursache, wie z. B. ein fehlerhaftes Reset-Signal, auszuschließen, da die Transaktionszustandsmaschine nicht mit der erwarteten Geschwindigkeit zu arbeiten scheint und somit die Ausnahme verursacht. Die Hauptursache wird im Taktfrequenzgenerator im IP-Core des Benutzers vermutet.

Läuft es nicht mit der richtigen Frequenz, kommt es zu den beschriebenen Fehlern.

In dieser Situation ist es wahrscheinlich eine bessere Strategie, den Active Probe-Ansatz durch den Live Probe-Ansatz zu ersetzen. Dies wird in der obigen Abbildung durch die orangefarbene LP-Box veranschaulicht, wobei das JTAG Signal zur Auswahl der Sondenquelle.

Externe Testgeräte
Für diesen Fall ist die Methodik sehr ähnlich zu der zuvor beschriebenen einfachen ExampDas Benutzertaktsignal wird zum Testpunkt geführt (möglicherweise über einen Header), was eine zeitaufwändige Neukompilierung erforderlich macht. Es kann auch hilfreich sein, ein Referenzsignal, beispielsweise einen Systemtakt, der zum Takten der Benutzer-IP als Vergleichssignal verwendet wird, herauszugeben. Wir müssen erneut neu kompilieren und programmieren, sodass der gesamte Vorgang erheblich viel Zeit in Anspruch nehmen kann.

Interner Logikanalysator
Dieser Fall ist dem einfachen Beispiel sehr ähnlichampDer ILA muss eingefügt oder das gewünschte Signal definiert und ein Neukompilierungs- und Neuprogrammierungszyklus ausgeführt werden. Alle zuvor beschriebenen Probleme führen weiterhin zu einer erheblichen Debug-Zykluszeit. Hinzu kommt jedoch eine zusätzliche Komplexität. Der Taktgeber des ILA muss synchron und idealerweise deutlich schneller sein als der Taktgeber des Soft-IP-Cores des Benutzers. Sind diese Taktgeber asynchron oder weisen sie nicht die korrekten Zeitbeziehungen auf, ist die Datenerfassung unvorhersehbar und kann den Debug-Prozess verwirren.
Beachten Sie, dass der Designer möglicherweise ein Taktmodul hinzufügen muss, um einen schnelleren ILA-Takt zu generieren, der zusätzliche Ressourcen nutzt und möglicherweise eine Zeitverletzung verursacht, wenn der Soft-IP-Takt des Benutzers nicht auf dem Chip generiert wird (vielleicht wird er von der seriellen Schnittstelle wiederhergestellt).

Live-Sonde
Mit dieser Methode kann die Live Probe schnell auf die Quelle des Benutzertakts und anderer Taktquellen aus einem Register gerichtet werden, um die Fehlerursache zu ermitteln. Die Live Probe zeigt die ausgewählten Signalausgänge in Echtzeit an, wodurch die zeitliche Beziehung zwischen den Signalen deutlich einfacher zu bestimmen ist. Der gesamte Vorgang dauert nur wenige Sekunden.

Weitere Debug-Funktionen für serielle Schnittstellen
Es ist auch wichtig darauf hinzuweisen, dass es in SmartFusion2 SoC FPGA- und IGLOO2 FPGA-Geräten viele zusätzliche Debug-Funktionen gibt, die auf seriellen Schnittstellen verwendet werden können, wie im vorherigen Beispiel.ample Design, bei dem Fehler noch komplizierter sind. SERDES Debug, zum Beispielample bietet spezielle Debug-Funktionen für dedizierte serielle Hochgeschwindigkeitsschnittstellen. Zu den SERDES-Debug-Funktionen gehören PMA-Testunterstützung (wie PRBS-Mustergenerierung und Loopback-Tests), Unterstützung für mehrere SERDES-Testkonfigurationen mit Rekonfiguration auf Registerebene, um die Nutzung des gesamten Design-Flows für Konfigurationsänderungen zu vermeiden, sowie Textberichte mit konfigurierten Protokollen, SERDES-Konfigurationsregistern und Lane-Konfigurationsregistern. Diese Funktionen vereinfachen das SERDES-Debugging erheblich und können in Verbindung mit Live Probe und Active Probe eingesetzt werden, um das Debugging komplexer Schaltungen weiter zu beschleunigen.
Das zuvor beschriebene Memory-Debug-Tool kann auch in Verbindung mit SERDES Debug verwendet werden, um Tests zu beschleunigen. Da Speicherpuffer mit Memory Debug schnell und einfach überprüft und geändert werden können, ist es möglich, Testpakete schnell zu erstellen und Loopback- oder Intersystem-Kommunikationsergebnisse zu beobachten. Der Entwickler kann diese Funktionen nutzen und so den Bedarf an speziellen Test-Harnesses minimieren, die zusätzliche FPGA-Struktur verbrauchen und das Chip-Timing beeinträchtigen könnten.

Abschluss
In diesem Dokument wurden verschiedene Ansätze zur Implementierung von In-Circuit-Debugging für FPGAs und SoC-FPGAs detailliert beschrieben – die Verwendung eines integrierten Logikanalysators, externer Testgeräte und dedizierter, in die FPGA-Struktur integrierter Testschaltungen. Die Verwendung spezialisierter und dedizierter Testschaltungen, wie beispielsweise Active Probe und Live Probe von Microsemi für SmartFusion2 SoC-FPGAs und IGLOO2-FPGAs, beschleunigt und vereinfacht den Debug-Prozess erheblich. Die Möglichkeit, die Auswahl interner Signale schnell zu ändern (ohne einen sehr zeitaufwändigen Neukompilierungs- und Neuprogrammierungszyklus durchführen zu müssen) und interne Signale zu prüfen (ohne die FPGA-Struktur zu verwenden und möglicherweise Timing-Verstöße zu verursachen), stellt einen großen Vorteil dar.tagbeim Debuggen von FPGA-Designs. Darüber hinaus wurde die Verwendung mehrerer Methoden beschrieben, die zusammenarbeiten können, um eine noch umfassendere Debug-Funktion zu bieten. Abschließend zwei BeispieleampZur Veranschaulichung der Kompromisse zwischen den beschriebenen Methoden wurden Anwendungsfälle zum Debuggen angegeben.

Mehr erfahren

1. IGLOO2-FPGAs
2. SmartFusion2 SoC-FPGAs

Microsemi Corporation (Nasdaq: MSCC) bietet ein umfassendes Portfolio an Halbleiter- und Systemlösungen für die Kommunikations-, Verteidigungs- und Sicherheits-, Luft- und Raumfahrt- und Industriemärkte. Zu den Produkten gehören leistungsstarke und strahlungsfeste analoge Mixed-Signal-integrierte Schaltkreise, FPGAs, SoCs und ASICs; Energiemanagementprodukte; Zeit- und Synchronisierungsgeräte und präzise Zeitlösungen, die den weltweiten Standard für die Zeit setzen; Sprachverarbeitungsgeräte; HF-Lösungen; diskrete Komponenten; Sicherheitstechnologien und skalierbare Anti-TampMicrosemi bietet Produkte, Power-over-Ethernet-ICs und Midspans sowie kundenspezifische Design- und Serviceleistungen an. Der Hauptsitz befindet sich in Aliso Viejo, Kalifornien, und beschäftigt weltweit rund 3,400 Mitarbeiter. Weitere Informationen finden Sie unter www.microsemi.com.

© 2014 Microsemi Corporation. Alle Rechte vorbehalten. Microsemi und das Microsemi-Logo sind Warenzeichen der Microsemi Corporation. Alle anderen Warenzeichen und Dienstleistungsmarken sind Eigentum ihrer jeweiligen Inhaber.

Hauptsitz von Microsemi

• Eins Enterprise, Aliso Viejo CA 92656 USA
• Innerhalb die USA: +1 800-713-4113
• Draußen die USA: +1 949-380-6100
• Verkäufe: +1 949-380-6136
• Fax: +1 949-215-4996
• E-Mail: sales.support@microsemi.com

Häufig gestellte Fragen

• F: Wie hoch ist die maximale Datenerfassungsfrequenz des Geräts?
  A: Das Gerät unterstützt die Datenerfassung mit bis zu 100 MHz und ist für die meisten Zieldesigns geeignet.
• F: Muss ich das Design neu kompilieren, wenn ich Prüfschaltungen zum Debuggen verwende?
  A: Nein, die Positionen der Prüfpunkte können schnell geändert werden, ohne dass eine Neukompilierung oder Neuprogrammierung des Designs erforderlich ist.

Dokumente / Ressourcen

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

Verweise

• Bedienungsanleitung