Forum: FPGA, VHDL & Co. FF schalten. Verständnisproblem?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Don Diego (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hallo alle miteinenader!


Ich habe das Wochenende genutzt zum lernen... Bzw. eher um Frust 
aufzubauen, daher brauche ich glaube ich eure Hilfe!
Der Anfang meiner Hirnzerrung war, dass ich an einem spi Master 
gearbeitet habe, der nicht so funktioniert hat wie gehofft. (code su 
weit entschlackt, dass mein Problem erhalten bleibt aber nicht zu viel 
Text auftaucht. MISO, MOSI, Taktteiler etc weg)

Was ich nicht verstehe ist wieso das Signal isl_tx_en nicht starten 
kann, wenn ich es in der Testbench mit dem weggehenden ols_ss generiere.

Schaut euch dazu den dummy process an.
1
DUMMY_PROCESS : process
2
begin
3
wait until rising_edge(isl_clk);
4
  slv_dummy_sr <= slv_dummy_sr(2 downto 0) & isl_dummy;
5
end process DUMMY_PROCESS;
 Das sit ein Shift Register. Wenn isl_dummy '1' ist, wird das bit mit 
der Schaltflanke in das shiftregister übernommen. WARUM ist mir immer 
noch nicht ganz klar, denn wenn bei 100 ns die Taktflanke kommt, die ja 
die FF schaltet die dummy speichern, ist bis DAHIN ja noch gar keine '1' 
da. Irgendwie wird also der Wert direkt NACH dem Schalttakt 
gespeichert.... ?

Das funktioniert nur irgendwie beim Spi nicht (Problem bei 820 ns). Wenn 
SS weggenommen wird, wechselt doch der spi_state auf idle. Warum wird 
dann von FFs nicht der Wert kurz danach gespeichert?
Und seltsamerweise dort auch bei dem dummy-shiftregister. Bei 820 ns 
wird nicht nur der Start des spi-bus verpennt, sondern es wird auch 
dummy nicht ins shift Register übernommen, obwohl das ja völlig 
unabhängig vom spi ist.


Wahrscheinlich ist mein Verständnisproblem albern wenn man es begriffen 
hat, aber ich komme irgendwie nicht mehr weiter. Weil solche Handshake 
und Trigger Signale ja nun aber früher oder später alle meine Module 
betreffen werden, wünsche ich mir da schon ein gewisses AHA-Verständnis.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Don Diego schrieb:
> Irgendwie wird also der Wert direkt NACH dem Schalttakt gespeichert....
> ?
Bitte nicht Plenken.

> WARUM ist mir immer noch nicht ganz klar, denn wenn bei 100 ns die
> Taktflanke kommt, die ja die FF schaltet die dummy speichern, ist bis
> DAHIN ja noch gar keine '1' da. Irgendwie wird also der Wert direkt NACH
> dem Schalttakt gespeichert.... ?
Dein Problem ist, dass du in der Testbench nicht den Takt zum 
Generieren deiner Signale nimmst, sondern eine Zeit. Und hier gibt es 
jetzt 2 mögliche Probleme:
1. Rundung
Durch die Berechnungen der Zeiten bekommst du Verschiebungen im fs 
Bereich und damit liegt das isl_dummy eben doch noch kurz vor dem Takt 
auf '1'.
2. Delta Time Delay und Zero Time Delay
Weil der Simulator nicht alles gleichzeitig berechnen kann, gibt es 
durchaus Abhängigkeiten, die auftreten können, wenn etwas zur selben 
Zeit passieren soll.
http://web.cecs.pdx.edu/~mperkows/CLASS_VHDL_99/tran888/lecture004-timing-and-simulation.pdf
http://dea.unsj.edu.ar/sda/31_DeltaTime_Concept.pdf

Lösung:
Mach alle Signalaktualisierungen in der Simulation abhängig vom Takt. 
Denn von diesem hängen Sie in der Realität auch ab.
Schreib statt so...:
1
  dummy : process
2
  begin
3
    wait for isl_clk_period*5;
4
    isl_dummy <= '1';
5
    wait for isl_clk_period;  
6
    isl_dummy <= '0';
7
    :
... einfach so:
1
  dummy : process
2
  begin
3
    wait for rising_edge(isl_clk);
4
    wait for rising_edge(isl_clk);
5
    wait for rising_edge(isl_clk);
6
    wait for rising_edge(isl_clk);
7
    wait for rising_edge(isl_clk);
8
    isl_dummy <= '1';
9
    wait for rising_edge(isl_clk);
10
    isl_dummy <= '0';
11
    :

: Bearbeitet durch Moderator
von Don Diego (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort, werde ich heute Abend etwas mit rum 
experimentieren wenn meine Kinder kooperativ sind ;-)

P.S. Hatte groß geschrieben, um im Text etwas von der Betonung der 
Stimme rüber zu bringen. Tschulligung.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Don Diego schrieb:
> P.S. Hatte groß geschrieben, um im Text etwas von der Betonung der
> Stimme rüber zu bringen.
Das passt schon, der angemängelte Plenk sitzt am Ende des Satzes, war 
nur ein Ausreißer und den davor stehenden Punkten geschuldet...
https://de.wiktionary.org/wiki/plenken
https://de.wikipedia.org/wiki/Plenk

> werde ich heute Abend etwas mit rum experimentieren
Viel Spass dabei  ;-)

