Timing-Warnungen für Funktionsmodell

Ich schreibe einen Controller für ein Low-Power-/mobiles DDR-Modul auf meinem FPGA. Um das Debuggen zu ermöglichen, verwende ich ein in Verilog geschriebenes Funktionsmodell. Darin ist die Setup- und Haltezeit für einige Signale auf 1,5 ns eingestellt. Wenn ich alles richtig verstehe, bedeutet dies, dass sich das Signal nicht 'innerhalb' von 1,5 ns einer steigenden Taktflanke ändern kann.

Die RTL, die ich geschrieben habe, enthält jedoch kein Timing, sodass sich das Signal scheinbar sofort ändert, was zu Haltezeitwarnungen führt.

Einerseits mache ich mir keine allzu großen Sorgen; Ich bekomme nur Warnungen, und ich glaube, dass wir während eines Projekts für meine Universität aufgefordert wurden, diese Fehler einfach zu ignorieren.

Andererseits mag ich es nicht, Warnungen zu ignorieren. Der Hersteller hätte diese Warnungen nicht implementiert, wenn sie keinen Zweck hätten. Da Xilinx ISE in der Lage ist, Timing-Einschränkungen zu überprüfen, sollte es meiner Meinung nach möglich sein, mein Design zu routen und abzubilden und die generierten Timings irgendwie zu verwenden (aber vielleicht mache ich die Dinge hier zu einfach).

Ich bin sicher, es gibt noch mehr Leute mit dem gleichen Problem. Wie geht man mit diesen Warnungen richtig um?

Bearbeiten: Auf dieser Seite habe ich weitere Informationen gefunden. Sie können ein Post-Map- oder Post-Place-and-Route-Simulationsmodell generieren. Ich vermute, dass dies die Timings beinhaltet. Es scheint jedoch, dass nur Modelsim die Simulation tatsächlich durchführen kann.

Klarstellung: Im Idealfall wäre ich in der Lage, meinen Teil des Designs zu synthetisieren (oder zumindest so weit wie möglich im Prozess der Erstellung des Layouts zu kommen) (ich habe die RTL und ich habe das Board spezifiziert, also denke ich, dass dies so sein sollte). möglich), dann kombiniere es in einer Testbench mit dem Funktionsmodell, um zu testen, ob mein Design die richtigen Timing-Verzögerungen hat. Ich kann dies jedoch nicht in Xilinx ISE 14.7 zum Laufen bringen.

Antworten (3)

