I am targetting an S3 and need a VCXO. This can be done by permanently rotating the delay in the DLL. Unfortunately the DLLs in S3 do not wrap (IIRC).
Is there another option than interleaving two DLLs and spool the second towards the oposite end and switch on the overflow on the first.
Example: The first one goes towards the max delay end. The second one is spooled to minimum. On overflow the clock will be swittched to the second one. (uh, it's frighting me!).
Thanks Thomas
Thomas,
We did this to prove a point (that we could do clock and data recovery by such a scheme).
So while you advance one DLL phase, the other is waiting at its minimum (or maximum) until you are about to (undeflow) overflow. Then you switch DLLs (using a BUFGMUX) and trade roles for the DCM's (one is now the source of the clock, and the other is set to max or min based on the direction you wish to move the phase).
It gave a number of folks a headache here as well, but it did work, and was able to act as CDR to recover data from a 270 Mbs data stream.
My thought was to always have one DLL be a mirror of the other (if one advances, the other goes back) so that when you reach 0, the other is at max, and if you reach 255, the other is at 0, and use the BUFGMUX to switch between them when you need to. They ended up not doing it that way, but I saw no reason why not. Maybe they hit on a simpler control scheme their way.
This does not make a VCXO however (always get the same frequency out).
Aust> I am targetting an S3 and need a VCXO. This can be done by permanently
Exactly!
You will have to spend a lot of time to find a save switching point in either case.
That's a good idea. It takes less resources to do that.
Of course, you need to permanently increase/decrease phase.
Thanks a lot. And please tell your developers that a wrap option can be very useful in new devices.
Thomas
Austin, Did you do that for DVB-ASI? I ask because the data rate is 270Mbps. I tried to do something similar for ASI but using a carry chain--the number that got "added" to the clock controlled how long it took the clock to propagate through the carry chain. An NCO controlled where the clock got injected into the carry chain. It worked pretty well in the post-synthesis sim but the gate-level sim wouldn't work and I gave up on it. There were also some glitches to be resolved.
I'd disagree that you always get the same frequency out. Phase is the derivative of frequency, so if you are adding phase that is changing linearly, that is the same as adding a constant value to the freqency, thereby changing the frequency to a new one.
-Kevin
Kevin,
Yes, if you continuously add phase, you can change the frequency (slightly).
Since you can't add phase faster than the DCMs will let you (~100 clocks per update), the range is only +/- 50 ppm or so....if my memory serves me right here.
There was no specific application in mind.
There are two app notes on CDR for the 270 Mbs app you mention, one that uses the carry chain, and one that uses an oscillator.
Hope this helps,
Austin
Hi Thomas, I dont know what is your application that reqiuers the vcxo so maybe my suggestion will be useless but here it is anyway..
to my knowledge, a vcxo is an oscillator that is being controlled by analog tuning voltage determining its output frequency (usually used in pll sync applications) - so I'm not sure how to implement it in a fpga . but if what you need is a module with a controlled output frequency to be used either inside the fpga or outside it I suggest you to use a NCO - Nomerically Controled Oscillator which is very easy to implement in a fpga (using just an rotating accumulator).
I hope that its helpfull in some way..
Regards, Moti.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required