Hallo zusammen, es wird immer von synchronen Design gesprochen. D.h alle FF sollen mit dem gleichen CLK betrieben werden. bei einem UART wird z.B. das Nutzsignal mit einer 16 fach höheren CLK abgetastet. Oder anders, das eigentliche Bit hat eine Breite von f/16. Ich hoffe das ist verständlich ausgedrückt. Wo drauf ich hinaus will ist die Xilinx App xapp339, "Manchester Encoder-Decoder". Wenn ich mir den Verilog Source anschaue (md.v) arbeiten die einzelnen Teile mit einem clk16x. Dieser wird über einen Counter durch 16 geteilt: always @(posedge clk16x or posedge rst) begin if (rst) cnt = 4'b0 ; else cnt = cnt + 1 ; end assign clk1x = cnt[3]; Später wird dieser neue Clock (clk1x) für weitere Module verwendet. always @(posedge clk1x or posedge rst) begin // do something here end Ist das die richtig Art, oder sollte man hier lieber mit einer Art Clockfreigabe arbeiten? always @(posedge clk16x or posedge rst) begin if (rst) cnt = 4'b0 ; else if (cnt < 16) cnt = cnt + 1; clk_en = 0; else cnt = 0; clk_en = 1; end always @(posedge clk16x or posedge rst) if (rst) begin // reset end else if (clk_en) begin // do something here end Ja ich weis, im Beispiel wir ein asynchroner RESET verwendet was auch nicht schön ist. Viele Grüße, Michael
Michael Fischer schrieb: > Wo drauf ich hinaus will ist die Xilinx > App xapp339, "Manchester Encoder-Decoder". Wenn ich mir den Verilog > Source anschaue (md.v) arbeiten die einzelnen Teile mit einem clk16x. > Dieser wird über einen Counter durch 16 geteilt: > Später wird dieser neue Clock (clk1x) für weitere Module verwendet. > Ist das die richtig Art, oder sollte man hier lieber mit einer Art > Clockfreigabe arbeiten? Du musst beachtet, dass sich diese Application Note auf CPLDs bezieht - dort ist das durchaus gängige Praxis. In FPGA sollte man aber die von dir beschriebene Version mit clock-enable Signalen bevorzugen, sonst hat man am Ende relativ große Probleme mit dem Timing. > Ja ich weis, im Beispiel wir ein asynchroner RESET verwendet was > auch nicht schön ist. Richtig, das sollte man im FPGA auch vermeiden. Hängt aber auch sehr vom Hersteller ab - Lattice hat in seinen FPGA beispielsweise einen (einen, nicht mehr!) globalen, asynchronen Resetpfad zu allen Komponenten.
Hallo Jan, Danke für die Erklärung. D.h. aber auch das ich auf der sicheren Seite bin wenn ich versuche bei CPLDs die gleiche Vorgehensweise zu benutzen wie bei FPGAs. Gruß, Michael
Na ja, ganz so hart würde ich mit diesem erzeugten Takt nicht ins Gericht gehen wollen. Es ist durchaus in Ordnung, innerhalb eines FPGA-Designs mehrere unterschiedliche Takte zu verwenden. Man muss nur wissen, was man da tut und die nötigen Maßnahmen an den Übergängen zwischen den Taktdomänen ergreifen. Aber dann ist das ok. Ein einzelner, schneller Takt der überall im Design nur zusammen mit einem Freigabesignal verwendet wird, kann auch mal nachteilig sein, z.B. bei der Leistungsaufnahme. Grüße, Harald
Harald Flügel schrieb: > Ein einzelner, schneller Takt der überall im Design nur zusammen mit > einem Freigabesignal verwendet wird, kann auch mal nachteilig sein, > z.B. bei der Leistungsaufnahme. Hmmm.... Gerade der Leistungsaufnahme ist es (relativ) egal, wie oft der Takt verwendet wird. Denn nur FFs, die tatsächlich schalten, brauchen auch Strom. Ok, ein wenig mehr Verluste hast du, wenn du statt nur 1/4 vom Taktnetz das ganze Taktnetz bestromen mußt, aber ich stelle hinter dieses Argument ein Fragezeichen. Allerdings muß ganz ohne Frage der letze Pfad von der Enable-Kombinatorik bis zu allen beteiligten FFs ausreichend schnell sein, dass ein Enable rechtzeitig/gleichzeitig an allen FFs ankommt. Und das kann bei einer unnötig hohen Taktfrequenz schon mal Probleme geben... (und hoffentlich war dann wenigtens das Clock-Constraint gesetzt)
>D.h. aber auch das ich auf der sicheren Seite bin wenn ich versuche bei >CPLDs die gleiche Vorgehensweise zu benutzen wie bei FPGAs. Ja, weil das Clk-Verteil-Problem bei CPLD/FPGA prinzip. das Gleiche ist. (Und man mit möglichst guter Clk-Verteilung u. Enab-Sign rel grossen Freiraum hat)
Hallo Harald, >Na ja, ganz so hart würde ich mit diesem erzeugten Takt nicht ins >Gericht gehen wollen. Es ist durchaus in Ordnung, innerhalb eines >FPGA-Designs mehrere unterschiedliche Takte zu verwenden. Man muss nur >wissen, was man da tut und die nötigen Maßnahmen an den Übergängen >zwischen den Taktdomänen ergreifen. Und das ist genau mein Problem! Als C Programmierer der etwas mehr mit HDL machen möchte fehlen mir hier einfach noch die Grundlagen welche über eine einfach kombinatorische Schaltung hinausgehen. Ich habe hier mehrere Bücher unter anderem das immer wieder empfohlene Buch "VHDL-Synthese Entwurf digitaler Schaltungen und Systeme". Aber so richtig kann ich mich mit VHDL nicht anfreunden. Darum habe ich mal einen Blick auf Verilog geworfen und mir folgendes Buch besorgt, "FPGA-Design mit Verilog" Harald, kann es sein das Du hier der Autor bist? ;o) Als C Programmierer komme ich mit dem Buch/Sprache (Verilog) besser zurecht. Wobei an einigen Stellen hier auch noch die Fragezeichen auftauchen. Lothar hat geschrieben: >Und das kann bei einer unnötig hohen Taktfrequenz schon mal Probleme >geben... (und hoffentlich war dann wenigtens das Clock-Constraint >gesetzt) Man liest die Info über die Clock-Constraints immer wieder. Aber für jemanden der sich HDL im Selbststudium beibringen möchte sind die Grundlagen etwas umständlich/schwer zu erlernen. Ich kenne Lothar seine Seite, wo schon viel erklärt wird, aber ich glaube hier muss man schon einen bestimmtem Level überschritten haben. Bei der Software ist es einfacher, hier gibt es den klassischen Debugger wo man die Probleme suchen kann. Bei HDL ist das dann eher der Logic Analyzer. Ich habe selber mal versucht den Anwender eine ARM Toolchain näher zu bringen, http://www.yagarto.de/ , und entsprechende kleine Beispiele und HowTo Seiten erstellt. Vielleicht gibt es so eine Art Seite auch für "HDL-DAUs" die noch mehr in die Grundlagen eingeht als Lothar seine Seite? Mit den Grundlagen meine ich jetzt nicht was ist ein NAND oder FF, sondern eher noch die Hintergrundinformationen wie z.B. Clock-Constraint. Viele Grüße, Michael
>Als C Programmierer der etwas mehr mit HDL machen möchte fehlen mir >hier einfach noch die Grundlagen welche über eine einfach >kombinatorische Schaltung hinausgehen. Musst dir halt grundl. Digit-Schaltungen, komb...seq.Logic anguggen (<>C!). HDL kommt erst danach.
Hallo Michael, ich weiß schon, dass das Erlernen des "Modellierens einer digitalen Schaltung" nicht ganz ohne ist. Und wenn man außer dieser neuen Vorgehensweise auch noch eine krätzige Sprache wie VHDL lernen muss, dann ist das doppelt schwer. Das war der Grund warum ich dieses Buch geschrieben habe. Die syntaktische Nähe von Verilog und C ist sicherlich eine Hilfe, aber man muss trotzdem lernen, dass das, was man da hinschreibt, kein Programm sondern ein Modell ist, eine Beschreibung für eine Schaltung aus Gattern und Flipflops. Die Flipflops haben die nicht wegzudiskutierenden Eigenschaft, dass sie in einer Zeitspanne vor und nach der relevanten Taktflanke keine Änderung des Eingangssignals verkraften. Das muss verhindert werden. Wenn da trotzdem eine Änderung auftritt, dann ist das Ausgangssignal für eine kurze Zeit undefiniert. Timing Constraints sind dazu da, dem Synthesetool Taktinformationen zu geben. Damit kann es die Gatterschaltung zwischen zwei Flipflop der gleichen Taktdomäne so optimieren, dass diese Zeitbedingung eingehalten wird. Ach und noch 'was: Michael Fischer schrieb: > Bei der Software ist es einfacher, hier gibt es den klassischen Debugger > wo man die Probleme suchen kann. Bei HDL ist das dann eher der > Logic Analyzer. Nein, es ist der Simulator. Und ich würde dir von Anbeginn an raten, deine FPGA-Designs im Simulator zu testen, bevor Du sie ins FPGA bringst. Grüße, Harald p.s. hast Du dir die Beispieldesigns runtergeladen?
So wie oben formuliert assign clk1x = cnt[3]; sind die Flanken von clk1x und clk16x phasenverschoben, denn nach der clk16x Flanke muss das Signal noch die clock-to-output Verzoegerung im clk16x synchronen Teiler, die Verzoegerung im clock Puffer und die Verzoegerung im clocknety durchlaufen. Wenn jetzt etwas, was in clk16x passiert, mit clk1x abtastet wird , kann sich der Ausgang mit clk16x schon geaendert haben bevor die Flanke in clk1x kommt, und umgekehrt. Damit haette man das typische Problem beim Uebergang in den Clock Domains. Wenn man statt des Teiler eine DCM/PLL verwendet, wuerden bei richtiger Beschaltung durch die DCM/PLL die Flanken aneinander angepasst und alles ist in Ordnung. Beim FPGA Design bringt das aber nur etwas in der Leistungsaufnahme, da die Last auf dem schnellen Takt verringert wird. Ausserdem kann es das Schreiben der Randbedingungen (Constraints) vereinfachen, wenn Netze in clk1x sehr lang werden und die Durchlaufzeit laenger als clk16x wird. Arbeitet man mit einem Clock Enable, muss man dann fuer jedes dieser Netze spezielle Multiclock Contraints (oder wie sie auch heissen) schreiben.
Michael Fischer schrieb: > Man liest die Info über die Clock-Constraints immer wieder. Sagen wir mal so: wenn du ein Ideal-Design hast (nur 1 Takt), dann hast du nur 1 Constraint auf genau diesen Takt. Und damit sagst du der Toolchain: Sorge doch bitte gefälligst dafür, dass alle Logikpfade zwischen 2 Flipflops im FPGA so kurz sind, dass die Laufzeit (durch die Verbindungen/Routing und die Kombinatorik) dazwischen diese Taktfrequenz ermöglicht. Hier eine kleine Skizze zum Thema:
1 | ... ---[FF1]--Kombinatorik--[FF2]--- ... |
2 | | | |
3 | clk ... -o--------------------o---- ... |
4 | |
5 | | | | | | |
6 | ... tco tpd tsu tco ... |
Die maximale Taktfrequenz ist also 1/(tco+tpd+tsu). Hier eine Erklärung zu den Kürzeln: Beitrag "Re: Wie viel sind 304Mhz denn wirklich?" Und weil tco (Clock to Output) und tsu (Setup) fest in die Flipflops eingebaut sind, kann die Toolchain nur noch was an der tpd (Propagation Delay) drehen. Dein Clock-Constraint betrifft also die maximale Logiktiefe zwischen 2 Flipflops (z.B. Und, Oder, MUX, Addierer, Multiplizierer...).
> kann die Toolchain nur noch was an der tpd (Propagation > Delay) drehen clock skew bei PLLs nicht unterschlagen
da kann halt aufgrund der Streukapazitäten im FPGA dein Hund krank werden. Hunde reagieren sehr empfindlich auf Taktunterschiede!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.