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
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
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
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 :-(
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
Bitte 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.