cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
2,952 Views
Registered: ‎05-02-2018

ISERDESE in KU - LVDS interfacing,

Hi All

 

I have an ADC that outputs its samples in LVDS DDR serial streams, with bit clock and byte clock. A case that was described hundreds of times on this forum, dozens of XAPPs, etc.

 

The boards for the final design are not complete yet, so we currently work with the KCU105 board, the ADC evaluation board and some mezzanine board to adapt between them both. There is only one ADC on the ADC EVB, and we have currently an implemented and working interface which works and allows to see two different sine signals from two different external generators (other two channels of the ADC are not used currently) on ILA in Vivado. The working design is implemented as follows:

 

ADC=>LVDS channel => IBUFDS -> IDELAY -> ISERDESE and then bitslip mechanism implemented in regular logic, based on ideas found in XAPP1208. 

 

Clocking of the ISERDESE is done like this:

 

ADC => differential clock => IBUFDS \-> BUFGCE -> undivided fast DDR clock, feeds CLK input of ISERDESE

                                                            \-> BUGCE_DIV(/4) -> divided clock, feeds CLKDIV input of ISERDESE, CLK of  IDELAY, etc

 

This interface looks good, however in our target board we will have several ADCs, and with the bitslip idea as we implemented it looks like we will have problems synchronizing the samples in time. So we devised a new method of bitslip, without logic but with clock gating. 

 

For example, if we are trying to sample the FCLK signal, and the ISERDESE3 goes out of reset in some random point in time, then (of course after bitwise calibration) its output should be one of the next four combinations: 1100_0000, 1111_0000, 0011_1100 or 0000_1111. The ADC outputs pattern as in the screenshot, and bits with even indices would be sampled by the rising edge of the DDR clock and bits with odd indices would be sampled by the falling edge of the DDR clock (assuming we are working LSB first). Indeed most of the times we encounter those patterns and by gating out 1 to 3 pulses of the fast clock we manage to align the ISERDES to the proper byte boundary.

 

However sometimes we encounter patterns like 1000_0111, 1110_0001 or 0111_1000, which are not supposed to happen, because they mean that the ISERDESE samples the incorrect bits in the incorrect order. Unluckily for some reason Xilinx has chosen to limit the documentation for the ISERDESE3 to 4 pages as opposed to 14.5 pages of the ISERDESE2, and we cannot clearly understand what has happened and how to mend it. We tried simulating it, and we indeed get the same problem in simulation, but the cause is unclear and the simulation only confused us more.

 

Has anyone encountered this problem? I would also like to have Xilinx' comment about this issue, perhaps referring to a XAPP. No need to refer to UG571/UG471.

 

Thanks in advance;

 

Igor

 

P.S. the ADC outputs this:

 

lvds ddr.PNG

Tags (3)
0 Kudos
10 Replies
Highlighted
Moderator
Moderator
2,932 Views
Registered: ‎04-18-2011

Hi
Thanks for posting.
Not sure that I like the idea of gating the clock to make the CLKDIV.
There is a clock to out delay associated with the CE of the bufg. Can this plus clock skew cause a problem like this I wonder?

Does this Always occur on the same channels or does it move around?
How do you manage the reset to the ISERDES?
Does it depend on reset? Can a failing channel recover with a reset?

Keith

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
2,909 Views
Registered: ‎05-02-2018

Hi Keith

 

Thanks for quick answering.

 

I do not think that the problem is caused by the clock to output delay of the BUFGCE. We encountered the "invalid" patterns previously, when we were not using clock gating but instead using bitslip in logic.

 

In my opinion, the problem caused by ISERDESE incorrectly coming out of reset. If we assume that the ISERDESE is essentially built from 8 flops, 4 of them clocked by CLK and 4 clocked by CLKB, as in this crude picture I drew:

 

ISERDESE.jpg

 

Then this arrangement can come out of reset in two possible ways - one will sample the incoming data ABCDEFGH correctly as ABCDEFGH and the other will sample it as BADCFEHG. (The first bit can be sampled by flop 6 and not 7, depends on the phase of the CLK and the additional logic that would keep this from happening).

 

The problem is that we do not understand the internal logic of the ISERDESE and therefore it is a problem.

 

Could you please shed some more light on the operation of it?

 

0 Kudos
Highlighted
Moderator
Moderator
2,902 Views
Registered: ‎04-18-2011

How do you reset and more importantly take the ISERDES out of Reset?

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
2,896 Views
Registered: ‎05-02-2018

