Hallo, ich bastel schon länger an einem erät das folgendes macht: Es bekommt einen Triggerimpuls und dann ein 13-Bit Bitmuster (beides TTL) und baut daraus ein Spektrum im RAM. Also die Bitmuster werden nach Häufigkeit sortiert. Dann kann man das Spektrum über UART auslesen was prima funktioniert. Als neue Funktion ist jetzt noch hinzugekommen, dass das Board jedes einzelne Bitmuster in Echtzeit über einen zweiten UART schickt. Und zwar mit genauer Zeitinformation wann das Bitmuster angekommen ist. Da manchmal Bitmuster schneller ankommen als der UART senden kann, habe ich ein 16kB FIFO gebaut (BlockRAM). Soweit so gut. Das Problem ist jetzt, dass ich hier an meinem Schreibtisch das alles schön an den PC anschließe, und alles so funktioniert wie es soll. Also ich kann da am Triggerpin wackeln und Bitmuster anlegen und bekomme sowohl ein Spektrum im RAM als auch die einzelnen Bitmuster über den zweiten UART und es passt auch alles ganz genau zusammen, den FIFO kann ich füllen und er wird wieder leergeschrieben, alles fein. Wenn ich das jetzt aber im Keller (da wo die anderen Messgeräte stehen die das reale Bitmuster ausgeben) anschließe, dann ist alles etwas komisch. Ich bekomme zwar ein Spektrum im RAM, aber der UART schickt nicht die einzelnen Bitmuster. Selbst wenn ich anstelle des UART einen einfachen Pin als TX nehmen, zeigt mein Logicanalyzer nichts an. Ich verstehe das nicht, es ist 1:1 der selbe Aufbau, das selbe Bitfile für den FPGA, und die Daten komme ja auch an, sonst wäre im RAM kein ordentliches Spektrum. Der eigentliche Witz ist, dass ich den Teil der nur die Bitmuster über UART schickt zuerst alleine zum Testen gebaut habe, also gleiches Board (Nexys2) nur fehlt eben die ganze andere Logik im FPGA. Tja und wenn ich dieses Bitfile lade, dann funktioniert es. Und eigentlich hatte ich nur den Code genommen und in das größere Projekt zusätzlich reingeklebt was ja auch mit simulierten Bitmustern prima funktioniert. Ich bin etwas ratlos, weiß aber auch nicht, was man wissen müsste um mir zu helfen, die FPGA Konfiguration will ich eigentlich ausschließen weil es doch funktioniert wenn ich einfach so Bitmuster anlege und am Triggerpin wackel. Ich will eher fragen: Habt ihr auch manchmal so krude Situationen? Und was sind da die häufigsten Fehler? Sowas wie schlechte Netzteile vielleicht oder sonst irgend etwas? gustl
Dann würde es aber auch unter anderen Bedingungen Fehler geben. Ich kann natürlich den ganzen Code hochladen, aber das ist richtig viel und vermutlich nicht die Ursache.
Vermutlich doch. Du mußt bei der Simulation das gleiche Timing und Signale anlegen wie im Keller dann wird auch das gleiche passieren. Also ist entweder was im Code falsch (die timings der echten Signale passen nicht zum Code) oder die Signale im Keller sind unsauber und können auch mit gutem Code nicht verarbeitet werden ohne vorher aufbereitet zu werden). Eine schlechte Spannungsversorgung könnte aber auch möglich sein bzw. ein schlechtes Platinen Layout.
Uwe schrieb: > Du mußt bei der Simulation das gleiche Timing und Signale anlegen wie im > Keller dann wird auch das gleiche passieren. Nicht unbedingt. Man nehme einen asynchronen Eingang und eine FSM, und die Realität ist eine ganz andere als die (Verhaltens-)Simulation...
Naja, der Witz ist doch, dass das Timing und so auch im Keller passen muss, weil ich auch da ein richtig schönes Spektrum aufnehmen kann. Nur die Funktion, die das einzelne Bitmuster mit genauer Zeit über UART ausgibt, die funktioniert nicht mehr. Und diese Funktion nimmt das Bitmuster natürlich vom selben Eingang die auch die Funktion die das Spektrum im RAM baut. Mir ist das ein Rätsel, weil hier wenn ich das stehen habe und einfach am Trigger Pin wackel, dann kommen die Daten auch schön über RS232. Auch die Geschwindigkeit passt, der FIFO kann locker ein Bitmuster+Zeit je us speichern. Generell benutzen beide Funktionen erstmal die selbe Stufe, also Trigger wird einsynchronisiert, nach dessen falling Edge wird 1us gewartet und wenn der Trigger dann immer noch unten ist wird das Bitmuster übernommen - und dann erst geht es einmal an die Funktion die es direkt mit der Zeit verschickt und da die, die da das Spektrum im RAM draus baut. Und sogar nochmal an eine Funktion, die das Spektrum im VideoRAM baut und auf den Monitor schreibt (was auch funktioniert). Eigentlich bin ich nur frustriert... gustl
Wie lang ist denn Deine UART-Verbindung im Keller? Und wie erzeugst Du die passenden Pegel? Duke
Es hat sich ja auch nichts getan, als ich das einfach auf einen Pin gelegt hatte und den mit dem Logicanalyzer angeguckt habe. Der "Fehler" war etwas seltsam, aber hatte ich schon mehrmals. Wobei Fehler eben nicht sicher ist, weil es ja am Schreibtisch immer funktioniert hat. Also ich hatte ja den Trigger und wenn der gefallen ist, dann wurde bis 50 gezählt und dann ein anderes Signal für einen Takt lang auf '1' gesetzt. Das habe ich in einer Unterkomponente gemacht und dieses neue Signal dann schön mit Port Map in der Hauptdatei weiterverteilt. Und da war das Problem, ich habe das Signal das ich von der Unterkomponente bekam einfach dann wieder an drei Komponenten weitergegeben, also genau das gleiche Signal. (Hat ja auch in alles Tests funktioniert.) Geändert habe ich, dass die Unterkomponente drei Signale erzeugt, die dann alle rausgereicht werden und jedes der Signale geht dann nur an genau eine neue Komponente. Und jetzt geht das. Vermutlich wäre auch gegangen, dass ich in der Hauptdatei das eine Signal an drei neue übergeben und diese dann an die drei Unterkomponenten verteile. Jedenfalls seltsam, also klar man könnte sagen jedes Signal darf nur einen Start und einen Endpunkt haben und keine Verzweigungen, aber das stimmt auch nicht weil es doch sehr oft funktioniert hat. gustl
So ähnliches Problem hatte ich auch bei UART-Code. Aber bei mir lag der Fehler bei Rx_Modul. Der PC schickt immer ein Handshake-Singal zum mein System(mit FPGA). Wenn der uart dieses Signal richtig empfängt, erkannt mein System die Befehle und fängt er an die Daten zu schicken. Aber wenn das Signal falsch empfängt wird, weiß das System gar nicht mehr was es machen soll und schickt es natürlich kein Daten weiter. Und der "3-in-1" Signal-Fehler habe ich leider auch gehabt. Meine Meinung ist: Der FPGA kann kein "langes" logische Signal routingen. Wenn ein Signal, z.B Daten_WR, überall in den vhdl-Code erscheint, siehst du dann in den Routingplan die sogenannte Signals Daten_WR_1, Daten_WR_2,..... Normaleweise ist es OK. Aber wenn du von Daten_WR_1 und Daten_WR_2 noch zwei weitere Signale erzeugst und die beide Signale unbedingt unter ein exakt Timing bearbeitet werden müssen, dann hast du ein Problem. Meine Lösung ist: alle interne logische verknüpfte Signale werden in die "process" zugeordnet und mit System Takt synchronisiert. Und die FPGA Einstellung "Fanout-limit" erhöhen.
Chong schrieb: > Meine Lösung ist: alle interne logische verknüpfte Signale werden in die > "process" zugeordnet und mit System Takt synchronisiert. Das gibt dann zwar einen Takt Latency, aber dafür kann Register Duplication angewendet und so der Fan-Out eines einzelnen Flipflops reduziert werden... http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pp_db_xilinx_specific_options.htm
Das Seltsame war halt, dass das doch richtig geroutet war, sonst hätte es ja nie funktioniert. Aber wenigstens was gelernt dabei. Mit ISE 14.1 bin ich auch erstmal gestolpert als nichts mehr ging und dann hab ich gesehn, dass ich die Pins in der .ucf Datei noch nicht auskommentiert hatte. Das alte 13.x hat da immer einen Fehler gebracht und keinen Bitstream gebaut, das 14.1 macht es trotzdem und der geht dann nicht wie er soll.
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.