Xilinx ISERDESE2 deserializer primitive behaviour

ed (width expansion) ISERDES-pair:

generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR mod e. The VHDL file can be downloaded here:

_wiz_v4_1.zip

e frame is aligned - I have marked the frame by the two cursors. It is clea r that the ddly input within this frame (10000111100100) is what appears on iserdes_q_vec on the next rising edge of clkdiv.

ooked in the User Guide (ug471) but can't find info on this.

g out of the results (in this design, rst is de-asserted synchronously with clkdiv, as suggested by the user guide).

gnment with bitslip operations. In my case, for the serial data, clkdiv is equal to the frame clock. From the simulation I can of course determine how the frame is placed in the serial data, and fix the paralell words in cust om logic, but then I need to understand why I get this particular offset, a nd be convinced that I will always get exactly this particular offset.

but nothing in the UG suggests that, and according to the simulation, that is also clearly not the case.

I don't think you can rely on the real hardware presenting the parallel wor d in any particular bit alignment or offset. You will want to add a trainin g sequence that is run at startup to bitslip the iserdes appropriately, and then turn the interface lose for general traffic.

Which really sucks when you have no training pattern as noted in the OP. In the past, I've used DDR registers instead of ISERDES in cases where there was no way to have a training pattern. However I never needed to do this above 585 Mbps. In my case I was doing Camera Link (7:1 serial with 1x word clock), and I "deserialized" the clock to get a framing signal. It might be possible to do the same with ISERDES, if you can relay on multiple ISERDES to come up in the same phase each time. Then applying the same number of bitslips to all ISERDES (including the one "deserializing" the clock) should allow you to find the right alignment by applying bitslip until the deserialized clock has the right phase (1100011 for Camera Link).

ESE2 primitive. What I need to understand is exactly how the unit will dist ribute the serial input to the bits in the output (paralell) words, or in o ther words, how ISERDESE aligns the frames on the incoming serial data stre am in order to deliver the paralell words.

caded (width expansion) ISERDES-pair:

is generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR mode. The VHDL file can be downloaded here:

_if_wiz_v4_1.zip

the frame is aligned - I have marked the frame by the two cursors. It is c lear that the ddly input within this frame (10000111100100) is what appears on iserdes_q_vec on the next rising edge of clkdiv.

e looked in the User Guide (ug471) but can't find info on this.

hing out of the results (in this design, rst is de-asserted synchronously w ith clkdiv, as suggested by the user guide).

alignment with bitslip operations. In my case, for the serial data, clkdiv is equal to the frame clock. From the simulation I can of course determine how the frame is placed in the serial data, and fix the paralell words in c ustom logic, but then I need to understand why I get this particular offset , and be convinced that I will always get exactly this particular offset.

ll, but nothing in the UG suggests that, and according to the simulation, t hat is also clearly not the case.

word in any particular bit alignment or offset. You will want to add a tra ining sequence that is run at startup to bitslip the iserdes appropriately, and then turn the interface lose for general traffic.

I've done something similar for an AD9228 ADC, bitslip applied until the deserialized frame clock shows the correct pattern

-Lasse

Thanks for comments.

Yes, it does seem like there's no good solution for this (when no training pattern is available).

Good ideas from Gabor and Lasse about deserialising the frame clock. Howeve r, in my case, the data and the frame clock would come from different ports on the ISERDESE2 (DDLY and D respectively) since the data comes from a pad through an IDELAY and the frame clock comes from an MMCM. I don't know if I can then fully trust the deserialised data to be in phase.

I decided to drop the ISERDES and do my deserialiser in logic instead. A pi ty I can't use the silicon resources though; a deterministic behaviour of t he primitive, and it being documented, would have been enough.

I may be missing something, but if there is no training pattern then surely all alignments are equally valid.

If not, then you need to specify how you know when the alignment is correct. Then take the ISERDES output, apply the specified algorithm, and (if necessary) shift the ISERDES output appropriately.

ly all

ow

ately.

What you're missing is when the pattern is simply specified and therefore a 'given'. An example, as Gabor mentioned, is Camera Link which specifies u se of specific parts that are recommended for use for that interface. Thos e parts sync it up so that the incoming low speed clock edges occurs on par ticular high speed clock cycle. No training pattern is needed.

With the FPGA SERDES primitives, no such alignment occurs automatically. F urthermore, multriple SERDES primitives are not guaranteed to be aligned wi th each other so each needs to be bit-slipped independently.

When you try to implement a Camera Link interface (or any SERDES interface that normally uses those same TI interface parts) using an FPGA, you will w ant to either have control of both ends (so you can insert a training patte rn) or come up with creative work arounds (like Gabor seems to have found).

Kevin Jennings

As I wrote, I do have a frame clock which specifies the alignment.

(The concept of a frame clock: the frameClock:dataClock ratio is equal to the width of the parallel words. Coinsiding rising edges of the data and frame clocks assigns the current serial bit to either end of the parallel word.)

I had an issue like this in Virtex 5, where the output of the IDELAY could either route to a global clock as a route-through or to an input flop as a delay element. I worked around this (this was for LVDS intput) by using an IBUFDS_DIFFOUT and deserializing the inverted output while using the non-inverted output to feed the PLL.

Note that the phase going to the PLL is no longer important if you are going to deserialize the clock to find the proper sampling phase. The important thing is to use the same input delay element for the clock to ISERDES as the data to ISERDES paths.