Wie kann ich in VHDL einen Teiler erstellen, der einen Takt von 20Mhz
auf 16Mhz runterteilt ? Ich hab nicht mal ansatzweise ne Idee wie ich
das umsetzen könnte. Vielen Dank !
@ Ralph H. (guru)
>Wie kann ich in VHDL einen Teiler erstellen, der einen Takt von 20Mhz>auf 16Mhz runterteilt ?
So, wie du es haben willst, also einen schönen 16 MHz Takt mit 50%
Tastverhältnis, geht nicht. Kauf dir einen passenden Quarzoszillator.
>Ich hab nicht mal ansatzweise ne Idee wie ich>das umsetzen könnte. Vielen Dank !
Man kann mit dem 20 MHz per State Machine ein Clock enable erzeugen, das
nach 4 Takten einmal aussetzt, macht 4/5 * 20 MHz = 16 MHz ;-)
Nennt der Angelsache gapped clock (enable).
MfG
Falk
@Ralph H. (guru)
>@ Falk... na das klingt doch gut :-) Ich brauch zum Testen nicht>zwingend ein Tastverhältnis von 50% beim Takt. Wie könnte sowas aussehen>?
Dass sowas jemand wie du mit den Nickname fragen muss . . .?
Dankeschön.. hätte nicht gedacht das es so einfach ist :-)
> Dass sowas jemand wie du mit den Nickname fragen muss . . .?
Du für den Nick hab ich mich hier bei meinen ganzen Fragen ehrlich schon
geschämt ;-).. grins aber das ist nun mal mein Cosename :D
Jo Lothar.. wenigstens das hab ich so erkannt. :-)
Manchmal aber ist wirklich ne ganz einfache Lösung so nah, dass man sie
vor lauter Grübeln gar nicht sieht. Und dafür gibt es zum Glück solche
hilfreichen Menschen wie Euch !! :-) Danke dafür !!
Ralph H. schrieb:> Und dafür gibt es zum Glück solche> hilfreichen Menschen wie Euch !! :-) Danke dafür !!
Also ich finde Deine Fragen gar nicht so schlecht :) Ich denke die sind
auch für andere hilfreich. Danke dafür ;)
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":
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.
df1as schrieb:> Aber wie soll ich ahnen, dass ein Undescore-Zeichen etwas> anrichtet?
Wenn du sowas schreibst:
1
*ein Stern* schreibt hier im Forum *FETT*
2
/ein Slash/ schreibt /kursiv/
3
ein Underline schreibt _unterstrichen_
4
_ein Underline_ schreibt _unterstrichen_
Kommt sowas raus:
ein Stern schreibt hier im Forum FETTein Slash schreibt kursiv
ein Underline schreibt unterstrichenein Underline_ schreibt _unterstrichen
Und wie man sieht, geht es am ehesten beim Underline schief. Da wird der
Anfang und das Ende der Formatierung nicht so ohne weiteres erkannt...
:-o
df1as schrieb:> Nur wenn es um minimalen Jitter geht, ist man um den Faktor 2 besser,> wenn man beide Flanken ausnutzt und einen neuen Clock generiert.
Richtig, aber es gibt keine FFs, die auf beide Flanken triggern können,
und so wird das eine üble kombinatorische Bastelei. Das ist in
programmierbaren Bausteinen nach Möglichkeit zu vermeiden...
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 ;-)
df1as schrieb:> Das Clock-Enable wird meist nicht über ein Clock-Netz verteilt.
Kein Clock-Enable wird über Taktnetze verteilt. Denn Taktnetze sind für
Takte da...
> verbraucht aber ggf. auch mehr Ressourcen (je nach Fan-out)
Davon hat das FPGA genug... ;-)
> als eine kleine, nur einmal vorhandene Kombinatorik für> ein neues Clock-Signal (wenn es dann das einzige ist).
Die allerdings dann garantiert nicht mehr protabel ist, und mit üblen
Effekten von Glitches bis Spikes daherkommt, und daher auch von der
Toolchain nicht mehr sauber verwaltet werden kann...
Sowas mache ich nur, wenn mir das Wasser bis Unterkante Oberlippe steht.
Und das war bisher genau 1 mal... ;-)
Ü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.
Thread beobachten
Seitenaufteilung abschalten