Einschränken synchroner Uhren auf unterschiedliche Frequenzen in VHDL

Ich habe ein Design mit einem FPGA, einer MCU und anderen externen Peripheriegeräten, die über einen parallelen Peripheriebus miteinander verbunden sind.

Das gesamte System wird von zwei synchronen Uhren getaktet. Die Takte sind ein 32-MHz-Oszillator und ein 16-MHz-Takt, der durch Teilen des 32-MHz-Oszillators durch zwei durch ein Flip-Flop erzeugt wird.

Der 16-MHz-Ausgang des Flip-Flops wird zum Takten der MCU verwendet, außerdem wird eine PLL in der MCU verwendet, um einen 16-MHz-Peripheriebus-Taktausgang nachzubilden. Und dieser 16-MHz-Peripheriebus-Ausgang taktet zusammen mit dem ursprünglichen 32-MHz-Oszillator das FPGA.

Das FPGA wird also von zwei Takten angesteuert, die durch die Laufzeit des Flip-Flops (8 ns) und die Phasenverzögerung des PPL (5 ns) verschoben sind. Aber ansonsten sind sie synchron. Insgesamt hier angezeigt.

System

Hier ist also der knifflige Teil, wie kann ich diese einschränken, um Quartus dazu zu bringen, die Beziehung zwischen diesen beiden in der Zeitanalyse zu berücksichtigen. Das Standardverhalten besteht darin, ihre interne Beziehung als 0,05 zu betrachten, was nicht wirklich stimmt. Da das Minimum die Periode des langsameren Takts oder des gesamten langsameren Takts wäre, wenn Mehrfachzyklen von zwei zulässig sind. Die Standardbeziehung führt automatisch dazu, dass das Design die Timing-Analyse nicht bestanden hat, und das Ignorieren der beiden Domänen zusammen mit der asynchronen Taktgruppendefinition ist auch nicht wirklich sinnvoll, oder? Es scheint, als ob eine statische Zeitanalyse möglich sein sollte, da sie "flankensynchron" sind, jedoch bei unterschiedlichen Frequenzen.

Die Spalten sind Uhr1, Uhr2, Beziehung, Taktverschiebung, Datenverzögerung.

Geben Sie hier die Bildbeschreibung ein

Bisher habe ich versucht, sie zusammen zu gruppieren, und nicht zusammen mit der set clock group-Anweisung. Wie zum Beispiel.

set_clock_groups -asynchronous \
-group { external_clock  } \
-group {    processor_clock }

Zusätzlich bei Verwendung der Multicycle-Definition

set_multicycle_path -setup -from [get_clocks {cpu_clk}] -to [get_clocks {e_clk}] 2
set_multicycle_path -hold -from [get_clocks {cpu_clk}] -to [get_clocks {e_clk}] 2

Aber das Ergebnis ist entweder das völlige Ignorieren der domänenübergreifenden Interaktion oder eine unveränderliche Beziehung von 0,05.

Die Uhren sind definiert als

create_clock -name external_clock -period 31.2 [get_ports e_clk]
create_clock -name processor_clock -period 62.5 [get_ports cpu_clk]

Wie würden Sie dies einschränken.

Der Grund für die seltsamen 0,05 ist, dass Ihre Periode für den 32-MHz-Takt 31,25 ns und nicht 31,2 ns beträgt. Alternativ können Sie den Zeitraum als angeben-period "32MHz"
Es ist jedoch nicht so einfach, nur die Uhren anzugeben, Sie müssen auch die Schnittstellen einschränken, damit Quartus weiß, mit welchen Setup/Hold-Zeiten es arbeiten muss.
Könnten Sie Ihrem Diagramm auch Pfeile hinzufügen, aus Ihrer Beschreibung ist nicht ganz klar, welche Uhr wohin geht
In jedem Fall ist es am einfachsten, beide Takte als asynchron zu behandeln ( set_clock_groups -asynchronous -group [list processor_clock] -group [list external_clock]) und dann Dual-Clock-FIFOs in Ihrem Design zu verwenden, um die Taktdomänen zu kreuzen.
Vielen Dank für den Hinweis bezüglich des 0,05-Artefakts Tom. Ich glaube, es gibt Synchronisierer in der gesamten Domäne, aber ich bin mir nicht ganz sicher. Dies ist eigentlich nicht mein Code, es ist eine Portierungsaufgabe und ich sollte so wenig wie möglich ändern. Ich werde Pfeile hinzufügen. Das ursprüngliche System hat funktioniert, aber jetzt werden einige zusätzliche Verzögerungen aufgrund von Level-Übersetzern hinzugefügt (nicht gezeigt). Aber ich möchte die Uhren einschränken, damit die domänenübergreifende Interaktion enthalten ist.
@TomCarpenter Es scheint, dass das Beheben des Taktfehlers (31,2 ns bis 31,25 ns) dies meistens behoben hat! Jetzt glaube ich, dass dies wie beabsichtigt funktioniert. Wenn Sie eine Antwort geben, werde ich sie als gelöst markieren.

Antworten (1)

Der Grund für das Seltsame 0.05ist, dass Ihr Zeitraum für den 32MHz-Takt 31.25nsnicht gilt 31.2ns. Alternativ können Sie den Zeitraum wie folgt angeben:

create_clock -name external_clock -period "32MHz" [get_ports e_clk]

Es ist jedoch nicht so einfach, nur die Uhren anzugeben, Sie müssen auch die Schnittstellen einschränken, damit Quartus weiß, mit welchen Setup/Hold-Zeiten es arbeiten muss. Dazu müssen Sie das TimeQuest-Benutzerhandbuch zu Rate ziehen.

In jedem Fall ist es am einfachsten, beide Takte als asynchron zu behandeln und dann Dual-Clock-FIFOs in Ihrem Design zu verwenden, um die Taktdomänen zu kreuzen. Wenn Ihre Uhren als asynchron behandelt werden können, können Sie TimeQuest dies mit folgendem Befehl mitteilen:

set_clock_groups -asynchronous -group [list processor_clock] -group [list external_clock]
Einschränken synchroner Uhren auf unterschiedliche Frequenzen in VHDL
AntwortenHierDatenschutz-Bestimmungen1y, 0v