Hallo zusammen, in meinem Betrieb setzen wir seit einer Weile einen bunten Mischmasch an FPGA-Familien ein und während wir früher mit Altera's Signaltap immer viel Spass hatten - ist das bei Lattice' RevealInserter und auch schon bei Vivado's ILA Cores manchmal schwierig. Während man zumeist (Altera/Efinix) das Design so lassen kann wie es ist und sich einfach die Signale raussucht, die man gerne sehen möchte muss 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... ==== Die Idee, die wir hatten 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...? Auf der PC-Seite könnte man die Daten mit einem halbwegs einfach gestrickten Programm empfangen und im einfachsten Fall .vcd-Dateien erstellen, die man in gtk-Wave anschaut ... oder man visualisiert sie on-the-fly :-) ==== Gibt's das nicht schon - oder noch was besseres? 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 * weil's Blödsinn ist (evtl. hab ich's auch nicht sinnvoll genug erklärt) * weil's bessere Alternativen gibt, mit der Problematik umzugehen
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.