This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ADS54J54EVM: Data received from ADS54j54 inconsistent across lanes

Part Number: ADS54J54EVM
Other Parts Discussed in Thread: LMK04828, ADS54J54

I'm connecting the ADS54j54evm to a Xilinx FPGA evaluation board through an FMC connector.  I'm observing some strange behavior when I test the ADC.   Here is the background:

  • I am using a sample rate of 500 Msps, and two lanes.  LMFS=8411
  • I can receive the  test patterns (incrementing pattern or alternating pattern) across both lanes without issue.
  • I then input a 10 MHz, 0 dBm sine wave into the ADC and observe the output inside the FPGA.  The FPGA has a Xilinx JESD204b core in the design to do the decoding.  The upper lane that represents bits 13:6 of the input signal look good.  The lower lane with bit 5:0 is random data.  It's not a good signal -- the FPGA decode is showing errors on that lane.
  • If I change the frequency or amplitude of the sine wave, the good lane will go bad as well.   The only way to recover is to assert "sync" to the ADC, and then the one MSB lane does recover. 

At this point I am stuck and can't figure out the source of the problem.  This could be a problem in the FPGA, but it's hard to determine at this point and I can use some guidance.   Here are some other steps that I tried that will be helpful.

  • I have replicated this exact behavior on our own hardware, which has the same ADC and FPGA on the same board.   So this rules out a hardware problem.
  • I've tried both using a continuous and a pulse-based SYSREF on the EVM, which made no difference.
  • I changed the configuration of the hardware to use a single lane.  In that case, the lane works for about 1000 clock cycles, followed by bad random data.

