mikrocontroller.net

Forum: FPGA, VHDL & Co. Logic Analyzer im FPGA via JTAG


Autor: hunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich hab mal den Logic Analyzer von sump.org via BSCAN_SPARTAN3 
(Xilinx-spezifisch) ans JTAG gehängt um damit vor allem andere Logik im 
FPGA im laufenden Betrieb zu debuggen.
Soll so in die Richtung Chipcope - obwohl ich das bisher nie 
gesehen/getestet habe - gehen, nur offen/frei sein und auch, bzw. vor 
allem unter Linux laufen.

Um mal gleich zur Sache zu kommen: Prinzipiell funktionierts, gibt aber 
noch etliche Baustellen. Daher meine Frage, ob vllt. jmd. Lust & Zeit 
hat, dran mitzubasteln. Vor allem auf Host-Seite fehlt hier noch code.

Ich benutze derzeit ein Nexys(2) Board mit ner eigenen Firmware im Fx2, 
die sich um JTAG und ne slave fifo kümmert: 
http://code.google.com/p/open-nexys/source/browse/...

Auf Hostseite benutz ich für die Ansteuerung ein modifiziertes xilprg: 
http://code.google.com/p/xilprg-hunz/source/browse...
Das xilprg wurde um das "user" Kommando erweitert - damit kann man mit 
der BSCAN_SPARTAN3 primitive reden, bzw. daran angeschlossene 
Schieberegister entsprechend lesen/schreiben.

Daran hängt im FPGA dann der sump.org Analyzer - aktueller code davon 
hier: 
http://code.google.com/p/open-nexys/source/browse/...

Im Readme gibts auch ne Kurzanleitung wie man den LA mal testen kann. 
Brauchbar ist das ganze ohne GUI so aber nicht wirklich.

2 Wege sehe ich hier:
1) Original Java-GUI an xilprg "kleben"
2) GTK/Glade-GUI basteln, an xilprg "kleben" und die Darstellung mit 
GTKWave machen

Ich hab schon angefangen in xilprg ein "server" Kommando einzubauen das 
die Schnittstelle auf die das "user" Kommando zugreift via TCP 
zugänglich macht, ist aber glaub ich noch nicht ganz funktionstüchtig 
und im Java LA-Client fehlt entsprechende Unterstützung.

Hätte da vor allem auf Client-Seite jmd. Lust mitzucoden?

Die server-Funktionalität in xilprg solls generell externen Programmen 
ermöglichen, auf BlockRAM oder Register zugreifen zu können ohne dass 
die Programme sich selber um JTAG kümmern müssen.
(Hab beispielsweise den AX8 AVR Softcore mit 2xBRAM als ROM+RAM am 
laufen und kann über xilprg RAM/ROM lesen/schreiben. GDB könnte man 
darüber auch an nen softcore hängen, etc.)

Aber zurück zum Logic Analyzer.

Wenn die GUI mal steht hatte ich auch angedacht, das so zu erweitern, 
dass man da auf ein VHDL-Projekt "klickt", er dann alle Module/Signale 
anzeigt und man bequem anklicken kann, welche davon man auf den 
Logic-Analyzer legen will. Chipscope kann sowas vermutlich?

Sollte nicht so schwer sein, da mal mit Perl durchzuparsen und wo nötig 
interne signale einzufügen und die automagisch aus den jeweiligen 
Modulen bis zum LA zu ziehen.

So weit, so gut.
Hat jmd. Lust+Zeit mitzuhacken?

Grüße!
hunz

