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.

ADS42JB69: How to implement JESD204 IPs on Xilinx FPGA to work with the dual core part

Part Number: ADS42JB69

Hi,
We’d appreciate your help:
We’re setting up ADS42JB69 which has 2 cores, to work with our Xilinx MPSOC Ultrascale+ FPGA.
We’re using licensed Xilinx’s JESD204 IPs meaning - a PHY IP and an RX IP.
How should the IPs be configured to work correctly with the TI ADS42JB69 2 cores, 2 lanes per each core?

Should we use - see image below:
a. 1 phy IP and 2 rx IPs?
b. 2 phy IPs and 2 rx IPs?
Something else?

Most importantly, if we use option b and the data is all in the same transceiver quad,
Can we use the same clock pins source for both phys? (meaning ref_clk_a and ref_clk_b are the same clock)

Many thanks.

  • Hi Hershko,

    The recommended approach will be Option A (all lanes to one Quad, and a single reference clock). In addition, you can also configure the JESD Rx IP as a single 4 lane IP. This will allow the IP to automatically align samples across all the lanes (provided the TI ADCs are synchronized with a SYSREF signal).

    Regards,

    Ameet

  • Hi Ameet,

    Thank you for your response.
    Our device needs to handle data from 2 anntennas at the same time.
    Each core of the 2 of the ADC has a 2 lane link.

    Will the approach you're suggesting allow us to use the two 2 lane links separately? 

    Thank you.

  • Hi Hershko,

    The ability to use a single IP for multiple ADCs will work if you are able to route a balanced clock and SYSREF to the ADCs (thus synchronizing them). In addition, the assumption is that both links will be active simultaneously (as the Rx IP will monitor all 4 lanes).

    If these conditions can be addressed, then you can use a single IP. It will export a 128 bit data bus (32 bits per lane), so you will be able to monitor the samples independently). 

    My apologies if I have misinterpreted your query.

    Regards,

    Ameet

  • Hi Ameet,

    Thank you for your response. 

    There might be a case in which one of the links will not work and one will.

    What should be the implementation in such case?

    Only 1 phy IP and 1 JESD RX IP per link? meaning a total of 2 phy 2 jesd? 

    If so, and we have 2 PHY IPs, can they share the same ref clock (Transceiver clk)?

    We will use 16b per lane.

    Thanks,

    Hofit

  • Hi 

    I think, it is easy to use only one JESD RX IP which needs 1 transceiver clock, 1 core(device) clock and 1 sysref clock because the transceiver ip within the phy ip can regard two adcs with each 2 lanes as one adc with 4 lanes

    Refer to this article

    support.xilinx.com/.../69610

  • Hi Kim, Hershko,

    Apologies, I was on travel for a couple of days.

    There are a few ways to approach thing, but unfortunately this is very implementation and application dependent.

    To begin with, using only one JESD Rx IP will not be possible given that your application can have one ADC link going down while the other is active. This will cause the entire IP to initiate a restart, because it thinks it is talking to one ADC. The other options are:

    1> One 4 lane (Quad) feeding two lanes each to two JESD IPs, with one shared reference clock and one QPLL

    2> One 4 lane (Quad) feeding two lanes each to two JESD IPs, with one shared reference clock and a separate QPLL for each pair of lanes. This is assuming that your lane rate is supported by both QPLLs

    3> Two separate Quads with two JESD IPs, but with one reference clock feeding both Quads. This will give each IP complete control over the Quad logic that it is interacting with.

    At the end of the day, each Rx lane (channel) in a transceiver (PHY) can function independently in terms of locking into the data from the corresponding Tx. As a result, you can have two lanes of a PHY Quad going to one JESD IP and two to another JESD IP. However, the IP also has initialization sequences that can cause it to reset logic in the PHY, so if one link is down while the other is working, and you re-init the disabled link, as the IP is coming up, it may reset the PLL that is also feeding the other.

    The summary is that you may have a few approaches to choose from, but it will be important to validate the behavior in simulations to ensure that one link's behavior does not impact the other.

    Regards,

    Ameet