cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
8,349 Views
Registered: ‎06-25-2014

XAPP585 Receiver Bit Misalignment

Jump to solution

Hello Xilinx Forum,

 

I am using the XAPP585 reference design files to generate a Camera Link receiver and transmitter.  I've written a Camera Link video test pattern generator and used this to test loopback of the interface, both in simulation and in my target hardware (Artix-7 device) using an external CL cable between two CL connectors on the board.  Furthermore, I've been successful in transmitting this test pattern video to an Express Card frame grabber.  So far the testing has been strictly in the Base configuration.

 

The final test I am running is to receive Base Camera Link video from an external source (i.e. CL simulator or an actual CL camera) using my hardware, then forward this video back out to the same Express Card frame grabber.  Unfortunately, when using an external source, my received data has timing misalignment.  I've tried to find the problem by changing the various user-settable parameters, including changing the HIGH_PERFORMANCE_MODE setting, varying input clock rates to test both SDR and DDR versions and per-bit deskew vs. no per-bit deskew,  and using a PLL vs. MMCM.  None of these changes had an impact on the problem.  

 

The most troubling thing is the fact that the external loopback test I ran works perfectly every time, even with very challenging sync (0x000000 followed by 0xFFFFFF) patterns, but the external source test does not, even for simply gradient patterns.  At first I tried just the external CL simulator, and after seeing the problem, tried a CL camera that was available in order to rule out an isolated issue with the simulator.  Both the CL simulator and camera work fine when directly connected to the Express card frame grabber, but both exhibited bit errors when connected to my FPGA hardware.  I am able to vary the CL simulator across the 20-85 MHz range, so I repeated the test with varying clock rates, but I still had issues.  I changed the test pattern output on the CL simulator to output a constant 0xFFFFFF for the data, which would result in the data changing from 0x000000 to 0xFFFFFF at the start of each line.  This showed that not all of the data bits in the received output are transitioning at the same time, as shown in this screenshot.  Note:  Bit 6 is FVAL, so it rises earlier. Bit 2 is DVAL and it is set to a constant by the simulator.  Bit 3 is Spare, which is not used.  Bit 10 is the LVAL signal.  Also, the simulator was set to a pixel clock of 40 MHz, which allows me to use SDR mode, but disables any per-bit deskew.  I've tried the same test using an 80 MHz clock and DDR mode, but this yields the same results.

 

 

camLinkRxIssue.PNG

 

 

Conversely, when I do the same test pattern using my hardware in external loopback mode (out one connector and back in another), I get the following.  This is done using DDR mode and a pixel clock of 85 MHz, but I've also run this same test at 40 MHz using SDR mode.  My test pattern generator raises FVAL/LVAL/DVAL at the same time, so the only strange bit is #3, which is the unused Spare line.

 

camLinkRxLoopback.PNG

 

Furthermore, when transmitting the much more difficult sync pattern (0x00000, followed by 0xFFFFFF, repeating), I get the following results, showing that the link is working properly.  Bits 10, 6, and 2 are the LVAL/FVAL/DVAL, so they remain high.

 

camLinkRxLoopbackSync.PNG

 

 

So my CL simulator and CL camera are outputting video that my FPGA can't handle properly, but an Express card frame grabber, using Channel Link receiver chips, can receive their video just fine.  I'm at a loss for what to try next and was hoping someone would have some useful suggestions that I haven't tried.  

 

For reference, I am using the design files linked from the XAPP585.pdf file with version 1.1.1 and dated March 18, 2015.  

Thank you in advance,

 

Scott

 

 

P.S. 

As an aside, Figures 2, 3, 6, and 7 of the XAPP585 document should be updated to reflect the fact that the PLL/MMCM block is actually being driven from the output of the IDELAY block, not the output of the IBUFGDS_DIFF_OUT block as is currently shown.   

 

  

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Observer
Observer
13,988 Views
Registered: ‎06-25-2014

Re: XAPP585 Receiver Bit Misalignment

Jump to solution

I was able to solve my problem tonight.  The XAPP585 receiver code allows the user to set the DIFF_TERM generic at a higher level, which ripples down through the hierarchy and is used to set the DIFF_TERM generics for the IBUFDS_DIFF_OUT buffers.  I had the DIFF_TERM generic set to TRUE when instantiating the XAPP585 receiver macro, as required for my design, but it appears this property wasn't actually being set.  When I redundantly (or so I thought) added the DIFF_TERM constraints to my XDC file, my receiver started working perfectly when connected to my external sources.

 

In my working version, I checked the properties for the differential input nets and the DIFF_TERM box was checked.  When I commented out the DIFF_TERM constraints in the XDC file and ran through synthesis and implementation again, the DIFF_TERM box was no longer checked in the properties window for the differential inputs, as shown below.  I pored through the slew of warning messages that Vivado generated for the design looking for anything pertaining to the DIFF_TERM property, but nothing indicated that the DIFF_TERM setting would be ignored, which can happen if bank I/O standards are not set appropriately.  

 

diffTermGenericOnly.PNG

 