In the current design - it is synchronized into CLK domain from VIO that I use to calibrate the data manually. Assertion and removal is synchronous to CLK. I experimented with synchronizing it to CLKDIV, not much change. Could be nice if table 2-6 in UG571 (v1.8, the most recent one) that currently says "Asynchronous reset. Deassert synchronously for best results." for RST port, would also mention synchronously to which clock it should be deasserted - for best results.

 

Yes, I know about p190 in UG571. We did a slightly modified method of that in the design with the bitslip in logic.

 

BTW, still an error here:

 

release_reset.PNG

 

 

 

 

0 Kudos
Highlighted
Observer
Observer
2,891 Views
Registered: ‎05-02-2018

I see that in the UG381 (the SelectIO guide of Spartan 6) there is a very useful diagram:

 

iserdese in SP6.PNG

 

Can we please have something similar for Ultrascale' ISERDESE3? Why there is no such diagram in the UG571 in the first place?

0 Kudos
Highlighted
Moderator
Moderator
2,842 Views
Registered: ‎04-18-2011

We always suggest that the reset be synchronous to CLKDIV and not CLK.
We can't give a diagram of the ISERDES in ultrascale since it doesn't really exist. Iserdes is an abstraction of the native mode rxbitslice.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
2,828 Views
Registered: ‎05-02-2018

I will make the reset synchronous to CLKDIV.

 

I also understood (got the idea from XAPP1208, simulated it, but not verified in hardware) that the CLKDIV is not necessarily has to be a divided version of the CLK itself (i.e. can also be some other clock in the matching frequency), because the ISERDESE really divides the CLK internally (and outputs it on INTERNAL_DIVCLK pin, but we won't use this pin because it is explicitly reserved).

 

I do not need nor want an internal diagram of the ISERDESE3, I only want waveform diagrams to understand its behavior. The IDDRE1 component appears to be a subfunction ( or "an abstraction" ?) of the ISERDESE3 and therefore a subfunction of RX Bitslice. It has three modes of operation and each one of them is described in sufficient detail while it is only a DDR flip-flop. Why can't we have a detailed description of ISERDESE3? No need to disclose trade secrets, just some waveforms of input and output signals.

 

I pretty much understand that Xilinx pushes us to move to native-mode operation. I indeed would very much like to comply, but I still don't have the hardware (the PCB with native-mode supporting routing and pin assignment), which would be ready in a couple of month. But I still need to develop the rest of the design in that time, cannot sit on my hands waiting for the boards. I need some interface functioning now, and functioning correctly. 

 

0 Kudos
Highlighted
Community Manager
Community Manager
2,674 Views
Registered: ‎08-08-2007

I also understood (got the idea from XAPP1208, simulated it, but not verified in hardware) that the CLKDIV is not necessarily has to be a divided version of the CLK itself (i.e. can also be some other clock in the matching frequency), because the ISERDESE really divides the CLK internally (and outputs it on INTERNAL_DIVCLK pin, but we won't use this pin because it is explicitly reserved).

You are correct. The ISERDESE3 has a build in FIFO, if you BYPASS the FIFO then the timing to fabric is from the INTERNAL_DIVCLK that the ISEDESE3 creates from the CLK. In Vivado timing you can see the path.

 

In UG571 figures Figure 2-12: ISERDES FIFO Latency with DATA_WIDTH = 8 and Figure 2-13: ISERDES FIFO Latency with DATA_WIDTH = 4 http://www.xilinx.com/support/documentation/user_guides/ug571-ultrascale-selectio.pdf

are the diagrams of ISERDES waveforms, it does not include the Reset or CE ports. Is what you are missing these waveforms with these included? Or a similiar diagram with the FIFO Bypassed? 

 

 

Thanks,
Sandy

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
2,663 Views
Registered: ‎05-02-2018

Hi Sandrao

 

Thanks for answering.

 

Yes, I would very much like to see both: the diagram with the FIFO bypassed and the diagram with Reset and CE ports. I've been simulating the ISERDESE3 for a while but couldn't understand this part.

 

Additional questions that are unclear:

Why the ISERDESE begins to sample with the falling edge of the CLK? (marked with red on the screenshot)

Does it always do so and can one indeed rely on that? 

 

Where are the pipeline stages in the figure 2-12? The FIFO seems to be FWFT too.

 

Thanks in advance.

ISERDESE3 FIFO.PNG

0 Kudos
Highlighted
Observer
Observer
1,526 Views
Registered: ‎05-02-2018

No answer yet from Xilinx's support on that issue...

0 Kudos