Hallo, ich schreiber gerade an meine Testbench. In der Testbench habe ich 2 CLOCKs mit folgender Frequenz: 57,6MHz und 192MHz Ich habe mir 2 Perioden definiert jedoch läuft der Clock in der Simulation auseinander da ich anscheinend nicht genügen Nachkommastellen angegeben habe. In der Realität werden die beiden Clocks Phasenstabil über eine PLL erzeuegt. 57,6MHz * 10 / 3 = 192MHz nur leider kann ich dies nicht in der Testbench umsetzen. Ich habe es wie folgt probiert: constant CLOCK_1 : time := 17.361ns; --57,6MHz constant CLOCK_2 : time := 17.361 * 3 / 10 ns; hier bekomme ich aber immer einen Fehler das der Operator / unzulässig ist.
Beitrag #5971437 wurde vom Autor gelöscht.
Martin schrieb: > constant CLOCK_2 : time := 17.361 * 3 / 10 ns; hier bekomme ich aber > immer einen Fehler das der Operator / unzulässig ist. Probier mal
1 | constant CLOCK_2 : time := CLOCK1 * 3.0 / 10.0; |
:
Bearbeitet durch User
Martin schrieb: > hier bekomme ich aber immer einen Fehler das der Operator / unzulässig > ist. Ich bekomme da was Aussagekräftigeres:
1 | found '0' definitions of operator "/", cannot determine exact overloaded matching definition for "/" |
Und damit ist klar: du rechnest da mit wild mit Integern, Floats und
Zeiten herum und der Compiler weiß nicht so recht, wie das gehen soll.
> 17.361 * 3 / 10 ns
Schreib mal hin, was der Compiler da sieht: (17,361*3)/(10 ns)
Und das was bei 1/ns herauskommt, ist eine Frequenz und keine Zeit...
So kommt kein Fehler mehr:1 | .... time := (17.361 * 3 / 10) * 1 ns; |
Aber ich vermute sehr, dass auch diese Zeit nicht genau passt (float hat ja nur 6 signifikante Stellen) und davonläuft.
:
Bearbeitet durch Moderator
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.
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.
Und warum eigentlich nicht den hohen, multiplizierten Takt als einzigen
ps-genau generieren und die zwei dann per Teilerverhältnis
("clock-enable") davon ableiten?
Trifft genau das, was die pll macht, braucht aber nicht die PLL
Berechnungszeit in der Simulation, ist ziemlich nah an der Realität was
die tatsächliche Taktrate angeht und läuft garantiert nie
auseinander....
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.
Weltbester FPGA-Pongo schrieb im Beitrag #5972547: > Weil Simulieren in ps langsamer ist und unnötige Rechenschritte > generiert Habe es gerade mal mit einem Beispieldesign in Modelsim probiert, das einen 100Mhz Takt nutzt: - Resolution 10 ns: ~26.3ms je Sekunde Echtzeit (Design funktioniert logischerweise nicht mehr richtig) - Resolution 1 ns: ~10.3ms je Sekunde Echtzeit - Resolution 100 ps: ~9.8ms je Sekunde Echtzeit - Resolution 10 ps: ~8.9ms je Sekunde Echtzeit - Resolution 1 ps: ~8ms je Sekunde Echtzeit - Resolution 1 fs: ~7.8ms je Sekunde Echtzeit Scheint Also etwas dran zu sein. Den multiplizerten Takt zu nutzen kosten etwa eine 10er Stufe und somit rund 5-10% Performance beim Simulieren. Muss man wissen obs das einem Wert ist. Keine Ahnung wie repräsentativ das ist. Weltbester FPGA-Pongo schrieb im Beitrag #5972547: > in keinester Weise isat das das , was die PLL macht > Eine PLL jittert um die theoretische Flanke herum Wir reden hier über Simulation oder? Wäre mir neu das die Herstellermodelle der PLL "rumjittern" würden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.