Ich lasse mein Design auf spartan3a 3s700afg484 bei 50 MHz laufen.
Es gibt keine Setup-and-Hold-Time-Verletzungen.
Es gibt nur ein globales Uhrennetz.
Mein Uhrbericht für zwei Läufe sind
LAUF 1:
Info: [707]: | Uhr Netz | Ressource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
Info: [707]: | clk_int | BUFGMUX_X2Y11| Nein | 2056 | 0,236 | 1.213 |
Die Post-PNR-Frequenz beträgt 140 MHz
Ich habe mein Design für einige Timing-Optimierungen zusammengestellt und die folgenden Ergebnisse erhalten.
LAUF 2:
Info: [707]: | Uhr Netz | Ressource |Locked|Fanout|Net Skew(ns)|Max Delay(ns)|
Info: [707]: | clk_int | BUFGMUX_X2Y11| Nein | 2049 | 0,216 | 1.191 |
Die Post-PNR-Frequenz beträgt 112 MHz
Beachten Sie, dass die Takt-Nettoverzögerung in RUN 2 geringer ist und ordnungsgemäß funktioniert.
Die Post-PNR-Frequenz ist in RUN 1 höher, aber Designs funktionieren auf FPGA nicht richtig
Der einzige Unterschied zwischen zwei Läufen besteht darin, dass RUN 2 mit einigen Timing-Optionen kompiliert wird. Ich habe die Post-PNR-Netzliste simuliert und es funktioniert gut.
Was kann ein mögliches Problem sein? Ich möchte, dass mein Design für RUN 1 richtig funktioniert, da es eine höhere Post-PNR-Frequenz hat. Wenn die Taktnetzverzögerung das Problem ist, wie kann man sie dann reduzieren?
Danke,
Ich verwende Xilinx-Chips und -Werkzeuge schon sehr lange. Die erste Version, die ich verwendet habe, war Foundation 2.1 vor etwa 20 Jahren. Ich mache viel mit FPGAs. Unnötig zu erwähnen, dass ich dabei einiges gelernt habe.
Eine Sache, die ich gelernt habe, ist, dass Sie kein Timing-Problem haben, wenn Ihre Timing-Einschränkungen korrekt eingerichtet sind und der Timing-Analysator sagt, dass Sie kein Timing-Problem haben. Komisch, wie das ist – ein Tool, das tatsächlich richtig funktioniert!
Das bedeutet, wenn Sie ein Timing-Problem haben, ist es wahrscheinlich, dass entweder Ihre Einschränkungen nicht richtig eingerichtet sind oder Sie etwas falsch machen in Bezug auf Signale, die asynchron zu Ihrer Uhr sind.
Das Durchführen einer Post-PAR-Simulation (mit Timing-Daten) garantiert keinen ordnungsgemäßen Betrieb. Tatsächlich würde ich argumentieren, dass für die meisten Designs mit einfachen Timing-Anforderungen eine Post-PAR-Timing-Simulation nichts bewirkt, was mit einer Verhaltenssimulation erreicht werden kann. Heutzutage mache ich deshalb überhaupt keine Timing-Simulationen mehr, und diese Entscheidung hat mich nie verbrannt.
Wie auch immer, der Punkt ist folgender: Die Chancen stehen gut, dass entweder Ihre Zeitbeschränkungen falsch sind oder Sie mit asynchronen Signalen etwas falsch machen.
Das Debuggen dieser Art von Problem ist schwierig, aber hier sind einige Tipps, wie Sie es angehen können:
Gehen Sie beim Debuggen akribisch und methodisch vor. Konzentrieren Sie sich auf das, was Sie über das Problem wissen, und folgen Sie ihm bis zur Quelle. Gehen Sie nicht mit der Schrotflinte vor und probieren Sie viele verschiedene Dinge aus, die verstreut sind. Konzentrieren Sie sich auf das bekannte Problem (Ausgangssignale sind falsch) und folgen Sie diesem zurück zum Fehler. Suchen Sie nicht einfach in den vielen Xilinx-Berichtsdateien nach Anomalien – denn es gibt viele Dinge, über die Sie sich Sorgen machen müssen, und fast keine davon sind wirkliche Probleme. Die Suche nach Anomalien wird Sie nur frustrieren.
pjc50
David Tweed
Quarz
user_1818839
David Tweed
Quarz
Quarz
David Tweed