DCM vs. PLL

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.

Much obliged,
Rob

Rob wrote:
> 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.
> 
> Much obliged,
> Rob


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.

- John_H

Rob,

Here goes,

See below:

Austin

-snip-
> Serious question:  Does Altera's PLL's offer an advantage (veratility, 
> jitter, etc) over Xilinx's DCM's?
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
> PLL, correct?  What is the working principal behind the DCM (any literature 
> links?)
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.
> 
> 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.
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).
> 
> 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.
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.

Austin Lesea schrieb:

> Rob,
>
> Here goes,
>
> See below:
>
> Austin
>
> -snip-
> > Serious question:  Does Altera's PLL's offer an advantage (veratility,
[snip]
> 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

Austin,

the OP desing looks very much like CameraLink.

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.

Antti
http://xilant.com

Antti,

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.

http://direct.xilinx.com/bvdocs/userguides/ug070.pdf
page 355

Austin

Antti wrote:
> Austin Lesea schrieb:
> 
>> Rob,
>>
>> Here goes,
>>
>> See below:
>>
>> Austin
>>
>> -snip-
>>> Serious question:  Does Altera's PLL's offer an advantage (veratility,
> [snip]
>> 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
> 
> Austin,
> 
> the OP desing looks very much like CameraLink.
> 
> 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.
> 
> Antti
> http://xilant.com
> 

Oops,

You still need to have the X7 clock, the the ISERDES does all the work.

Austin

Austin Lesea wrote:
> Antti,
> 
> 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.
> 
> http://direct.xilinx.com/bvdocs/userguides/ug070.pdf
> page 355
> 
> Austin
> 
> Antti wrote:
>> Austin Lesea schrieb:
>>
>>> Rob,
>>>
>>> Here goes,
>>>
>>> See below:
>>>
>>> Austin
>>>
>>> -snip-
>>>> Serious question:  Does Altera's PLL's offer an advantage (veratility,
>> [snip]
>>> 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
>> Austin,
>>
>> the OP desing looks very much like CameraLink.
>>
>> 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.
>>
>> Antti
>> http://xilant.com
>>

"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
news:echs1s$anl6@xco-news.xilinx.com...
> Oops,
>
> You still need to have the X7 clock, the the ISERDES does all the work.
>
> Austin
>
> Austin Lesea wrote:
>> Antti,
>>
>> 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.
>>
>> http://direct.xilinx.com/bvdocs/userguides/ug070.pdf
>> page 355
>>
>> Austin

ah yes, the x7 must be there ;)

well the OP asked for V2Pro - it is doable in V2Pro too.
V4 is maybe better withe ILOGIC

but dedicated chip may even be better as it does the
job it was made to do.

Antti 

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.

Take care,
Rob



"Antti Lukats" <antti@openchip.org> wrote in message 
news:eci8hd$ml$1@online.de...
>
> "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
> news:echs1s$anl6@xco-news.xilinx.com...
>> Oops,
>>
>> You still need to have the X7 clock, the the ISERDES does all the work.
>>
>> Austin
>>
>> Austin Lesea wrote:
>>> Antti,
>>>
>>> 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.
>>>
>>> http://direct.xilinx.com/bvdocs/userguides/ug070.pdf
>>> page 355
>>>
>>> Austin
>
> ah yes, the x7 must be there ;)
>
> well the OP asked for V2Pro - it is doable in V2Pro too.
> V4 is maybe better withe ILOGIC
>
> but dedicated chip may even be better as it does the
> job it was made to do.
>
> Antti
> 

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)

"Antti" <Antti.Lukats@xilant.com> writes:

> the OP desing looks very much like CameraLink.
> 
> 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.
> 

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