VHDL Signaländerung bei Taktflanke

[Jonathan J. (Gast)]

Das ist eine absolute anfängerfrage. Ich bin etwas verwirrt bei 
registered Logik. Wenn ich Daten verarbeitet ändern die sich in der 
Simulation quase mit einer steigenden taktflanke. Dann hätte ich ja zum 
Beispiel beim lesen von Rom werten, was ein Zyklus dauert und 
anschließender Addition mit etwas festem immer signaländerun zur Flanke.

Gibt das nicht Probleme im realen fpga?

[Fpgakuechle K. (Gast)]

Jonathan J. schrieb:

> Gibt das nicht Probleme im realen fpga?

Nö.
Dier ist der Unterschied zwischen Signal-propagation und -änderung nicht 
klar.

Klar wird beim ROM bei jeden Takt der Wert aus der Speicherzelle zum Bus 
propagiert. Aber wenn sich die angelegete Adresse nicht ändert, ändert 
sich auch nichts an dem ausgegebenen Wert.

[Jonathan J. (Gast)]

Das mit dem Rom war jetzt nur ein Beispiel. Wenn ich Daten vom 
vorherigen entity entgegennehme, beide die gleiche clock, dann ändert 
sich der Ausgangswert des ersten entity während das zweite liest. Das 
führt doch zu Problemen.

[Fpgakuechle K. (Gast)]

Jonathan J. schrieb:
> Das mit dem Rom war jetzt nur ein Beispiel. Wenn ich Daten vom
> vorherigen entity entgegennehme, beide die gleiche clock, dann ändert
> sich der Ausgangswert des ersten entity während das zweite liest. Das
> führt doch zu Problemen.

Nö, das führt zur Takt-Latency: Was die Source-Entity im Takt 1 in ihrem 
outputregister ausgibt, kann die Destination-entity erst im Takt 2 in 
ihr input-register übernehmen.

Vielleicht wird es klarer, wenn Du dir pipelining anschaust:

https://arstechnica.com/features/2004/09/pipelining-2/4/
https://www.dauniv.ac.in/public/frontassets/coursematerial/computer-architecture/CompArchCh06L02PipeLinePerformance.pdf

die nachfolgende Stufe liest bei einem FF zwischen den Stufen, wen wert 
den die vorhergehende Stufe einen Takt vorher reingeschrieben hat.

Das das so im FF (FLipflop) funktioniert, gibt es spezielle 
Schaltungsstrukturen dafür, JK-FF oder mAsterSlave-FF. aber das muss nur 
ein Schaltungstechniker wissen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jonathan J. schrieb:
> Wenn ich Daten vom vorherigen entity entgegennehme
Meine Vermutung: du hast vorher C (oder sontwas Prozedurales) 
programmiert und willst jetzt VHDL "programmieren"? Das geht schief.

Ein Hardwaremodul nimmt nichts von einem anderen Hardwaremodul 
"entgegen", sondern die beiden Module sind miteinander verdrahtet und 
haben innen drin ebenfalls eine Hardware, die irgendwie verdrahtet ist. 
Und diese Hardware beschreibst du mit VHDL.

> Wenn ich Daten vom vorherigen entity entgegennehme, beide die gleiche
> clock, dann ändert sich der Ausgangswert des ersten entity während das
> zweite liest.
Und rechtzeitig vor dem nächsten Takt muss alles wieder stabil sein, 
dass die vielen Flipsflops definierte Werte übernehmen können.

> Das führt doch zu Problemen.
Du bist bei solcher taktsynchroner Übergabe immer "einen Takt später" 
dran. Dieses Verhalten nennt sich Latency. Und Probleme bringt das nur, 
wenn man diese Latency nicht beachtet hat oder sie nicht haben darf.

[Fpgakuechle K. (Gast)]

Fpgakuechle K. schrieb:

> Das das so im FF (FLipflop) funktioniert, gibt es spezielle
> Schaltungsstrukturen dafür, JK-FF oder mAsterSlave-FF. aber das muss nur
> ein Schaltungstechniker wissen.

Anbei wie so ein JK-FF arbeitet. Das Geheimnis ist die interne 
aufteilung in zwei Stufen. Die Seiten sind aus dem HS-Lehrbuch Seifart: 
"Digitale Schaltungen"

