www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Internes Signal nach außen führen?


Autor: Some User (seraphe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Some User (seraphe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Some User (seraphe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ottmar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Some User (seraphe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Some User (seraphe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...)?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.