Bradward B. schrieb:
Moin,
Vielleicht kann man ja diese Einarbeitung mit Hilfe eines
Frage-Antwort-Dialogs mit einer AI verbessern/verkürzen ?! Man kann ja
nicht immer auf den nächsten workshop/Experten warten.
Hier kommt was der AI experte (claude) sagt:
Ethernet Lite / RMII: gleiches Projekt, drei Builds, nur einer fällt aus
Wir haben ein Problem, bei dem ich noch nicht am Ende bin – vielleicht hat jemand eine Idee.
Gleiches Projekt, drei Builds: für -2C, -2I und -1I. Getestet wird auf -1I-Silizium. Die Bitstreams für -2C und -2I laufen dort einwandfrei. Mit dem -1I-Bitstream funktioniert der Ethernet-Lite-RMII-Transmit bei manchen Platinen nicht – aber nicht bei allen.
(Nebenbei: -2C und -2I sind timing-identisch, der Buchstabe ist nur der Temperaturbereich. Wir haben also effektiv zwei Platzierungen verglichen, nicht drei Speed Grades.)
Der Fehler folgt damit dem Bitstream, nicht der Platine – dieselbe Platine läuft mit dem einen Build und nicht mit dem anderen. PCB und Hardware sind erst mal entlastet.
Das Interessante: das -1I-Design erfüllt das Timing. WNS 214 ps, WHS 50 ps, TNS und THS null, auf dem richtigen, langsameren Silizium. Es ist also kein Timing-Verstoß, den man schließen könnte, sondern ein Pfad, den die statische Timing-Analyse gar nicht abdeckt. Und die Richtung passt dazu: der konservativere Build fällt aus, der aggressivere läuft. Das spricht gegen Marge und für Routing-Glück.
Zwei Fehlerbilder, die ich für dieselbe Ursache halte:
- Ethernet geht nicht, keine Pakete gehen raus.
- Linux-Boot friert in
xemaclite_update_address ein – seltener, kommt aber vor. Der Treiber setzt dort das PROG_MAC_ADDR-Bit und pollt ohne Timeout, bis die TX-State-Machine es löscht. Passiert ohne angeschlossenes Kabel, es ist also kein PHY- und kein RX-Problem.
Was ich bisher gefunden habe:
Das ganze Design liegt in der rechten Hälfte des Chips, die RMII-Pins sitzen aber links. Die RMII-Eingangsregister lagen nicht im IOB, sondern in der Fabric, mit 3,7 ns Routing vom IO-Buffer zum Flipflop. Ursache war banal: falsche Pin-Namen in meinem XDC, und ein set_property auf eine leere Objektliste ist ein No-op ohne echte Meldung. Nach der Korrektur sind alle sechs Pins im IOB, ein Pblock nahe der RMII-Bank hat vorher schon von 3,7 auf 1,1 ns geholfen. Real, aber es erklärt Fehlerbild 2 nicht.
Besser passt, was im Methodology Report steht:
- TIMING-4: primary clock redefinition auf einem Clock Tree (2x)
- XDCC-1 / XDCC-7: zwei scoped Constraints überschreiben sich auf derselben Source
- TIMING-6 / TIMING-7: fünf Clock-Paare ohne gemeinsamen primary clock bzw. ohne gemeinsamen Knoten
Letzteres heißt, dass diese Pfade gegen eine Launch-Capture-Beziehung geprüft wurden, die es physikalisch nicht gibt – „Timing met“ sagt dort also nichts. Der AXI-Takt von Ethernet Lite kommt bei uns nicht vom Systemtakt, sondern vom PHY-Referenztakt (50 MHz, eigener Oszillator). Wenn dieses Clock-Paar in den fünf steckt, wäre ein AXI-Zugriff, der nie zurückkommt, eine saubere Erklärung für den Freeze: die CPU hängt dann im Load, nicht in der Poll-Schleife.
Den Methodology Report konnte ich nicht als Text kopieren, also Screenshot an eine KI gegeben – OCR gemacht und einsortiert, welche Warnungen relevant sind und welche nicht. Das hat gut funktioniert. Grobe Regel, die dabei herauskam: was in AMD-IP-Cores liegt (LUT-getriebene asynchrone Resets zum Beispiel), kann man weitgehend beiseitelegen; was aus dem eigenen XDC kommt, nicht.
Falls jemand TIMING-6/7 in einem IPI-Design schon mal aufgelöst hat, oder eine Meinung dazu, ob man den AXI-Takt von Ethernet Lite überhaupt vom PHY-Referenztakt nehmen sollte: ich nehme Hinweise.
Das ist ein Projekt wo ich schon viel AI generiertes TCL ausprobiert habe! Das Projekt ist schon mehrere Jahre alt, es kam nie Probleme, bis jetzt wo wir große Ausfall rate sehen bei Platinen Tests.
