Hallo,
ich hab vor einiger mal wieder ein Projektchen von einem Kollegen
geerbt. Dabei ist ein Marvell-PHY an einen Spartan3 angeschlossen und
macht 1GBit Ethernet.
Als ich das Projekt übernommen hab, hatte ich das Problem, daß bei etwa
jedem 2. bis 3. Bitfile, das ich erzeugt habe, die
Ethernet-Kommunikation nicht korrekt funktioniert hat (einzelne Bits in
den Frames waren falsch).
Nach langem Suchen bin ich dann drauf gekommen, daß die
Setup/Hold-Zeiten der Signale vom/zum PHY nicht konfiguriert waren. Seit
ich entsprechende Timing-Constraints konfiguriert habe, funktionieren
alle Bitfiles zuverlässig und auch im Dauertest (unter Laborbedingungen)
einwandfrei.
Das Problem ist nun, daß die Toolchain sagt, sie könne die vorgegeben
Timing-Constraints nicht alle einhalten.
Beispiel:
RXD(3) ist laut Datenblatt mind. 2,5ns vor RX_CLK (125MHz) und danach
für mind. 0,5ns gültig.
Mein Constraint sieht so aus:
NET "PHYA_RXD[3]" OFFSET = IN 2.5 ns VALID 3 ns BEFORE "PHYA_RX_CLK"
RISING;
Der Timing-Report sagt dazu:
-------8<-------------------------------
Slack (setup path): -0.445ns (requirement - (data path - clock path
- clock arrival + uncertainty))
Source: PHYA_RXD<3> (PAD)
Destination: DH/PHYA/MyPhyInterface/iRxBuf_RXD_3 (FF)
Destination Clock: PHYA_GTXCLK_OBUF rising at 0.439ns
Requirement: 2.500ns
Data Path Delay: 2.289ns (Levels of Logic = 0)(Component delays
alone exceeds constraint)
Clock Path Delay: -1.095ns (Levels of Logic = 3)
Clock Uncertainty: 0.000ns
-------8<-------------------------------
Wenn ich die Kollegen dazu frage, heißt es:
Macht nix, der FPGA hat genug Reserven, das darf man nicht so eng sehen.
Was sagt denn Ihr dazu?
haha den gleichen Fehler hab ich genau gestern auch bekommen. Bei den
Datenbits hatte ich aber bisher nie Probleme, auch bevor ich die
Constrains eingetragen hab. Meine bisherige Erfahrung dieser
Timing-Fehler ist nicht so schlimm. Aber falls du Chipscope hast kannst
du ja mal die internen Signale über längeren Zeitraum beobachten.
Bronco schrieb:> Wenn ich die Kollegen dazu frage, heißt es:> Macht nix, der FPGA hat genug Reserven, das darf man nicht so eng sehen.>> Was sagt denn Ihr dazu?
Bei Raumtemperatur und Entwicklungsumgebung mag das durchaus gehen, da
ja die STA (normalerweise) für den ganzen erlaubten Temperaturbereich
gemacht wird.
Für den Release wäre ich dann aber vorsichtiger. Gibt ein besseres
Gefühl, wenn das Timing zugeht, als sich auf nicht näher spezifizierte
"Reserven" zu verlassen...
Stachele schrieb:> Sind deine Eingangsregister irgendwelche FFs oder IO-FFs sprich> IO-Eingangsregister?
Auf die Gefahr hin, mich zu blamieren: Was sind IO-Eingangsregister,
bzw. wie würde ich diese instanzieren?
IO-Eingangsregister sind Register, die in der IO-Zelle liegen und somit
ein definiertes Setup-Verhalten für Eingangsregister und ein definiertes
Clock-To-Out-Verhalten für Ausgangsregister ermöglichen.
Für die Eingangsregister gibt es die Möglichkeit verschiedene
Delay-Optionen einzustellen, je nach dem was man braucht.
"Normale" Register hingegen liegen irgendwo im Inneren des FPGAs, so
dass hier die Setup-Zeit variieren kann. Das hängt dann vom Synthese
bzw. Place&Route-Durchgang ab.
Such doch mal in Datenblatt nach "input register" und schau dir mal an,
was man hier so einstellen kann, um verschiedene Setup-Zeiten zu
erreichen.
Im IO/Pad-Report sollte man auch sehen können, ob IO-Eingangs- oder
Ausgangsregister verwendet werden.
Es gibt ein Attribut, mit dem man vorgeben kann, ob ein IO-Register
verwendet werden soll oder nicht.
Bronco schrieb:> Stachele schrieb:>> Sind deine Eingangsregister irgendwelche FFs oder IO-FFs sprich>> IO-Eingangsregister?>> Auf die Gefahr hin, mich zu blamieren: Was sind IO-Eingangsregister,> bzw. wie würde ich diese instanzieren?
Soweit ich das von zB. Actel kenne, kann man das Tool dazu zwingen, FF
möglichst in die Pads zu veschieben. Wenn es da welche gibt und das
Ausgangssignal nach dem FF nicht nochmal im Design selber verwendet
wird.
Bronco schrieb:> Der Timing-Report sagt dazu:> -------8<-------------------------------> Slack (setup path): -0.445ns (requirement - (data path - clock path> - clock arrival + uncertainty))> Source: PHYA_RXD<3> (PAD)> Destination: DH/PHYA/MyPhyInterface/iRxBuf_RXD_3 (FF)> Destination Clock: PHYA_GTXCLK_OBUF rising at 0.439ns> Requirement: 2.500ns> Data Path Delay: 2.289ns (Levels of Logic = 0)(Component delays> alone exceeds constraint)> Clock Path Delay: -1.095ns (Levels of Logic = 3)> Clock Uncertainty: 0.000ns> -------8<-------------------------------
Das "Clock Path Delay" lässt mich vermuten, dass eine DCM vorgeschaltet
ist und nicht der PHYA_RX_CLK verwendet wird. Laut dem Report kann es im
ungünstigen Fall dazu kommen, dass die Daten gelesen werden, bevor sie
anliegen oder noch schlimmer, während sie sich ändern.
Meiner Meinung nach genügt folgender Aufbau, um die Daten immer korrekt
einzulesen:
-------- ---------
DATA ------| IBUF |------|D FF Q|-----
-------- | |
---|C |
| ---------
--------- |
CLK -----| IBUFG |----
---------
Alternativ kann man die DCM verwenden und die vorhandene
Phasenverschiebung (-1.095ns) modifizieren. Jedoch habe ich die
Vermutung, dass der Takt auch gleichzeitig zum Senden der Daten
verwendet wird (PHYA_GTXCLK_OBUF). Wenn das so ist, dann sollte die
Takterei jedoch grundsätzlich überarbeitet werden.
Bronco schrieb:> Wenn ich die Kollegen dazu frage, heißt es:> Macht nix, der FPGA hat genug Reserven, das darf man nicht so eng sehen.Bronco schrieb:> Dabei ist ein Marvell-PHY an einen Spartan3 angeschlossen und> macht 1GBit Ethernet.
...
Bronco schrieb:> Auf die Gefahr hin, mich zu blamieren: Was sind IO-Eingangsregister
ohne das jetzt böse zu meinen, aber habt ihr eigentlich Ahnung davon was
ihr tut?
Der erste Satz ist grausam, hoffentlich mutet ihr das keinem Kunden zu.
Verletzte Timing können alles bewirken, aber mit Sicherheit nicht über
eine Serie stabil laufen.
Wieso man an einem GBit Ethernet rumpfuscht bevor man überhaupt
Grundlagen beherrscht verstehe ich auch nicht.
Bitte beschäftige dich erst mal ein wenig mit dem Thema FPGA bevor du da
direkt ein Projekt vor die Wand fährst....und tu mir einen Gefallen:
lerne nicht von derart inkompetenten Kollegen.
Ein Tipp zum Schluss: 2,5ns Datenpfad ist extrem sportlich für einen
Spartan 3, jedoch verstehe ich auch nicht warum du das schaffen willst.
125mhz sind 8ns. selbst wenn ich da 2.5 und 0.5 abziehe bin ich immer
noch bei 5 und nicht bei 2.5
tzu schrieb:> Ein Tipp zum Schluss: 2,5ns Datenpfad ist extrem sportlich für einen> Spartan 3, jedoch verstehe ich auch nicht warum du das schaffen willst.>> 125mhz sind 8ns. selbst wenn ich da 2.5 und 0.5 abziehe bin ich immer> noch bei 5 und nicht bei 2.5
Ich denke du hast dich noch nie mit einem GBit PHY beschäftigt. Beim
RGMII Interface (Pins sparen ist Trumpf) hat mat 125 MHz DDR, d.h. die
Datenleitungen ändern sich alle 4 ns.
Zum ursprünglichen Thema, auch ich bin der Meinung man muss
Timingviolations ernst nehmen. Die STA berechnet das über den gesamten
Temperaturbereich, Spannungsbereich sowie alle Prozessvariation.
Früher oder später wird man in der Serie auf die Schnauze fallen.
Lattice User schrieb:> Beim> RGMII Interface (Pins sparen ist Trumpf) hat mat 125 MHz DDR, d.h. die> Datenleitungen ändern sich alle 4 ns.
Na wie du das schaffen willst mit 2.5ns vorher und 0.5ns hinterher in
einem Spartan3 bin ich aber gespannt.
Wäre vielleicht sinnvoll DDR-IO zu nutzen wenn man schon so ein lahmes
FPGA hat, aber was weiß ich schon...
Lattice User schrieb:> Die STA berechnet das über den gesamten> Temperaturbereich, Spannungsbereich
Die Temperatur hat einen schönen Einfluss.
Angeblich soll es Studenten geben, bei denen das Timing nicht passt.
Wenn der FPGA mit Kältespray auf -30°C runtergekühlt wird, läuft alles.
Oszi -> Single Shot.
Von daher würde ich dir empfehlen, mal in einen Temperaturschrank zu
gehen oder zumindest den FPGA mit Fön / Lötkolben zu erwärmen.
Daniel M. schrieb:> Das "Clock Path Delay" lässt mich vermuten, dass eine DCM vorgeschaltet> ist und nicht der PHYA_RX_CLK verwendet wird. Laut dem Report kann es im> ungünstigen Fall dazu kommen, dass die Daten gelesen werden, bevor sie> anliegen oder noch schlimmer, während sie sich ändern.>> Meiner Meinung nach genügt folgender Aufbau, um die Daten immer korrekt> einzulesen:
Hey, das ist eine gute Idee! Werd ich mal probieren.
PS: ich hab vorhin mal versucht, ob sich etwas ändert, wenn ich die
Register in den IOB zwinge, aber hat nichts geholfen.
tzu schrieb:> ohne das jetzt böse zu meinen, aber habt ihr eigentlich Ahnung davon was> ihr tut?
Tja, was soll ich dazu sagen? Ich muß aus dem, was ich vorgesetzt
bekomme, das beste machen, dafür werd ich bezahlt.
Die Hardware war schon fertig, bevor mir das Projekt übergeben wurde.
>PS: ich hab vorhin mal versucht, ob sich etwas ändert, wenn ich die>Register in den IOB zwinge, aber hat nichts geholfen.
Hast Du denn auch geschaut, ob das IO-Eingangsregister so eingestellt
ist, dass es deinen Setup-Anforderungen genügt?
Einfach nur ein IO-Register einsetzen führt nicht zum Ziel. Man muss
sich schon die Timing-Größen anschauen!
Stachele schrieb:> Hast Du denn auch geschaut, ob das IO-Eingangsregister so eingestellt> ist, dass es deinen Setup-Anforderungen genügt?
Jetzt muß ich nochmal dumm fragen:
Ich hab die Timing Constraints der Signal vom PHY angegeben. Ich dachte,
die Toolchain macht den Rest und versucht alles, um die Vorgaben zu
erfüllen.
Muß ich mich dann wirklich mit IOBs auseinander setzen? Macht das
Toolchain nicht besser ohne mein Halbwissen?
Prinzipiell verlagert xst die FFs auch selbst in die IOBs, aber nur
dann, wenn es im Code keine explizite Resetbedingung dafür gibt. Die
IOB-FFs haben nämlich keinen (P)Reset wie die normalen CLB-FFs.
Allerdings sagt xst sowas auch in seinem Lauf, ebenso wie den Fall, dass
ein bestimmer Resetwert die Logikoptimierung erschwert und man evtl.
nochmal nachdenken sollte, ob der Wert wirklich notwendig ist.
Die Ausgaben sind recht informativ, ich schau da ab und zu immer wieder
drüber. Da ja auch ausgegeben wird, was xst da aus welcher Zeile sich
zusammensynthetisiert, entdeckt man manchmal schon versteckte
Logikgräber...
Daniel M. schrieb:> Meiner Meinung nach genügt folgender Aufbau, um die Daten immer korrekt> einzulesen:
Trotzdem benötigst du ein constraint für die Beziehung der Takte.
Bronco schrieb:> Dabei ist ein Marvell-PHY an einen Spartan3 angeschlossen und> macht 1GBit Ethernet.
Welchen PHY verwendest Du?
