Ich möchte hier gerne meine neuste Kreation zur Diskusion stellen. Oft ist man bei der Fehlersuche in einem FPGA-Design auf Ozzis und/oder Logikanalysatoren angewiesen. Nun sind diese Teile nicht ganz billig und das Ansetzen der Probs ist auch nicht ohne. Also warum nicht eine abgespeckte Variante in den FPGA zu dem zu testenden Design dazu compilieren? Altera und Xilinx bieten sowas ja schon teuer an => Daten intern sammeln und dann an eine externe Software zur Auswertung übergeben. Ist völlig OK aber oft wird da mit Kanonen auf Spatzen geschossen. Oft reicht es mal schnell drei- vier Leitung mit wenigen Speicherpunkten zu überprüfen. Manchmal reicht auch schon die Ausgabe eines Hexwertes. Genau hier setzt meine Idee an. Vorraussetzung für meine Idee ist ein Monitoranschluß am FPGA. Zur Not reichen auch 3 schnell angebaute Leitungen (Vsync, Hsync, Luma). Wird auf dem Board schon ein Moitorsignal erzeugt blendet sich das Datendisplay drüber, ansonsten reicht eine einfache Schaltung zum Erzeugen der Synchronsignale. Wie das aussieht zeigt angefügtes Foto. Die Eckdaten des Logikanalysers hängen von den im FPGA freien Resourcen ab. Mit 2 RAM-Blöcken in einem Cyclone I FPGA kann der LA z.B. 8 Kanäle mit 1024 Punkten Tiefe haben. Bei mehr freien Ram-Blöcken läßt sich der Datenpfad verbreitern. Die Samlingfrequenz des LA hängt hauptsächlich von der internen Geschwindigkeit des FPGAs ab. Das Foto stammt von einem Design mit 278 LCs und 2 Ramblöcken auf einem Terasic T-Rex C1 Board. Ich habe das Scope in VHDL geschrieben. Ich bin da zwar kein Neuling aber auch kein Profi. Wie kann ich das Scope für Xilinx umschreiben oder noch besser herstellerunabhängig schreiben? Viele Grüße TobiFlex
Das Einfügen in ein bestehendes Design könnte wie auf dem Foto aussehen. Viele Grüße TobiFlex
Die Idee ist nicht neue, aber trotzdem schön :-) Ich habe schon Ähnliches gemacht, aber ohne Display. Und ehrlich gesagt, kann ich mir erstmal nicht vorstellen, damit sinnvoll arbeiten zu können. ERstens, möchte ich nichts mehr in mein Design dazulinken, schon gar nicht, wenn die Ressourcen knapp sind. Da bin ich ein Mal doll auf die Nase gefallen -- nach dem Debuginterface entfernt wurde, funktionierte nichts mehr oder mit krassen Timingfehlern. Ich habe mir angewönt alle Register per i2c rauszuführen. Okay, Timingsachen kann ich da nicht überprüfen, aber dafür sind ja Simulatoren da. Für Hobbysachen ist die Idee toll, für Profis aber wohl eher nicht. Wenn ich so überlege, ich könnte auf keinem einzigen Board "mal eben" 3 Leitungen für Syncs reservieren. Bei BGAs ist es ja auch oft nicht möglich. Ich sehe zwar immer genug Testpunkte vor, es reicht aber selten. Eine andere (weiter) Möglichkeit wäre noch Pi(o)coblaze dazuzulinken. Ist schnell, klein, einfach. Gruß Kest
"Die Idee ist nicht neue, aber trotzdem schön :-)" Ja! Find ich auch ;-) "Und ehrlich gesagt, kann ich mir erstmal nicht vorstellen, damit sinnvoll arbeiten zu können." Naja. Man ist nich so flexibel wie mit Profiequipment. Der Trigger muß in dem Scopecore fest eingebunden werden. Andererseits kann man sich Trigger bauen, die extern nicht möglich wären. "nach dem Debuginterface entfernt wurde, funktionierte nichts mehr oder mit krassen Timingfehlern." Komisch. Eine ähnliche Erfahrung hab ich auch schon mal gemacht. Je weniger Platz ich auf dem Chip hatte umso schneller wurde das Design. So also ob wenn viel Platz ist alles in die Ecken verteilt wird. "Für Hobbysachen ist die Idee toll, für Profis aber wohl eher nicht." Profis holen sich auch kein Terasic T-Rex C1-Board ;-) "Pi(o)coblaze dazuzulinken" geht das denn auf einem ALTERA Chip??? Das würd ich mal probieren wollen. Viele Grüße TobiFlex
@tobiflex witzige idee :-)) find ich klasse. mit einem kleinen mini-la den man "mal eben" mit in ein design packt bin ich auch schon am überlegen (obwohl ich nicht unbedingt ein vga interface haben muß, mir würde ne schnittstelle zum pc bzw. uc reichen) schön schön :-) @tobi & kest das problem mit teilen die man rausnimmt und dann gar nichts mehr geht hatte ich auch schon gehabt (allerdings "andersherum", sprich ich hatte an ganz anderer stelle im design was geändert/hinzugefügt und schon funktionierte ein anderer teil nicht, obwohl die beiden teile absolut nichts miteinander zu tun hatten. nehm ich die änderung wieder zurück und schon funktionierte alles wieder wie gehabt) @kest wie schauts eigentlich aus mit dem audio-projekt ? noch interesse oder keine zeit ? gruß rene
@Mason: doch, jetzt habe ich sowohl Lust, als auch Zeit :-) Ich experemntiere gerade etwas mit Spartan 3E Board, bin dabei ein eigenes Prozessor (eher für Spezialanwendungen) zu entwickeln. Was mir fehlt ist eher die Zeit um ein Extension Board mit dem DSP zu basteln :-/ Kest
"(obwohl ich nicht unbedingt ein vga interface haben muß, mir würde ne schnittstelle zum pc bzw. uc reichen)" Ich finde die direkte Ausgabe ist einfacher zu implementieren. Für den PC oder uC braucht man ja dann auch wieder die passende Software. Ich hänge mal meinen Sourcecode als Quartussnapshot mit an - zur Nachnutzung und Verbesserung ;-) Vielleicht macht ja einer ne Xilinx oder eine herstellerunabhänige Version. Die interessante Datei heißt scope.vhd. crt.vhd erzeugt die Monitorsignale. Das Scope läßt sich mit Trigger und Layout anpassen. Mit shot=Lowimpuls wird der Trigger scharf geschaltet. Mit run=Low werden die Eingangsdaten ständig übernommen. o_trigger wird High wenn die Triggerbedingung erfüllt ist. o_oneshot wird High wenn der Trigger scharf ist. Viele Grüße TobiFlex
@kest fein :-)) ich bin in der zwischenzeit auch recht weit mit meinem eigenen dsp. habe einen kleinen dsp-kern (kleine statemachine, 32bit MAC, div. Multiplexer, MicroCode) programmiert und in einen Rahmen (kleine Statemachine, Programm-Speicher, I2S-Serializer/Parallizer, div. Multiplexer) gepackt. Funktioniert bombig und braucht realtiv wenig Ressourcen (abgesehen von 4 Block-Rams :-)). Insgesamt bin ich mit meinem Gesamtsystem (also Audio-Prozessor, VGA-Text-Interface, einfacher PS2Keyboard Empfänger, SPI-Interface für alle Teile, div. kleinkram) bei knapp 60 % Chip-Ausnutzung. Das ganze System kann mit bis zu 90 MHz getaktet werden. Rein theoretisch kann ich 100 Biquads durchrechnen (bei 48kHz). Die Steuerung des Systems übernimmt ein MSP430 (der per SPI an den FPGA angekorkt wird). Mir fehlt jetzt nur noch eine Hardware mit mehreren Codecs (hab nur einen einzigen auf meine Platine bekommen) Werde die Sachen bald mal reinstellen. Ich denke das ganze lässt sich gut gebrauchen und ist sehr flexibel. @tobiflex stimmt zwar das man immer eine software braucht, aber je nach dem wie man die schnittstellen/protokoll definiert braucht man u.U. immer nur eine Software die mit kleinen Änderungen die verbesserter Hardware nutzen kann. Jedenfalls finde ich die Idee eines "Embedded-LA" echt klasse. Werd mir bei Zeiten mal was für meinen Spartan 3 schreiben :-) gruß rene
>Oft ist man bei der Fehlersuche in einem FPGA-Design auf Ozzis >und/oder Logikanalysatoren angewiesen. Was das Oszi betrifft: Elektronikentwicklung, egal ob analog oder digital, macht ohne Oszi nicht wirklich Spaß. Mit meinem Oszi war das so wie mit meiner Mikrowelle: Wenn man erstmal eins/eine hat, versteht man nicht, wie vorher ohne es/sie ausgekommen ist. Zu deinem Design: Interessante Sache, obwohl ich zum Debuggen lieber einen guten VHDL-Simulator benutze. Wenn die Fehler im Code sind, findest Du sie auch im Simulator. >"Pi(o)coblaze dazuzulinken" >geht das denn auf einem ALTERA Chip??? Das würd ich mal probieren >wollen. Der Picoblaze ist speziell auf die Xilinxe optimiert. Ein kostenloser Open-Source-Nachbau heisst Pacoblaze: http://bleyer.org/pacoblaze/ Im Magazin "Circuit Cellar" war in Ausgabe 179 ein Artikel zum Thema Debugging mit Picoblaze: "Low-Cost Logic Analyzer for FPGAs".
@TobiFlex Hast du dir den SignalTap II schon mal angeschaut? Ist beim QuartusII ja schon mit dabei. Ersetzt bei mir den LA, obowohl, ich kann nicht behaupten dass ich den oft einsetze. Setup & Trigger ist komfortabel und blitzschnell mit den signalen die man darstellen will verhaengt. Das mit dem VGA output ist trotzdem eine lustige idee. Cheers, Roger
"Hast du dir den SignalTap II schon mal angeschaut?" Quartus Web Edition meint: Feature SignalTap II is not available with your current license, or license does not exist. :-) Außerdem was soll ich damit jetzt noch? ;-) Viele Grüße TobiFlex
@Roger "Hast du dir den SignalTap II schon mal angeschaut?" Danke Roger, daß du mich drauf gebracht hast. Ist ja wirklich eine feine Sache. Für die Webedition von Quartus mußte ich die Talkback-Funktion freigeben (Warum soll man nicht ALTERA helfen Quartus durch Datensammlungen zu verbessern ;-)) "Außerdem was soll ich damit jetzt noch? ;-)" Wie konnte ich sowas nur schreiben? Naja war ja auch ehr scherzhaft gemeint. Für Altera-Boards mit JTAG hat sich mein Scope also erledigt :-( Dafür habe ich aber SignalTap :-) Umsonst war die Arbeit aber trotzdem nicht. Ich entwickle hin und wieder was für den C-One. Und da gibt es, so bescheuert das auch ist, kein JTAG für die FPGAs. Also muß scope ran :-) Viele Grüße TobiFlex
@TobiFlex keine Ursache ;-) Hmm, der C-One hat doch ACEXs drauf? Da siehts IIRC mit der SignalTap Unterstuetzung nicht gut aus. Auch wenn das Board JTAG haette. Cheers, Roger
Hi, sehr nett, vielleicht solltest du dein Projekt in der Codesammlung vorstellen. Danke und Gruß, Dirk
Bitte 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.