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