Forum: FPGA, VHDL & Co. CPLD/FPGA syncron/asyncron ?


von Andreas Kratzsch (Gast)


Lesenswert?

Hallo,

wenn ich mir die verschiedenen Application Notes von Xilinx
so ansehe wird in der einen ein absolut syncrones Design verlangt,
in der nächsten steht daß möglichst nicht alle Outputs gleichzeitig
umschalten sollen.

Nach meinem Verständnis führt das syncrone Design aber doch gerade
dazu daß alle Umschalt Vorgänge genau gleichzeitig ablaufen (sollen) ?

Welche der Application Notes soll ich denn nun berücksichtigen
und welche nicht ?

Xilinx app note 784:
3. Use strict synchronous design.
Most college textbooks on sequential design praise the merits of
synchronous design. Yet,
many designers fail to heed the advice. Synchronous design is
essentially simple. With
synchronous design, there is a single clocking event. In a synchronous
design, there is
either a rising edge clock, or a falling edge clock, but not both. ...
usw.

Xilinx app note 112 Desing with XC9500XL CPLDs:
High Speed Design Considerations
...
2. Minimize the number of outputs switching simultaneously.
usw.


Kann man es noch als syncrones Design bezeichnen wenn man
verschiedene clock Frequenzen benutzt die aber fest
voneinander abgeleitet (geteilt) sind ?
100MHz (RAM)
50MHz
25MHz (VGA)
usw.

Andreas

von FPGA-User (Gast)


Lesenswert?

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.

von Andreas Kratzsch (Gast)


Lesenswert?

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

von Tom (Gast)


Lesenswert?

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?!?

von Stephan Walter (Gast)


Lesenswert?

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).

von Tom (Gast)


Lesenswert?

@ 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

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.