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
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.