mikrocontroller.net

Forum: FPGA, VHDL & Co. 2 CLOCKs in Simulation


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
constant CLOCK_2 : time := CLOCK1 * 3.0 / 10.0;

: Bearbeitet durch User
Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin schrieb:
> hier bekomme ich aber immer einen Fehler das der Operator / unzulässig
> ist.
Ich bekomme da was Aussagekräftigeres:
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:
....  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
Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: M. W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: -gb- (Gast)
Datum:

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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde tatsächlich einfach teilen.

Autor: tja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: dfIas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Robert P. (fpgazumspass) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Robert P. (fpgazumspass) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.