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...
Sind deine Eingangsregister irgendwelche FFs oder IO-FFs sprich IO-Eingangsregister?
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!
> ohne das jetzt böse zu meinen, aber habt ihr eigentlich Ahnung davon was > ihr tut? Das ist er wieder, füttert nicht den Troll!
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?
Bronco schrieb: > Muß ich mich dann wirklich mit IOBs auseinander setzen? Macht das Ja. Welches Interface zum PHY wird benutzt, RGMII oder GMII?
Bronco schrieb: > > GMII Wenn ich mir das GMII Timing im Marvell Datasheet anschaue, ist das nur zuverlässig zu implementiern wie hier vorgeschlagen: Beitrag "Re: Wie ernst muß man verletzte Timing-Constraints nehmen?" d.h. Clock und InputFF müssen direkt in den IOBs implemtiert werden. Sobalds ins Innere des FPGAs geht, hast du verloren.
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?
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.