mikrocontroller.net

Forum: FPGA, VHDL & Co. Takte entkoppeln


Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe das Problem, dass ich Daten mit einem Takt von 25 MHz bekomme 
und diese auch mit 25 MHz weiterleiten möchte, die beiden Takte jedoch 
nicht Phasengleich sind. Ich muss also etwas haben, was die Daten kurz 
zwischenspeichert,bis sie vom zweiten Takt gelesen werden können. Ich 
möchte dafür kein FIFO verwenden, sondern etwas in VHDL programmieren. 
Die ankommenden Daten sind 5 Bit breit und es gibt wie gesagt 2 takte.

Kann mir da jemand weiterhelfen?

Danke!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm ein fertiges asynchrones FIFO. Nein, sowas baut man nicht selber, 
das ist bisweilen kniffelig.

MFG
Falk

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, da wird sich Herr Shannon im Grab umdrehen.
Einfach: hier wird das Abtasttheorem verletzt.
Denn um ein Signal mit einer Frequenz von 25 MHz sicher zu erfassen sind 
theoretisch mindestens 50 MHz nötig.

Da sind also zwei Takte mit ca. 25 MHz.
Angenommen die Daten werden mit 25,000001 MHz eingetaktet und mit 
25,000000 wieder abgeholt, dann dauert es nicht lange (genau 1 Sekunde), 
bis ein Puffer-Überlauf passiert:
Auf einen Lesetakt kommen zwei Schreib-Takte.

BTW:
Wenn die Daten kontinuierlich kommen, dann hilft hier auch kein Fifo 
weiter.
Denn nach 1 sec ist der Fifo um 1 Wort zu spät, nach 2 sec um 2 Worte...

Autor: CLOCK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@lkmiller

Wie kommst du darauf ? So wie ich das verstehe ist die Clock invertiert 
(Vermutung) und es sollte mit einem FIFO-Puffer funktionieren. Jetzt muß 
man aber den Aufwand für den FIFO-Puffer sehen. Ein CPLD muß da 
mindestens ran.

@Hans

Clocks haben die dumme Eigenschaft das sie driften wenn sie nicht von 
einer Domain abgeleitet wurden (mal mehr mal weniger). Wenn dem so ist 
gibts Datenmansche.

Autor: Rick Dangerus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er hat was von nicht phasengleich geschrieben. Das lese ich erstmal 
so, das der eine Takt 0 Grad und der andere was zwischen -180 und 180 
Grad Phase hat.

Rick

Autor: Chef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Shannon wird hier nicht verletzt, wenn die Takte synchron laufen. Das 
tun sie ja, sie sind nur nicht phase aligned.

Also rntweder Taktverschiebeung des Lesetaktes und damit phase aligning 
erzielen oder, wie angesprochen, einen FIFO nutzen und damit clock 
domain boundary hopping betreiben.

Im einfachsten Fall einer genügenden Phasenverschiebung der Takte 
ausserhalb des Jitterbereiches, reicht ein FIFO mit nur 2 
Registerstufen, den man im Volksmund Wechselpuffer nennt und der zu 
einer Latenz von ca 1+d führt.

Im allgemeinen Fall, wenn 2 fast phased aligned Signale vorliegen, die 
innerhalb des Jitterbereiches die Reihenfolge tauschen könenne, benötigt 
man 3 Stufen, mit durchschnittlich 2.0 +/- j1+j2 an Latenz.

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@CLOCK
>ist die Clock invertiert (Vermutung)
Ja, meine Vermutung war da eben etwas anders ;-) weil O-Ton:
>die beiden Takte

>wenn die Takte synchron laufen
Full ACK

>nicht phasengleich
Ja, gesehen,
aber wenn die Takte einfach "nur" nicht phasengleich, ansonsten
aber genau gleich sind, dann habe ich meines Erachtens nur 1 Takt.
Und dann brauche ich keinen Fifo.

Ich muß dann nur sehen, dass meine S&H-Zeiten nicht verletzt werden,
und werde das Design entsptrechend constrainen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  lkmiller (Gast)

