"The phase adjustment might require as many as 100 CLKIN cycles plus 3 PSCLK cycles to take effect, at which point the DCM's PSDONE output goes High for one PSCLK cycle. This pulse indicates that the PS unit completed"
However it seems that our design is much slower... The DCM that does the phase shift gets its clock from another DCM. Could it be that there is too much jitter on this clock?
Anybody had a similar problem?
Thanks and best regards, Karel Deprez
Are you on the phase shift limits? Then it takes almost forever, and 3E has no status pin for the limit detection...
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
Hello Georg, The input clock is 115MHz (=8.7ns). This allows for a maximum of
20*(8.7-3) = 114steps. We are only doing 100 steps...Thanks for the information, Karel
no
We have tested this range. And it looks like all steps are slow. The first 10 steps are as slow as the last 10 steps.
best regards, Karel
I have one design where the shift range is asymmetrical. For a phase calibration, I moved the phase 60 steps back and then 120 forward. Depending on the routing, the backward steps worked or blocked after a few steps. I only noticed it after doing a check of PSDONE instead of a simple fixed wait loop.
Are you sure that the DCM is already locked when doing the phase shift?
--
Georg Acher, acher@in.tum.de
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
The DCM is locked before we start doing the phase shift.
Karel
Sorry I missed your post - business travel for a couple days.
My experience with the Spartan 3E shows that under some circumstances, the PSDONE is delayed. I was doing a significant number of phase tweaks back and forth under some conditions with one source behaving quite different than another (different designs, same effective signal). It seems - from discussions with people deep within Xilinx while pursuing these troubles - the phase shift is held off because the "Input clock is jittery with some special jitter pattern. The skew filter kicks in, managing DLL updates based on short term avg of input phase. Variaple updates are also delayed with other DLL updates.
I'd suggest you call the apps hotline and indicate you're having troubles with the PSDONE arriving in a timeliy manner, and that you'd like "a back door code to turn off skew filter (using a -g option in)." You'll need to provide the exact DCM location you are using for that option.
"Then PSEN->PSDONE cycles will be roughly 10 deterministic cycles."
While it was suggested that I could discontinue the -g option once I debugged the problem, the "problem" as I saw it was the DCM wasn't working for my input signal. I never changed the option back, but we are currently troubleshooting around that same front end.
It may be the very nature of the jitter on the DCM feeding your second DCM is why there are troubles getting the skew filter to cooperate.
In my own measurements, I ran a histogram of the number of cycles it took for my system to generate PSDONE. The results suggested that - in my circumstance - the deterministic data sheet values were not reliable. With the specific -g option, the system worked and worked solid. What was most fun was watching the DCM lose lock (without saying so) when I'd retry the PSEN after not receiving it for too long at the same cycle the PSDONE asserts (512 cycles later, for one timeout setting). By just retrying the PSEN, I'd eventually see the original PSDONE but when they tripped on each other in this strange situation, there might be lock troubles. The unreported lock loss was always preceeded by the PSEN reissue coincident with PSDONE report. I don't know if the inverse was true (it probably was not, given the number of delays extending this far).
- John_H
Hi John,
I've passed your information to the Xilinx support.
Thanks end best regards, Karel
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.