Spartan 3A DCM und Clock Uncertainty

[Anguel S. (anguel)]

Hallo Leute!

Ich dachte bisher, dass ISE bei Spartan 3A den Jitter, der durch DCMs 
entsteht schön berechnen und weitergeben würde. Jetzt sehe ich aber bei 
allen meinen Pfaden nur "Clock Uncertainty:    0.000ns" sowie folgende 
Info-Meldungen:
INFO:Timing:3390 - This architecture does not support a default System 
Jitter value, please add SYSTEM_JITTER constraint to the UCF to modify 
the Clock Uncertainty calculation.
INFO:Timing:3389 - This architecture does not support 'Discrete Jitter' 
and
   'Phase Error' calculations, these terms will be zero in the Clock
   Uncertainty calculation.  Please make appropriate modification to
   SYSTEM_JITTER to account for the unsupported Discrete Jitter and 
Phase
   Error.

Das lässt mich vermuten, dass der durch die DCMs entstandene 
Clock-Jitter gar nicht automatisch berücksichtigt wird. Stimmt das? 
Danke schon mal im Voraus.

Grüße,
Anguel

[Duke Scarring (Gast)]

Anguel S. schrieb:
> Das lässt mich vermuten, dass der durch die DCMs entstandene
> Clock-Jitter gar nicht automatisch berücksichtigt wird. Stimmt das?
Sieht ganz danach aus.

Aber die Lösung wird ja mit angegeben:
> please add SYSTEM_JITTER constraint to the UCF to modify
> the Clock Uncertainty calculation.

Duke

[Anguel S. (anguel)]

Danke für die Antwort! Habe inzwischen auch das gefunden:
http://www.xilinx.com/support/answers/13645.htm

Duke Scarring schrieb:
> Aber die Lösung wird ja mit angegeben:
>> please add SYSTEM_JITTER constraint to the UCF to modify
>> the Clock Uncertainty calculation.

Macht es überhaupt einen Unterschied, ob ich das ganze als SYSTEM_JITTER 
oder INPUT_JITTER angebe? Wenn ich mir diese Infos anschaue, nimmt man 
wohl eher INPUT_JITTER für sowas:
http://www.xilinx.com/support/answers/31087.htm

Nun habe ich in meinem Design zwei Clocks, die aus zwei DCMs 
herauskommen und ISE gibt mir Folgendes in den generierten DCM source 
files an:
"Period Jitter (Peak-to-Peak) for block DCM_SP_INST = 1.18 ns"
bzw.
"Period Jitter (Peak-to-Peak) for block DCM_SP_INST1 = 0.73 ns"

Das sind übrigens Werte, die gar nicht so unbedeutend sind, dass man sie 
einfach ignorieren könnte, was die Tools ja tun. Ich würde also den 
größeren Wert von 1.18 ns nehmen und als INPUT_JITTER zum externen Clock 
definieren. Wäre das OK, oder muss ich den Jitter des zweiten DCM auch 
irgendwie berücksichtigen? Die DCMs sind nicht hintereinander 
geschaltet, sondern parallel.

Grüße,
Anguel

[Duke Scarring (Gast)]

Anguel S. schrieb:
> Das sind übrigens Werte, die gar nicht so unbedeutend sind, dass man sie
> einfach ignorieren könnte, was die Tools ja tun. Ich würde also den
> größeren Wert von 1.18 ns nehmen und als INPUT_JITTER zum externen Clock
> definieren.
Da bin ich überfragt. Als INPUT_JITTER würde ich den Jitter des 
Eingangstaktes bezeichnen. Damit muß der DCM klarkommen. Durch den DCM 
(je nach Betriebsart) wird der Jitter kleiner oder größer. Auf den 
erzeugten Takten hast Du dann den SYSTEM_JITTER.
Die angegeben 1.18 ns beziehen sich möglicherweise auf den zusätzlichen 
Jitter durch die DCM.
An dieser Stelle würde ich das Datenblatt ganz genau studieren.

Duke

P.S.: Außerdem ist Jitter nicht gleich Jitter. Die einen messen 
peak-to-peak und die anderen mit RMS :-(

[Anguel S. (anguel)]

Duke Scarring schrieb:
> Auf den erzeugten Takten hast Du dann den SYSTEM_JITTER.
Vermutlich ist das dem Tool egal, weil es am Ende sowieso alles 
zusammenrechnet:
Clock Uncertainty = [((System Jitter^2) + (Input Jitter^2)) ^ (1/2) + 
DCM Jitter] / 2 + DCM Phase Error

> P.S.: Außerdem ist Jitter nicht gleich Jitter. Die einen messen
> peak-to-peak und die anderen mit RMS :-(

Xilinx sagt hierzu Folgendes:
---
JIN = The input period jitter as measured at the clock input pin of the 
FPGA
JSpec = DLL output period jitter as specified in the data sheet
JTotal = The total expected output period jitter

*All calculations must be performed using the peak-to-peak 
measurement/specification.*

Calculation:

The JTotal is calculated as the RMS (root mean square) of JIN and J:

JTotal = (JIN^2 + JSpec^2) ^1/2

Example calculation for a Virtex-II device with a CLK0 DCM output:

Given JIN = 100 ps peak-to-peak
JSpec = +/- 100 ps = 200 ps peak-to-peak
JTotal = (100^2 + 200^2)^1/2 = 224 ps

Consequently, the total jitter in the FPGA is 224 ps peak-to-peak or +/- 
112 ps. To account for jitter in your design, subtract 112 ps from your 
period constraint.

For example, if you expect to run your design at 100 MHz (10 ns period), 
constrain the design to 9.888 ns.
---

Statt des letzten Satzes kann man IMHO auch den Clock normal mit 10 ns 
angeben und dann eben durch INPUT_JITTER ergänzen.

Grüße,
Anguel