64MHz Takt in Modelsim erzeugen?

[Günter (. (dl4mea)]

Hallo,

zwei Fragen:
a) wie erzeuge ich in Modelsim einen 64MHz-Takt?
b) wie schreibe ich das effizient wenn ich über lange Zeiträume 
simulieren will?

Zu a)

ich möchte in Modelsim einen 64MHz-Takt erzeugen, also 7,8125ns low, 
7,8125 high. Leider aber macht mir das Modelsim die Nachkommastellen 
nicht, wenn ich es einfach so schreiben würde:

   -- the 64MHz clock  
   clock64 : process begin
      clk64 <= '0';
      wait for 7.8125 ns;
      clk64 <= '1';
      wait for 7.8125 ns;
   end process clock64;

Das ganze brauche ich weil ich extern gesamplete Daten als Input habe, 
die ein ganz genaues Timing haben, und das ständige Rumskalieren beim 
Ausmessen von Zeiten ist äußerst nervig. Das ganze verzehntausendfachen 
geht auch wieder nicht, weil dann der Simulator ewig läuft.
Also habe ich die Zeiten gerundet und mach meist 8ns und manchmal 7ns 
Delays. Die Frage hier: Geht das einfacher?

   -- the 64MHz clock  
   clock64 : process begin
      clk64 <= '0';
      wait for 8 ns;
      clk64 <= '1';
      wait for 8 ns;
      clk64 <= '0';
      wait for 7 ns; -- 7
      clk64 <= '1';
      wait for 8 ns;
      clk64 <= '0';
      wait for 8 ns;
      clk64 <= '1';
      wait for 8 ns;
      clk64 <= '0';
      wait for 8 ns;
      clk64 <= '1';
      wait for 8 ns;
      clk64 <= '0';
      wait for 7 ns; -- 7
      clk64 <= '1';
      wait for 8 ns;
      clk64 <= '0';
      wait for 8 ns;
      clk64 <= '1';
      wait for 8 ns;
      clk64 <= '0';
      wait for 8 ns;
      clk64 <= '1';
      wait for 7 ns; -- 7
      clk64 <= '0';
      wait for 8 ns;
      clk64 <= '1';
      wait for 8 ns;
   end process clock64;

zu b)

Mit diesem Takt sample ich das GPS 1pps-Signal ab, und wenn ich den 
Modelsim hier über 1sec (noch besser wären 16sec) simulieren lasse, dann 
läuft das ewig. Wie kann man das am effizientesten beschleunigen?

Danke für eure Hilfe!

Günter (dl4mea)

[user (Gast)]

du musst die simulation auf ps umschalten

vsim -t ps

den clk erzeuge ich dann so

signal clk : std_logic := '0';

begin
  clk <= not clk after 7812 ps

[Pacitus (Gast)]

Das timmt aber immer noch nicht genau.

