Xilinx ISERDESE2 deserializer primitive behaviour

[Carl]

Hi,

I'm having some problems to understand the exact behavior of the ISERDESE2 primitive. What I need to understand is exactly how the unit will distribute the serial input to the bits in the output (paralell) words, or in other words, how ISERDESE aligns the frames on the incoming serial data stream in order to deliver the paralell words.

Here is a screenshot showing the signals on some of the ports of a cascaded (width expansion) ISERDES-pair:
http://forums.xilinx.com/t5/image/serverpage/image-id/11986i790019220C7960F0/

This example is actually from a simulation of the example design that is generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR mode. The VHDL file can be downloaded here:
http://forums.xilinx.com/xlnx/attachments/xlnx/7Series/3904/2/selectio_if_wiz_v4_1.zip

The signal iserdes_q_vec is a vector [slave q8..q3] & [master q8..q1].

From the input (ddly) and output (iserdes_q_vec) I can clearly see how the frame is aligned - I have marked the frame by the two cursors. It is clear that the ddly input within this frame (10000111100100) is what appears on iserdes_q_vec on the next rising edge of clkdiv.

The reason for this particular alignment is however unknown to me. I've looked in the User Guide (ug471) but can't find info on this.

I tried to de-assert rst in various ways but couldn't really make anything out of the results (in this design, rst is de-asserted synchronously with clkdiv, as suggested by the user guide).

In my case, I have no training pattern and hance can't find the right 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 custom 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.

I would intuitively have expected clkdiv to act as a frame clock as well, but nothing in the UG suggests that, and according to the simulation, that is also clearly not the case.

Device: xc7k160t-2

Thanks in advance,
Carl

 

On Thursday, March 20, 2014 1:41:55 AM UTC-7, Carl wrote:

Hi,



I'm having some problems to understand the exact behavior of the ISERDESE2 primitive. What I need to understand is exactly how the unit will distribute the serial input to the bits in the output (paralell) words, or in other words, how ISERDESE aligns the frames on the incoming serial data stream in order to deliver the paralell words.



Here is a screenshot showing the signals on some of the ports of a cascaded (width expansion) ISERDES-pair:

http://forums.xilinx.com/t5/image/serverpage/image-id/11986i790019220C7960F0/



This example is actually from a simulation of the example design that is generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR mode. The VHDL file can be downloaded here:

http://forums.xilinx.com/xlnx/attachments/xlnx/7Series/3904/2/selectio_if_wiz_v4_1.zip



The signal iserdes_q_vec is a vector [slave q8..q3] & [master q8..q1].



From the input (ddly) and output (iserdes_q_vec) I can clearly see how the frame is aligned - I have marked the frame by the two cursors. It is clear that the ddly input within this frame (10000111100100) is what appears on iserdes_q_vec on the next rising edge of clkdiv.



The reason for this particular alignment is however unknown to me. I've looked in the User Guide (ug471) but can't find info on this.



I tried to de-assert rst in various ways but couldn't really make anything out of the results (in this design, rst is de-asserted synchronously with clkdiv, as suggested by the user guide).



In my case, I have no training pattern and hance can't find the right 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 custom 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.



I would intuitively have expected clkdiv to act as a frame clock as well, but nothing in the UG suggests that, and according to the simulation, that is also clearly not the case.



Device: xc7k160t-2



Thanks in advance,

Carl

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

 

[GaborSzakacs]

matt.lettau@gmail.com wrote:

On Thursday, March 20, 2014 1:41:55 AM UTC-7, Carl wrote:
Hi,



I'm having some problems to understand the exact behavior of the ISERDESE2 primitive. What I need to understand is exactly how the unit will distribute the serial input to the bits in the output (paralell) words, or in other words, how ISERDESE aligns the frames on the incoming serial data stream in order to deliver the paralell words.



Here is a screenshot showing the signals on some of the ports of a cascaded (width expansion) ISERDES-pair:

http://forums.xilinx.com/t5/image/serverpage/image-id/11986i790019220C7960F0/



This example is actually from a simulation of the example design that is generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR mode. The VHDL file can be downloaded here:

http://forums.xilinx.com/xlnx/attachments/xlnx/7Series/3904/2/selectio_if_wiz_v4_1.zip



The signal iserdes_q_vec is a vector [slave q8..q3] & [master q8..q1].



