Teiler von 20Mhz auf 16Mhz

Der Trick, jeden n-ten Clock auszulassen (dabei müsste n nicht einmal 
ganzzahlig sein), ist sicher sehr einfach zu realisieren und wenn es zum 
Ziel führt, spricht nichts dagegen (Variante a).

Die "Aussetzer" sind allerdings schon 2 Taktperioden lang (1 
Extrapause). Man könnte das - leider nur mit deutlichem Aufwand - 
doppelt so gut realisieren mit 1,5 Taktperioden, bzw. 0,5 Takten 
Extrapause (Variante b):

     _   _   _   _   _   _   _   _   _   
_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_ 20 MHz

     _   _   _       _   _   _   _       
_/ \_/ \_/ \_/ \_____/ \_/ \_/ \_/ \_____/ \_ 16 MHz a)

     _     _   _     _   _     _   _     
_/ \_/ \___/ \_/ \___/ \_/ \___/ \_/ \___/ \_ 16 MHz b)


Man muss dazu voraussetzen, dass der 20-MHz-Clock annähernd mit 50% Duty 
anliegt. Außerdem müsste dieser neue Clock kombinatorisch erzeugt 
werden. Das ergibt eine neue Clock-Domäne mit ihren Problemen.

Ist also keine Empfehlung, weil zu kompliziert - wäre aber eine mögliche 
Verbesserung des Timings.

Die Grafik wird hier nicht richtig wiedergegeben. Im Editorfenster sah 
es noch ok aus. Aus einem Underline-Zeichen wird eine 
Underline-Anweisung.

Zweiter Versuch als "Code":

1

   _   _   _   _   _   _   _   _   _   _   _ 

2

 _/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_ 20 MHz

3

4

   _   _   _   _       _   _   _   _       _ 

5

 _/ \_/ \_/ \_/ \_____/ \_/ \_/ \_/ \_____/ \_ 16 MHz a)

6

7

   _   _     _   _     _   _     _   _     _ 

8

 _/ \_/ \___/ \_/ \___/ \_/ \___/ \_/ \___/ \_ 16 MHz b)

Na ja ...

Ja klar. Aber wie soll ich ahnen, dass ein Undescore-Zeichen etwas 
anrichtet? Ist für mich bis hierher immer ein Zeichen gewesen, dass man 
ohne Seiteneffekte in den Text werfen durfte. Zum Unterstreichen hätte 
ich

1

<u> </u>

 oder ähnlich vermutet. An eine Vorschau habe ich daher nicht 
ansatzweise gedacht. Mein Fehler - man muss einfach mit allem rechnen!

Zum Thema: Das mit dem Clock-Enable ist ja bereits ganz gut. Nur wenn es 
um minimalen Jitter geht, ist man um den Faktor 2 besser, wenn man beide 
Flanken ausnutzt und einen neuen Clock generiert. Solange der 
ursprüngliche Clock für nichts anderes benutzt wird, hätte es auch keine 
weiteren Seiteneffekte, wie erforderliche Synchronisierungsstufen etc. 
Auf einen Clock-Netztreiber kommt man von der nötigen Kombinatorik auch 
wieder bei den meisten FPGA - und alles unter der Prämisse 'keine PLL'. 
Die hat auch ihre Nachteile.

Was ist an der Kombinatorik für ein neues Clock-Signal so 'übel'?

Immerhin braucht es damit in allen angeschlossenen Funkhäusern kein 
Clock-Enable mehr. Das Clock-Enable zieht sich ja durch alle 
angeschlossenen Prozesse hindurch. Müsste man also immer wieder 
hinschreiben ...

Das Clock-Enable wird meist nicht über ein Clock-Netz verteilt. Ist zwar 
auch unkritisch, weil es fast eine ganze Clock-Periode Skew haben darf, 
verbraucht aber ggf. auch mehr Ressourcen (je nach Fan-out) als eine 
kleine, nur einmal vorhandene Kombinatorik für ein neues Clock-Signal 
(wenn es dann das einzige ist).

df1as schrieb:
> Was ist an der Kombinatorik für ein neues Clock-Signal so 'übel'?

