64MHz Takt in Modelsim erzeugen?

Hi,

naja, dann machen wir halt einfach

1

   clock64 : process begin

2

      clk64 <= '0';

3

      wait for 7812ps;

4

      clk64 <= '1';

5

      wait for 7813ps;

6

   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

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.

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

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 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.

>>> 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)

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...

> 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.

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.)

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ß

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.