CPLD/FPGA syncron/asyncron ?

Hallo,

ob es synchron ist, hängt davon ab, wie Du die Clocks verwendest.
Wenn Du mit einem Taktteiler aus Clock A einen Clock B generierst
und diesen dann wieder auf Takt-Eingänge von Flip-Flops legst dann
ist es NICHT synchron.
Wenn alle Flip-Flops am Takt A hängen und der Taktteiler ein Clock-
Enable erzeugt, dann ist es sehr wohl synchron.
Wenn 3 verschiedene Clocks aus einer DCM oder PLL generiert werden,
dann sind diese auch synchron.

Natürlich schalten bei einem synchronen Design viele FFs zur selben
Zeit, das ist kein Problem. Bei den I/Os kommt dazu, dass diese evt.
richtig Strom liefern müssen. Wenn z.B. ein Datenbus (64 bit)
von 0x0000000000000000 auf 0xFFFFFFFFFFFFFFFF umschaltet, dann fließt
richtig Strom (kurzzeitig). Wenn dann nicht alles richtig abgeblockt
ist oder die Masse zu schwach ist, gibts Probleme, aber dem kann man
durch entspr. Layout und ausreichend Block-Cs vorbeugen.

Synchrone Designs sind ein Muss, wenn man erfolgreich FPGAs
programmieren möchte.

Hallo,

danke, das hilft mir weiter !

Dann kann ich vom DCM 2 clocks erzeugen lassen (100 und 50 MHz)
und diese mit einem syncronen Teiler auch noch weiter teilen.
Das löst alle Probleme.

Andreas

Wenn ich das mit der "Einsynchronisierung" von Signalen richtig
verstanden habe, dann erhalte ich doch ein synchrones Design, wenn ich
die externen Signale mit einer hochfrequenten Clock (von Clockunit/FPGA
oder mit einer ebenfalls externen hochfrequenten Systemclock) einlese.

D.h. es wird mit "rising_edge(clk)" (Systemclock) die ansteigende
Flanke des extern angelegten Signals mit "if ext_Sig_tmp1 ='1' and
ext_Sig_tmp2 = '0'" abgefragt und bei TRUE erfolgt die weitere
Verarbeitung des Codes innerhalb der if-Schleife, die dann synchron zur
Systemclock erfolgt.

Was ist aber, wenn ich aus dem externen Signal ein weiteres Signal mit
halber Frequenz ableite. Ist das dann mit meinem og
Synchronisiermechanismus noch synchron?!?

Eigentlich müßte es doch so sein, oder?!?

Ein asynchrones Signal sollte zu einsynchronisieren nur auf ein FF
führen. Wenn es parallel auf zwei FF führt, kann es zu Inkonsistenzen
kommen. Wenn sich das Signal in der Setup Time des FFs ändert, kann es
sein, dass das eine FF noch eine '0' sieht, das andere aber schon die
'1'.
Also: Signal auf ein FF, dann alle weiteren benötigten Signale daraus
ableiten.
Besser ist noch: Mit zwei FFs einsynchronisieren: Wegen der
Metastabilität (mal danach suchen! habe ich zu Anfangs auch nicht
geglaubt, dass sowas Probleme machen kann) ist es möglich, dass das
erste FF für eine (un)gewisse Zeit keinen gültigen Zustand hat, wenn
sich der Eingang nahe der Taktflanke ändert. Das zweite FF verschafft
dem ersten sozusagen eine Periode des Taktes Zeit, sich für einen
Zustand zu entscheiden (Settling Time).

@ Stefan:
Habe diese Einsynchronisierungsvariante mit 2 FF in meinem Design
beachtet (Dank für diesen Tipp nochmals an FPGA-User).
Sieht ia so aus:
..
Signal Sign_Tmp1 <= std_logic;
Signal Sign_Tmp2 <= std_logic;
..
if rising_edge(clk) then
 if (reset = '0') then
  ..
  ..
 else
  Sign_Tmp1 <= ext_Signal;
  Sign_Tmp2 <= Sign_Tmp1;
  ..
  ..
 if (Sign_Tmp1 = '1' and Sign_Tmp2 = '0') then
  ..
  ..

Mit der letzten if-Abfrage ist die Einsynchronisierung erfolgt...

Leider bringt diese Art der Einsynchronisierung auch Delay mit sich.
Ich  programmiere momentan eine Schnittstelle  an die zwei
Kommunikationsmodule angeschlossen werden und deren Transceiver erst
nach interenen Synchronisierungssignal aktiviert werden.

Derzeit bin ich mir nicht ganz sicher, in wie weit mir der
Einsynchronisierungs-Delay von den jeweiligen Bitclocks zur
Transmission der Daten und den internen Framesyncs mir Ärger ins Haus
bringt....

Gruß
Tom