>Nun, da wird sich Herr Shannon im Grab umdrehen.

Kaum. Der hat mit FIFOs gar nix am Hut gehabt.

>Einfach: hier wird das Abtasttheorem verletzt.

;-)
Lies dir dein Uni-Skript nochmal durch und denk drüber nach.

>Denn um ein Signal mit einer Frequenz von 25 MHz sicher zu erfassen sind
>theoretisch mindestens 50 MHz nötig.

Unseliges Halbwissen. Beim Hernn shannon gehts um die zeitdiskrete 
Abtastung von Signalen. Und worüber du hier redest bezieht sich auf ein 
Sinussignal. Hat mit Digitaltechnik hier so ziemlich gar nix zu tun.

>Wenn die Daten kontinuierlich kommen, dann hilft hier auch kein Fifo
>weiter.

Sicher, aber das weisst du doch gar nicht.

>aber wenn die Takte einfach "nur" nicht phasengleich, ansonsten
>aber genau gleich sind, dann habe ich meines Erachtens nur 1 Takt.
>Und dann brauche ich keinen Fifo.

Doch, auch wenns nur ein kleines ist.

>Ich muß dann nur sehen, dass meine S&H-Zeiten nicht verletzt werden,
>und werde das Design entsptrechend constrainen.

Reicht im allgemeinen nicht, nur wenn deine Takte eine streng definierte 
Phasenverschiebung haben.

MfG
Falk

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk
>Sicher, aber das weisst du doch gar nicht.
Gehts uns da nicht gleich ;-)

>nur wenn deine Takte eine streng definierte Phasenverschiebung haben
Nehme ich einfach mal an, Hans hat mir da keine Einschränkungen gesetzt.
Dir auch nicht.
Fazit: alles ist richtig und alles ist falsch wenn man die kompletten 
Rahmenbedingungen nicht kennt.
Und das mit dem Shannon weiß ich schon (Advocatus Diaboli).

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Dankefür eure Antworten. Also dann werd ich das nochmal genauer 
beschreiben.
Es gibt also einen Bus, der 5 Bit breit ist. Dazu gibt es einen Clock, 
der zu den Daten passt. Mit diesem Takt kommen die Daten an. Wenn ich 
diese Daten nun einen oder zwei Takt zwischenspeicher, dann müsste ich 
sie doch mit einem anderen Takt, den ich auch habe wieder auslesen zu 
können.

Ich habe es schon mit einem Fifo mit zwei Clocks versucht, leider kam es 
dabei immer zu komischen fehlern. Ich wollte mir nun eine einfache 
Version selber bauen um fehler bei der Fifoprogrammierung 
auszuschließen.

Ich gehe davon aus, das die Takte um plusminus 100ppm genau sind.

Gruß,
Hans

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, als Fifos hatte ich den Generic_fifo_dc von opencores verwendet. 
Ich hatte read enable und write enable einfach auf VCC geklemmt. Dadurch 
ergibt sich eine Verzögerung der Daten von 2 Takten. Beim genaueren 
Testen stellt sich dann herraus, dass in unregelmäßigen Abständen 
immerwieder nicht nachvollziehbare Fehler auftreten.

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans
Kommen die Daten kontinuierlich rein, oder gibt es da Pausen?

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, es  sind daten von der MII Schnittstelle. Die Daten kommen also in 
Frames an. Wenn man mal davon ausgeht,dass ein maximaler ethernetframe 
ca 1600Bytes hat, und die MII Schnittstelle immer einen nibbel 
transportiert, dann sind es maximal 3200 nibbel. Danach gibt es eine 
Pause von 12Byte also 24 nibbel.

Ich habe beobachtet, dass die Fehler häufiger werden, je kleiner die 
Pausenzeit zwischen den Frames ist. Also wenn ich die Pausenzeit auf 
1000Byte zwischen den Frames stelle, dann wird es besser.

Autor: CLOCK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans:

