FPGA Takt- und Flipflop-Verständnisfrage

Dosmo Gast #2466111
Lesenswert?
• ▲
▼ 
Hallo,

ich hab mal eine grundsätzliche (wahrscheinlich ziemlich doofe, sorry) 
Verständnisfrage zu Takt und Flipflop-Laufzeit im FPGA.

Angenommen, ich habe ein Signal, das mit der steigenden Taktflanke 
geschrieben und gelesen wird:
1
signal mySignal : std_logic := '0';

2


3
signal_schreiben: process(CLK)

4
begin

5
  if (rising_edge(CLK)) then

6
    if (Bedingung) then

7
      mySignal <= '1';

8
    else 

9
      mySignal <= '0';

10
    end if;

11
  end if;

12
end process;

13


14
signal_lesen: process(CLK)

15
begin

16
  if (rising_edge(CLK)) then

17
    if (mySignal = '1') then

18
    ...

19
    end if;

20
  end if;

21
end process;


Dann würde ich erwarten, daß
- "mySignal" als FlipFlop realisiert wird,
- dieses FlipFlop mit der steigende Flanke von CLK getriggert wird,
- der Ausgang dieses Flipflop den Eingangswert zum Zeitpunkt "Taktflanke 
+ Gatterlaufzeit" annimmt,
- die Gatterlaufzeit des Flipflops wahrscheinlich sehr klein ist.

Wenn ich nun dieses Signal mit der gleichen Taktflanke lese, laufe ich 
dann nicht Gefahr, daß das Einlesen des Flipflop-Ausgangs durch die 
nachfolgende Logik noch nicht 100%ig abgeschlossen ist, wenn sich der 
Flipflop-Ausgang aufgrund der aktuellen Taktflanke ändert?
Oder ist der Takt (bzw. die Einlese-Zeit) so schnell, daß das sicher 
ausgeschlossen werden kann?
Oder sehe ich da etwas grundsätzlich falsch?

(So rein vom Gefühl her hätte ich gedacht, daß es sinnvoller ist z.B. 
immer nur mit steigenden Takt zu lesen
und immer nur mit fallender Flanke zu schreiben.)

Danke,

Dosmo
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Duke Scarring Gast #2466134
Lesenswert?
• ▲
▼ 
Dosmo schrieb:
> Wenn ich nun dieses Signal mit der gleichen Taktflanke lese, laufe ich
> dann nicht Gefahr, daß das Einlesen des Flipflop-Ausgangs durch die
> nachfolgende Logik noch nicht 100%ig abgeschlossen ist, wenn sich der
> Flipflop-Ausgang aufgrund der aktuellen Taktflanke ändert?
Nein.

Der Zustand Deines FF ändert sich mit der steigenden Taktflanke.
Mit der gleichen Flanke wird der Wert des FF verwendet. Und zwar der 
Wert, der vor der Flanke im FF gespeichert war.

Jetzt hat sämtliche (kombinatorische) Logik Zeit bis zur nächsten 
Flanke. Denn da müssen die neuen Werte kurz vorher stabil sein (je nach 
setup-time).

Duke
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lothar M. Moderator (Firma: Titel) Persönliche Seite #2466139
Lesenswert?
• ▲
▼ 
Dosmo schrieb:
> Wenn ich nun dieses Signal mit der gleichen Taktflanke lese, laufe ich
> dann nicht Gefahr, daß das Einlesen des Flipflop-Ausgangs durch die
> nachfolgende Logik noch nicht 100%ig abgeschlossen ist, wenn sich der
> Flipflop-Ausgang aufgrund der aktuellen Taktflanke ändert?
Nein. Diese "Race-Condition" ist dir durch den FPGA-Hersteller durch die 
korrekte Auslegung des Taktnetzes garantiert abgenommen. Ein bestimmter 
Pegel kann nicht einfach durch eine Flipflopkette "durchfallen". Das ist 
die Grundlage aller synchronen Designs.

> (So rein vom Gefühl her hätte ich gedacht, daß es sinnvoller ist z.B.
> immer nur mit steigenden Takt zu lesen
> und immer nur mit fallender Flanke zu schreiben.)
Gefühle können täuschen. Diese virtuelle Taktverdopplung ist unnötig.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
JBB Gast #2466146
Lesenswert?
• ▲
▼ 
Natürlich nicht, denn du liest ja den Ausgang des FF. Auch wenn sich der 
Eingang im theoretischen Moment des Taktes ändert, bleibt der Ausgang 
still.

Das ist das Wesensmerkmal der voll synchronen Schaltungen in FPGAs: Die 
Taktvorgänge sind so kurz und koheränt im Chip, dass sie allesamt 
abgeschlossen sind, bevor sich die FF-Information am Ausgang zeigt.

In ASICs kann man es etwas aufweichen und fordern, dass der Takt in der 
lokalen Zone, in der er benutzt wird, koheränt arbeitet. Damit kann man 
designs "von links nach rechts" bauen und die Taktflanken verschoben 
einsetzen. Die Informationsverarbeitung läuft dann wie ein Lauffeuer in 
einem langen Takt durch den Chip. Man kann es sogar so bauen, dass es 
mehrere Takte dauert und vorne schon wieder Neues eingespeist wird.

Ich bin aber nicht sicher, ob das heute bei den hohen Taktraten noch 
gemacht wird, weil a) nicht mehr nötig und b) schlecht zu valdieren.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren