2 CLOCKs in Simulation

Dann verwende doch einen MMCM oder PLL in deinem Design. Bekommt dein 
FPGA von aussen wirklich mehrere Takte?

Kann man eigentlich auch PLLs aus dem Xilinx Wizard in die Testbench 
bauen? Also nicht ins UUT?

Das ist aber mehr, als einfach:

Man macht den Takt vom anderen abhängig, mit wait und und dann manuellem 
erzeugen der Takte und einem Synch. Das muss gehen, weil ja ein echtes 
Verhältnis besteht.

Z.B. erzeugt man einen Trigger und dann 7 Takte des einen Taktes.
Der andere warte und macht 5. Dann hat man 5:7.

Ja und in der testbench könnte man einen Takt auch problemlos durch 3 
teilen mit einem einfachen Zähler.

Vielen Dank für die zahlreichen Vorschläge ich habe es wie folgt gelöst:

-- CONSTANT DEKLARATION
constant C_FREQUENZ_1 : real := 57.6E6;
constant C_FREQUENZ_2 : real := 172.8E6;

constant C_57_6MHZ_CLK_0  : time := 1 sec / C_FREQUENZ_1; -- 57,6MHz
constant C_192MHZ_CLK_0    : time := 1 sec / C_FREQUENZ_2; -- 172,8MHz


Ich verwende auch ein PLL. Jedoch wollte ich den noch nicht mit 
simulieren. Ich teste zuerst die kleinen Module und arbeite mich dann 
zur TopLevel vor.

Ich habe natürlich nur 1 Takt der in den FPGA geht und erzeuge mir den 
2. Takt im FPGA mit Hilfe einer PLL. Das eine Module schreibt die Daten 
in den BlockRAM und das 2. Modul lies die Daten auch den BlockRAM aus 
und überträgt die Daten an den PC. Die Simulation sieht auch schon sehr 
gut aus jetzt muss ich noch die letzten Kleinigkeiten beseitigen.

Ich würde tatsächlich einfach teilen.

müssen es denn exakt diese Frequenzen sein?
Könntest ja auch T1 = 20 ns (50MHz) und T2 = 6 ns (166.6 MHz) verwenden. 
Diese sollten nicht auseinanderlaufen!

Das die Frequenzen auseinlander gelaufen sind war mein Fehler. Die 
Frequenz 57,6 MHz und 192MHz laufen immer auseinander.

Deshalb habe ich jetzt die Frequenz von 192MHz auf 172,8MHz geändert.

172,8MHz / 57,6MHz = 3
192MHz  / 57,6MHz = 3,33333

Dank für Eure Hilfe. Ich wünsche allen ein schönes Wochenende.

57,6 MHz sind genauso ein Problem wie die 192 MHz und die 172,8 MHz. 
Stattdessen nimmt man - wie hier ganz richtig mit 20 ns und 6 ns 
vorgeschlagen wurde - ähnliche Zeiten mit jeweils glatten Werten, aber 
dem richtigen Verhältnis. Da meist mit ps aufgelöst wird, kann man das 
auch noch etwas genauer definieren. 57,6 MHz und 172,8 MHz funktionieren 
nur zufällig gleichlaufend oder - je nach Rundung nach dem Teilen - auch 
mal nicht.

Robert P. schrieb:
> Und warum eigentlich nicht den hohen, multiplizierten Takt als einzigen
> ps-genau generieren und die zwei dann per Teilerverhältnis
> ("clock-enable") davon ableiten?
Weil Simulieren in ps langsamer ist und unnötige Rechenschritte 
generiert


> Trifft genau das, was die pll macht
in keinester Weise isat das das , was die PLL macht
Eine PLL jittert um die theoretische Flanke herum

> die tatsächliche Taktrate angeht und läuft garantiert nie
> auseinander....
Mit einer mathematisch sauberen Definition, die in Summe exakt dem Takt 
entspricht, stimmt es auch. Übernahme effekte bei nicht 100% synchronen 
Taktflanken sind eh nicht von Interesse, da im Bereich der Unsicherheit.