[M. Н. (Gast)]

Jonathan J. schrieb:
> Wenn ich Daten vom
> vorherigen entity entgegennehme, beide die gleiche clock, dann ändert
> sich der Ausgangswert des ersten entity während das zweite liest. Das
> führt doch zu Problemen.

Jein. Deine Kette sieht ja so aus:

FF-Ausgang -> Irgendwelche optionale Logic -> FF Eingang

Beide Flip-Flops werden mit dem identische Takt versorgt. Natürlich hast 
du recht, dass in erster Näherung der Ausgang zur Flanke gesetzt wird 
und gleichzeitig gelesen wird. Du hast aber immer verschiedene 
Verzögerungen in deinen Ketten.

1) Der Druchlauf von Eingang des FF zum Ausgang bei einer Taktflanke ist 
nicht instantan. Es dauert eine Zeit, bis der Ausgang umschaltet.
2) Die Logic / Routing zwischen deine Flip-Flops benötigt Zeit.

Das führt dann dazu, dass im "empfangenden" FF der Wert der 
vorangegangen Taktes gesampled wird.

Das Tooling muss dann bei der Synthese/Place&Route entsprechend alles so 
miteinander verwursten, dass die Setup & Hold Zeiten eingehalten werden.

Es ist bspw. in einem Asic durchaus so, dass Flip-Flops nicht direkt 
aneinander gekettet werden können, da sonst die Sample/Hold-Zeiten 
verletzt werden (Eingangssignal ändert sich zu schnell). Deshalb werden 
dann spezielle Delay-Zellen eingefügt, deren einziger Nutzen es ist, das 
Signal zu verzögern. Im FPGA ist das etwas anders, da das Routing 
deutlich mehr Zeit benötigt und auch jedes FF durch die Struktur der 
Logikelemente deutlich mehr Overhead an Ein- und Ausgang hat.

[Jonathan J. (Gast)]

OK das habe ich nun verstanden. Das heißt also ich nutze die endliche 
Signallaufzeit. Macht das synthesetool sowas für mich und beachtet die 
sample hold Zeit wenn ich die Taktfrequenz definiere oder muss ich für 
jede Stufe bestiegen wie das timing ist?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jonathan J. schrieb:
> muss ich für jede Stufe bestiegen wie das timing ist?
Du musst der Toolchain nur sagen, welchen Takt du im System verwenden 
willst. Und die Toolchain sagt dir dann, ob sie es geschafft hat, deinen 
Wunsch zu erfüllen.

M. H. schrieb:
> Im FPGA ist das etwas anders
Der FPGA Hersteller garantiert, dass seine Taktstruktur so ausgelegt 
ist, dass ein synchrones Design prinzipiell funktioniert, die nötigen 
Setup und Hold-Zeiten eingehalten werden und deshalb keine 
"Race-Condition" und kein "Fall-Through" auftreten. Hier hatte ich das 
schon mal ausgeführt:
Beitrag "Re: Zum Artikel in Sachen Taktung von FPGAs."

[J. S. (engineer)]

Jonathan J. schrieb:
> Das mit dem Rom war jetzt nur ein Beispiel. Wenn ich Daten vom
> vorherigen entity entgegennehme, beide die gleiche clock, dann ändert
> sich der Ausgangswert des ersten entity während das zweite liest. Das
> führt doch zu Problemen.

Nein, weil in realer Physik immer ein Zeitversatz besteht. Das, was aus 
einem Block herauskommt, ist erst in Änderung, wenn der Takt schon 
geschaltet hat. Damit reicht eine minimale Verzögerung der Leitung schon 
aus, damit da nichts schief geht. Die FFs sind dafür ausgelegt. Das 
einzige was passiert, sind nicht gleichzeitig schaltende FFs, weil der 
Takt ungleichmäßig belastet ist. Das wird durch die Konstruktion des 
FPGAs auf Halbleiterebene entschärft und ist bekannt.

Damit bleibt nur die generelle Taktunsicherheit nach vorn und nach 
hinten durch Jitter, in die alles hineingerechnet wird und welche von 
den Werkzeugen berücksichtigt werden muss. Das Hauptproblem sind aber 
nicht zu schnell schaltenden Schaltungen bei zu langsamem Empfänger, 
sondern zu lange Pfade und damit zu späte Signaländerungen.