Any help would be greatly appreciated.  If you need any more information, please contact me. 

  • Hi,

    one thing to check is the lane mapping from the ADC on the EVM through the FMC connector to the FPGA.  The lanes through the FMC connector are numbered from 0 through 7, (or zero to 3 on those platforms that only support four lanes which some do).  But the ADC54J54 EVM does not necessarily route lane0 from the ADC to lane0 of the FMC connector.   The lanes were routed for cleanliness on the EVM and then reassigned as needed in the FPGA.  In fact, looking at the ini file for our TSW14J56 i see the lane mapping statement:

    Lane Mapping=lane0:1,lane1:0,lane2:2,lane3:3,lane4:5,lane5:6,lane6:4,lane7:7

    This says that the lane assignment swaps lanes 0 and 1, but 2 and 3 are lined up, but then channels C and D are more swapped around with channel C on lanes 5 and 6, with channel D on lanes 4 adn 7.  If the test pattern were toggles, then the lane mapping might not be noticeable.   But the ramp pattern should make it very noticeable.  and channel B should be good in any event.  But i would check this.  Whe you turn on a test pattern for channel A you get the same on channel B.

    if you are using the logic analyzer tools inside the FPGA then you could also use the PRBS pattern available on each lane to test out the mapping from ADC to FPGA.  This would let you isolate lanes since the PRBS pattern can be enabled lane by lane. 

    The later experiments with 1 lane mode falling apart after about 1000 cycles concerns me too,  That makes me suspect the programmign or routing of SYSREF.  When you say pulsed - you mean you turn it off after a link is established?  If the SYSREF were continuous and did not meet setup and hold time relative to clock then there could be a disruption to the link on subsequent SYSREF edges.  But i believe the config file for our EVM leaves the SYSREF operating in continuous mode by default, so if this happens with the EVM into our capture card then it should not be a SYSREF problem.

    You mentioned you used our own hardware too - does that mean TSW14J56 revD?  if so, one issue i found there is that the default firmware installed by the HSDCPro has only the one SYNC signal driven as LVDS by the FPGA.  The ADC54J54 requires a SYNC for channels A and B, and another SYNC for channels C and D.   There is a firmware that comes with the installation that is called TSW14J56REVD_RX_ALT_SYNC_LVDS_FIRMWARE.rbf and i have to load that firmware to get both SYNC signals to the ADC.  Else the FPGA might fail the link initialization. 

    Regards,

    Richard P.

  • Richard,

    The lanes are definitely mapped to the right pins over the FMC connector. I have all of the pinouts of both cards, and they are correct. The issue is that one lane acts correctly, and the other does not. And if I fiddle with the input signal amplitude, the one good line goes bad as well.

    I have tested the 54J54 on two different hardware platforms. The first is the ADS54J54EVM connected to a Xilinx VC-709 evaluation board. I am NOT using the TSW14J56. The second hardware platform is a custom board made by my firm. It has the ADS54J54, LMK04828 clock generator, and the same model Xilinx FPGA as the evaluation board. As I said previously, I get the same symptoms on both of these hardware platforms, and they are very different designs. So this is not a hardware problem.


    I used two different strategies for Sysref, which yielded the same results. I first used a continuous Sysref waveform that ran at 1.625 MHz, which is a multiple of the frame rate. Later I used a pulsed solution. In this case, the clock generator on the EVM outputs 8 pulses and then quits. Shortly after that, a sync is sent to the ADC.
  • Hi,

    going back to your first posting where you mentioned that in single lane per channel the data was good for about 1000 samples and then went bad, I set up our EVM in both 2 lane per channel and 1 lane per channel.  And using the TSW14J56 with its GByte of memory I filled the memory with a long capture of 128Msample per channel. The capture was stable throughout, with a clean FFT taken on samples at the end of the capture (about a quarter of a second of data at 500Msps.  half a second of data in LMF 442 mode.)   Checking my config file, I see that I leave SYSREF running throughout this capture.  My SYSREF is the sample rate divided by 320, for a K value of 32.   I can supply the FFTs or the captured data if desired.

    You mention your SYSREF is 1.625 MHz, for a sample rate of 500Msps.   What is your SYSREF divider in your LMK04828?  and the K value you are using?  Those two frequencies from the LMK don't seem to add up for me.  May I see the screenshots of the programming of the EVM that you are using please, particularly the SYSREF divider and the clock dividers.  Hmmm, did you maybe mean SYSREF at 1.5625MHz?  That is what my config file sets up for SYSREF with a SYSREF divider of 1920 into the VCO rate of 3000M, or which would be sample rate of 500M divided by 320.   That would be a period of 10 multiframes with my K value of 32.

    you mention when you fiddle with the input signal amplitude you can get both lanes to be bad.   What amplitude do you observe for the transition from good to bad?   I may need to see a plot or data dump of what you are seeing as bad data. ah, you said you had decode errors on the bad lane, so it would not be simply a matter of seeing what 'data' was coming across.

    Regards,

    Richard P.

  • Richard,

    The SYSREF frequency that I listed was a typo -- really sorry about that.  The frequency is 1.5625 MHz, which is the same that you are using.  My SYSREF divider is 1920 as well.  K is set to 32.  I have tried a SYSREF frequency of 15.625 MHz as well and still get the same results.

    My input signal is a simple 10 MHz/0 dBm sine wave.  If I change the frequency OR the amplitude, the good lane goes bad. There is no distinctive signal amplitude or frequency that correlates with the bad behavior.  Simply changing either will cause the lane to go bad.

  • Richard,

    Could you tell me what the PRBS polynomials are for the 54J54?  The data sheet only lists the length of the four supported PRBS patterns, but not the polynomials. 

    Bob

  • Hi,

    I checked in the design document that the original designers for this device worked from and I do not see that information specified in that document either.   The designers of this particular device have moved on, so I do not have them available to ask the question of either.    I can say that the 2^7-1 pattern is the industry standard pattern that is represented by the polynomial  PRBS7 =  as I have worked that one.  (taken from Wikipedia, but I have been working with this particular polynomial since I first started working with 8b/10b coded interfaces in 1993.)   The other three polynomials mentioned in the datasheet would also be 'industry standard' and would probably be the same polynomial as listed on that same Wikipedia page, but I do not have confirmation of that.  There are usually several different polynomials that would work for each length of the pattern, but one of them is usually the most commonly implemented. 

    Regards,

    Richard P.