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/protocol http://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".
Design and implementation of an On-chip Logic Analyzer http://www.gaisler.com/doc/logan_report.pdf Vielleicht hilft dir das etwas weiter..
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..
http://opencores.org/project,adv_debug_sys Leider nicht einfach zu warten. Idee genial, leider ist der JTAG das Nadelöhr.
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
FPGA Pongo schrieb: > Ich suche eine echte Alternative für ChipScope. Is jetzt nich JTAG sonder VGA aber als Ansatz brauchbar: Durchblicker Diese schwedische Diplomarbeit scheint brauchbar: http://www.gaisler.com/doc/logan_report.pdf MfG,
Sowas habe ich mir auch gebaut. Ich benutzte ihn noch nicht so intensiv, hat mir schon zweimal weiter geholfen.
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
bei Xilinx Spartan6 habe ich eine durch die JTAG-Schnittstelle eine UART<-> Telnetverbindung. Den LA darüber zu tunneln wäre nicht das Problem.
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.
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.