I tried to create a simple example that I could share with others in an attempt to recreate this strange behavior, but unfortunately I couldn't reproduce it.  If someone else would like to look into this, I am using Vivado 2015.2 and targeting an XC7A100T-1CSG324C device.  I either have some Vivado project setting wrong or maybe there is a strange hierarchy related component to this problem, but it was a tricky one.

 

Sadly, I didn't follow my typical rule of questioning everything because my loopback test worked the first time, which gave me false confidence that the DIFF_TERM attribute was correctly being applied.  Apparently you don't need differential termination resistors on the differential inputs when driving an FPGA with itself, at least in my setup, which I guess makes a little bit of sense.  Even worse, I actually made the decision early on to exclude the DIFF_TERM constraints from my XDC file (the example XDC file for the XAPP585 included them) to allow sole control of this setting in the HDL, which I feel is a bit more flexible.  

 

In the end I hope my struggles help anyone else out there using XAPP585.  At the very least my explanation of the bit-ordering coming out of the XAPP585 receiver macro should answer several posts I have seen on the forum while looking for an answer to my problem.

 

Thank you to Gabor for bringing me back to the problem tonight.  I had left it to fester for awhile, but responding to your last post made me revisit some things.

 

Scott 

View solution in original post

0 Kudos
7 Replies
Highlighted
Professor
Professor
8,323 Views
Registered: ‎08-14-2007

Re: XAPP585 Receiver Bit Misalignment

Jump to solution

I'm trying to understand the significance of the bit shifts, however I don't know where your numbering scheme came from.  The Channel-Link standard numbering (from the original National data sheets, now T.I.) vs. Camera Link base looks like:

 

0  = A0      14 = B5
1  = A1      15 = C0
2  = A2      16 = C6
3  = A3      17 = C7
4  = A4      18 = C1
5  = A7      19 = C2
6  = A5      20 = C3
7  = B0      21 = C4
8  = B1      22 = C5
9  = B2      23 = Spare
10 = B6      24 = Line Valid
11 = B7      25 = Frame Valid
12 = B3      26 = Data Valid
13 = B4      27 = A6

 

You say bit 3 is spare, so I have no way of seeing what order the bits actually came in at the wire.

-- Gabor
0 Kudos
Highlighted
Observer
Observer
8,294 Views
Registered: ‎06-25-2014

Re: XAPP585 Receiver Bit Misalignment

Jump to solution

The 28 bits of data shown are directly out of XAPP585's  serdes_1_to_7_mmcm_idelay_sdr.vhd module, which is the rx_data output port, when using the "PER_CLOCK"  DATA_FORMAT generic setting.  Camera Link data is transmitted in a scrambled format across the 4 data pairs as shown below, which is a modified version of Figure 16 on page 9 of the TI DS90CR287/DS90CR288A data sheet.  I've added the rx_data bit numbers (in red) coming from the serdes module for clarity.  So rx_data(3) corresponds to TxIN23, which is the Spare signal of the Camera Link, rx_data(6) corresponds to TxIN25, which is the FVAL signal, and so on.  I reorder the data appropriately in a wrapper file, but I wanted to focus on the fact that the misaligned data was coming directly out of the XAPP585 reference files, not my own custom wrapper files.

 

bitOrdering.png

 

The significance of the bit shifts is that when a constant of 0xFFFFFF is sent as the video data, then 24 bits + LVAL should all rise simulataneously (assuming data is configured to be 0x000000 when LVAL = '0').  As you can see in my previous post, the data bits rise at different times when connected to my external source, but rise simultaneously when I run with an external loopback. 

 

Hope that clears up any confusion.  I'm not worried about misordering, but rather, just misalignment.

 

Thank you,

 

Scott

 

 

0 Kudos
Highlighted
Professor
Professor
8,218 Views
Registered: ‎08-14-2007

Re: XAPP585 Receiver Bit Misalignment

Jump to solution

It looks like there is a "bit slip" issue.  Usually if you don't have a training pattern (as in Camera Link) you need to make sure that all 5 deserializers (yes, there's one for the clock signal, too) come out of reset synchronously, and if you use bit slip to line up the clock signal, you need to apply the same number of slips to the 4 data channels.  In the loopback case, you might benefit from using the same clock resource on your transmitter as your receiver, and just get lucky when releasing the reset of the receiver ISERDES blocks.  When you have an external source, you would need to have PLL or MMCM lock before synchronously resetting the ISERDES blocks.  In the past I have had a lot of trouble understanding the inner workings of the ISERDES and ended up just using IDDR instead.  At the maximum rate of 595 Mbps, this is fairly easy to accomplish in any of the newer devices.

-- Gabor
Highlighted
Observer
Observer
8,096 Views
Registered: ‎06-25-2014

Re: XAPP585 Receiver Bit Misalignment

Jump to solution

Hi Gabor,

 

I appreciate your willingness to help with this problem.  I've posted a few questions to the Xilinx forum and I can't recall receiving another reply.  This is a difficult problem, so I am happy for any assistance.

 

The XAPP585 code uses the incoming pixel clock, which toggles at the frequency of the parallel data, as the training pattern.  As shown in the diagram from my previous post, a pattern of "1100011" on the clock represents the proper bit alignment to receive each data word.  

 

