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.

ADC12DJ3200EVM: KCU105 Reference Design Targeted for ZCU102 Byte Ordering

Part Number: ADC12DJ3200EVM
Other Parts Discussed in Thread: ADC12DJ3200

I modified the KCU105 reference design to conform to the ZCU102 dev kit.  I am able to see an aligned ramp pattern across all lanes but when I try to sample a terminated input the samples out of the TI transport code looks off (and out of the JESD core itself).  I have the following:

 

The Lane Data out of the core does match what come out of the transport layer.  I am suspicious there is a lane mismatch or something similar.  The out of sequence occurrence appears to be synchronous.  The image below shows that.

The reference design mapping is confusing so I may be interpreting something incorrectly but I have tried a few iterations.  Below is what I mapped for the reference design.  

KCU105
TX Lane FMC Mezz FMC Base MGT NAME Pack Pin MGT LOC XDC LOC NET INST
DA0 0 A10/A11 DP3 228-3 E4 X0Y19 3
DA1 1 C6/C7 DP0 228-0 D2 X0Y16 0
DA2 2 A6/A7 DP2 228-2 B2 X0Y18 2
DA3 3 A2/A3 DP1 228-1 A4 X0Y17 1
DB0* 4 B12/B13 DP7 227-3 M2 X0Y15 3
DB1* 5 A14/A15 DP4 227-0 H2 X0Y12 0
DB2* 6 B16/B17 DP6 227-1 K2 X0Y13 2 SWAPPED
DB3* 7 A18/A19 DP5 227-2 F2 X0Y14 1 SWAPPED
* polarity swapped

I then mapped the ZCU102

ZCU102
TX Lane FMC Mezz FMC Base MGT NAME Pack Pin MGT LOC
DA0 0 A10/A11 DP3 229-0 K2 X1Y8
DA1 1 C6/C7 DP0 229-2 H2 X1Y10
DA2 2 A6/A7 DP2 229-3 F2 X1Y11
DA3 3 A2/A3 DP1 229-1 J4 X1Y9
DB0* 4 B12/B13 DP7 228-2 M2 X1Y6
DB1* 5 A14/A15 DP4 228-3 L4 X1Y7
DB2* 6 B16/B17 DP6 228-0 T2 X1Y4
DB3* 7 A18/A19 DP5 228-1 P2 X1Y5
* polarity swapped

I do not understand the KCU105 mapping as the DA/DB buses don't appear to align to the MGT Quad IOs.

Lastly the only way I was able to achieve ramp alignment and incrementing is to use 2 JESD cores in the FPGA, which then matched all JESD parameters, like L.  The outputs are concatenated and fed to the transport code for sample extraction. 

Any insights into what might be wrong is greatly appreciated.  

Thank you!

    

  • Hi Drew,
    I have sent your question over to an engineer familiar with this device.
    Regards,
    Brian
  • Drew,

    Your mapping appears to be correct. You have a Rev A EVM correct? The firmware we use for the KCU105 was provided by Xilinx. You may need to consult with them regarding your question. We do have an example design using the ZCU102 with one of our other ADC boards. You can download this from the link below.

    Regards,

    Jim

    txn.box.com/.../7n7j0pzbw7khfmuvklbhrtpwun2jc59e

  • Hi Jim,

    Yes the EVM rev is A. I checked out the design you attached and the configuration of the cores and IO are almost identical for what I have on port A for the ADC12DJ3200EVM. They did do something different with the JESD core clock which I am testing now. I will report back once complete.

    Thanks!
  • Jim,

    I tested the alternative clock buffer approach and it did not fix the issue.  I did not realize that Xilinx did the initial KCU105 design.  The user guide really only shows the ramp pattern so I am wondering what was done for transport layer verification.  When I enable the transport layer test pattern I see the attached results.  There is clearly a byte ordering issue.  I have reached out to my FAE at Xilinx to try and work it from that side.  Have you seen anything like this before?    

    Thanks!

  • Hi 

    I think the octet ordering shown is OK for Transport Test mode. It's tricky to decode by hand at first because the earliest octets are at the right within the 4 octet groups.

    Taking DA0 (Lane 0) as an example for the 495 and 496 octet groups:

    f0021ff0 50f0043f

    Starting with the rightmost octet in the first group and organizing from earliest to latest:

    • F0
    • 1F
    • 02
    • F0
    • 3F
    • 04
    • F0
    • 50

     Regrouping into 3 digit hex (12 bit binary) values gives

    F01 sample 1

    F02 sample 2

    F03 sample 3

    F04 sample 4

    F05 sample 5

    0     tail bits are 0000b

    This matches the information for DA0 shown in Table 40 in the ADC12DJ3200 datasheet.

    I hope this is helpful.

    Best regards,

    Jim B

  • Jim,

    Thank you for that explanation, that data makes a lot more sense now.  The resolution is now contained within the transport code in the FPGA.  It is curious that the ordering on the Zynq MPSoC is different than what was verified in the Kintex KCU105 board but it is an easy fix.  I have seen posts on Xilinx forums about byte orders changing with parameter changes so I guess this is just something we will need to track and mitigate.   

    I appreciate the help!