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
Nimm nen selbstgebauten RAM-Sampler und hänge einen Prozessor dran. 10mal schneller.
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 :-(
1 | Caused by: java.lang.NoClassDefFoundError: gnu/io/CommPortIdentifier |
Duke
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.
@W.S ich bewundere deine Webseite, du hast dort ja nur tolle Projekte, und alle so durchdacht, Wahnsinn!
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
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-usb-cable-for-scm-black-148945 Ich habe ein Lcsoft Mini Board. Das läßt sich auch noch für andere Spielereien verwenden. Duke
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..
ok, nun habe ich das kapiert. Meiner ist natürlich "planned" status.
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.