Clock teilen oder Clock-Enable?

naja die Frage ist, ob es sinnvoll ist ein Takt zu generieren und dann 
später nur dieses Signal abzufragen statt ein Clockenable zu generieren 
und dieses gemeinsam mit dem Haupttakt abzufragen?

wusst ich doch, dass das so sonst "sch*****" ist, hab ich doch was bei 
Herrn Reichardt gelernt!
Aber warum gibt es denn überhaupt so viele Beispiele, in denen 
Taktteiler vorgestellt werden statt Takt-Enable-Generatoren???

Lothar Miller schrieb:
> Und weils bei ASICs durchaus möglich ist, so einen neuen Takt zu
>
> erzeugen.

in FPGAs ist das auch möglich, nur halt nicht vorgesehen und damit 
schwer zu handhaben. Das geht dann in richtung low level design, das oft 
unnötig und nicht selten schlechter ist.

Taktteiler im FPGA und manuel erzeugte Takte sind in FPGAs nur in 
seltenen Fällen sinnvoll.

Abgeleitete Takte mit anderen Frequenzen sind immer aus PLLs / DCMs zu 
beziehen, weil die physikalischen Strukturen das genau so vorsehen.

Robert schrieb:
> Taktteiler im FPGA und manuell erzeugte Takte sind in FPGAs nur in
> seltenen Fällen sinnvoll.
Um z. B. die elektrische Leistung zu verringern ... Solange die kürzeren 
Takte nirgends weiter verwendet werden, macht es daher schon 
gelegentlich Sinn, herunterzuteilen, bevor es in die Clock-Netze geht.

> Abgeleitete Takte mit anderen Frequenzen sind immer aus PLLs / DCMs zu
> beziehen, weil die physikalischen Strukturen das genau so vorsehen.
Das "immer" gilt z. B. nicht für Raumfahrtanwendungen, wo PLLs & Co. gar 
nicht verwendet werden können, da diese Teile viel zu SEU-empfindlich 
sind und es dort i. d. R. keine TMR-Architektur gibt. Die Auswahl an 
Space-FPGA ist aber ohnehin stark eingeschränkt.

Ich hänge mich mal hier an den Thread. Ich hab das mit Clock Enable zwar 
schon verstanden, aber mit dem Ergebnis bin ich unzufrieden. Und zwar 
mit den sich ergebenden Timings.

Ich habe ein externes Taktsignal von 32 MHz. Ich verarbeite Daten in 
einem mit diesem Clock-Signal getakteten Prozess. Ich will einen 
zweiten, internen Takt von 8 MHz für einen zweiten Prozess erhalten. Der 
zweite Prozess enthält viel kombinatorische Logik, daher kann dort die 
Taktfrequenz auch nicht sehr hoch werden, 8 MHz muss ich aber trotzdem 
erreichen. Wenn ich jetzt wie im Wiki "Taktung FPGA/CPLD" beschrieben 
vorgehe, und einen 2 Bit-Zähler implementiere, erhalte ich eine maximale 
Taktfrequenz von unter 30 MHz für meinen ersten Prozess nach der 
Synthese und PAR. Lasse ich den Taktzähler und CE weg und nehme 
stattdessen einen (eigentlich nicht vorhandenen) externen Takt von 8 MHz 
für meinen zweiten Prozess, habe ich keine Timingprobleme und beide 
Prozesse werden für Taktraten >32 resp. 8 MHz synthetisiert.

Ist das normal, und gibt es für dieses Verhalten eine Lösung?

Danke für das Stichwort. Hab jetzt etwas herumprobiert, gegoogelt und 
PDFs gelesen, aber funktionieren tut nichts. Naja, ich widme mich 
erstmal anderen Problemen :)

Georg A. schrieb:
>> wo PLLs & Co. gar nicht verwendet werden können
>
> Doch, gibt's und werden verwendet, zB. im ATC18RH-Prozess:
>
> http://www.atmel.com/images/doc4261.pdf
Es ging auch um FPGAs, nicht um ASICs.

RT- und RH-FPGAs haben überwiegend alle Elemente ihrer 
"Normal"-Pendants. Dennoch sind davon einige, wie Memory-Blöcke und 
PLLs, mit größerer Vorsicht zu genießen. Die SEL-Schwelle und die 
total-dose liegen zwar ohne zusätzliche Abschirmmaßnahmen schon im 
Verträglichen, aber die SEU-Empfindlichkeit variiert untereinander immer 
noch um Größenordnungen. Das gab es bereits seit der ersten 
RH-FPGA-Generation (z. B. Actel A1020-RH, später A1280-RH u. s. f), so 
dass man sequentielle Logik selbst noch z. B. durch TMR absichern 
musste. Kombinatorische Zellen waren ok. Inzwischen wird bei den RH-FPGA 
überwiegend TMR schon auf S-Zellbasis zur Verfügung gestellt (3 FFs plus 
voter). Bei analogen Schaltungsteilen funktioniert das aber nicht so 
einfach. Hin und wieder gibt es auch noch eine Reihe anderer 
Einschränkungen zu beachten. Es ist auf keinen Fall so, dass man einen 
RH-FPGA einsetzt und meint, alles ginge wie immer, nur dazu noch 
trittfest.

Statt PLLs setzen wir, wenn nötig, entsprechend hohe Eingangstaktraten 
ein und teilen ggf. herunter für langsamere Schaltungsteile. 
Synchronisieren kann man als Alternative immer noch zwischen 
verschiedenen Clock-Domänen, z. B. mit asynchronen FIFOs (Gray-coded). 
Summa summarum ergibt das u. U. einen geringeren Leistungsbedarf, obwohl 
nur die Clocknetze selbst betroffen sind. Für die Anzahl an Umladungen 
in der eigentlichen Logik macht es ja keinen Unterschied, ob der Clock 
geteilt ist oder ein Enable-Signal anliegt. Das Enable-Signal muss 
allerdings auch noch verteilt werden, ist aber bereits so langsam, wie 
der geteilte Clock. Die Review-Boards sehen allerdings auch lieber ein 
völlig synchrones Design, wenn möglich. Die WCAs sind übersichtlicher, 
da man nicht alles gegen alles abschätzen muss. Allerdings spielt 
elektrische Leistung immer noch eine große Rolle. Einen Lüfter kann man 
halt nicht mitnehmen.

Es ging mir eigentlich nur darum, dass behauptet wurde, PLLs würden 
IMMER eingesetzt werden.

Bevor wir seit einigen Jahren CPUs nur noch als Cores in RH-FPGA (aber 
auch RH-ASICs) verbaut hatten, gab es übrigens auch schon einige 
RH-CPU-Ansätze. Bei denen durften dann die Caches nicht verwendet werden 
u. s. w. Das sprengt jetzt aber das Thema komplett.

Sry für die kurze Störung
DF1AS