Wie/wann wissen wir bei einem HDL-Design, dass wir einen multi_cycle-Pfad benötigen, wie implementieren wir ihn?

Sie haben eine Reihe sehr allgemeiner Fragen gestellt, daher werden meine Antworten zwangsläufig auch sehr allgemein sein. Wenn Sie ein bestimmtes Beispiel haben, das Sie diskutieren möchten, fügen Sie es Ihrer Frage hinzu.

Wie kann man bei einem HDL-Design vorhersagen, dass die kombinatorische Logik zwischen zwei Registern mehr als ein Taktzyklus betragen soll und daher die Multi_cycle-Pfadbeschränkung verwendet werden muss?

Es ist im Design implizit. Wenn das Ergebnis in einem Taktzyklus verfügbar sein soll (wie durch das Verhalten angegeben), muss der Taktzyklus so lang wie erforderlich sein, um dies zu ermöglichen. Wenn das Verhalten so geschrieben ist, dass 2 oder 3 Taktzyklen für das Ergebnis zulässig sind, müssen Sie an dieser Stelle auch die Multi-Cycle-Einschränkung hinzufügen. Letzteres tut man nicht, ohne auch ersteres zu tun.

Abgesehen davon, wie können wir für ein HDL-Design, bei dem wir möglicherweise nicht genau wissen, von welchen Registern wir sprechen, eine Multi_cycle-Pfadbeschränkung einfügen?

An diesem Punkt müssen Sie die Abstraktion auf hoher Ebene aufgeben und sich mit den Implementierungsdetails befassen, die von den Synthesewerkzeugen bereitgestellt werden. Es kann anfangs schwierig sein, die Berichte zu entziffern, aber mit der Erfahrung wird es einfacher.

Ist es wichtig, dass diese Verzögerung sowohl unter den besten als auch unter den schlechtesten Bedingungen mehr als 1 Taktzyklus beträgt?

NEIN.

So weit ich das verstehe. Wir synthetisieren zuerst unser Design und wenn die Ausbreitungsverzögerung der Gatter zwischen zwei Registern groß genug ist, dann wissen wir, dass wir diese Einschränkung brauchen. Dies muss vor dem Monteur geschehen, da sich nach dem Einbau auch die Routing-Verzögerung summiert. Ist das richtig?

Art von. Die Synthese-Tools werden hart daran arbeiten, die Logik so zu implementieren, dass sie die bereits festgelegten Zeitbeschränkungen erfüllt, einschließlich Routing-Verzögerungen. Wenn es nicht kann, wird es Ihnen sagen.

Fortgeschrittene Tools wissen sogar, wie man Logik von einer Seite eines Registers auf eine andere verschiebt, um die Ausbreitungsverzögerungen auszugleichen und die erforderliche Taktperiode zu minimieren.

Können wir den Fitter auch zwingen, die Logik so anzupassen, dass es 2 Taktzyklen dauert, bis Daten das Latch-Register erreichen?

Im Allgemeinen nein. Aber es gibt keine wirkliche Notwendigkeit, dies zu tun.

Meine Verwirrung besteht, weil wir uns bei einem HDL-Design auf einer höheren Abstraktionsebene befinden und nicht über alle physischen Register Bescheid wissen, die im Design vorhanden sind, es sei denn, wir führen eine STA auf der Post-Synthese-Netzliste durch.

Hohe Abstraktionsebenen sind bis zu einem gewissen Punkt eine Geldstrafe, aber wenn Sie wirklich daran interessiert sind, die beste Leistung aus Ihrem Design herauszuholen, müssen Sie bereit sein, sich mit dem RTL-Code (Register-Transfer-Level) zu befassen, in dem Sie sich ausdrücklich auskennen wo die Register sind und welche Logik zwischen ihnen läuft.

Mein eigener Hintergrund ist der eines EE, also schreibe ich meinen synthetisierbaren Code immer als RTL, da ich so über das Hardwaredesign denke. Ich verwende in meinen Simulationstestbenches nur übergeordneten, reinen Verhaltenscode, der niemals synthetisiert werden soll.