ASIC-Timing-Einschränkungen über SDC: Wie kann man einen Ripple-Divided-Clock korrekt angeben?

Einführung

Nachdem ich im Internet und in einigen Schulungen mehrere, manchmal widersprüchliche oder unvollständige Informationen darüber gefunden habe, wie man Timing-Constraints im SDC-Format korrekt erstellt, möchte ich die EE-Community um Hilfe bei einigen allgemeinen Takterzeugungsstrukturen bitten, auf die ich gestoßen bin.

Ich weiß, dass es Unterschiede gibt, wie man eine bestimmte Funktionalität auf einem ASIC oder FPGA implementiert (ich habe mit beiden gearbeitet), aber ich denke, es sollte einen allgemeinen, korrekten Weg geben, das Timing einer bestimmten Struktur unabhängig davon einzuschränken zugrunde liegende Technologie - lassen Sie es mich bitte wissen, wenn ich da falsch liege.

Es gibt auch einige Unterschiede zwischen verschiedenen Tools zur Implementierung und Zeitanalyse verschiedener Anbieter (obwohl Synopsys einen SDC-Parser-Quellcode anbietet), aber ich hoffe, dass es sich hauptsächlich um ein Syntaxproblem handelt, das in der Dokumentation nachgeschlagen werden kann.

Bitte beachten Sie auch die verwandte Frage ASIC-Timing-Einschränkungen über SDC: Wie wird ein Multiplex-Takt korrekt angegeben?

Frage

Hier geht es um den folgenden Ripple-Clock-Teiler, der Teil des clkgen -Moduls ist, das Teil eines größeren Designs ist, das die Erzeugungsuhren verwendet:

Ripple-Clock-Teiler

Die Generierung von clk0scheint relativ einfach zu sein:

create_clock [get_pins clkgen/clk0] -name baseclk -period 500

Obwohl ich mir bei den SDC-Befehlen für die generierten, geteilten Uhren clk2, clk4und nicht so sicher bin clk8: Wie sollten die Quell- und Zieloptionen angegeben werden? Mein anfänglicher Gedanke war, dass das Ziel der Ausgangspin der takterzeugenden Zelle ist, die Quelle so nah wie möglich am Ziel ist:

create_generated_clock -name div2clk -source [get_pins clkgen/divA/clk] -divide_by 2 [get_pins clkgen/divA/q]

Die Quelle könnte auch der Takteingangspin des Moduls sein:

create_generated_clock -name div2clk -source [get_pins clkgen/clk0] -divide_by 2 [get_pins clkgen/divA/q]

Oder die zuvor definierte Quelluhr , wie hier vorgeschlagen :

create_generated_clock -name div2clk -source [get_clocks baseclk] -divide_by 2 [get_pins clkgen/divA/q]

...was auch die Frage aufwirft, ob die Quell- oder Zieloptionen etwas anderes als sein müssen get_pins, wie zum Beispiel get_nets, get_registersoder get_ports.

Um das Beispiel so allgemein wie möglich zu halten, nehmen wir an, dass die generierten Takte clk2, clk4und clk8andere, potenziell interagierende (Clock Domain Crossing) Register ansteuern könnten (nicht im Schema gezeigt).

Ich denke, die Einschränkungen für clk4und clk8sollten offensichtlich sein, sobald wir wissen, wie die clk2Einschränkung geschrieben ist.

Die X1 -Instanz (ein einfacher Puffer) im Schaltplan ist nur ein Platzhalter, um hervorzuheben, wo im Clock-Propagation-Netzwerk die Source- Option des create_generated_clockgesetzt werden sollte, da automatische Place&Route-Tools normalerweise frei sind, Puffer überall zu platzieren (z wie zwischen den divA1/qund divB1/clkPins).

Antworten (1)

Ich würde sagen, die Faustregel lautet: Stellen Sie entweder den Eingangsport des oberen Moduls oder den Q-Pin eines internen Flip-Flops als Quelle des generierten Takts ein.

Beispiel Verilog-Code:

module top (

input clk,
input rst,

...

);

...

