Timing-Beschränkungen für die Überquerung von Taktdomänen für Altera

Ich habe ein kleines Problem mit den Zeitbeschränkungen meiner Taktdomäne.

Ich habe zwei Uhrengruppen

set_clock_groups -asynchronous -group {clk_A} -group {clk_B}

So wie ich es verstehe, werden alle Signale von clk_Aals clk_Bfalsche Pfade behandelt.

Ich möchte jedoch einige dieser Pfade als einschränken

set_max_delay -to [get_registers {*|*|some_reg}] 8

Aber wenn ich die Altera-Dokumentation richtig verstanden habe. Die impliziten falschen Pfade, die von den asynchronen Taktgruppen erzeugt werden, bewirken, dass die spätere Einschränkung ignoriert wird.

Im Moment ist es mir ein Rätsel, warum eine spezifischere Einschränkung weniger Priorität hat als die allgemeinere.

Hat jemand dies auf praktische Weise gelöst, oder muss ich die Verwendung von Uhrengruppen einstellen und alle relevanten Pfade manuell einschränken?

Antworten (2)

Obwohl es in der Branche ziemlich üblich ist, alle Pfade zwischen zwei Clock-Gruppen global zu unterbrechen, würde ich dringend von dieser Praxis abraten, da es sehr schwierig ist, Stellen zu erkennen, an denen Sie ein Signal unbeabsichtigt zwischen Clock-Domänen neu abgetastet haben.

Verwenden Sie besser einen gemeinsamen Block für die Datenübertragung zwischen Domänen. Betten Sie die Einschränkungen in den gemeinsamen Block ein oder verwenden Sie Platzhalter in den Pfaden, um jede Instanz des Blocks in Ihrem Design einzuschränken. Machen Sie die Verwendung eines gemeinsamen Synchronisationsblocks zu einem Teil Ihrer Codierungsrichtlinien.

Sie können dann alle Clock-Domain-Kreuzungen melden und Stellen finden, an denen Sie keinen sicheren Übertragungsmechanismus verwendet haben. Sie können auch eine automatische Überprüfung in Ihren Ablauf integrieren und versehentliche Taktkreuzungen in Ihrem Design schnell lokalisieren.

Sie werden auch in der Lage sein, Ihre Einschränkung zu verwenden set_max_delayund sie nicht ignorieren zu lassen :)

Dies deckt sich mit meiner eigenen Erfahrung. Das Entfernen von Beschränkungen für asynchrone Taktgruppen und das Ersetzen durch falsche Pfade (und Inline-Einschränkungen in Synchronisierern) hilft, Fehler frühzeitig zu finden.

+1 für @chiggs-Kommentare, die darauf hindeuten, dass Sie keine Wege zwischen Domänen schneiden. Es ist einfach durchzuführen und funktioniert oft, aber es kann fehlschlagen, wenn die P&R-Werkzeuge stark beansprucht werden, z. B. wenn das Teil fast voll ist.

Wenn Sie set_max_delay verwenden, müssen Sie auch set_min_delay verwenden. Beachten Sie, dass es aufgrund der Art und Weise, wie Pfade analysiert werden, zu negativen Verzögerungen kommen kann. Wenn Sie beispielsweise ein 8-ns-Fenster anstreben, können Sie die minimale Verzögerung auf -1 und die maximale Verzögerung auf 7 setzen. Obwohl Sie jedoch die gesamte Fenstergröße (auch bekannt als Skew) kennen, die Sie anstreben, alle Sie Sie können nur eine fundierte Vermutung anstellen, wo das Fenster in Bezug auf den Takt, [-1,7] oder [-2,6] usw. platziert werden soll. Aus diesem Grund ist dieser Ansatz nicht unbedingt optimal, insbesondere für hohe Takte Preise.

Was Sie letztendlich für die funktionale Korrektheit wirklich interessiert, ist der Versatz zwischen den Netzen, die die Grenze überqueren. Und der beste Weg, dies zu spezifizieren, ist mit einer maximalen Schräglaufbeschränkung. Informationen zur Verwendung finden Sie in der Altera-Dokumentation für set_max_skew