ADC12DJ5200RF: JESD204C link with FPGA

JMODE31 is in 64b66b encoding, so SYNC is not used to initialize a link. The link should come up automatically as long as the ADC & GTY xcvr are configured properly with a proper reference and core clock.

Can you put the ADC into transport layer test mode and review the results? This should help to understand if the link data is being received correctly in the FPGA with Xilinx IP.

Hi Bill,

Thanks for quick reply.

The customer conducted transport layer test modes with following commands.

adc_write(0x061, 0x00); # CAL_EN(0x061)

adc_write(0x200,0x00); # JESD_EN(0x200)

adc_write(0x205,5); # enter transport layer test

adc_write(0x061, 0x01); # CAL_EN(0x061)

adc_write(0x200,0x01); # JESD_EN(0x200)

TransportLayerTestMode.csv

They also conducted test mode using clock mode(15) as attached.

iladata_15clockmode.csv

Best regards,

Shota Mago

Hi Shota,

The clock mode data shows that bits are shifted but have been properly decoded - you can see a 0x00ff pattern present in the data on all cycles. It does not seem to be consistent from cycle to cycle in the ILA and there is some drift over time, but you still see a pattern of 0b11111111 followed by 0b00000000

Is this a timing or alignment issue in the FPGA which is causing the frame to drift?

Thanks,

Bill

Hi Bill,

When we combine the entire 66-bit frame, including 2-bit header, we can see a correct pattern of 0x00ff. Consequently, the customer's understanding is that the clock mode continuously transmits 0x00ff00ff... without making any distinction between the header and data. Is this understanding correct?

Regarding scramble of test modes, for example, test pattern of Table 6-60 of transport layer test are scrambled and data transmitted on signal lines are scrambled pattern. Meanwhile, test pattern of clock mode(0x00ff) is not scrambled since transport layer and link layer are bypassed. Is this understanding correct?

Best regards,

Shota Mago

Hi Bill,

Below is initialization for ADC12DJ5200RF provided by the customer. Could you please review it? So far it doesn't link up.

# ADC12DJ5200RF Initialization
# adc_write(addr,data) : Write to ADC12DJ5200RF register
# jesd204phy_write(addr,data) : Write to Xilinx IP "JESD204PHY" register
# jesd204c_write(addr,data) : Write to Xilinx IP "JESD204C" register
# ADC12DJ5200RF Settings：
# Device Clock：5GHz
# JMODE=31
# SYSREF : 3.90625MHz

adc_write(0x000,0xB0);
usleep(1_000);
adc_write(0x200, 0x00);
adc_write(0x061,0x00);
adc_write(0x201,31);# JMODE=31
adc_write(0x202,0x1F); # Number of frames in a K-multiframe
adc_write(0x03B,0x00);
adc_write(0x204,0x01);
adc_write(0x048,0x00);
adc_write(0x029,0x20|0b1_0000); #! [4] SYSREF_ZOOM ON
adc_write(0x029,0x60|0b1_0000); #! [4] SYSREF_ZOOM ON
adc_write(0x062,0x01);
adc_write(0x213,0x07);
adc_write(0x2B1,0x0f); #! SRC_CFG
adc_write(0x2B0,0x01);
usleep(1_000);
adc_read(0x2b4);
adc_write(0x031, 0x80);
adc_write(0x030, 0x00);
adc_write(0x033, 0x80);
adc_write(0x032, 0x00);
adc_write(0x061, 0x01);
adc_write(0x200,0x01);

############################################
# ADC linkup
############################################

jesd204phy_write(0x608,0x0000_0001);
jesd204phy_write(0x60C,0x0000_0001);# = //Toggle: Write 1
jesd204phy_write(0x60C,0x0000_0000);# = //then write 0
jesd204c_write(0x034,0x0000_0001);# =
jesd204c_write(0x050,0x0000_0002);# =
jesd204c_write(0x044,0x0000_0000);
jesd204c_write(0x020,0x0000_0001);
jesd204c_write(0x020,0x0000_0000);
usleep(20_000);
jesd204c_read(0x020);
jesd204c_read(0x20);
jesd204c_read(0x60);
adc_read(0x208);
adc_write(0x029,0x20|0b1_0000);

Best regards,

Shota Mago

The clock output mode is a raw output test pattern, so data is not encoded or scrambled. 

What is the output from reading 0x208? This should tell if the ADC thinks it is sending a link correctly. It also looks like sysref is being used, can you provide details of the sysref configuration, how it is being generated, and configuration on the board?

As a debug step it may be useful to try to bring up a link in subclass 0 without sysref enabled, this should at least help to check that the FPGA is able to establish a link and read data correctly.

Hi Bill,

Thank you very much for your support so far.
I was introduced to you by the TI Japan team regarding our JESD204C setup.

I would like to continue the discussion directly with you.

I will also try communication in subclass 0. Thank you.

Setup is below.
- device clock : 5GHz
- SYSREF : 3.90625MHz
- JESD rate : 16.5Gbps
- lane use :
DA0~3 -> Xilinx IP JESD204PHY.lane0~3
DA4~7 -> not used
DB0~3 -> Xilinx IP JESD204PHY.lane4~7
DB4~7 -> not used
- FEC : not used(CRC mode)

- JMODE : 31
- encode : 64b66b

Situation is below.

- 0x208 read value is 0x7C.

- I collected 32 sync headers to form packets, but the EoMB does not appear every 32 headers.
(I have attached the file used for this analysis.)

- When I descrambled the data output from the JESD204 PHY, the resulting data matched the Transport Layer Test pattern described in the datasheet.

I have an additional question.
In JESD204B, if lanes 0–3 are mistakenly connected as lanes 3–0, I believe the ILAS phase would detect the lane misconnection and generate an error. However, what happens if lanes are connected incorrectly in JESD204C?
Since JESD204C does not have an ILAS phase, I assumed that the ADC or FPGA would not detect the lane misconnection, and the system would link up and operate with the data samples in the wrong order. Is this understanding correct?

Translated with DeepL.com (free version)

Best regards,
Kazuhiro Iida

search_EoMB.xlsx

Hi Shota-san,

This understanding is correct. Fig 6.25 in the datasheet illustrates where the different test pattern modes are present in the datapath. The transport layer and ramp test pattern modes are before the scrambler and 64b66b encoder. The clock pattern is after, so it does not get encoded with header bits.

Regards,
Ameet