hallo gemeinde! ich würd gern ein internes singal zu testzwecken nach außen führen, typ std_logic. ich habe also in allen modulen in der hierarchie bis zu dem modul mit dem signal einen neuen test-port eingeführt, der nachher per ucf an eine led geht. in dem modul, wo das signal definiert wird, habe ich eine zuweisung "test-port <= erwuenschtes_signal" gemacht. durchverdrahtet bis zum toplevel-modul sind dann die ports auch. wenn ich mir aber nun mit dem fpga-editor das design anschaue, ist mein signal futsch, dafür steht dort nun test-port-obuf. ich will aber ja den out-port nicht runterleiten, sondern das signal nach außen führen... was mache ich falsch?
Some User schrieb: > dafür steht dort nun test-port-obuf. Ein obuf ist ein Output Buffer. Passt doch. Bleibt die Frage: warum siehst du dir dein Design im FPGA-Editor an? Was geht nicht?
Lothar Miller schrieb: > Some User schrieb: >> dafür steht dort nun test-port-obuf. > Ein obuf ist ein Output Buffer. Passt doch. ja nach außen hin klar. > Bleibt die Frage: warum siehst du dir dein Design im FPGA-Editor an? > Was geht nicht? ich hätte erwartet, dass das signal, welches ich eigentlich nach außen führen möchte, immer noch dort liegt, wo es vorher auch war. es soll eigtl. eine kopie des signalwertes nach außen geleitet werden, das signal soll aber im ursprungsdesign genauso erhalten bleiben, wie es jetzt ist.
Hm, komische Erwartung. Durch das nach außen Legen des Signals kann es sein, dass der Place&Route Prozess völlig andere Ausgangsbedingungen hat und große Teile des Designs anders routet. Wozu soll das denn gut sein? Ist das so ein zeitkritisches Design? Wenn du das willst, musst du selbst routen...
Christian R. schrieb: > Hm, komische Erwartung. Durch das nach außen Legen des Signals kann es > sein, dass der Place&Route Prozess völlig andere Ausgangsbedingungen hat > und große Teile des Designs anders routet. Wozu soll das denn gut sein? es gibt einen init-fehler. allerdings nicht jedes mal. es ist runtergebrochen auf dieses eine signal und zum testen würd ich es gern an eine led nach außen führen. das signal steuert auch ein we-signal an einer lut, die als schieberegister konfiguriert ist und das signal ist manchmal falsch beim start. > Ist das so ein zeitkritisches Design? Wenn du das willst, musst du > selbst routen... nein, so ist es eigtl. nicht. siehe oben.
Im FPGA-Editor warst du schon richtig. Du musst dein Design gar nicht modifizieren und interne Signale durch die Hierarchien führen um sie auf Pins zu bekommen. 1. Du machst deinen ganz normalen Flow. 2. Design im FPGA-Editor öffnen und editierbar machen. 3. Das "Probes" tool aufrufen. (Button auf der rechten Seite) 4. Gewünschte signale auf die gewünschten Pins routen lassen. 5. Bitfile neu generieren. Fertig. Das ursprüngliche Routing bleibt erhalten. Nur die load für das geprobte Signal erhöht sich um eins. Das ganze lässt sich auch sehr gut scripten. Einfach die Komandos unten aus der Konsole klauen.
Ottmar schrieb: > Im FPGA-Editor warst du schon richtig. > Du musst dein Design gar nicht modifizieren und interne Signale durch > die Hierarchien führen um sie auf Pins zu bekommen. > > 1. Du machst deinen ganz normalen Flow. > 2. Design im FPGA-Editor öffnen und editierbar machen. > 3. Das "Probes" tool aufrufen. (Button auf der rechten Seite) > 4. Gewünschte signale auf die gewünschten Pins routen lassen. > 5. Bitfile neu generieren. Fertig. > > Das ursprüngliche Routing bleibt erhalten. Nur die load für das geprobte > Signal erhöht sich um eins. was man nicht alles lernt?! großartig, werde ich direkt morgen ausprobieren. vielen dank!
Schau an, das wusste ich auch noch nicht. So ein Forum ist doch sehr nützlich. Insgesamt hört sich das Problem aber nach einem asynchronen Reset an, der irgendwie wild läuft, weil er nicht korrekt einsynchronisiert ist. Vielleicht sogar der grausame Reset-Taster :)
Some User schrieb: > es gibt einen init-fehler. allerdings nicht jedes mal. Liese dir mal von diesem Post den letzten Satz: Beitrag "Re: (asynchronen) Reset vermeiden. oder nicht?" Und wenn dir das bekannt vorkommt, dann lies auch den Rest... Christian R. schrieb: > Insgesamt hört sich das Problem aber nach einem asynchronen > Reset an, der irgendwie wild läuft, weil er nicht korrekt > einsynchronisiert ist. ACK.
Lothar Miller schrieb: > Some User schrieb: >> es gibt einen init-fehler. allerdings nicht jedes mal. > Liese dir mal von diesem Post den letzten Satz: > Beitrag "Re: (asynchronen) Reset vermeiden. oder nicht?" > Und wenn dir das bekannt vorkommt, dann lies auch den Rest... > > Christian R. schrieb: >> Insgesamt hört sich das Problem aber nach einem asynchronen >> Reset an, der irgendwie wild läuft, weil er nicht korrekt >> einsynchronisiert ist. > ACK. das design hat mit absicht kein reset... weder synchron, noch asynchron.
Some User schrieb: > das design hat mit absicht kein reset... weder synchron, noch asynchron. Pech, dann wirds aufwendiger... ;-) Dann ist da irgendein (asynchrones) Signal, mit dem irgendeine FSM zu diesem Zeitpunkt nicht rechnet. > das design hat mit absicht kein reset... weder synchron, noch asynchron. Ich bin mir ziemlich sicher, dass da (zumindest) ein Zähler irgendwann zurückgesetzt (=reset) wird. Oder? > es gibt einen init-fehler. Woran merkst du das? > und das signal ist manchmal falsch beim start. Woraus wird das Signal generiert? Ist da noch etwas anderes im Spiel (DCM...)?
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.