always @(posedge clk or negedge rst)
begin
if (rst == 1'b0) 
    div_2_clk = 1'b0;
else
    div_2_clk = ~div_2_clk;           
end

...

endmodule

Beispiel SDC-Code:

create_clock -name clk -period 5 [get_port clk]
...
create_generated_clock -name slow_clk -source [get_port clk] -divide_by 2 [get_pins div_2_clk_reg/Q]

Ich habe die obige Syntax nicht getestet. Beachten Sie auch die Erweiterung _reg, die dem RTL-Namen des Signals hinzugefügt wurde - dies ist die Erweiterung, die vom Synthesetool hinzugefügt wird, wenn es erkennt, dass das Signal durch ein Flip-Flop dargestellt werden muss. Diese Erweiterung kann zwischen den Tools variieren (ich weiß es nicht genau).

Wenn Sie einen RTL-Wrapper um Flip-Flops verwenden, stellen Sie die Quelle der generierten Takte auf den internen Q-Pin des Flip-Flops ein, nicht auf den Ausgangs-Pin des Wrappers.

Wenn Sie diese einfachen Regeln befolgen, müssen Sie sich keine Gedanken über Puffer machen, die von den Synthese- oder P&R-Tools hinzugefügt werden.

Danke für deine Antwort! Bedeutet das, dass der Timing-Analysator die Verzögerungen des Pfads (und des potenziell eingefügten Puffers) zur Latenz der (erzeugten) Takte hinzufügt? Sollte meine erste SDC-Leitung daher create_clock [get_ports clk0]stattdessen sein (vorausgesetzt, clk0es handelt sich um den Top-Level-Port)? Wenn Sie das in Ihre Antwort aufnehmen und auch mindestens ein vollständiges Beispiel der create_generated_clockAussage hinzufügen könnten, würde ich es gerne akzeptieren!
@FriendFX, ich habe einige Codeschnipsel hinzugefügt, aber behandle sie mit Vorsicht - sie sind nicht verifiziert.
danke für den SDC-Schnipsel (brauchte den Verilog nicht). Bedeutet dies für die create_*clockBefehle, dass der Timing-Analysator die Verzögerungen des Pfads (und des potenziell eingefügten Puffers) zur Latenz der (erzeugten) Takte hinzufügt?
@FriendFX, was meinst du mit "der Latenz der (erzeugten) Uhr"? Latenz in Bezug auf was? Seine Quelluhr? Wenn ja, dann sind Sie wahrscheinlich an etwas interessiert, das mit der Überquerung der Uhrendomäne zwischen diesen Uhren zu tun hat?
Was ich meinte, war, ob die Pfadverzögerung vom zum sourcezum targetin einer generierten Uhr alle Puffer enthält, die das P&R-Tool zwischen diesen Knoten einfügen könnte?
@FriendFX, ich bin mir nicht sicher, ob ich diese Frage beantworten kann, ohne zu verstehen, warum Sie an einer Verzögerung zwischen diesen Uhren interessiert sind. Im Allgemeinen werden alle Verzögerungen im Taktbaum berücksichtigt (Puffer, Muxes, High-Fanout-Netze usw.), sobald Sie eine Timing-Analyse im Post-P&R-Schema durchgeführt haben.
Meine einzige Sorge war, dass ich in den Best Practices für den Quartus II TimeQuest Timing Analyzer gelesen habe , dass „die -sourceOption auf den nächstgelegenen Clock-Pin des angegebenen Ziels verweisen sollte “ . In diesem Fall kann die -master_clockOption trotzdem verwendet werden. Ich möchte nur sicherstellen, dass ich den Timing-Analysator nicht daran hindere, alle Verzögerungen richtig zu berücksichtigen.
Zu Ihrer Frage "Warum interessieren Sie sich für Verzögerungen zwischen diesen Takten": Wenn in meinem Beispiel Datenpfade von Register zu Register zwischen clk0und clk4vorhanden sind, müssen Verzögerungen im Taktnetzwerk zwischen clk0und clk4durch das Timing berücksichtigt werden Analysator für diese Pfade, habe ich recht?
@FriendFX, ich kann die Quartus-spezifische Frage nicht beantworten, da ich die FPGAs von Altera noch nie verwendet habe. Wenn Sie einen Pfad zwischen den Registern clk0und haben clk4, definieren Sie ihn entweder als falschen Pfad (wenn sich die Uhren gegenseitig ausschließen, wenn Sie Synchronisierer verwenden, ...) oder als Multi-Cycle-Pfad. Im ersten Fall sollte das Tool keine Timing-Analyse durchführen und es liegt an Ihnen, sicherzustellen, dass kein logischer Fehler auftreten kann. Im letzteren Fall wurden alle relevanten Verzögerungen von anderen Tools berücksichtigt, die ich gesehen habe.
Ich möchte auch nicht Quartus-spezifisch werden. Leider habe ich keine anderen (ASIC-bezogenen) SDC-Ressourcen gefunden, die auch nur auf diese Details eingehen - alle Hinweise wären willkommen! Ich hoffe, dass SDCs universell genug sind, um über Tools und Flows hinweg angewendet zu werden, wie in meiner ursprünglichen Frage erwähnt.
@FriendFX, ich habe keine guten Referenzen, die ich dir geben könnte. Versuchen Sie, das Synopsis Design Compiler User's Guide zu finden - ich vermute, dies ist die Quelle der vollständigsten Dokumentation.
Ich habe es hier gefunden , aber leider enthält es keine Einzelheiten zum create_generated_clockSDC-Befehl. Ich habe deine Antwort akzeptiert. Vielleicht starte ich -sourceirgendwann eine separate Frage zu den Details der Option. Danke für Ihr Bemühen!