Ich suche eine echte Alternative für ChipScope. Ich hatte über drei
Ecken vor rund 2 Jahren mal Kontakt zu einem Österreicher, der sowas
angeboten hat, aber leider ist der Kontakt verloren. Email nicht mehr
auffindbar.
Wer kennt ein System, dass sozusagen als plugin über JTAG an interne
RAMs ankoppeln und Daten rauschieben kann, sodass man es einem
FPGA-Neuling aufs Auge drücken kann?
Ich hätte gerne etwas, dass auch für LAttice / Altera funktioniert.
Befasst habe ich mich mit SUMP, aber da muss man zuviel per Hand machen.
Hier läuft gerade in einem parallelen Thread eine Frage
zu einem OLS LA/LogicSniffer, ähnlich SUMP 1/2.
OLS bzw. deren OpenSource-Clients laufen leider nicht
über JTAG (wäre wahrscheinlich aber eh langsam), aber
wenn du noch zwei Pins übrig hast, dann lässt sich OLS
per UART (max 10KByte) bzw. UART2USB (max 100KByte) zum
PC leiten und so einfach mit SIGROK etc. kommunizieren.
Das Protokoll ist sehr einfach gehalten:
http://www.sump.org/projects/analyzer/protocolhttp://sigrok.org/wiki/Openbench_Logic_Sniffer
Für einfache Sachen müsst du nur auf die ID-Anfrage
und auf das Sampeln reagieren. Ich habe das mal
mal so gemacht und bin damit unabhängig von Xilinx',
Altera' bzw. Lattice' "ChipScope".
Moin,
wie intrusiv darf das ganze sein? Und muss es mehr können als Lattice
Reveal?
Ich habe bisher folgende Ansätze gewählt:
- "Lahmes" Scoping per JTAG (geht nur mit speziell aufgebohrten
JTAG-Controllern, bzw. nur relativ asynchron mit einem FT2232 Chip)
- Trace buffer, der per Soft-CPU via JTAG bei Auftreten eines Events
ausgelesen wird (a la Reveal).
Ich fürchte, ohne dran "rumtweaken" geht's nicht. Reveal scheiterte ab
einer gewissen Komplexität des Designs. An der SUMP-Sache gefiel mir
damals die SW nicht..bei Xilinx hatte ich den JTAG schon belegt.
Falls es Dir was bringt: http://tech.section5.ch/news/?p=267
Da liegt auch noch etwas Code, um VCD-Wavefiles zu schreiben, die man
dann mit GTKWave begucken kann. Wollte da mal noch mehr zu machen, aber
die Tools für den End-User klarzumachen kostet einfach zu viel Zeit..
Hm, also das bekannte Zeugs. Ich denke über einen Adapterchip nach , der
mit wenigen Leitungen aus dem FPGA heraus auf USB 2.0 übersetzt und
einfach brutal rausstreamt. Braucht dann nur einen Empfänger in Form von
Software, der USB lesen kann und die Daten mit Start Stopp auf die
Platte haut. Dann vielleicht noch ein Wandler, der lädt, in
tabellarisches ASCII verwandelt.
FPGA Pongo schrieb im Beitrag #4117332:
> Hm, also das bekannte Zeugs. Ich denke über einen Adapterchip nach> , der> mit wenigen Leitungen aus dem FPGA heraus auf USB 2.0 übersetzt und> einfach brutal rausstreamt. Braucht dann nur einen Empfänger in Form von> Software, der USB lesen kann und die Daten mit Start Stopp auf die> Platte haut. Dann vielleicht noch ein Wandler, der lädt, in> tabellarisches ASCII verwandelt.
Genau das macht der aufgebohrte JTAGger über nen Cypress FX2. Der
"Grabber" gibt über die Scope-API die VCDs aus, dazwischen gibts noch
etwas Kompression. Die gesamte JTAG-Engine läuft taktsynchron auf dem
FPGA. Mit einem geeigneten Interface (nennt Analog Devices z.b. BTC)
kriegt man Datentransfers um wenige MB/s über JTAG hin. Aber eben,
benötigt extra HW. Ich hab's auf nem EFM01-Modul implementiert, keine
Ahnung, ob's das noch gibt. Eigene HW hat sich nicht gerechnet..
Der fiese Hack ist die JTAG-Engine, das ist für Endnutzer eben kaum zu
brauchen, da dedizierte JTAG-Befehle (a la FTDI MPSSE) verwendet werden.
Ich denke mal, um Selbermachen kommt man nicht herum. Die ganzen
üblichen OpenSource-Dinger sind seltenst brauchbar...
Wenn man nicht über JTAG gehen will, machts wohl mehr Sinn, nen
programmierbaren LA einzusetzen.
Grüsse,
- Strubi
Ich nehme an, der ist für Deine MAIS CPU mit der Du dann aus dem PCB
rauskommst? Den LA in VDHL zu bauen ist je weniger das Problem. Der
Aufwand besteht ja darin, ihn schnell zu konfigurieren und aus dem FPGA
rauszukommen. Einfach und effektiv geht es nur mit einem externen LA und
einer Art Busverbinung, wobei der LA ein USB oder ein Self Built sein
könnte, oder man nutzt eine PC-Schnittstelle.
Da gibt es aber nur USB, UART und ETH. UART haben die meisten sicher
schon gemacht, ist aber zu langsam. ETH geht nicht ohne PHY und auch USB
braucht einen Chip.
Ideal wäre ein kompletter USB-Core fix unf fertig zum reinwerfen, den
man abspeckt und mit einem einfachen LA-Interface versieht.
FPGA Pongo schrieb im Beitrag #4121172:
> Da gibt es aber nur USB, UART und ETH. UART haben die meisten sicher> schon gemacht, ist aber zu langsam. ETH geht nicht ohne PHY und auch USB> braucht einen Chip.
Geschwindigkeit ist relativ. Mir hat der UART am SUMP-LA immer gereicht.
Ich entwerfe meine Designs nicht mit dem Logicanalyser, sondern mit dem
Simulator. Da brauche ich den LA äußerst selten.
Irgendwo im Nachbarthread kam auch schon der Hinweis auf die
FIFO-Schnittstelle der FTDIs. Und ich meine es gab/gibt das Projekt
Bithound die den SUMP mit Ethernet versehen haben.
Duke
Geschwindigkeit ist relativ.
> Jaja, aber wir high Speed phreaks wollen eben mehr :-)>Ich entwerfe meine Designs nicht mit dem Logicanalyser, sondern mit dem>Simulator.
Ich verstehe, was Du sagen willst, aber simuliere mal das durch, was ein
falsch programmierter ARM, der am oder im FPGA hängt, so an Buszugriffen
macht. Will sagen, ich muss wissen, was da passiert und wie die Signale
aussehen.
>Irgendwo im Nachbarthread kam auch schon der Hinweis auf die>FIFO-Schnittstelle der FTDIs.
Braucht also einen Chip auf der FPGA-Seite.
> Und ich meine es gab/gibt das Projekt>Bithound die den SUMP mit Ethernet versehen haben.
Ja, aber braucht eben Hardware, die erst sampelt und dann einen PHY hat.
Dann lieber Logic Analyzer a la Agilent.
Ich brauche ihn aber innen drin, damit man mal eine Serie von Geräten
laufen lassen kann, und sich der LA automatisch mit dem Fehler meldet.
Vor allem darf es keine Extra Hardware im System kosten.
FPGA Pongo schrieb im Beitrag #4121220:
> Geschwindigkeit ist relativ.>> Jaja, aber wir high Speed phreaks wollen eben mehr :-)>
Wieviel darf es denn sein ?
>>Ich entwerfe meine Designs nicht mit dem Logicanalyser, sondern mit dem>>Simulator.> Ich verstehe, was Du sagen willst, aber simuliere mal das durch, was ein> falsch programmierter ARM, der am oder im FPGA hängt, so an Buszugriffen> macht. Will sagen, ich muss wissen, was da passiert und wie die Signale> aussehen.>
Welche Signale ? Falsche Daten oder Adressen sind ja noch harmlos. Aber
wenn es um Verletzung von Setup oder Hold Zeiten geht wird es richtig
schnell.
>> Ich brauche ihn aber innen drin, damit man mal eine Serie von Geräten> laufen lassen kann, und sich der LA automatisch mit dem Fehler meldet.> Vor allem darf es keine Extra Hardware im System kosten.
Nehmen wir mal ein FX2 + CPLD dann sollten >30 Mbyte/s über USB zum PC
und entsprechend 240 MBit/s seriell vom FPGA zum CPLD über 2 Leitungen
machbar sein. FX2 und CPLD über 16Bit Datenbus verbunden.
Da bin ich auch an einer finalen Lösung dran! Das ganze ist bisher daran
gescheitert, dass es entweder eine umfangreiche Implementierung im FPGA
brauchte, oder auf der SW-Seite.
Vor Ewigkeiten hatte ich mal probiert, vom FPGA über S/PDIF (AES/EBU =
RS 422) in den Rechner zu streamen, denn dann kann man die Daten auf
diese Weise mit jedem Audioprogramm empfangen und speichern. Das
Protokoll wird vom FPGA besteuert. Er sendet Adressen und Daten auf 2x24
Bit. Allerdings braucht der PC dann wieder einen S/PDIF-Eingang. Das
hatten viele Karten damals nicht und an LAPTOPS gibt es da gar nicht.
Richtig funktioniert hat bei voller Bandbreite auch nur der Zugriff auf
den FPGA vom Rechner aus, also z.B. das Absampeln von online streams und
Digitalradio in Digitalqualität. Für die heutigen höheren Bandbreiten
braucht man immer einen Treiber, wegen der Leistung und die ganz
geringeren Bandbreiten gehen auch über UART oder einen implementierten
USB-Converter.
Für den Audiobereich daheim reden meine FPGAs nach wie vor mittels eines
Pseudo-MIDI über S/PDIF - das zwischen Platinen einfach als 5cm langes
LVDS läuft. Da rennen 768kHz x 32 Samplerate bzw 1024 MIDI-Kanäle nach
altem Standard. Für die Kommunikation zum PC suche ich noch eine
(bessere) Option.
Aus dem FPGA ohne irgendwas Zusätzliches rauszugehen, funktioniert
eigentlich nur mit RS-485 über kurze Leitungen an einem billigen
Converter, der auf USB übersetzt und dem Gerät einen virtuellen COM-Port
zur Verfügung stellt. Der sollte preislich drin sein. Dann besteht halt
noch der Bedarf, eine Software zu schreiben, die USB bedient. Das halte
ich ohnehin für den aufwändigsten Teil. Mit Labview könnte man da gfs
schnell was zusammenstricken.
In den Industrieprojekten lief es schon oft auf RS 485 hinaus, z.B.
MODBUS. Das hat den Vorteil, dass es bidirektional ist. Allerdings
braucht man dann schon auch Leitungstreiber. Man wird also so oder so um
ein Adapterplatinchen zum FPGA nicht herumkommen.
Für die Software gibt es aber in der Automationsindustrie inzwischen
fertige Lösungen zum Zusammenstricken, die es ermöglichen, ohne
irgendwelche Programmierung eine Oberfläche zu erzeugen, die einen
Ablauf anwirft, Daten sammelt, sortiert, filtert und darstellt. Es gibt
sogar Baukastensysteme, die richtige Signalverarbeitung können und ein
Standalone-Software hinstellen. http://www.dsprobotics.com/
Das Ding wird in Ruby programmiert, kann aber auch mit Assembler. Für
einen FPGA Monitor müsste man nur eine allgemeine Oberfläche machen, das
RS485 bidirektional über 4 Pins auf USB übersetzen und ein einfaches
Steuerprotokoll nach obigem Muster aufsetzen.
> Dann lieber Logic Analyzer a la Agilent.>> Ich brauche ihn aber innen drin, damit man mal eine Serie von Geräten> laufen lassen kann, und sich der LA automatisch mit dem Fehler meldet.> Vor allem darf es keine Extra Hardware im System kosten.
Also irgendwas fehlt noch.
Du hast einen ARM und da hängt ein FPGA als LA dran. Wenn der FPGA ein
Event enfängt wo gehen die Daten hin?
An den ARM oder hast du noch einen PC mit im Feld? Dann bräuchtest du
noch eine weitere Schnittstelle. Oder liest der ARM den FPGA aus?
Den Signalfluß habe ich noch nicht erkannt.
Wenn du keine weiteren Kosten haben willst. Bleibt die nur die JTAG des
FPGAs übrig und musst die Daten über die Hersteller Register Tunneln. So
macht es auch CHipscope.
FPGA Pongo schrieb im Beitrag #4121172:
> Ich nehme an, der ist für Deine MAIS CPU mit der Du dann aus dem PCB> rauskommst? Den LA in VDHL zu bauen ist je weniger das Problem. Der> Aufwand besteht ja darin, ihn schnell zu konfigurieren und aus dem FPGA
Richtig der ist aus meinem Mais Projekt.
> Da gibt es aber nur USB, UART und ETH. UART haben die meisten sicher> schon gemacht, ist aber zu langsam. ETH geht nicht ohne PHY und auch USB> braucht einen Chip.
Wichtig ist das Ereignis richtig zu triggern und dan hast du Zeit es
auszulesen. Dafür reicht der UART aus. Das Problem ist eine Toolchain
hinzubekommen.
Toll wäre ein Plugin für GTKwave. Sump war mir auch noch zu bastelig.
Moin,
>> Wichtig ist das Ereignis richtig zu triggern und dan hast du Zeit es> auszulesen. Dafür reicht der UART aus. Das Problem ist eine Toolchain> hinzubekommen.>
Der UART ist halt doch etwas zu lahm und ein weiteres
Soft-Debug-Interface ist den meisten (wie auch mir) zu intrusiv in
bestehende Designs. Wie gesagt kriegst Du über die native
JTAG-Schnittstelle einige MB/s, wenn der Chip 20-50 MHz JTAG-Clock
verkraftet. Das geht sogar noch mit dem FTDI-Chip (bis 30 MHz), wenn man
die MPSSE (FTDI JTAG engine) richtig "queued". Nur für synchrones
laufendes Scoping (insbesondere direktes Boundary-Scanning ohne
Trace-Logik dazwischen) braucht man eben spezielle JTAGger a la
Lauterbach.
Buszugriffe von externen ARMs kann man damit aber auch nicht timinggenau
debuggen, im Endeffekt braucht das auch einen internen Bus-Tracer.
> Toll wäre ein Plugin für GTKwave. Sump war mir auch noch zu bastelig.
Gibt's ja schon, allerdings andersrum. GTKwave IST das Plugin :-)
Über das SHM-Interface kann man so einiges machen. Geht halt nur unter
Linux.
Ein Kollege macht da noch mit dem geda-Viewer was, sah auch ganz nett
aus.
Gruss,
- Strubi
Moin,
nehme mal an, du meinst die GTKwave-Sache?
Den netscope-Kram hab ich oben mal gelinkt gehabt (zumindest die
VCD-Ausgabe)
Am besten in den Source von shmidcat schauen. Der shared-mem Kram lässt
sich gut in eigene apps einbauen. Vom virtuellen Vorläufer hab ich hier
noch 'n screencast (flash):
http://www.section5.ch/doc/jtag/movies/interactive.html
Hier gibts auch noch n Link:
http://wsim.gforge.inria.fr/tutorials/monitor-option/online_gtkwave.html
So habe ich das mit dem "netscope" gemacht, im Prinzip ist das ein
Server, der GTKwave aufruft, Ereignis-Daten vom Trace-Modul
entgegennimmt und per SHM an GTKwave übergibt. Ist zwar ein Hack, aber
es gibt auf Toolchain-Seite keine Arbeit, und GTKwave ist IMHO das beste
Wave-Display auf dem freien Markt. Das coolste ist, dass man zwei
Wave-Displays aufs Mal aufmachen kann (siehe twinwave) um z.B.
Simulation mit Realität zu vergleichen.
Gruss,
- Strubi
René D. schrieb:> Kann GTKwave auch über das SHM-Interface daten senden?
Nee, warum sollte es das tun? shared mem macht nur Sinn für die
effiziente Datenübergabe an das Wave-Display. Wenn Du was rückmelden
müsstest, lässt sich das natürlich programmieren, aber wäre bisschen ein
Hack.
> bei Xilinx Spartan6 habe ich eine durch die JTAG-Schnittstelle> eine> UART<-> Telnetverbindung.>> Den LA darüber zu tunneln wäre nicht das Problem.
Dann ist das ja kein echter UART mit limitierter Baudrate...oder?
Grüsse,
- Strubi
>> Dann ist das ja kein echter UART mit limitierter Baudrate...oder?
Genaugenommen sind es zwei 8bit register. Eins für in und eines für out.
Bei einem Uart wird das mit dem 8N1 Muster herausgeschoben und in dem
Fall geht es hat durch den JTAG. Ist ein Debug Output.
FPGA Pongo (Gast) was für ein Bertiebssystem benutzt du?
ICh habe mich mal mit dem Weg beschäftigt, den Strubi ( SHM-Interface im
GTKwave) vorgeschlagen hat beschäftigt.
Das habe ich noch nicht vollständig verstanden, aber machbar.
Den JTAG zu tunneln habe ich bereits in Griff. Von der Sache ist es nur
Arbeit.
