Austin Lesea wrote:
> 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
>>>

why not use the x3.5 clock and then use a DDR FF at the input => lower 
clock frequency, we use this all the time in video processing units ...

xilinx even has a core for it: 
<http://www.xilinx.com/bvdocs/appnotes/xapp265.pdf>

Rob,

See below,

Austin

Rob wrote:
> 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.
Yes.
> 
> 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.
Three DCMs, one for each clock.  That works.  No problem here.
  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.
That is OK.  Some of my best friends use Altera FPGAs...
 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.
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).

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.

Barry


"Rob" <robnstef@frontiernet.net> wrote in message
news:BcQGg.8182$oa1.7226@news02.roc.ny...
> 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
>
>
>
>
>

Peter,

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.

Take care and thank you for the response,
Rob


Peter Alfke wrote:
> 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

   

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)

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
> 

"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 

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
>>

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
>