Generische Debug-Schnittstelle (Signaltap/ILA) über UART - gibt's das schon ?

Roman D. schrieb:

Könnte man nicht mit einem DualPorted-RAM und ein klein bisschen Logik einen eigenen SignalTap basteln, der die angeschlossenen Signale im Kreis herum schreibt, auf eins der eintreffenden Signale triggert und dann den RAM-Inhalt auf der UART-Schnittstelle raus schiebt...?

Ja, kann man, Stichwort 'trace buffer'. Den lese ich allerdings typischerweise per JTAG aus (je nach Architektur unter argem Vorbehalt), oder streame alles gleich per UDP an einen Socket, mit socat kann man dann in der Tat recht elegant die Wellenformen in gtkwave reinstreamen, oder man nutzt die sigrok-Tools. Fuer so hartes Debugging ueber Distanz wird dafuer auch gerne ein FPGA-Kaertchen als JTAG-Adapter eingesetzt. UART bindet halt viele Resourcen, ist langsam und braucht on top noch ein Protokoll.

Bisher ist mir auch noch keine bessere Loesung ueber den Weg gelaufen. Das Problem ist in der Tat, dass die Hersteller-Tools a la Reveal bei komplexeren Designs mehr Probleme schaffen als loesen, besonders, wenn man einen CPU-Debug-TAP auf Basis der eingebauten Primitiven nutzt.

Da man ein Debug-Tool moeglichst nicht auch noch debuggen will, ist man fuer seinen Zweck wohl am besten beraten, eine in der eigenen Testumgebung verifizierbare Loesung zu bauen.

schon mal vielen Dank für die schnelle Antwort. Werd ich mal nachlesen (mit den TraceBuffern).

Vor zwölf Jahren hat mal ein engagierter Forist ein ähnliches Projekt hochgeladen:

• https://www.mikrocontroller.net/articles/Durchblicker

Das zeichnet nach einem Trigger die Signal auf und stellt diese ganz ohne PC auf einem VGA-Monitor dar. Implementiert auf einem Xilinx-Evalboard mit spartan-CPU.

man bei Xilinx mit Signal-Parametern ("Mark as debug") versuchen, das Signal in seiner ursprünglichen Form zu retten (sodass die Optimierung es nicht frisst) und somit fummelt man im Code rum...

Diese Fummelei kann ich zumindest für neuere Designs so nicht bestätigen. Da hat sich aber mit Vivado statt ISE einige weiterentwickelt. So nennt man es nicht mehr Chipscope sonder ILA (Integrated Logic Analyzer) und der funktioniert als Blockdesign (zu instrumentierende Signale müssen Ports von Blöcken sein) ganz gut. Vielleicht gilt das besonders für die Zynq-Familie, die m.E. dafür auch den Debugport der ARM's im PS mitbenutzt. Da nutzt man auch nicht die JTAG-Programmieradapter sondern meist die USB-Schnittstelle auf dem Board.

Wir hatten genau sowas (Debugger mit Blockrams und UART) bei einem früheren AG. In den Blockrams wurden die angeschlossenen Signale RLE-komprimiert gespeichert, was den Vorteil hatte, daß man Signale, die nur selten den Zustand wechseln, über lange Zeiträume und in hoher Zeitauflösung betrachten konnte. z.B. im Bereich Videotechnik ein Vertikalsynchronsignal und das Teilbildflag zusammen in 120 MHz Abtastrate über mehrere Bilder hinweg (~200ms)

Roman D. schrieb:

Zumeist ist man (bei einer halbwegs ordentlichen Idee) nicht der erste, dem so etwas einfällt - somit würde ich mich freuen, wenn man mir ein bisschen Kontra geben könnte:

• weil's das schon gibt

Ja, die Idee ist halbwegs ordentlich und entsprechend hatte 2005 jemand mal so etwas gebaut. Damals noch mit JTAG bitbanging am Parallelport: https://sourceforge.net/projects/chipspy/

Eine andere Idee kann sein, sich einen SUMP logic analyzer in den FPGA zu packen und dann einfach nur interne signal anzuklemmen. Natürlich nicht mehr mit der original Software sondern mit sigrok: https://sigrok.org/wiki/SUMP_compatibles

• weil's bessere Alternativen gibt, mit der Problematik umzugehen

Bei unseren BLDC Motoransteuerungen (Strom- und Positionsregelung) haben wir zum Auslegen und Fehlerfinden einen internen Datenrecorder. Das ist kein Logic Analyzer sondern nur ein FIFO aus Blockram der bei einem Valid Signal einen Datenwert speichert (z. B. Eingangströme und Stromreglerausgang bei jedem PWM Zyklus). Wäre einfach, dem Ding noch ein einfaches Triggersystem zu geben.

Tip: Hänge deinen eigenen Analyser (zusätzlich) an die selbe Schnittstelle wie alle andere Funktionalität.

Unser Recorder ist angeschlossen am internen AHB/AXI Bus und kann so ausgelesen werden wie jedes andere Register. Heisst in unserem Fall wir könnten den Recorder nutzen lange nach dem Raketenstart um zu messen ob noch alles richtig geht.

Bei einem früheren Arbeitgeber in der Leistungselektronik hatten wir einen Ringpuffer der alle ADC Werte mitgelesen hatte. Triggereingang zum Stoppen war die Überstromabschaltung und man konnte das pre-/post-trigger Verhältnis wie bei einem richtigen Logic Analyzer einstellen.

ADC Werte Protokollieren ist IMHO was anderes als des Logik-Debug wie es dem TO vorschwebt.

Bei den FPGA-interenen ADC sollte auslesen über JTAG/Debug ohne extra User-Logik funktionieren (Stichwort Systemmonitor).

Neben dem Protokollieren bieten sich bei AD-Werten von sensoren auch das Inverese, der Player an um die Regelstrecke auf Schwingneigung etc zu untersuchen ohne das Gerät in einen Teststand einzubauen.

Wow - das waren jetzt wirklich lauter interessante und sehr fachdienliche Antworten.

Der Tipp mit sigrok ist super - das hätte ich sicherlich nicht gefunden. Dass ein Arbeitgeber das schon mal umgesetzt und im Real-Einsatz genutzt hat ist auch eine super Info.

Wir würden mal versuchen, ne Studien-Arbeit in dem Themengebiet zusammenzuschreiben und jemand motiviertes zu finden. => Würden es dann (wenn's was wird) durchaus als OpenSource laufen lassen und irgendwo bei opencores o.ä. einpflegen.

Vorerst auf jeden Fall schon mal vielen Dank für den ganzen Input. Wenn's weiter geht würde ich auf jeden Fall hier noch was posten...

Bradward B. schrieb:

man bei Xilinx mit Signal-Parametern ("Mark as debug") versuchen, das Signal in seiner ursprünglichen Form zu retten (sodass die Optimierung es nicht frisst) und somit fummelt man im Code rum...

Diese Fummelei kann ich zumindest für neuere Designs so nicht bestätigen.

Man muss das nicht mit "mark debug machen". Geht über ein script einfacher. Man lässt das einmal bauen und hinterlegt das dann. Auf diese Weise kann man man verschieden Versionen hinzuladen ohne das jedesmal im grafischen Design zu ändern. Das ist unnötige Spielerei.

Ich habe gerne einen Mehrkanal DAC anschliessbar. Der wird per SPI angesteuert, Den kann man fuer einen Prototypen bestuecken und nachher weglassen, oder auch nur die 5 Pins per Draht/Kabel verbinden. Und sich dann die Werte analog rausgeben lassen fuer ein Oszilloskop. Fuer kontinuierliche Rechenwerte.