From the input (ddly) and output (iserdes_q_vec) I can clearly see how the frame is aligned - I have marked the frame by the two cursors. It is clear that the ddly input within this frame (10000111100100) is what appears on iserdes_q_vec on the next rising edge of clkdiv.



The reason for this particular alignment is however unknown to me. I've looked in the User Guide (ug471) but can't find info on this.



I tried to de-assert rst in various ways but couldn't really make anything out of the results (in this design, rst is de-asserted synchronously with clkdiv, as suggested by the user guide).



In my case, I have no training pattern and hance can't find the right 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 custom 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.



I would intuitively have expected clkdiv to act as a frame clock as well, but nothing in the UG suggests that, and according to the simulation, that is also clearly not the case.



Device: xc7k160t-2



Thanks in advance,

Carl

I don't think you can rely on the real hardware presenting the parallel word in any particular bit alignment or offset. You will want to add a training 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).

--
Gabor

 

Den fredag den 21. marts 2014 20.44.37 UTC+1 skrev Gabor:

matt.lettau@gmail.com wrote:

On Thursday, March 20, 2014 1:41:55 AM UTC-7, Carl wrote:

Hi,







I'm having some problems to understand the exact behavior of the ISERDESE2 primitive. What I need to understand is exactly how the unit will distribute the serial input to the bits in the output (paralell) words, or in other words, how ISERDESE aligns the frames on the incoming serial data stream in order to deliver the paralell words.







Here is a screenshot showing the signals on some of the ports of a cascaded (width expansion) ISERDES-pair:



http://forums.xilinx.com/t5/image/serverpage/image-id/11986i790019220C7960F0/







This example is actually from a simulation of the example design that is generated by Coregen (SelectIO Interface Wizard). Width is 14 bits, DDR mode. The VHDL file can be downloaded here:



http://forums.xilinx.com/xlnx/attachments/xlnx/7Series/3904/2/selectio_if_wiz_v4_1.zip







The signal iserdes_q_vec is a vector [slave q8..q3] & [master q8..q1].







From the input (ddly) and output (iserdes_q_vec) I can clearly see how the frame is aligned - I have marked the frame by the two cursors. It is clear that the ddly input within this frame (10000111100100) is what appears on iserdes_q_vec on the next rising edge of clkdiv.







The reason for this particular alignment is however unknown to me. I've looked in the User Guide (ug471) but can't find info on this.







I tried to de-assert rst in various ways but couldn't really make anything out of the results (in this design, rst is de-asserted synchronously with clkdiv, as suggested by the user guide).







In my case, I have no training pattern and hance can't find the right 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 custom 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.







I would intuitively have expected clkdiv to act as a frame clock as well, but nothing in the UG suggests that, and according to the simulation, that is also clearly not the case.







Device: xc7k160t-2







Thanks in advance,



Carl



I don't think you can rely on the real hardware presenting the parallel word in any particular bit alignment or offset. You will want to add a training 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).

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

-Lasse

 

[Carl]

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. However, 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 pity I can't use the silicon resources though; a deterministic behaviour of the primitive, and it being documented, would have been enough.

 

[KJ]

On Friday, March 28, 2014 2:32:03 PM UTC-4, Tom Gardner wrote:

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.

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 use of specific parts that are recommended for use for that interface. Those parts sync it up so that the incoming low speed clock edges occurs on particular high speed clock cycle. No training pattern is needed.

With the FPGA SERDES primitives, no such alignment occurs automatically. Furthermore, multriple SERDES primitives are not guaranteed to be aligned with 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 want to either have control of both ends (so you can insert a training pattern) or come up with creative work arounds (like Gabor seems to have found).

Kevin Jennings

 

[Tom Gardner]

On 20/03/14 08:41, Carl wrote:

I'm having some problems to understand the exact behavior of the ISERDESE2 primitive. What I need to understand is exactly how the unit will distribute the serial input to the bits in the output (paralell) words, or in other words, how ISERDESE aligns the frames on the incoming serial data stream in order to deliver the paralell words.

In my case, I have no training pattern and hance can't find the right alignment with bitslip operations.

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.

 

[Carl]

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.

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

 

[Gabor]

On 3/28/2014 10:46 AM, Carl wrote:

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. However, 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 pity I can't use the silicon resources though; a deterministic behaviour of the primitive, and it being documented, would have been enough.

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.

--
Gabor