Serious question: Does Altera's PLL's offer an advantage (veratility, jitter, etc) over Xilinx's DCM's? I'm to understand that the DCM is not a PLL, correct? What is the working principal behind the DCM (any literature links?)
This question arises from an upcoming design where we have three serial LVDS interfaces that need to go into a V2PRO part. I implemented this interface within an Altera Stratix part without a problem; but I'm told by the group responsible for the V2PRO design that their FPGA doesn't have the resources to handle the aforementioned interface, which will necessitate putting deserializers on the board at an added cost.
Here's some information on the LVDS interface: Each interface has its own clock and 3 serialized lanes, for a total of 3 clocks (45MHz) and 9 x 7 deep (315MHz fast clock) serialized lanes.
The Virtex-II Pro and Virtex-II Pro X Platform FPGAs: Complete Data Sheet pages 61-64 go into little detail about the DCM compared to the Virtex-II Pro and Virtex-II Pro X FPGA User Guide pages 89-121 which goes into great detail about working with the DCM.
Neither document seems to illustrate the tapped delay-line structure at the root of the "Delay Locked Loop" like those found in so many devices these days (such as DDR memories). There might be a better description deeper into the text than I cared to review.
A Phase Locked Loop will tend to give much better phase noise. The DLL reacts *immediately* to an input phase change, where the PLL doesn't. There are advantages and disadvantages to each.
External Serializer/Deserializers are not necessarily your best option. Instead consider using a clock generator capable of reasonably clean
315 MHz generation such as the IDT5V9885 (good to 550 MHz). You might get the performance you need.
Very good question. PLLs will filter out high frequency jitter above a certain frequency, but all also susceptible to creating jitter as they share the same substrate with the FPGA logic and IOs. One study we di shoed the PLL with much less jitter when nothing else was happening, but it had twice the jitter of the DCM when a moderate amount of logic and IOs were switching. There is also the concern for a PLL that it must have clean (filtered) power and ground connections (so pcb layout can be critical to success). That said, sometimes you need a PLL, and nothing else will suffice.
I'm to understand that the DCM is not a
The DCM uses six tapped delay lines, with a DSP engine that creates all the phase shifts, frequency multiples, etc. It is 100% digital, so it is process/voltage/temperature independent. The phase resolution is ~20 ps (V4), so fine phase shifts, or even dynamic phase shifting can be done.
What resources does it not have? This surprises me, as Stratix (generally speaking) is competitive with Virtex II. Of course, they do not have a hardened microprocessor in Stratix, which means that if you need one, VII Pro is your only choice (at that technology node). Other than that, I didn't think there was any real significant differences between the two (not being in marketing, I can say this).
As long as you stick with the DLL features, and do not have to use the DFS outputs (CLKFX, CLKFX_180), you will have less jitter (synhthesis of a new frequency creates the most jitter). Use of the DLL and its fine phase shifting capabilities should be able to do what you need to have done.
I am confused, however, the 45 MHz ports should be trivial, and won't even require a DCM. It is the 315 MHz ports that will make use of the DCM. V2Pro does not have the ability to phase shift individual IOBs to allow for pcb trace lengths, and V4 does have this capability, so it is too bad that you will be using V2Pro, as V4 could do it cleaner, with more features (ie the pcb traces for the 315 MHz ports could be completely different in length, and each bit can be phase shifted so that the sample points all line up perfectly).
Or is the 315 = 7 X 45 ? In which case, you probably need the DFS CLKFX (to multiply the 45 MHz clock by 7, and keep it aligned), and you will have to carefully watch the resulting jitter, and be sure you still have margin for recovery of the data.
If this is the case, then the V4 is a much better solution, as it has built in IO serdes functions on every pin.
so the incoming clock would be multiplied by x7 to get bit clock.
it is doable with Virtex and DCM, but for what I would suggest (if it is CameraLink) is still to use the dedicated deserializer.
if you look at Virtex boards with Cameralink support than most of them (but not all) have dedicated serializers.
of course if it not Cameralink (or those deserializers can not be used) then it has to be checked if it makes sense to use only virtex LVDS + DCM or have external circutry too.
Thank you. Yes, it does look like this is a X7 deserializer. In which case the cheapest, fastest and easiest may be to just buy the ASSP that was designed to do that job.
I still think that V4 could also do this without any need for the ASSP as the SSIO features include X7 sampling, without having to mutliply the clock.
I appreciate the feedback guys. Sorry for the delayed response--I've been tied up all day.
The interface, though it looks like Camera Link, is not. The V2PRO part would need to receive from three separate IC's ,each generating its own
45MHz clock and three lanes of x7 serialized data. So, yes, the FPGA would need to take the 45MHz and derive the 315MHz fast clock to pick off the data. So, based on this thread, there's nothing inherent about the DCM which would preclude it from this task.
I wonder why this other group is telling me that the V2PRO can't do the job? Perhaps the V2PRO30 doesn't have enough DCM's? I believe the FPGA would need to have three, since there are three IC's generating the data. You couldn't just use one of the three clocks for all the data lanes because the three chips could have some slight variation in timing. The implemenation I chose was to use three PLL's, and clock everything into a FIFO to switch and sycnchronize all the data from the three chips into a single clock domain. I implemented this within a Stratix (sorry Austin--nothing personal. When I entered into the FPGA world my group used Altera) and it works. The design must be transferred to another group for a different design and the constraint (long story) is to use the V2PRO. The contingency plan is to use National's 90C flavor chips to deserialize the data before the V2PRO, thus sending it parallel data.
My original post--due to my ignorance about the device--was to inquire about the DCM and its capability and limitations (if any) with this interface.
It looks pretty straightforward to me. Three incoming ~45 MHz clocks, each multiplied by 7 in its own DCM, triggering the input DDR registers. You have to do a little bit of thinking, because 7 is an odd number, but I see no problem with that. Of course, it would be much simpler in Virtex-4, but that seems to be not your choice. Peter Alfke, Xilinx (from home)
We have a Virtex-II design that does Camera link reception.
We wanted the same board to do input and output (not at the same time - over the same connector), and the board space for both directions of serialisers as well as the discrete bits for the Ser_TFG and Ser_TC and CCx signals was too large.
So we put a 2V40 down and have two bitstreams.
It works well, even in a car - we use it to extract lane markings and provide feedback to the driver about unintentional lane-changes.
After all that, the Tx part never quite got around to being used, but we have the code for it...
Cheers, Martin
--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronic-hardware.html
Yes, I agree, the interface is straightforward. Which is why I was promted to post and try to get a feel for the DCM, since I don't have much experience with it.
I do appreciate the feedback and will push a little harder on this group to get a better answer as to why they feel the V2PRO30 can't handle this interface.
Xilinx offers a reference design in XAPP265 for a 7:1 serdes (see app A). I have used the receiver successfully at 60MHz clock in Virtex II to deserialize data that was transmitted by National "Channel Link" transmitters. Each clock requires one DCM and two global clocks.
I noticed that the DCM phase shift value calculated per the app note was not optimum. By changing the phase shift value back and forth until I found the limits of good data, I empirically determined a value to put the clock in the center of the data eye.
Aust> I appreciate the feedback guys. Sorry for the delayed response--I've been
Yes.
Three DCMs, one for each clock. That works. No problem here. The implemenation I
That is OK. Some of my best friends use Altera FPGAs... When I
As I said, the X7 requires the DFS section of the DCM, and will add jitter due to synthesis (the CLKFX output). But, you can also use the phase shift feature, and dynamically move the CLKFX output in relation to the first rising edge of the 45 MHz input. The phase control will be
0 to 255 steps in 256 of one 45 MHz period. 1/45 MHz = 22.2 ns. So
22.2/256 = 87 ps per step, and with the min phase step of the V2Pro DCM being ~ 30 ps, that is going to be from 2 to 3 tap steps automatically selected based on the XXX/256 of a 45 MHz period that you wish to move the 315 MHz output. You can find the exact best phase shift that recovers all the 7 data bits error free, and then use that number as a fixed phase shift for all pcbs (as it all being digital, once you find the best sample point, it shouldn't move). Each DCM may have its own best phase shift.
You could also do M=7, D=2, and only go up to 315/2 MHz, use CLKFX rising edge and falling edge for DDR recovery of all 7 bits, but with everything running at half the 315 MHz rate, for less power and more timing margin (with some complexity in the interface).
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.