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/#svn/trunk/fx2fw
Auf Hostseite benutz ich für die Ansteuerung ein modifiziertes xilprg:
http://code.google.com/p/xilprg-hunz/source/browse/#svn/trunk
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/#svn/trunk/bscan_la
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
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
> 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.
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
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.
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 :-(
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.
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
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.
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.
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.
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
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.
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" :-)
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?
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.
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
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..
