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!
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...
@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.
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
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.
@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.
@ 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
@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).
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
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.
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.
@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 ...
@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 ;-)
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.
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.
@ 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
