Hallo Wie erzeugt und verteilt man eigentlich in einem FPGA Taktraten, die deutlich unter dem Systemtakt liegen? Mit den DCMs im Spartan beispielsweise kommt man ja auch nur auf 5 MHz runter, wobei in der Praxis aber Taktraten bis in den KHz-Bereich hinunter ja durchaus vorkommen. Ich sehe zwei Möglichkeiten, wie man dies tun könnte, als Basis dient jeweils ein Counter. - Bei einem bestimmten Counterstand könnte man ein Signal jeweils low oder high setzen und via IBUFG in ein Taktnetzwerk einspeisen. - Man könnte die langsamen Komponenten weiterhin mit dem vollen Systemtakt arbeiten lassen, aber jeweils per Enable-Signal nur alle n Taktschritte für einen Taktzyklus einschalten. Welche dieser Varianten (oder welche dritte Variante) ist vorzuziehen? Gruss Michael
Die zweite mit einem Clock-Enable-Signal. Bei durch Logik erzeugten Takten garantiert dir keiner irgendeine bestimmte Phasenlage zum "echten" Takt. Taktung FPGA/CPLD
Ich würde für die langsamen Schaltungsteile auch einen möglichst langsamen clock benutzen, das spart Strom.
Etwas verunsichert mich bei der Variante mit dem Clock-Enable: Ich habe ja den Counter, der bei einem bestimmten Wert für einen Takt das Clock-Enable-Signal einschaltet. Sagen wir, das geschieht jeweils bei der steigenden Flanke. Bei der nächsten steigenden Flanke schaltet er das Clock-Enable-Signal ja wieder aus. Genau bei dieser Flanke aber sollte die dem Clock-Enable-Signal nachgeschaltete Logik aber etwas tun. Im Prinzip wird somit also das Clock-Enable-Signal in dem Moment ausgeschaltet, in dem es der nachgeschalteten Logik sagen sollte, dass sie nun für diesen einen Taktzyklus etwas tun soll. Ist das sauber?
Du kannst ja auch länger das Enable aktivieren, indem Du zB nur die x oberen Bits des Counters vergleichst. Oder von vorneherein den Counter so auslegen dass Du nur das oberste Bit brauchst.
Keine schlechte Idee, so sollte das Problem sicher gelöst werden. Allerdings machen die das in meinem VHDL-Buch eben haargenau so wie oben erklärt.
Ach nee, das geht so doch nicht, denn: Wenn ich zwei Takte mit dem Enable-Signal oben bleibe, dann kriegt die dazugehörige Logik ja auch zweimal eine Taktflanke bei eingeschaltetem Enable.
Dein enable wird aus irgendeiner Logik entstehen, die hat Laufzeit. Deine FFs haben eine setup Zeit. Effektiv wird also der Zustand kurz vor der steigenden Flanke verwendet. Folglich reicht ein Takt mit enable = 1 aus. Um den Rest kümmert sich die Synthese.
Hmm, wo Du recht hast, hast Du recht ;) Naja letzten Endes kommt es daruf an, was Du machen willst. Ich habe schon oft einfach mit einem Counter den Takt selber geteilt, weil wenn man schon so ein langsamen Takt braucht, dann arbeitet das ja selten direkt mit schnellerer Logik zusammen (sondern über ein Register oder so). Vergessen darf man auch nicht, dass ja das Enable prinzipiell in der Low-Phase vor der Clock kommen muss und dann in der nächsten wieder weggeht. Du musst Dich also entscheiden, ob das mehr ein enable ist, dann muss die Logik aber auch damit zurechtkommen dass der Takt nach einem Cycle wieder weg ist, oder ob Du eine langsame Clock haben willst, um irgendwas externes oder so zu betreiben. Interne Sachen mit geteiltem Takt zu betreiben wird denke ich mehr Ärger machen als es nützt, nicht umsonst gibts bei CPU ja fast nur Abschalten der Clock und nicht Runtertakten von einzelnen Schaltungsteilen oder so.
Die Lösung "Langsame Clock kommt ans Clock-Enable" stimmt nicht ganz, und zwar genau weil dann an jeder Flanke des (schnelleren) Systemtakts das Enable an wäre. Deshalb brauchst du eine synchrone Flankenerkennung:
1 | process (systemclock) begin |
2 | if systemclock'event and systemclock='1' then |
3 | langsamer_takt_alt <= langsamer_takt_in; |
4 | end if; |
5 | end process; |
6 | |
7 | langsamer_takt_flanke_und_damit_clock_enable <= langsamer_takt_in and not langsamer_takt_alt; |
Beachte dass die Flankenerkennen außerhalb des synchronen Teils passiert, damit das Enable genau dann anspringt, wenn der langsame Takt high geht (also 1 Systemtakt früher als wenn im synchronen Block, und spart auch ein Register). Außerdem brauchst du evtl. eine Entprellung für den langsamen Takt.
Das ist aber trotzdem einen Systemtakt hinterher im Vergleich zu einem ASIC, wo der langsame, heruntergeteilte verwendet wird.
Stimmt, anders wären's aber zwei ;) Diese Verzögerung macht oft nichts aus, weil sich der externe Takt schlimmstenfalls im Bereich ~100x langsamer bewegt, oft sogar noch langsamer. Einen Systemtakt Verzögerung liegt also oft unterhalb der Schwankungen, die der langsame Takt eh hat. Wenn der externe Takt in die Nähe des Systemtakts kommt, sollte man ihn lieber als zweiten Systemtakt behandeln, und das heißt -> Clockpin. Ausnahmen bestätigen die Regel, z.B. wenn der externe Takt ähnlich schnell ist und nur zum Samplen einer einzigen ext. Datenleitung benutzt wird. Aber dann wird's eh haarig, von wegen Verzögerung der FPGA-internen Leitungen.
Man braucht überhaupt keine Flankenerkennung, wenn man das enable Signal genau einen Takt lang macht.
Wird hier nicht etwas aneinander vorbei geredet? Wieso "externen Takt", es ging doch ursprünglich um einen intern erzeugten langsameren Takt?
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.