Wie dave_59 betonte, sind Timing-Checks bei RTL nicht sehr aussagekräftig. Hier sind 4 mögliche Ansätze:

  1. Stellen Sie die Timing-Checks nicht mit RTL zusammen
  2. Verwenden Sie ein Compiler-Direktiven-Makro ( `ifdef ... `endif) um Ihre Timing-Prüfungen herum; Timing-Checks bei RTL deaktiviert
  3. Fügen Sie Haltezeit in das RTL-Verhalten ein, indem Sie alle Flop-Zuweisungen ( <=) auf ändern <= `D, wobei `Da Ihre Verzögerung ist (z. B. `define D #2)
  4. Hacken Sie Ihre Dame, um ein Maskierungsattribut zu haben. ex:
    $setuphold( D, CLK &&& actiming_enable, tSETUP, tHOLD);
Aber wenn ich die RTL habe und weiß, auf welches FPGA ich abbilden werde (ich kann den Bitstream erzeugen), ist im Wesentlichen das gesamte Layout bekannt. Sollte ich nicht in der Lage sein, die Timings zu generieren, da ich alle notwendigen Informationen habe?
Die Synthese ist einer der Schritte, um diese Informationen zu erhalten. Sie könnten eine Simulation mit synthetisierten Gattern mit SDF-Anmerkung ausführen, aber das ist keine RTL-Simulation. Die RTL-Simulation dient der Validierung der Logik. Die Verilog-Gate-Simulation ist eine Plausibilitätsprüfung für Timing und logische Äquivalenz (es gibt spezielle Tools für jedes, die eine umfassendere Arbeit leisten als die Gate-Simulation).

Setup-and-Hold-Timing-Checks sind nur mit Post-Layout-Informationen sinnvoll. Vor einem Jahrhundert konnten Sie Timing-Analysen ohne Layout-Strukturinformationen durchführen, da die Geräteverzögerungen im Vergleich zu Routing-Verzögerungen überwältigend waren. Sie können mit RTL-Code keine genaue Timing-Analyse mehr durchführen.

Einige Modelle sind so geschrieben, dass sie sowohl in RTL- als auch in Struktursimulationen verwendet werden können, sodass Sie diese Warnungen ignorieren können. Noch besser wäre es, die Timing-Checks auszuschalten, was die RTL-Simulationsleistung verbessert (vielleicht nicht relevant für Ihr Projekt, aber das, was die Leute in der Industrie tun).

Das ist nicht wirklich wahr. Es werden ständig sehr genaue Timing-Modelle ohne endgültige Layout-Informationen generiert. So werden MCUs generiert. Jeder Block wird unabhängig getaktet und jeder I/O in Bezug auf Setup/Hold/Delay/Load/Slew-Raten charakterisiert. Andernfalls würde es Milliarden von Dollar kosten, nur auf einem Chip zu iterieren. Da er ein FPGA programmiert, muss es eine Möglichkeit geben, ihm mitzuteilen, dass es seine RTL in ein physisches Board-Mapping synthetisieren soll. Von hier aus ist R/C in einer bewährten FPGA-Technologie sehr vorhersagbar.
@ jbord39 für größere/schnellere FPGAs können Sie kein genaues Timing für RTL erhalten, da es so stark vom Routing abhängt. Das gleiche Design in einem Teil eines FPGA kann das Timing treffen, aber ein etwas anderes Routing/Platzierung kann zu einer zusätzlichen Routing-Verzögerung und einem fehlerhaften Timing führen – selbst wenn die RTL in beiden identisch ist .
@TomCarpenter: Ich wollte nichts anderes andeuten, das Routing wird zu Verzögerungen führen, wenn die Technologien kleiner werden. Aber die Software soll eine Probeschaltung von RTL machen können. Von hier aus weiß es, wie weit die Drähte gehen müssen, und das Fanout jedes Gates (zusammen mit Antriebsleistung). Es sollte auch in der Lage sein, den Widerstand / die Kapazität jedes Drahtes abzuschätzen. Sobald es eine Probeplatzierung hat, sollte es in der Lage sein, fast alle Parameter genau abzuschätzen. Wenn das Timing schlecht ist, kann es neu gestartet und erneut platziert werden. Aber es kann einige Gründe geben, warum dies nicht möglich ist, an die ich nicht denke.
@ jbord39 RC jeder Route ist nicht ganz nützlich. Alle Routing-Switches (die im Grunde nur SRAM sind) machen ziemlich viel aus. Heutzutage enthalten die Timing-Modelle typischerweise die Verzögerung für jedes Segment jedes Pfads und typische Verzögerungen für jeden Multiplexer, sodass die gesamte Pfadverzögerung berechnet werden kann, sobald Sie den Pfad kennen. Aber das Durchführen einer "Probeplatzierung" unterscheidet sich so gut wie nicht davon, nur eine vollständige Designsynthese/Anpassung/Routing durchzuführen und dann die Simulation mit einer Post-Fit-Netzliste (anstelle von RTL) durchzuführen.
@TomCarpenter: Nun, die Probeplatzierung und das Timing mit geschätzten Parasiten ist viel schneller als die vollständige Layoutextraktion (und ist notwendig, um Sie die meiste Zeit in den richtigen Bereich zu bringen). Ich meine, 5 Minuten für einen 500-Gate-Testplatz + Route + Timing im Vergleich zu sonst vielleicht 10 Stunden. Tools können auch Verzögerungsänderungen aufgrund von Schaltrauschen verarbeiten (Signalintegrität). Moderne CPUs sind nicht einmal alle zusammen getaktet. Jedes Stück ist in ein bestimmtes Format (Bibliothek) gekennzeichnet, und diese werden auf der obersten Ebene unter Verwendung der Bibliotheken zeitlich festgelegt. Spice kann für die Teile der unteren Ebene verwendet werden, aber nicht für den Block der obersten Ebene.

Es sollte eine Möglichkeit geben, eine Zeitverzögerung einzugeben.

Dies könnte auf ein paar Arten geschehen, die mir einfallen (vielleicht mehr):

  • Ändern Sie das Start-Flip-Flop so, dass es eine Takt-> Aus-Verzögerung hat, die größer ist als die Haltezeit des Capture-Flip-Flops.
  • Ändern Sie das Flip-Flop-Modell so, dass es eine Haltezeit von -0,1 ns hat.
  • Ändern Sie jedes Gate (wie einen Puffer) so, dass es eine feste Verzögerung von 1,6 ns hat, und setzen Sie diese vor jedes Capture-Flip-Flop.
  • Verschieben Sie das Taktsignal am Erfassungs-Flip-Flop (zweites Flop, das die Halteverletzung erfährt) um mindestens 1,5 ns relativ zum Starttakt (geht zum ersten Flip-Flop).

Die meisten davon umfassen das Modifizieren der Darstellung eines Gatters oder Puffers, um eine Verzögerung einzubeziehen. Wenn Sie .libs für die Charakterisierung verwenden, können Sie einfach die gesamte Lade-/Slew-/Verzögerungstabelle auf einen Standardwert von 2 ns setzen.

Wie sind Sie auf diese Zeiten gekommen? Kann ich sicher sein, dass sie korrekt sind? Ich würde lieber einen automatisierten Prozess verwenden, der Zeitschätzungen für mich bereitstellt (um es mir schwerer zu machen, Fehler zu machen).
@Ruben: Es kommt darauf an, Sie müssen sich ansehen, welches Modell Sie verwenden, um dies herauszufinden. Aber da Sie sagen, dass es keine Verzögerung durch Logikgatter und eine flache Setup- und Haltezeit von 1,5 ns für die Latches gibt, kann ich Ihnen sagen, dass sie NICHT genau sind. Jedem Logikgatter sollte eine Verzögerung zugeordnet sein (mindestens flache Verzögerung). Genauere Verzögerungsmodelle für PnR werden unter Verwendung einer Last/Steigungstabelle charakterisiert.
Timing-Warnungen für Funktionsmodell
AntwortenHierDatenschutz-Bestimmungen1y, 0v