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
waituntilrising_edge(isl_clk);
4
slv_dummy_sr<=slv_dummy_sr(2downto0)&isl_dummy;
5
endprocessDUMMY_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.
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.pdfhttp://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...:
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.
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/plenkenhttps://de.wikipedia.org/wiki/Plenk> werde ich heute Abend etwas mit rum experimentieren
Viel Spass dabei ;-)
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.
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?
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?
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?
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... ;-)
Thread beobachten
Seitenaufteilung abschalten