Forum: Mikrocontroller und Digitale Elektronik Wieso funktioniert der Synchronzähler?


von Kranto (Gast)


Angehängte Dateien:

Lesenswert?

Kann mir irgendwer erklären wieso der Synchronzähler funktioniert?

Ok das erste FF ist mir klar. Das zweite aber nicht mehr ganz:
So hab ich das verstanden:

1. Taktflanke: erstes FF kippt auf eins, da es aber ein prop delay gibt 
hat das zweite FF diesen einser verpasst.
Jetzt liegt aber schon fix ein einser am Ausgang Q0 an

2. Taktflanke: erstes FF kippt auf 0 , da aber prop delay kippt das 
zweite FF auf eins um aufgrund des vorigen einsers auf Q0

also habe ich jetzt:
1.Tkt: 100
2.Tkt: 010

3.Taktflanke: erstes kippt wieder auf 1, zweites bleibt aber aufgrund 
des prop delays auf 1, so ergibt sich der zählstand 3

also
1.Tkt: 100
2.Tkt: 010
3.Tkt: 110

4.Taktflanke: erstes kippt auf 0, zweites kippt auf 0 und drittes kippt 
auf 1 aufgrund des prop delays...


Habe ich das so richtig verstanden, dass der Zähler nur funktioniert 
weil die FF nicht ideal sind?

von Daniel S. (supernova01)


Lesenswert?

>>prop delay

was soll das sein?

>>nicht ideal

was soll das heißen?

Es ist zur Zeit nicht klar was du darunter verstehst...

DS

von Klaus (Gast)


Lesenswert?

Kranto schrieb:
> Habe ich das so richtig verstanden, dass der Zähler nur funktioniert
> weil die FF nicht ideal sind?

Nein! Ein ideales FF hat genau diese Eigenschaft, eben der Wert vor 
der Taktflanke zu übernehmen. Ob sich die Eingänge nach der Flanke 
ändern ist egal.

In real musst du bei den FF 3 Zeiten beachten: die Setup, Hold und clock 
to output time. Bei idealen Flipflops wären die alle 0.

von Kranto (Gast)


Lesenswert?

Dennis S. schrieb:
> was soll das sein?

propagation delay (durchlaufzeit)

Dennis S. schrieb:
> was soll das heißen?

Naja angenommen die FF Durchlaufzeit betrage 0 sekunden, die Haltezeit 0 
Sekunden und die vorbereitungszeit 0 Sekunden.

Kranto schrieb:
> 1. Taktflanke: erstes FF kippt auf eins, da es aber ein prop delay gibt
> hat das zweite FF diesen einser verpasst.
> Jetzt liegt aber schon fix ein einser am Ausgang Q0 an

Hier würde dann das gekippte Signal nach 0 Sekunden schon noch während 
der Taktflanke am Ausgang Q0 anliegen und somit auch auf J und K des 
zweiten FlipFlop was bedeuten würde, dass das zweitezeitgleich mit dem 
ersten kippt und das wäre ja dann kein Zähler...

von MaWin (Gast)


Lesenswert?

> Habe ich das so richtig verstanden, dass der Zähler nur funktioniert
> weil die FF nicht ideal sind?

Ja, es müssen sogenannte Master Slave FlipFlops sein, oder die 
Durchlaufzeit muß garantiert länger sein als die JK Haltezeit.

Bei unendlich schnellen Bauteilen klappt das nicht.

von Klaus (Gast)


Lesenswert?

Kranto schrieb:
> Hier würde dann das gekippte Signal nach 0 Sekunden schon noch während
> der Taktflanke am Ausgang Q0 anliegen und somit auch auf J und K des
> zweiten FlipFlop was bedeuten würde, dass das zweitezeitgleich mit dem
> ersten kippt und das wäre ja dann kein Zähler...

Nein, denn in einer idealen Welt ist die Taktflanke auch nur exakt 0 
Sekunden lang. Das heißt, beide FFs erkennen gleichzeitig die Flanke. 
Danach gibt das erste FF das geänderte Signal aus. Aber da ist die 
Taktflanke schon vorbei und das zweite FF tut nichts mehr.

Du hast in einer idealisierten Welt zwar Verzögerungszeiten von 0, aber 
das ändert nicht an der Abfolge der Ereignisse! Sachen, die in einer 
bestimmten Reihenfolge passieren, tun dies auch weiterhin, auch wenn du 
die Ereignisse theoretisch unendlich schnell aufeinander folgen lässt.

1) Es kommt die Taktflanke
2) Die FFs geben einen neuen Wert aus
3) Der neue Wert liegt an den FF Eingängen an
4) Hier kannst du nicht einfach wieder zu 1) springen, auf wenn seit dem 
nur eine unendlich kleine Zeitspanne vergangen ist. Es gilt immer 
Ursache --> Wirkung. Und nicht umgekehrt ;-)

von Kranto (Gast)


Lesenswert?

MaWin schrieb:
> Ja, es müssen sogenannte Master Slave FlipFlops sein, oder die
> Durchlaufzeit muß garantiert länger sein als die JK Haltezeit.
>
> Bei unendlich schnellen Bauteilen klappt das nicht.

DAAAAAAAAAAAAAANKE!!! Bis vor kurzem dachte ich ich verstehe den 
Synchronzähler nicht!

von Kranto (Gast)


Lesenswert?

Klaus schrieb:
> Es gilt immer
> Ursache --> Wirkung. Und nicht umgekehrt ;-)

Naja man kanns so oder so drehen. Ich hab auch nicht unrecht, denn du 
begründest dein Argument damit, dass DU weißt was ein Ereignis ist. Das 
FF weiß das aber nicht. Ich nehme auch an alle Simulatoren gehen so vor 
wie du, es ist auch nicht falsch, man kann es aber auch anders sehen...

Danke aber!!

von Klaus (Gast)


Lesenswert?

MaWin schrieb:
> Ja, es müssen sogenannte Master Slave FlipFlops sein, oder die
> Durchlaufzeit muß garantiert länger sein als die JK Haltezeit.
>
> Bei unendlich schnellen Bauteilen klappt das nicht.

Klar klappt das. Macht man in jeder RTL-Simulation so. Um die Kausalität 
dabei sicherzustellen, nimmt man sogenannte Delta-Delays. Eine 
theoretische Verzögerung von 0 Sekunden. Damit ist in der Simulation 
sichergestellt, das ein Ereignis zwar zum gleichen Zeitpunkt, aber 
trotzdem nach dem vorherigen bearbeitet wird.

von Peter A. (Gast)


Lesenswert?

MaWin schrieb:
> Bei unendlich schnellen Bauteilen klappt das nicht.

Für das Taktsignal gilt das Umgekehrte.

Allzu "nicht-ideal" darf dieses allen FlipFlops parallel zugeführte 
Signal nicht werden:

Mit geringer werdender Flankensteilheit des Taktsignals wird der Zähler 
irgendwann zum "Zufallsgenerator", desen Zustandsfolge von den 
Streuungen der Taktschaltschwelle der einzelnen Elemente abhängt.

Um das zu verhindern sollen laut diesem Phillips-Dikument die Anstiegs- 
und Abfallzeiten des Taktes kleiner sein als das doppelte der 
Laufzeitverzögerung (Seite 12, Abschnitt 3.6):

http://www.nxp.com/documents/other/HCT_USER_GUIDE.pdf

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.