Forum: FPGA, VHDL & Co. ISim VHDL Simulation - Signalzustand bei steigender Flanke


von Luke.skywalker (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

ich arbeite momentan an einem Controller für ein Interface, das Daten 
von einer Schnittstelle lesen soll. Ich bin leider ein Anfänger und 
deswegen noch nicht so erfahren mit VHDL und ISim, deswegen Folgende 
Frage:

Das Interface übernimmt das Signal (siehe Grafik) mit jeder steigenden 
Taktflanke. Wird an der Position des Cursors jetzt nun eine '1' oder 
eine '0' eingetaktet?

von Duke Scarring (Gast)


Lesenswert?

Luke.skywalker schrieb:
> Wird an der Position des Cursors jetzt nun eine '1' oder
> eine '0' eingetaktet?
Oder.
Schau in das Datenblatt Deines Chips, was dort als Setup-&-Hold Zeit 
angegeben ist. Was für einen Chip verwendest Du? Welcher 
Signalisierungsstandard ist eingestellt (CMOS, LVTTL, LVDS, ...)?

Wo kommt der Takt her? Wenn er von außerhalb kommt, könnte die 
Verzögerung vom Takteingang bis zum Flipflop des Datensignals 
ausreichen, daß eine '1' gesampelt wird.

Duke

von Lutz H. (luhe)


Lesenswert?

Das Signal muss eine bestimmte Zeit vor der Flanke  und nach der Flanke 
einen definierten Pegel haben. Siehe Datenblatt

Im konkreten Fall wird eine 1 oder 0 eingelesen, oder der Schaltkreis 
macht irgendwas anderes.

von Falk B. (falk)


Lesenswert?

@ Luke.skywalker (Gast)

>    Capture.JPG


Ist dein Projekt soooo geheim, dass du sie Signalnamen unkenntlich 
machen musst?

von Luke.skywalker (Gast)


Lesenswert?

Hallo,

schon mal danke für die hilfreichen Antworten. Ich habe jetzt erstmal 
noch einen Zustand hinzugefügt, damit das Signal garantiert eingetaktet 
wird.

Die Signalnamen tuen im Bezug auf die Frage nichts zur Sache.

von Falk B. (falk)


Lesenswert?

@ Luke.skywalker (Gast)

>schon mal danke für die hilfreichen Antworten. Ich habe jetzt erstmal
>noch einen Zustand hinzugefügt, damit das Signal garantiert eingetaktet
>wird.

So ein "Angstzustand" ist auf Dauer sehr kontraproduktiv. Denn damit 
verschließt du die Augen vor den Grundlagen der Digitaltechnik!

Wer erzeugt denn in der Testbench den Takt und das fragliche 
Eingangssignal? Wahrscheinlich deine Testbench, die DU geschrieben hast. 
Also sollte sie auch die Realität möglichst gut abbilden. d.h., das 
Signal ändert sind nicht EXAKT gleichzeitig mit der Taktflanke, sondern 
immer ein paar ns später. Damit die sowohl die Darstellung als auch die 
Funktion eindeutig.

: Bearbeitet durch User
von Luke.skywalker (Gast)


Lesenswert?

Falk,

da ist vermutlich etwas dran. Die besagten Signale werden von einem 
Zustandsautomaten erzeugt und sind synchron zu einer internen Clock. Die 
anzusteuernde Komponente ist ebenfalls synchron zu dieser Clock. Es 
handelt sich dabei um einen zugelieferten IP-Core. Ich gehe mal davon 
aus, dass das Clock Signal um Bruchteile schneller ist, als das das 
hervorgehobene Signal (internes Clock-Netz) und deswegen nicht 
eingetaktet wird. Was macht man in einem solchen Fall? (außer einen 
zusätzlichen Zustand einführen)

von berndl (Gast)


Lesenswert?

Signale von "aussen" (off-chip oder auch off-component) setze ich immer 
mit der falschen Flanke (bei dir dann falling_edge). Damit habe ich 
keine Setup/Hold Geschichten in der Simulation und es ist eindeutig.
Mit passenden contraints (off-chip) und korrekter Synthese/... (on-chip) 
funktioniert dann auch die HW spaeter...

von berndl (Gast)


Lesenswert?

PS: Asynchrone Signale muss man aber trotzdem speziell 
betrachten/behandeln

von Falk B. (falk)


Lesenswert?

@ Luke.skywalker (Gast)

>da ist vermutlich etwas dran. Die besagten Signale werden von einem
>Zustandsautomaten erzeugt und sind synchron zu einer internen Clock.

einer internen Clock?
Oder vielleicht interner Takt? (Denglisch ist bäh)

> Die
>anzusteuernde Komponente ist ebenfalls synchron zu dieser Clock. Es
>handelt sich dabei um einen zugelieferten IP-Core. Ich gehe mal davon
>aus, dass das Clock Signal um Bruchteile schneller ist, als das das
>hervorgehobene Signal (internes Clock-Netz) und deswegen nicht
>eingetaktet wird.

Nein, das ist vollkommen normales Verhalten, wenn gleich die Darstellung 
irritiert. Die Ausgangsdaten das Zustandsautomaten änderns sich eine 
geradezu winzige Zeit nach der steigenden Flanke des Taktes. Das ist ein 
sogenannter Delta-Zyklus, welcher sich aus der Logik des Ablaufs ergibt.

Das FlipFlop "sieht" die Flanke und reagiert daraus.

Leider ist die Verzögerungszeit bei einer reinen Verhaltenssimulation 
0ns, damit sieht es so aus, als ob Taktflanke und Signalwechsel EXAKT 
gleichzeitig passieren. Tun sie aber nicht.

> Was macht man in einem solchen Fall? (außer einen
>zusätzlichen Zustand einführen)

Das ist eine Lösung für ein nicht vorhandenes Problem. Denn es wird '0' 
eingetaktet. Immer der Zustand, der VOR der Taktflanke vorhanden ist. 
Mit diesem Wissen kann man die Darstellung problemlos verstehen.

von Luke.skywalker (Gast)


Lesenswert?

Falk Brunner schrieb:
> Das ist eine Lösung für ein nicht vorhandenes Problem. Denn es wird '0'
> eingetaktet. Immer der Zustand, der VOR der Taktflanke vorhanden ist.
> Mit diesem Wissen kann man die Darstellung problemlos verstehen.

Das sieht mir nach der korrekten Antwort aus. Der Takt möge mit dir 
sein.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Luke.skywalker schrieb:
> Wird an der Position des Cursors jetzt nun eine '1' oder eine '0'
> eingetaktet?
Weil und wenn das eine Vehrhaltensimulation ist: eine '0'.
In der Praxis kommt es allerdings stark darauf an, woher das Signal 
kommt...

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
Noch kein Account? Hier anmelden.