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!
Nimm ein fertiges asynchrones FIFO. Nein, sowas baut man nicht selber, das ist bisweilen kniffelig. MFG Falk
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 ;-)
Ja, keine Ahnung. Hat jemand schonmal mit den Altera Mege Funktion Wizzard einen Dual Clock Fifo getestet? Sonst würde ich den mal testen.
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: halte den FIFO mal bei ~50% ohne ihn ganz leer zu lesen oder komplett zu füllen.
@ 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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.