Hallo, ich hab mal (wieder) eine Verständnisfrage: Konkret hab ich ein Projekt, in dem ein Gigabit-Ethernet-PHY an einem Spartan3 hängt. Der PHY schickt seine Daten als 8Bit-Bus mit 125MHz. Die 125MHz sind jetzt aber zu schnell für die Logik, die die Daten vom PHY verarbeiten soll (bitte nicht fragen, ich hab's nicht programmiert), d.h. das 8ns-Timing-Constrain wird nicht eingehalten. Ich hab jetzt folgendes gemacht: Ich verwende einen FIFO mit 8-Bit-breitem Eingang, 16-Bit-breitem Ausgang und unterschiedlichen Clock-Signalen zum Schreiben und Lesen. Die eingehenden 8-Bit-Daten gehen mit 125MHz in einen FIFO. Ich teile den 125MHz-Takt durch 2 auf 62,5MHz und lese dann die Daten als 16-Bit-Worte mit 62,5MHz aus dem FIFO wieder aus. Der 62,5MHz-Prozeß schaut beim Auslesen nur auf "FIFO_EMPTY = 0", es gibt keine anderen Bedingungen zum Auslesen des FIFO. Kann es nun eigentlich vorkommen, daß im FIFO jemals mehr als 2 Bytes liegen? Kann der FIFO jemals voll laufen? Danke.
Kommt drauf an wie stark die beiden Takte variieren. Wenn du ihn wirklich wie du schreibst durch 2 Teilst mit nem FlipFlop dann kannst du auch zwei 8 Bit breite D-FlipFlops benutzen (es darf jedoch nie passieren, das der Auslesende Prozess mal was anderes zu tun hat z.B. nen IRQ bearbeiten). Deshalb denke ich das ein FIFO schon der richtige Ansatz ist.
@ Dosmo (Gast) >Ich verwende einen FIFO mit 8-Bit-breitem Eingang, 16-Bit-breitem >Ausgang und unterschiedlichen Clock-Signalen zum Schreiben und Lesen. Kann man machen. Ein schnödes Schieberegister mit 2x8 Bit + Register mit 1x16 Bit würde es auch tun und wäre deutlich resourcensparender, auch wenn das im Stratix-Virtex 7 Zeitalter nicht sonderlich wichtig ist. >Die eingehenden 8-Bit-Daten gehen mit 125MHz in einen FIFO. >Ich teile den 125MHz-Takt durch 2 auf 62,5MHz und lese dann die Daten >als 16-Bit-Worte mit 62,5MHz aus dem FIFO wieder aus. Schön. >Kann es nun eigentlich vorkommen, daß im FIFO jemals mehr als 2 Bytes >liegen? Ja, wenn man beim "Anfahren" des FIFOs etwas wartet und ihn sich teilweise füllen lässt. > Kann der FIFO jemals voll laufen? Fangfrage? Schon mal über phasenstarr gekoppelte Takte nachgedacht? Der Schöler wöllte mich wöhl veröppeln? MFG Falk
Wieso kann der Spartan 3 die 125 MHz nicht? Wir haben hier ein Design mit dem 3E auf 150MHz am Laufen. (Multi-USB Interface). Hast Du das FiFo händisch gebaut oder nutzt Du eine Xilinx-Primitive (CoreGen)? Das Beste wäre ein Wechselpuffer mit einem leicht verzögerten Takt.
Falk Brunner schrieb: > Der Schöler wöllte mich wöhl veröppeln? Aber es war doch nor ein wänziges Schlöckchen... Es war nicht der Schüler, sondern der FIFO-IP-Core: Der war so konfiguriert, daß er auf "FULL" eine 1 rausgibt, wenn der "RESET" aktiv ist. Daher hab ich regelmäßig ein "FIFO voll" gesehen, welches ich mir nicht erklären konnte. Jetzt hab ich den FIFO richtig konfiguriert und siehe da: kein FULL mehr. Maß man halt alles erstmal wissen... >Schon mal über phasenstarr gekoppelte Takte nachgedacht? Die beiden Takte der Logik werden von einem DCM aus dem externen Takt des PHY generiert. Sollte also passen. > Wieso kann der Spartan 3 die 125 MHz nicht? In meinem Fall ist die Logik, die mit 125MHz laufen soll, zu komplex. Ich hab's nicht programmiert, jedenfalls ISE kriegt's nicht geplace-and-routet.
Hajo schrieb: > Wieso kann der Spartan 3 die 125 MHz nicht? Wir haben hier ein Design > mit dem 3E auf 150MHz am Laufen. (Multi-USB Interface). Der Spartan 3 dürfte einen Ticken langsamer sein, als der Spartan 3E. Dosmo schrieb: > In meinem Fall ist die Logik, die mit 125MHz laufen soll, zu komplex. > Ich hab's nicht programmiert, jedenfalls ISE kriegt's nicht > geplace-and-routet. Viele Pfade schaffen denn das Timing nicht? Evtl. kannst Du mit Placement Constraints noch was rausholen. Duke
Die GMII Schnittetelle ist 8bit breit und hat 125MHz. Die GMII ist abwärtskompatibel und kann auch MII. MII ist 4 bit breit und hat 25MHz. Wenn dier 100bit LAN ausreichen? Die sicherste und einfachst Lösung.
Duke Scarring schrieb: > Viele Pfade schaffen denn das Timing nicht? Evtl. kannst Du mit > Placement Constraints noch was rausholen. Schon probiert. Es hat ca. 3500 Timing Fehler, auch bei maximalem Place-And-Route-Aufwand. René D. schrieb: >Wenn dier 100bit LAN ausreichen? Die sicherste und einfachst Lösung. Leider nein. Wat (Gast) schrieb: >Was ist jetzt dein eigentliches Problem? Ich hab einen FIFO, der nach meinem Verständnis niemals voll laufen kann, aber trotzdem regelmäßig sein "FULL"-Flag hebt. Mir war nicht bewußt, daß dies mit dem RESET zusammenhängt, und da ich bei FPGAs grundsätzlich mit dem schlimmsten rechne, dachte ich, es gäbe da ein wesentliches Verständnisproblem.
Besteht die Möglichkeit dir die Füllstandszähler (schreib- und leseseitig) in Chipscope anzeigen zu lassen, wenn der Fifo voll läuft? Du könntest dir natürlich auch anschauen, ob im RdReq-Signal Pausen zu sehen sind. Gruß, Wat
>Schon probiert. Es hat ca. 3500 Timing Fehler, auch bei maximalem >Place-And-Route-Aufwand. Du solltest außerdem den Timing-Problemen auf den Grund gehen und versuchen zu verstehen, was das Problem ist. Ist das Routing der Fifo-Ausgangsdaten zu lang?
Da die 62,5 MHz ja direkt aus den 125 MHz erzeugt werden, würde ich statt dem FIFO nochmal den Ansatz von Uwe bzw. Hajo untersuchen: Uwe schrieb: > Wenn du ihn > wirklich wie du schreibst durch 2 Teilst mit nem FlipFlop dann kannst du > auch zwei 8 Bit breite D-FlipFlops benutzen Hajo schrieb: > Das Beste wäre ein Wechselpuffer mit einem leicht verzögerten > Takt. Bzw. mit der anderen Taktflanke. Wat schrieb: > Besteht die Möglichkeit dir die Füllstandszähler (schreib- und > leseseitig) in Chipscope anzeigen zu lassen, wenn der Fifo voll läuft? > > Du könntest dir natürlich auch anschauen, ob im RdReq-Signal Pausen zu > sehen sind. Das braucht er alles nicht. Der FIFO würde mit 8 Bit @ 125 MHz gefüllt und mit 16 Bit @ 62,5 MHz geleert. Wie soll da was überlaufen? Dosmo schrieb: > Es hat ca. 3500 Timing Fehler, auch bei maximalem > Place-And-Route-Aufwand. Sind das die fehlerhaften Pfade oder ist das der Timing-Score? Wat schrieb: > Ist das Routing der > Fifo-Ausgangsdaten > zu lang? Timingprobleme hat er nur ohne FIFO (gesamtes Design auf 125 MHz), wenn ich das richtig verstanden bzw. gelesen habe... Duke
Wegen den FIFOs: Seit ich die IP-Core so konfiguriert habe, daß sie bei "RESET" nicht mehr "FULL" aktivieren, habe ich nie mehr ein "FULL" gesehen. Wegen dem Timing: Ursprünglich wird der Ethernet Frame mit 125MHz zusammengebaut. Bei vielen Bits des Frames sind aber zuviele Gatter drinn, so daß der Spartan3 nicht garantieren kann, daß er innerhalb 8ns den richtigen Zustand erreicht hat. Man kann sich das schön im "FPGA Editor" anzeigen lassen. Wenn ich von 125MHz auf 62,5MHz heruntergehe, hab ich keine Timingprobleme mehr.
Dosmo schrieb: > Ich teile den 125MHz-Takt durch 2 auf 62,5MHz und ... Verwendest Du den "geteilten Takt" dann als Clock für die weitere Logik oder als CE zusammen mit dem 125MHz-Takt auf dem Clock-Netzwerk? Verwendest Du irgendwo asynchrone Resets? Pipeline-Register? Zum Vergleich: Ich verarbeite hier einen 2,5GBit/s Datenstrom in einem Lattice MACHXO in Form eines 125MHz x 16Bit Busses. So viel langsamer werden X's Spartaner doch nicht sein - oder?
Stefan Wimmer schrieb: > Zum Vergleich: Ich verarbeite hier einen 2,5GBit/s Datenstrom in einem > Lattice MACHXO in Form eines 125MHz x 16Bit Busses. So viel langsamer > werden X's Spartaner doch nicht sein - oder? Ich denke mal, das Problem ist, was man unter "verarbeiten" versteht. Ich muß in Echtzeit MAC, IP, ICMP, UDP und ein proprietäres Protokoll verarbeiten. Empfangen geht ja noch, aber das Antwortprotokoll mit allen Varianten und Checksummen hat einfach zu lange Logikwege für die 125MHz.
@ Dosmo (Gast)
>Varianten und Checksummen hat einfach zu lange Logikwege für die 125MHz.
Das Zauberwort heißt Pipelining, auch wenn das nicht immer ganz einfach
ist.
Dosmo schrieb: > Ich denke mal, das Problem ist, was man unter "verarbeiten" versteht. > > Ich muß in Echtzeit MAC, IP, ICMP, UDP und ein proprietäres Protokoll > verarbeiten. Empfangen geht ja noch, aber das Antwortprotokoll mit allen > Varianten und Checksummen hat einfach zu lange Logikwege für die 125MHz. ...dafür gibt es Pipelining und FIFOs. Ich muss auch meinen Datenstrom erst mal in eine FIFO einfüllen um in einer FSM das Steuer-Protokoll zu verarbeiten um dann beim Auslesen der FIFO am anderen Ende zu wissen, was mit den Daten jeweils "passieren" soll. Und Checksummen(Polynome) kann man meist auch parallelisieren damit es schneller geht.
Wie voll ist denn dein FPGA eigentlich? Bei den kritischen Pfaden, wie gross ist der Anteil Logik/Verdrahtung? Ich habe mehrere Spartan3 Designs mit 100MHz am laufen, es ist immer wieder eine positive Ueberraschung wieviele LUTs man in den 10ns Takt reinkriegt. Nur wenn das Chip mal zu voll wird, dann gehts rapide bergab mit der Geschwindigkeit... Also, 125MHz sollten bei ausreichend Resourcen auf dem Chip ueberhaupt kein Problem sein... Waehl doch einfach in ISE mal ein groesseres S3 aus und schau dann, wo deine kritischen Pfade liegen...
Stefan Wimmer schrieb: >...dafür gibt es Pipelining und FIFOs. Ich muss auch meinen Datenstrom >erst mal in eine FIFO einfüllen um in einer FSM das Steuer-Protokoll zu >verarbeiten um dann beim Auslesen der FIFO am anderen Ende zu wissen, >was mit den Daten jeweils "passieren" soll. Ich habe das Modul nicht selbst entwickelt. Ich hab es übergeben bekommen, weil es nicht zuverlässig funktioniert (weil das 8ns-Timing-Constrain nicht eingehalten wird), und jetzt darf ich es zum Laufen bringen. Wenn ich es von Grund auf selber gemacht hätte, wäre ich einen anderen Weg gegangen, als alles On-the-Flight zu machen. Mein Ansatz mit der Takt-Halbierung funktioniert und die Timings werden jetzt eingehalten, insofern besteht kein Bedarf, alles noch mal von vorne zu machen (auch wenn es ohne Frage besser wäre). Die CRC wird übrigens parallel gerechnet. berndl (Gast) schrieb: >Wie voll ist denn dein FPGA eigentlich? Es ist ein 3S5000, also der größte Spartan3, mit Speedgrade 4, also der schnellste, und er belegt nur 5% der Ressourcen, weil ich im Moment noch nichts anderes drinn habe, außer der Ethernet-Kommuniaktion.
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.