So nützen Sie XDC-Timing-Constraints in FPGA-Designs richtig

Anbieter zum Thema

MES Electronic Connect GmbH & Co. KG

Xilinx UK

Nachdem man die Takt-Gegebenheiten identifiziert hat, kann man nun die Bedingung “set clock group” dazu verwenden, um die für sie geltende Timing-Analyse zu deaktivieren. Die Vivado-Suite verwendet die Xilinx Design Constraints (XDC). Sie basieren auf den Synopsys Design Constraints (SDC), einem weithin gebräuchlichen, Tcl-basierten Constraint-Format. Mit den XDC-Constraints kann man den folgenden Befehl zur Definition einer Taktgruppe nutzen:

Bildergalerie

Darin ist –name der dieser Gruppe zugewiesene Name. Die Option –group ist die Stelle, an der man die Mitglieder der Gruppe definieren kann, also die Takte, die keine Timing-Beziehung haben. Die logisch und physisch exklusiven Optionen werden eingesetzt, wenn mehrere Taktquellen vorliegen, aus denen man wählen kann, um einen Clock Tree (baumartige Taktstruktur) zu treiben, einschließlich BUFGMUX und BUFGCTL. Deshalb können die Takte am Clock Tree nicht alle zur gleichen Zeit präsent sein. Im Allgemeinen will man nicht, dass Vivado die Beziehungen zwischen diesen Takten analysiert, da sie sich gegenseitig ausschließen. Die asynchrone Bedingung wird verwendet, um asynchrone Taktpfade zu definieren.

Der abschließende Gesichtspunkt bei der Erstellung der Timing-Beziehung ist die Berücksichtigung der nicht-idealen Beziehung zwischen den Takten, speziell in Bezug auf Jitter. Den auftretenden Jitter muss man in zwei Erscheinungsweisen betrachten: Eingangs- und System-Jitter. Der Eingangs-Jitter tritt an den primären Takteingängen auf. Er ist die Differenz aus seinem Wert beim Auftreten des aktuellen Übergangs und dem Zeitpunkt des Auftretens unter idealen Bedingungen. Der System-Jitter resultiert aus dem im Design existierenden Rauschen.

Man kann die Bedingung set_input_jitter nutzen, um den Jitter für jeden primären Eingangs-Takt zu definieren. Dabei gilt der Wert des System-Jitters für das gesamte Design (also alle verwendeten Takte) bei der Nutzung der Bedingung set_system_jitter.

Timing-Ausnahmen

Ein weiteres Problem erfordert unbedingte Beachtung: Was geschieht in einer definierten Taktgruppe, wenn eine Ausnahme vorliegt. Frage: Was ist eine Ausnahme?

Ein typisches Beispiel für eine Timing Exception ist ein Ergebnis, das nur bei jedem zweiten Taktzyklus beobachtet wird. Ein weiteres ist der Datentransfer von einem langsameren in ein schnelleres Taktsystem (oder umgekehrt), wenn beide Takte synchron sind. Diese beiden Situationen sind somit auch Beispiele für eine Timing Exception, die meist als Multicycle Path bezeichnet wird (siehe Bild 2).

Die Deklaration eines Multicycle Path für diese Pfade führt zu einer besser angemessenen und weniger restriktiven Timing-Analyse. Damit kann die Timing Engine auf Andere, kritischere Pfade fokussieren. Das resultiert in einer höheren Qualität der Ergebnisse.

In der XDC-Datei lässt sich ein Multicycle Path mit dem folgenden XDC-Befehl deklarieren:

Wenn man einen Multicycle Path deklariert, multipliziert man im Grunde die Anforderungen für die Setup- und die Hold-Analyse (oder beide) mit path_mutiplier. Beispielsweise hat im ersten angeführten Beispiel, bei dem das Ausgangssignal nach jeweils zwei Taktzyklen erscheint, der path_multiplier für das Setup-Timing die Größe Zwei.

(ID:44009087)