| INDEX... |
|
|
|
|
|
|
|
|
|||
|
|
|
||
Um Verzögerungszeiten von (realen) Gattern "unschädlich" zu machen, arbeitet man beim Entwurf digitaler Schaltungen mit einem Takt. Diese sog. synchronen Schaltungen erledigen alle "Berechnungen" (d.h. Änderungen der Ausgänge und internen Zustände als Folge von internen Zuständen und Eingängen) nur zu einem ganz bestimmten Zeitpunkt, nämlich zur Takt-Flanke (steigend oder fallend).
Dies bedeutet, daß alle Eingangssignale Zeit haben, sich bis kurz vor der Flanke zu stabilisieren und die Reaktion darauf kurz nach der Flanke erfolgt. Allerdings bedeutet das auch, das mit der Taktung eine Verzögerung der Reaktion (eben bis zur nächsten Flanke) einhergeht. Dies sollte man immer beachten.
Beispiel (nur Kernteil, Reset und Entity/Architekture fehlen)
Ein Zähler, der bei jeder steigenden Flanke von CLK weiterzählt
und gleichzeitig
mit Zählerstand 5 (0101) das Signal ist_5 setzen soll:
NR1:
process
-- nicht ganz korrektes Beispiel
begin
wait until clk='1';
n<=unsigned(n)+1;
if n="0101" then
ist_5<=´1´;
else
ist_5<=´0´;
end if;
end process;
Wenn man das mit einer Verzögerung zwischen CLK und den Ausgängen simuliert, entsteht folgendendes:

Wie man sieht, dauert es etwas, bis die Reaktion der Ausgangsignale auf die steigende Takt-Flanke erfolgt.
Aber: Warum kommt IST_5 einen Takt zu spät?
Dies kommt daher, daß N ein Signal ist! Das heißt, zur Auswertung der <= Zuweisungen für die rechte Seite werden alle aktuellen Signalwerte erst mal eingefroren. Dies simuliert die "Gleichzeitigkeit" der Berechnungen. Die Zuweisungen der neuen, berechneten Werte erfolgt erst, wenn man wieder auf ein wait (oder ein end process) trifft. Für das Beispiel heißt das, daß der Vergleich auf 5 mit dem Wert von N vor der Erhöhung erfolgt. Damit entsteht die unerwünschte Verzögerung um einen Takt.
Korrektes Beispiel also:
process
begin
wait until clk='1';
n<=unsigned(n)+1;
if n="0100" then --
Vergleich auf 4
ist_5<=´1´;
else
ist_5<=´0´;
end if;
end process;
Dies würde bei der Logiksynthese zu folgender Schaltung führen,
dabei ist der aktuelle Wert
von N rot hervorgehoben:

Das obere Flipflop hat am Eingang D den "aktuellen Zählerstand+1", dieser wird mit der steigenden Takt-Flanke auf den Ausgang Q gegeben. Gleichzeitig wird der "Vergleich auf den aktuellen Zählerstand mit 4" auf den Eingang für das untere Flipflop gelegt. Nach der steigenden Takt-Flanke gelangt dieses (zur selben Zeit wie das "neue" N) auf den Ausgang.
Wenn nun mehrere Prozesse bzw. Komponenten mit Signalen miteinander kommunizieren, ist diese Takt-Verzögerung natürlich auch da.
Ein zweiter Prozess, der immer den Zählerstand N intern
abspeichern soll, wenn IST_5 ´1´ ist, sieht so aus:
NR2:
process
begin
wait until clk='1';
if ist_5='1' then
speicher<=n;
end if;
end process;
Was ist jetzt dann in SPEICHER, wenn IST_5 ´1´ wurde? Und wann ist dieser Wert verfügbar?
Lösung:

Der Zeitpunkt der Übernahme ist mit mit roten Punkten markiert. Wie man sieht, wird zwar der Wert 5 abgespeichert, allerdings ist er intern mit einem Takt Verzögerung gegenüber IST_5 verfügbar.
In obigen Diagrammen wurde immer davon ausgegangen, daß die Reaktion auf den Takt verzögert erfolgt. Dies stimmt natürlich in der realen Welt. Zudem ist in den Diagrammen damit auch Ursache (Takt-Flanke) und Wirkung erkennbar.
Ohne Zeitverzögerung (d.h. bei der normalen Simulation) sieht dies nicht mehr so klar aus:

Jetzt ist eigentlich nicht mehr so ganz einsichtig, wo die "Übernahmepunkte" sind und warum bis auf die fehlende Verzögerung immer noch derselbe Ablauf da ist. Verständlich wird es, wenn man in Gedanken die Verzögerung unendlich klein werden läßt. Dann verschiebt sich die Reaktion zwar immer näher an die steigende Flanke heran. Allerdings sind genau zum Entscheidungszeitpunkt (steigende Flanke) immer noch die Eingangswerte gültig, d.h. die Berechnungen ergeben immer dieselben Werte.
Für Interessierte:
Machen wir das Gedankenspiel umgekehrt, die Verzögerung werde größer: Irgendwann erfolge die Reaktion zu spät vor der nächsten Flanke, d.h. es werden alte Werte übernommen. Dann gibt es ein großes Problem: Zähler "verschlucken" sich, Zustandsautomaten fallen in ungültige Zustände; mit anderen Worten: Die Schaltung versagt total. Die Verzögerung kann gemeinerweise nur einzelne Pfade betreffen, z.B. die Übertragslogik eines Addierers.
Wenn dies auftritt, muß man die Schaltung so optimieren, daß
die Verzögerungszeit dieser kritischen Pfade kleiner als die Taktperiode
wird. In der Realität muß das Signal bereits etwas vor der Flanke
stabil sein (sog. Setup-Zeit), weil das reale Flipflop neben der Verzögerung
(Takt->Ausgang) eine gewisse "Trägheit" besitzt.
| Georg Acher |
Last Update: 2000-09-30
|