Wie synchronisiert du dein write/read ? Ich hoffe du holst keine Daten 
wenn noch keine geschrieben wurden !?
Auch wenn du einen FIFO benutzt mußte du das machen ...

Autor: CLOCK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans:

> Also wenn ich die Pausenzeit auf
> 1000Byte zwischen den Frames stelle, dann wird es besser.

Da sind die Clocks dann wieder synchron wie es scheint ;-)

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, keine Ahnung. Hat jemand schonmal mit den Altera Mege Funktion 
Wizzard einen Dual Clock Fifo getestet? Sonst würde ich den mal testen.

Autor: lkmiller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Overrun?
Zähl doch mal mit, wieviele nibbles reingeschrieben und rausgelesen 
werden. Sollten ja am Ende des Tages genau gleich viel sein.

>Ich gehe davon aus, das die Takte um plusminus 100ppm genau sind
100ppm bedeutet, dass du z.B. 25MHz+-2500Hz haben kannst
(1ppm bei 25MHz = 25Hz).
Also ist es denkbar, dass du mit 25.002500 Mhz eintaktest
und mit 24.997500 ausliest --> früher oder später: Overrun


Mit der erhöhten Pausenzeit verringerst du lediglich die 
Wahrscheinlichkeit, dass du einen Fehler bemerkst.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, sowas hatte ich mir auch schon gedacht. Deshalb habe ich den Fifo 
mal risesn groß gemacht (20.000). Dann habe ich den Füllstand überwacht. 
Der Generic Fifo hat einen level aufgang, der zurückgibt ob der Fifo 
0-25% 25-50% usw gefüllt ist. Ich hab den Fifo immer soweit volllaufen 
lassen bis 50% erreicht sind und habe dann erst den read enable 
aktiviert. Das sollte bei einer solchen Fifogröße nicht so schnell dazu 
führen dass der Fifo leergelesen wird.

Mir ist aufgefallen, dass wenn ich einfach re und we auf VCC klemme und 
keinerlei Füllstandsüberwachung oder ähnliches vornehme weniger Fehler 
passieren. Das wundert mich schon.

Autor: CLOCK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans:

halte den FIFO mal bei ~50% ohne ihn ganz leer zu lesen oder komplett zu 
füllen.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Hans (Gast)

>Es gibt also einen Bus, der 5 Bit breit ist. Dazu gibt es einen Clock,

Das ist ein TAKT.

>Ich habe es schon mit einem Fifo mit zwei Clocks versucht, leider kam es
>dabei immer zu komischen fehlern.

Sowas soll vorkommen.

> Ich wollte mir nun eine einfache
>Version selber bauen um fehler bei der Fifoprogrammierung
>auszuschließen.

Kaum ;-)
Wenn du nciht mal nen fertigen GETESTETEN FIFO zum Laufen bringst, 
kannst du eine selbstgestrickte Lösung mal gleich vergessen. Glau mir. 
Nimm einen fertigen asynchronen FIFO. Das ist hier der wasserdichte Weg.

>Ich gehe davon aus, das die Takte um plusminus 100ppm genau sind.

Als DOCH asynchron und nicht nur phasenverschoben! Das ist ein 
himmelweiter Unterschied.

Aber bei Ethernet gibts ja Pausen zwischen den Frames, die reichen zum 
Taktausgleich.

@  lkmiller (Gast)

>und mit 24.997500 ausliest --> früher oder später: Overrun

Passiert praktisch kaum, weil nie mit 100% Bandbreite gearbeitet wird 
bei Ethernet.

@ Hans (Gast)

>Ja, sowas hatte ich mir auch schon gedacht. Deshalb habe ich den Fifo
>mal risesn groß gemacht (20.000). Dann habe ich den Füllstand überwacht.

Bringt gar nix.

>keinerlei Füllstandsüberwachung oder ähnliches vornehme weniger Fehler
>passieren. Das wundert mich schon.

Da ist ein Bug in deiner Ansteuerung oder ein Timingfehler an den 
IO-Pins.

MfG
Falk

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.