[Günter (. (dl4mea)]

Hi,

naja, dann machen wir halt einfach

   clock64 : process begin
      clk64 <= '0';
      wait for 7812ps;
      clk64 <= '1';
      wait for 7813ps;
   end process clock64;

und schon ists bis auf das Tastverhältnis ziemlich genau

Womit ich sagen wollte: Danke, das geht!

Jetzt nur noch die ergänzende Frage: Wie kann ich es am effizientesten 
machen wenn ich mit diesen Einstellungen 1sec oder länger simulieren 
möchte?

Ciao, Günter

[Christian R. (supachris)]

Günter (dl4mea) schrieb:
> Jetzt nur noch die ergänzende Frage: Wie kann ich es am effizientesten
> machen wenn ich mit diesen Einstellungen 1sec oder länger simulieren
> möchte?

Hm, für solche langen zeiten ist Modelsim nicht wirklich optimal. Das 
simuliert man am besten mit File I/O und dann ohne Wave-Ausgabe.

[Bertram (Gast)]

Günter (dl4mea) schrieb:
> und schon ists bis auf das Tastverhältnis ziemlich genau
vollkommen irrelevant, da man nur aus rising baut

[O_o (Gast)]

Christian R. schrieb:
> Günter (dl4mea) schrieb:
>> Jetzt nur noch die ergänzende Frage: Wie kann ich es am effizientesten
>> machen wenn ich mit diesen Einstellungen 1sec oder länger simulieren
>> möchte?
>
> Hm, für solche langen zeiten ist Modelsim nicht wirklich optimal. Das
> simuliert man am besten mit File I/O und dann ohne Wave-Ausgabe.

oder waveform größe begrenzen, dann kannst du modelsim auch 24h 
simulieren lassen :D

[Günter (. (dl4mea)]

Hallo,

ganz verstehe ich das mit der Waveform-Größe nicht. Denn das würde doch 
heißen, ich kann mir die Ergebnisse bei 1sec, 2sec usw. nicht anschauen 
kann?

Also genauer gesagt: Ich taste mit den 64MHz ein 1pps von GPS ab und 
bräuchte eh nur das Geschehen rings um den 1pps rum (1pps plus etwa 500 
clocks). Da wird nämlich der nächste Korrekturfaktor ausgerechnet.

Ciao, Günter

[Christian R. (supachris)]

Wie gesagt solche langen sachen macht man lieber mit Ein- und Ausgabe 
über Files. Lass doch alles was du sehen willst, in ein File schrieben, 
meinetwegen noch mit Simulationszeit usw. dann kannst du ohne Wave 
Ausgabe simulieren lassen, das geht um einiges schneller.

[PittyJ (Gast)]

>> Das ganze verzehntausendfachen
>> geht auch wieder nicht, weil dann der Simulator ewig läuft.

Das vestehe ich jetzt nicht.
Der Simulator sollte, wenn man den Process von der Clock abhängig macht, 
doch eh nur auf die Flankenwechsel bei der Clock achten. Und ob die 
Zeitbasis das ms us oder ps ist, das ist für die Rechenzeit völlig egal.
Die Zeiten zwischen den Flankenwechseln werden ignoriert, weil da ja eh 
nichts passieren kann.
Jedenfalls habe ich es so verstanden.

[Klaus F. (kfalser)]

PittyJ schrieb:
> Jedenfalls habe ich es so verstanden.

Stimmt so auch.
Das eigentliche Problem mit der zeitlichen Auflösung ist die maximale 
Simulationszeit, weil die Simulatoren die interne Zeit entweder als 
unsigned 32 Bit oder 64 Bit Zahl darstellen.
Bei 32 Bit und ps Auflösung ist dann bei ca. 4 ms Schluss.

Eine Auflösung in ps oder ns macht die Simulation nicht schnelle oder 
langsamer.

[Günter (. (dl4mea)]

>>> Das ganze verzehntausendfachen
>>> geht auch wieder nicht, weil dann der Simulator ewig läuft.

Ich benötige für die Bearbeitung meiner Inputdaten (Capture-File des 
ADC) immer dieselbe Anzahl Taktflanken und nicht einfach nur einen Lauf 
über insgesamt 1sec. Wenn ich also Faktor Zehntausend mache, nur damit 
ich mit Nanosekunden-Auflösung zeitlich 1:10000 skalierte Timing-Events 
brauche, dann brauch ich dennoch dieselbe Anzahl Events bis mein 
komplettes Capturefile abgearbeitet ist.

Das "-t ps" hat schon was gebracht.

Günter (dl4mea)

[SuperWilly (Gast)]

>ich kann mir die Ergebnisse bei 1sec, 2sec usw. nicht anschauen

Siehst du dann überhaupt noch irgendetwas? Du solltest dir überlegen, 
wie man die Ergebnisse ohne Wave-Betrachtung überprüfen/bewerten kann.

VG, SuperWilly

[Paul B. (Gast)]

Wie würde man die Simulation ansetzen, um z.B. einen Takt von exakt 
66.000 MHz, bzw auch 66,6600 MHz (1%-Grenze für Jitter) anzulegen?

Wie bekomme ich das langzeitgenau?

Soweit bekannt rechnet Modelsim mit fs, damit ist man in der Auflösung 
limitiert.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Frank P. schrieb:
> Wie würde man die Simulation ansetzen, um z.B. einen Takt von exakt
> 66.000 MHz, bzw auch 66,6600 MHz (1%-Grenze für Jitter) anzulegen?
Das wäre eigentlich eh' unsinnig, weil es in der Realität keinen so 
genauen Takt gibt...

> Soweit bekannt rechnet Modelsim mit fs, damit ist man in der Auflösung
> limitiert.
Dann skaliere doch einfach alles um drei Zehnerpotenzen nach oben: 
Verwende einen 66,6600 kHz Takt...

[J. S. (engineer)]

> Wie bekomme ich das langzeitgenau?
Das timing muss als solches natürlich stimmen. Ich mache das bei krummen 
Takten so, dass ich eine genügend grosse Anzahl modelliere und 
zwischendurch runde, dann aber bei dem letzten irgendwo ein paar fs 
einspare, sodass es langfrisitig stimmt.

So kriegt man eigentlich jeden krummen Takt in die Simulation.

[Paul B. (Gast)]

Lothar Miller schrieb:
> Dann skaliere doch einfach alles um drei Zehnerpotenzen nach oben:
> Verwende einen 66,6600 kHz Takt...
Das ist nicht so wirklich eine Lösung, weil diverse Timings in den Cores 
reale Zeiten brauchen ...

Jürgen Schuhmacher schrieb:
> irgendwo ein paar fs einspare, sodass es langfristig stimmt.
Ist aber eine zimeliche Fummelei und wird auch nicht wirklich genau.

[P. K. (pek)]

Frank P. schrieb:
>> irgendwo ein paar fs einspare, sodass es langfristig stimmt.
> Ist aber eine zimeliche Fummelei und wird auch nicht wirklich genau.

Weiss nicht, was Du mit der Timing-Simulation genau beweisen willst: Den 
realen Jitter (oder auch Wander, falls Du spread spectrum verwendest) 
kannst Du eh nicht abbilden, bzw. die Chance, dass Du die "böse" 
Kombination auch wirklich simulierst ist eher klein.

Würde daher eine Simulation mit "ungefähr"-Timing (damit grobe 
Relationen sichtbar sind) für die Funktion nehmen, und das Timing mit 
der STA abhandeln.

(Falls Du Chip-Design machst und nicht FPGA, kann es natürlich sinnvoll 
sein, eine Timing-Simulation mit dem backannotierten Layout 
durchzuführen. Deren "pass" wäre aber auch wieder nur notwendig und 
nicht hinreichend.)

[Valko Z. (hydravliska)]

Hi

probiere es so aus:

...
  CONSTANT c_clk_666_freq   : REAL := 66.6e+6;
  CONSTANT c_clk_666_period : TIME := 1e9 NS / c_clk_666_freq;
...

  SIGNAL clk666            : STD_LOGIC := '1';
...
  clk666   <= NOT clk666 AFTER c_clk_666_period/2;


Gruß

[Sym (Gast)]

Wenn es wirklich genau sein soll:
Halbperiode mit dem eingebauten Datentyp 'real' berechnen.

Schleife:
1) Mit now Zeit1 abfragen.
2) Warten bis Halbperiode abgelaufen ist
3) Mit now aktuelle Zeit2 abfragen. Zeit2-Zeit1 ergibt aktuelle 
Halbperiode. Mit soll-Periode vergleichen und die nächste Halbperiode 
geeignet verlängern. Zurück zu (1)