Autor: Christian Leber (ijuz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hunz schrieb:

> Soll so in die Richtung Chipcope - obwohl ich das bisher nie
> gesehen/getestet habe - gehen, nur offen/frei sein und auch, bzw. vor
> allem unter Linux laufen.

Chipscope hat zwar eine unterirdische usability und Zuverlaessigkeit, 
aber es laeuft unter linux.

Da du eh von den anderen unfreien tools abhängig bist bringt es auch 
nichts, wenn der Teil frei ist.

Aber viel Erfolg.


Gruss
Christian

Autor: FalscheMeinung (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Chipscope hat zwar eine unterirdische usability und Zuverlaessigkeit,
> aber es laeuft unter linux.
> Da du eh von den anderen unfreien tools abhängig bist bringt es auch
> nichts, wenn der Teil frei ist.

Aber dann ist wieder ein Teil frei !

Mach es !


Grüße.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne xilprg (noch) nicht, aber die "original Java-GUI", hab ich mir 
schonmal erweitert.

Das ging dank Java und Dokumentation relativ gut. Letztendlich werden 
von der GUI nur Bytes (Kommandos) auf die serielle Schnittstelle 
gegeben.

Duke

Autor: Pauiluk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm nen selbstgebauten RAM-Sampler und hänge einen Prozessor dran. 
10mal schneller.

Autor: Gast (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
**harhar** sowas brauchen nur Anfänger.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hunz hast du an dem Tool weitergearbeitet?

Ich könnte einen interen Logic Analyserbenötigen, der mit internem Ram 
auskommt. Sump greift auf exteren SRAM zu.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René D. schrieb:
> Ich könnte einen interen Logic Analyserbenötigen, der mit internem Ram
> auskommt. Sump greift auf exteren SRAM zu.
Wenn ich mich recht erinnere, arbeitet die Variante für den Spartan3E 
(wahlweise?) mit BRAMs.

Aber die GUI bekomme ich unter Win64+cygwin momentan auch nicht zum 
Laufen :-(
Caused by: java.lang.NoClassDefFoundError: gnu/io/CommPortIdentifier

Duke

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man denn den Zugriff auf das externe RAM nicht umleiten, oder 
einfach einen wrappen bauen, der die Signale nach aussen vor den Port 
auf Eingangs-Pins mapped, die dann den BRAM wie ein zweites Design 
einklinken?

Ich habe sowas mal für ein Altmodul gebaut, dass mehr RAM brauchte: Der 
FPGA stellt einfach einen Teil seines CHips einer anderen Schaltung 
bereit. Mit dem eigentlichen Design hat das nichts zu tun.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
> Kann man denn den Zugriff auf das externe RAM nicht umleiten, oder
> einfach einen wrappen bauen, der die Signale nach aussen vor den Port
> auf Eingangs-Pins mapped, die dann den BRAM wie ein zweites Design
> einklinken?
>
Sicher möglich. ich habe mir denn Code noch nicht genauer angeschaut.


zu Duke

probier mal den fork, zumindest der Client startet unter Linux.

http://www.lxtreme.nl/ols/#Download

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte mal Hunz fragen ob es hier Neuigkeiten gibt?

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, wie es sich hier darstellt, wohl nix.

Leute, es ist wie immer: Die tollen Spezis wurschteln immer drauflos 
ohne jeden wirklichen Plan.

Wenn man schon an einen Logikanalysator denkt, dann sollte man sich erst 
mal ne passende Schnittstelle ausgucken - und JTAG scheint mir dafür so 
ziemlich das Verkehrteste der Welt zu sein.

Anschließend sollte man sich ein protokoll auf der gewählten 
Schnittstelle ausdenken, damit Hardwareentwicklung und 
Softwareentwicklung getrennt möglich ist und man nicht auf irgendeinen 
Kram festgenagelt ist.

FPGA-Entwickler, die sich mal nebenher mit Java versuchen - oder 
umgekehrt. Jaja.

W.S.

Autor: spicecat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@W.S
ich bewundere deine Webseite, du hast dort ja nur tolle Projekte, und
alle so durchdacht, Wahnsinn!

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hunz schrieb:
> Vor allem auf Host-Seite fehlt hier noch code.

Guckt euch dazu mal sigrok an:

"The sigrok project aims at creating a portable, cross-platform, 
Free/Libre/Open-Source signal analysis software suite that supports 
various device types, such as logic analyzers, MSOs, oscilloscopes, 
multimeters, LCR meters, sound level meters, thermometers, hygrometers, 
anemometers, light meters, dataloggers, function generators, spectrum 
analyzers, power supplies, GPIB interfaces, and more.

It is licensed under the terms of the GNU GPL. Design goals and features 
include:

- Broad hardware support. Supports many different logic analyzers, 
oscilloscopes, multimeters, data loggers etc. from various vendors.
- Cross-platform. Works on Linux, Mac OS X, Windows, FreeBSD, OpenBSD, 
NetBSD (and on x86, ARM, Sparc, PowerPC, ...).
- Scriptable protocol decoding. Extendable with stackable protocol 
decoders written in Python 3.
- File format support. Supports various input/output file formats 
(binary, ASCII, hex, CSV, gnuplot, VCD, ...).
- Reusable code. Consists of the libsigrok and libsigrokdecode shared 
libraries which can be used by various frontends/GUIs.

http://sigrok.org

Sind auch nette Typen da auf der Mailingliste bzw. im IRC.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.lxtreme.nl/ols/
Ist auch eine neu Variante.da.


>
> Guckt euch dazu mal sigrok an:
>
> "The sigrok project aims at creating a portable, cross-platform,

Bei Sigrok fehlt mir der Einstieg. Es scheint die Eierlegende 
Wollmilchsau zu werden. Ich will auch keine Busprotokolle debuggen.
Will auch nicht unterschiedliche Messgeräte auf meinem Bilschirm 
vereinen.


Ich habe einefache unterschiedlichen Signal aus dem Innenleben des FPGs 
zu begutachten. Wie z.B.
Wird beim Interrupt alles richtig gesichert?
Und danach auch wieder zurückgeschrieben?



Die Idee mit GKTwave zur Darstellung fand ich sehr gut, da ich mit 
GTKwave ständig die Simulationsergebnisse auswerte. Man bräuchte ein 
paar Buttons zum Steueren der Sump state machine und einen 
kontinuierlichen Import zur Darstellung unter GTKwave.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Zu W.S. kann ich nur sagen: Selber besser machen anstatt zu motzen.
Abgesehen davon, dass JTAG ein ziemlich cleverer Standard ist, und, wenn 
man die Boundary-Scan-Primitiven mal verstanden hat, sich damit besser 
debuggen lässt als mit händisch dazucodierten Interfaces. Ansonsten 
würde man zuviel am System verändern.

Ich mache das auf verschiedenen Plattformen mit GTKwave über das shared 
mem-interface. Der interne LA triggert auf gewisse Ereignisse und 
signalisiert, dass Daten auslesbar sind. Einerseits können per BSCAN 
laufend Pins gepollt werden (mit geringer Zeit-Auflösung) oder beim 
Ereignis der Trace-Buffer ausgelesen werden. Der Debugger-Daemon 
schmeisst die Daten einfach in eine VCD-Pipe und gtkwave liest es aus. 
Klappt super, und ist bei Xilinx relativ simpel anzubinden.
Macht aber jeweils Sinn, sich sowas selbstzuschreiben, denn die 
eierlegende Wollmilchsau führt meist jeweils dazu, dass gewisse 
quantenmechanische Effekte beim FPGA-Debuggen auftreten. Und seinen 
Debugger will man nicht debuggen müssen..

Grüsse,

- Strubi

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René D. schrieb:
> Die Idee mit GKTwave zur Darstellung fand ich sehr gut, da ich mit
> GTKwave ständig die Simulationsergebnisse auswerte.

Hindert dich ja niemand daran, die Daten die Sigrok zusammensammelt in 
GTKwave auszuwerten.

Schön an Sigrok ist, dass es Modular ist. Kein Busdecoding nötig, lass 
es einfach weg.

Du baust ein Gerät das, sagen wir mal an einem DMX512 Bus hängt, du 
möchtest aber die Protokolldaten auf dem internen parallen Bus debuggen. 
Dann klebst du den Busdecoder für den internen parallen Bus mit dem 
DMX512 Decoder zusammen (Den sonst die meisten Anwender zusammen mit dem 
RS485 Decoder zusammen bauen).


Aktiv habe ich den Einstieg auch noch nicht gefunden, da ich aber diesen 
Sommer wieder Oszilloskop/Logic Analyser Grundkurse geben werde, muss 
ich mich da mal durchbeissen um meine Beispiele mit Sigrok anstatt OLS 
zu machen.

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine schöne Idee:

Du kombinisert den internen LA mit Multimetern die den Strom auf den 
Versorgungsleitungen messen...

War vor ein paar Monaten mal so ein Buzz-Word in meinem Postfach: "Power 
Aware Debugging" :-)

Autor: Tom W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph schrieb:
> Du kombinisert den internen LA mit Multimetern die den Strom auf den
> Versorgungsleitungen messen...
Nicht wirklich oder?
Nach IO-Block getrennt, nehme ich an?

Autor: W.S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Abgesehen davon, dass JTAG ein ziemlich cleverer Standard ist,

Ich hab ja garnix gegen JTAG, aber warum zum Kuckuck wollen die Leut'z 
auf der Auswerteseite nicht erstmal eine Schnittstellendefinition 
erarbeiten, sondern gleich mit sowas loslegen:

hunz schrieb:
> 2 Wege sehe ich hier:
> 1) Original Java-GUI an xilprg "kleben"
> 2) GTK/Glade-GUI basteln, an xilprg "kleben" und die Darstellung mit
> GTKWave machen

Das ist wie so häufig der zweite Schritt vor dem ersten und genauso 
häufig landet dann so ein Vorhaben im Nirvana.

Die Sigrok-Leute haben ihren Kram auch so angefangen und was ist draus 
geworden? Ein Haufen Gestrüpp, das bestenfalls für einige 
Linux-Varianten geeignet zu sein scheint (sicher ist das aber auch 
nicht). Von "Crossplatform" ist bislang nix zu sehen. Es nützt dabei 
nix, den ganzen Prassel unter GPL stellen zu wollen, denn wer will sich 
schon freiwillig durch so ein Gestrüpp durchquälen? So ähnlich scheint 
sich auch dieses Vorhaben entwickeln zu wollen:

hunz schrieb:
> Daher meine Frage, ob vllt. jmd. Lust & Zeit
> hat, dran mitzubasteln. Vor allem auf Host-Seite fehlt hier noch code.

Ja, eben.

W.S.

Autor: Christoph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Ich hab ja garnix gegen JTAG, aber warum zum Kuckuck wollen die Leut'z
> auf der Auswerteseite nicht erstmal eine Schnittstellendefinition
> erarbeiten, sondern gleich mit sowas loslegen:
 [...]
> Das ist wie so häufig der zweite Schritt vor dem ersten und genauso
> häufig landet dann so ein Vorhaben im Nirvana.

Ja, das sehe ich auch so. Darum mag ich es immer, wenn sich in einem 
Feld ein Standard herausgebildet hat. Ich mag z. B. das ganze 
IEEE488.2/SCPI/IVI Zeugs weil es definiert was wie funktioniert und die 
Schnittstellen sind abstrahiert.

Bei Debuggern hat sich da ja z. B. die Netzwerkschnittstelle von GDB 
herausgebildet etc.
Wenn es sowas gibt, bin ich immer dafür, in sowas zu investieren.

> Die Sigrok-Leute haben ihren Kram auch so angefangen und was ist draus
> geworden?

Ein Projekt, dass zum Ziel hat eine definierte und dokumentierte API zu 
haben auf der Ebene libsigrok.

Alles darunter können sie nicht, da sie "nur" Software machen und eben 
keine Hardware. Die Hersteller kochen ja alle ihre eigenen Süppchen, da 
möchte Sigrok eine Abstraktion hineinbekommen, um da interoperabilität 
zu schaffen.
Ist so ein Projekt einfach zu überblicken? Wahrscheinlich nicht und 
sicher ein Knackpunkt für die Entwicklung und Dokumentation eines 
solchen Projekts.


Als ich die Sigrok-Leute vor 2 Jahren getroffen hatte, ging es ihnen z. 
B. gerade darum, eine definierte API für die Signaldekoder zu entwerfen, 
die längere Zeit bestand hat. Genau damit die investierte Zeit für 
Dekoder Entwicklung für längere Zeit bestand hat.
Sie wollen sich für diese Definitionen Zeit lassen, auch ein Grund wieso 
Sigrok "nicht so schnell" vorwärtskommt.
http://sigrok.org/wiki/Protocol_decoder_API

> Ein Haufen Gestrüpp, das bestenfalls für einige
> Linux-Varianten geeignet zu sein scheint (sicher ist das aber auch
> nicht). Von "Crossplatform" ist bislang nix zu sehen. Es nützt dabei
> nix, den ganzen Prassel unter GPL stellen zu wollen, denn wer will sich
> schon freiwillig durch so ein Gestrüpp durchquälen?

Ja, für einige Linux-Varianten gibt es fertige Binärpakete. Für alle 
anderen Plattformen (Windows, BSD, OS X, Android) heisst es im Moment 
noch selber kompilieren:
http://sigrok.org/wiki/Downloads

Autor: Tom W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was benötige ich denn an simpler Hardware, um das sigrok ins Laufen zu 
bekommen?  FPGA mit JTAG?

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Werner schrieb:
> was benötige ich denn an simpler Hardware, um das sigrok ins Laufen zu
> bekommen?  FPGA mit JTAG?
Das steht doch auf der Sigrok-Seite unter "Supported hardware".
http://sigrok.org/wiki/Supported_hardware#Logic_analyzers

Die billigste Variante dürften die FX2 basierten Nachbauten von Saleae 
und USBee sein:
http://dx.com/p/logic-analyzer-w-dupont-lines-and-...

Ich habe ein Lcsoft Mini Board. Das läßt sich auch noch für andere 
Spielereien verwenden.

Duke

Autor: Fitzebutze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne kein FPGA, welches kein JTAG hat...
Die Frage ist: Willst Du einen richtigen LA oder einen ChipScope-Klon?
Bei den unzähligen sigrok-Forks ist mir nicht klar, ob es da etwas 
funktionierendes gibt (fand erst mal http://sigrok.org/wiki/Fpgalafw).
Was relativ populär ist: Der Papilio mit dem Spartan3E 250k. Da ist die 
Community riesig und die Chancen gross, dass es damit läuft. Den Papilio 
kriegt man für rund 50 USD bei seeedstudio.
Nachteil bei dem Ding ist bloss, dass nur die lahme serielle als 
"Standard-Interface" (nebst JTAG) angebunden ist. Also kein Durchsatz 
per USB-FIFO, leider..

Autor: Tom W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, nun habe ich das kapiert. Meiner ist natürlich "planned" status.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.