Additionally, the XAPP585 code does use the lock signal from the MMCM or PLL, plus a bit-slip state machine, in order to control the reset on the ISERDES modules.  In general, the code appears to be valid as others have used it successfully and I can use it just fine in external loopback mode.  

 

In the case of external loopback, I am not using the same clock to recover the data as I am to generate it.  A PLL in the FPGA generates my desired pixel clock frequency and then I use the transmit version of XAPP585 to send the clock and data out one of the board's Camera Link connectors.  I connect a CL cable between this connector and another one to implement the external loopback.  Then I use the receive version of XAPP585 to recover the clock and data.  The receiver does not use any of the transmitters clocks during this process, other than the parallel one that is transmitted as part of the Camera Link interface, which would be true of an external source as well.  In this way, I think my loopback setup is representative of an interface where there is an external source.  That said, clearly there are advantages to sharing the same power and ground, sharing the same I/O voltage levels (even though its still LVDS), and transmitting a known good pixel clock from an FPGA.  

 

I appreciate your recommendation to look at using IDDR buffers, but I am still hoping that someone has a few recommendations on what I could change in the XAPP585 code, or some other constraints, to allow the code to work as is.  Perhaps not many people are using XAPP585 in their designs and the author does not appear to work for Xilinx anymore.  It really is a novel concept that allows one to avoid putting down Camera Link receivers/transmitters, which cost space on the board, 2.8X more clock/data I/O lines, and lock you into either a receive or transmit interface, instead of allowing a convenient bidirectional interface for multi-purpose boards.

 

I'm hoping to get the chance to try it with some different CL cameras in the near future.  Hopefully my luck changes, but I'm not holding my breath.

 

Scott

  

0 Kudos
Highlighted
Observer
Observer
13,989 Views
Registered: ‎06-25-2014

Re: XAPP585 Receiver Bit Misalignment

Jump to solution

I was able to solve my problem tonight.  The XAPP585 receiver code allows the user to set the DIFF_TERM generic at a higher level, which ripples down through the hierarchy and is used to set the DIFF_TERM generics for the IBUFDS_DIFF_OUT buffers.  I had the DIFF_TERM generic set to TRUE when instantiating the XAPP585 receiver macro, as required for my design, but it appears this property wasn't actually being set.  When I redundantly (or so I thought) added the DIFF_TERM constraints to my XDC file, my receiver started working perfectly when connected to my external sources.

 

In my working version, I checked the properties for the differential input nets and the DIFF_TERM box was checked.  When I commented out the DIFF_TERM constraints in the XDC file and ran through synthesis and implementation again, the DIFF_TERM box was no longer checked in the properties window for the differential inputs, as shown below.  I pored through the slew of warning messages that Vivado generated for the design looking for anything pertaining to the DIFF_TERM property, but nothing indicated that the DIFF_TERM setting would be ignored, which can happen if bank I/O standards are not set appropriately.  

 

diffTermGenericOnly.PNG

 

I tried to create a simple example that I could share with others in an attempt to recreate this strange behavior, but unfortunately I couldn't reproduce it.  If someone else would like to look into this, I am using Vivado 2015.2 and targeting an XC7A100T-1CSG324C device.  I either have some Vivado project setting wrong or maybe there is a strange hierarchy related component to this problem, but it was a tricky one.

 

Sadly, I didn't follow my typical rule of questioning everything because my loopback test worked the first time, which gave me false confidence that the DIFF_TERM attribute was correctly being applied.  Apparently you don't need differential termination resistors on the differential inputs when driving an FPGA with itself, at least in my setup, which I guess makes a little bit of sense.  Even worse, I actually made the decision early on to exclude the DIFF_TERM constraints from my XDC file (the example XDC file for the XAPP585 included them) to allow sole control of this setting in the HDL, which I feel is a bit more flexible.  

 

In the end I hope my struggles help anyone else out there using XAPP585.  At the very least my explanation of the bit-ordering coming out of the XAPP585 receiver macro should answer several posts I have seen on the forum while looking for an answer to my problem.

 

Thank you to Gabor for bringing me back to the problem tonight.  I had left it to fester for awhile, but responding to your last post made me revisit some things.

 

Scott 

View solution in original post

0 Kudos
Highlighted
Visitor
Visitor
8,042 Views
Registered: ‎08-18-2015

Re: XAPP585 Receiver Bit Misalignment

Jump to solution

Thank you for posting this!

I've been struggling with the same problem (I'm using XAPP585 for video deserialization) for the last couple of days, starting to believe that my board suffers from far end cross talk. Turns out the problem was reflections from the mismatched impedance caused by the ignored diff_term attribute on the ibuf_ds.

 

Eyal

0 Kudos
Highlighted
Observer
Observer
8,034 Views
Registered: ‎06-25-2014

Re: XAPP585 Receiver Bit Misalignment

Jump to solution

I'm glad I could be of assistance to you.  It's good to know I'm not the only one who runs into these problems.

 

Scott

0 Kudos