von Don Diego (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hallo Lothar,

ich hatte nicht exakt die Zeit die ich gehofft hatte, aber ich ein 
kleines Zeitfenster gab es.

Zum Auflösen meiner Konfusion hat es aber nicht beigetragen. Wenn ich 
mir den screenshot anschaue, dann wird osl_ss gesetzt und zwar nicht 
dann wenn bei 40 ns die steigende Flanke des Taktes kommt (und die 
Testbench isl_tx_en auf '1' setzt), sondern erst bei der nächsten 
steigenden Flanke.

In meiner Welt hatte ich mir die ganze Geschichte zu zusammengereimt, 
dass ein FF den Wert direkt nach der Schaltflanke speichert. Wenn nun 
bei 40 ns der Takt kommt und isl_tx_en='1' ist wird der prozess doch das 
in idle erkennen und in quasi Zeit 0 durchlaufen. Dann sollte doch auch 
gleichzeitig osl_ss kommen?

Die Erklärung mit Rundungsfehlern ist plausibel, wenn in meinem 
ursprünglichen Beispiel das ganze minimal vor 40 ns gesetzt würde.

Ich wäre sehr dankbar wenn mir jemand meine Verwirrung nehmen könnte.

von Don Diego (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Oder andersrum gesagt: ich dachte dass bei der Zuweisung osl_ss='1' und 
später osl_ss='0' eben '0' überschreibt.
Ist da jetzt ein Takt Latenz drinnen, oder habe ich die FF falsch 
verstanden?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Don Diego schrieb:
> Wenn nun bei 40 ns der Takt kommt und isl_tx_en='1' ist wird der prozess
> doch das in idle erkennen und in quasi Zeit 0 durchlaufen.
Von 30ns bis 40ns ist die FSM im Zustand sample...

> dass ein FF den Wert direkt nach der Schaltflanke speichert.
Ein Flipflop speichert wegen der Taktflanke. Dass in der Realität noch 
irgendwelche Laufzeiten dazukommen, interessiert in der 
Verhaltensimulation nicht.

> in quasi Zeit 0 durchlaufen.
Vergiss den Begriff "Zeit durchlaufen" in der Verhaltenssimulation. Dort 
passiert alles gleichzeitig. Du musst nur noch die passende Denkweise 
lernen... ;-)

Don Diego schrieb:
> Ist da jetzt ein Takt Latenz drinnen, oder habe ich die FF falsch
> verstanden?
Ja, vermutlich.
Du hast es so beschrieben, das passt alles: wenn du in idle bist und 
vor der Taktflanke das Signal isl_tx_en='1' anliegt, dann wird durch 
den Takt eine Aktion osl_ss<='0' ausgelöst.

Und eins noch: fang jetzt nicht mit einer Timingsimulation an. Dort 
hättest du zwar irgendwelche Laufzeiten mit drin, die sind aber 
prinzipiell unnötig und du wirst andere seltsame Effekte wie z.B. lange 
Simualtionszeiten und wegoptimierte Signale bekommen.

BRW: wie erzeugst du den isl_clk? Doch nicht mit einem Taktteiler?

von Don Diego (Gast)


Bewertung
0 lesenswert
nicht lesenswert
isl_clk ist ja nur der fiktive Takt aus dem Simulator. Einen 'echten' 
Takt gibt es (noch?) nicht, falls du das meinst. Ich denke eine Hardware 
brauche ich derzeit nicht wenn ich irgendwie zu blöd bin mit 
Simulationen zurecht zu kommen. Also würde ja sowiso nix funktionieren 
und auf einen Lerneffekt hoffe ich derzeit ohne Hardware.

Stelle aber fest, dass ich versucht habe, mir ein falsches Bild auf zu 
zwingen: Taktflanke speichert Zustand der davor anlag - soweit korrekt? 
Das wäre doch erst mal ein kleiner Schritt und mein Mantra für heute.

Ich bedanke mich recht herzlich!


P.S. Wenn ich einen Prozess habe der irgendein Steuersignal setzt. Dann 
kann ich davon ausgehen, dass jeder andere Prozess mit Takt das Signal 
einen Takt später registrieren kann und wenn das Steuersignal direkte 
Auswirkungen haben soll, muss das eine Kombinatorik sein?

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Don Diego schrieb:
> Stelle aber fest, dass ich versucht habe, mir ein falsches Bild auf zu
> zwingen: Taktflanke speichert Zustand der davor anlag - soweit korrekt?
Ja, das ist der Knackpunkt.

Und so läuft es in der realen Hardware auch: da kommt eine (z.B. 
steigende) Takflanke, dann herrscht Hektik im FPGA, weil neue Zustände 
ermittelt werden. Und rechtzeitig vor der nächsten (z.B. steigenden) 
Taktflanke müssen die stabil sein, damit das Spiel von Neuem losgehen 
kann. Also immer Takt-Hektik-Pause-Takt-Hektik-Pause.

Und in der Verhaltenssimulation ist die Hektik einfach nur unendlich 
kurz und die nachfolgende Pause einen Takt lang. Der Rest bleibt gleich. 
Deshalb wird ein Design, das in der Verhaltenssimulation korrekt läuft 
auch in der Realität laufen, solange mindestns noch Ziet für eine kurze 
Pause vor der nächsten Taktflanke ist...

(Ausnahmen bestätigen hier wie üblich nur die Regel... ;-)

: Bearbeitet durch Moderator

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]
  • [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.