Es gibt 2 Gründe:
- Clock Skew. In Clock-Netzwerken sind die Leitungen schön ausbalanciert 
und mit starken Treibern versehen, so dass das Clocksignal überall 
gleichzeitig ankommt und eine Steile Flanke aufweist.
- Hazards: Logikschaltungen können bei einer Änderung am Eingang mehrere 
Flanken am Ausgang erzeugen. Dadurch hast du also mehrere Taktsignale. 
(Genaueres findest du sicher in der Wikipedia.)

df1as schrieb:
> Das Clock-Enable wird meist nicht über ein Clock-Netz verteilt. Ist zwar
> auch unkritisch, weil es fast eine ganze Clock-Periode Skew haben darf,

Warnung: Das spielt überhaupt keine Rolle bzw. hilft hier gar nicht! 
Beispiel Schieberegister:

--- FF(1) --- FF(2) --- FF(3)

Bei der Taktflanke übernimmt also jedes Flipflop die Daten, die am 
Ausgang seines Vorgängers anliegen. Wenn der Clock Skew zu gross ist, 
und somit Flipflop(2) seinen Takt deutlich nach Flipflop(1) bekommt, 
dann ist es gut möglich, dass Flipflop(1) seinen Eingang bereits 
übernommen und an den Ausgang weitergeleitet hat. Flipflop(2) übernimmt 
dann also sogar schon Daten, die am Anfang der Taktperiode noch am 
Eingang von Flipflop(1) lagen. (Stichwort: Contamination Delay)

modem schrieb:
> df1as schrieb:
>> Das Clock-Enable wird meist nicht über ein Clock-Netz verteilt. Ist zwar
>> auch unkritisch, weil es fast eine ganze Clock-Periode Skew haben darf,

Moment...da habe ich ungenau gelesen. Meine Antwort bezieht sich auf 
'Clock' und nicht 'Clock-Enable', sorry ;-)

Üble Effekte, Glitches, Spikes? Keiner sagt, dass man es falsch machen 
soll! Und was soll dabei nicht "portabel" sein? Kann man doch relativ 
übersichtlich und geschwind in VHDL dahinschreiben.

Mit VHDL wären das ein paar übersichtliche Zeilen, als Schematic 
zusammen eine Handvoll FF und Gatter. Kaum aufwändiger als der 
Bis-fünf-Zähler, der ein CKE generiert, das mit kaum Hold-Time 
daherkommt und an sämtliche (!) angeschlossenen Speicherelemente mit 
verteilt werden muss. Den Bis-fünf-Zähler braucht man in ähnlicher Form 
natürlich sonst auch, das muss aber auch kein Binärzähler sein. Besser 
wäre hier z. B. ein Johnson-Counter, dessen Ausgänge direkt 
kombinatorisch beliebig (und immer glitchfrei!) verküpft werden können.

Man kann immer ein von einem Speicherelement erzeugtes Signal auf der 
richtigen Seite und mit der passenden Logik mit dem Ursprungs-Clock 
vergattern, ohne dass es Glitch gibt. Wenn das nicht ginge, könnte man 
gar keine Speicherelemente bauen. Die Wirkung kommt zum Glück nie vor 
der Ursache.

Synchron tut ja ganz gut, aber man kann es auch mal schnell falsch 
verstehen. Ich sehe in einem generierten Clock nur den einen Nachteil, 
wenn nämlich BEIDE Clocks (hier 20 MHz UND 16 MHz) verwendet werden 
müssen. Ansonsten vereinfachte sich die ganze Geschichte sogar.

df1as schrieb:
> Ich sehe in einem generierten Clock nur den einen Nachteil,

Also wie gesagt: Clock muss über ein Clock-Netz verteilt werden, 
ansonsten handelt man sich die von mir oben genannten Probleme mit Skew 
und verletztem Contamination Delay ein.

Wenn man sehr genau weiss, was man tut, dann kann man Clock 
kombinatorisch verschalten bzw. erzeugen. "Gated Clock" kennen wir ja 
beispielsweise auch von Prozessoren, die einen Teil ihrer Logik bei 
Nichtbenutzung auschalten können. Aber man sollte sich dann im Minimum 
vergewissern, dass keine Spikes, Glitches etc. auftreten können, und 
zwar bis hinunter zu den Details der Synthese.

Ja wie? Generierte Clocks können etwa NICHT in ein Clock-Netz 
eingespeist werden? Merkwürdig, sehr merkwürdig ...

DCM und fertig! Ein Takt ist ein Takt und kein Enable wie oben 
diskutiert wird.