Vorteil: Keine Akkumulation vom Fehlern (ausgenommen der Berechnung der 
Halbperiode). PLLs sind so auch modelierbar. Funktioniert mit ps 
Zeitauflösung genauso wie mit ns.
Nachteil: Halbperiode ist +- 1 Simulatorzeiteinheit unterschiedlich.

Wem das noch wegen der Verwendung von Real zu ungenau ist, der kann 
zusätzlich noch dann, wenn die Periode ein vielfaches der 
Simulatorauflösung hat, den Fehler der floats korregieren. Habe ich noch 
die benötigt.

Bei Bedarf, kann ich gerne den Source-Code heraussuchen.

[J. S. (engineer)]

Frank P. schrieb:
> Lothar Miller schrieb:
>> Dann skaliere doch einfach alles um drei Zehnerpotenzen nach oben:
>> Verwende einen 66,6600 kHz Takt...
> Das ist nicht so wirklich eine Lösung, weil diverse Timings in den Cores
> reale Zeiten brauchen ...
>
> Jürgen Schuhmacher schrieb:
>> irgendwo ein paar fs einspare, sodass es langfristig stimmt.
> Ist aber eine zimeliche Fummelei und wird auch nicht wirklich genau.

Nun, es wird auf die fs genau, wenn man damit simuliert und die 
Berechnung geht automatisch von Statten, da ich das mit einem Excel 
erzeuge, das auch gleich den VHDL-Code mit auswirft.