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.

ADS54J64: RX_LN_DATA_WIDTH for TI204C-IP

Part Number: ADS54J64


When I set RX_LN_DATA_WIDTH =64, I can successfully receive 64 width user stream of JESD204B IP.

However, when I set RX_LN_DATA_WIDTH =32, I cannot receive 32 width user stream of JESD204B IP.

Which parameters should I change?

 

<jesd_link_params.vh>
`undef RX_LANE_DATA_WIDTH
`define RX_LANE_DATA_WIDTH 32

<gth_8b10b_rxtx.sv>
if (TX_BYTES_PER_LANE == 4 && RX_BYTES_PER_LANE == 4)

  • Jae-heung,

    We are looking into this.

    Regards,

    Jim

  • Hello Jim

    Thanks for your concern.

    If necessary, I can give more information and FPGA IP.

    Best Regards

    Jae-Heung Yeom

  • Hi Jae-heung,

    The changes that you have made seem fine. I am assuming that you have updated the reference clock to 200MHz. Do you see the SYNCn signal transition from 0 to 1?

    I will also recommend running a simulation before you try the build on the FPGA. If you have used the TI reference design firmware, please do a Tx-Rx loopback simulation. This will help identify if there are any problems. 

    Regards,

    Ameet 

  • Hi Ameet

    I use the reference clock of 200MHz for the  RX_LN_DATA_WIDTH =32 while 100MHz for the  RX_LN_DATA_WIDTH =64,

    As shown below, SYNCn signal transition does not happen.

    From the simulation results of the TI reference design, I ask questions.

     The TI design is based on 'RX_LN_DATA_WIDTH =64' as default.

    So, I want to receive the reference design based on 'RX_LN_DATA_WIDTH =32'.

    I used the ZCU102.

    Best Regards

    Jae-Heung Yeom

  • Hi Ameet

    I also see the warning shown below.

    Does this affect the IP operation?

    [Designutils 20-2385] This program cannot decrypt an IEEE-1735 envelope without a Xilinx key. ["E:/5_FPGA_WORK/7012/PL/GROUND/pd_gnd_20221006b/SRC/JESD204BTI/TI_204c_IP_questasim.svp":302]

    Regards

    Jae-Heung

  • Hi Jae-Heung,

    The questasim file is meant only for Mentor Modelsim or Questa simulators. The *_xilinx.svp file is the JESD IP core for Vivado simuations.

    Unfortunately, TI doesn't have a 32 bit reference design, as customers usually create their own by modifying the IP parameters. Please ensure that all the panes of the GT Wizard match that of the original transceiver (except for the 64 bit / 32 bit change and the reference clock changing from 100MHz to 200MHz). If the SYNCn signal is remaining '0', it means that the Rx IP is not able to find the control characters in the data.

    If you need a 32 bit data width to reduce the number of samples for processing, one option is to use the IP in its 64 bit mode and to add a 2:1 FIFO to reduce the samples per cycle.

    Regards,

    Ameet

  • Hi Ameet

    I have another problem.

    When taking implementation in Vivado, I found the following critical warnings:

    [Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks -of_objects [get_pins TI_IP_inst/mgt_rx_usrclk2]]'. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":9]

    [Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group '. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":9]

    [Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group [get_clocks -of_objects [get_pins TI_IP_inst/mgt_tx_usrclk2]]'. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":10]

    [Vivado 12-4739] set_clock_groups:No valid object(s) found for '-group '. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":10]

    [Vivado 12-4739] set_max_delay:No valid object(s) found for '-from [get_clocks -of_objects [get_pins TI_IP_inst/mgt_rx_usrclk2]]'. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":13]

    [Vivado 12-4739] set_max_delay:No valid object(s) found for '-to [get_clocks -of_objects [get_pins TI_IP_inst/mgt_rx_usrclk2]]'. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":14]

    [Vivado 12-4739] set_max_delay:No valid object(s) found for '-from [get_clocks -of_objects [get_pins TI_IP_inst/mgt_tx_usrclk2]]'. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":17]

    [Vivado 12-4739] set_max_delay:No valid object(s) found for '-to [get_clocks -of_objects [get_pins TI_IP_inst/mgt_tx_usrclk2]]'. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":18]

    [Vivado 12-4739] set_false_path:No valid object(s) found for '-through [get_nets master_reset_n]'. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":21]

    [Vivado 12-5201] set_clock_groups: cannot set the clock group when only one non-empty group remains. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":9]

    [Vivado 12-5201] set_clock_groups: cannot set the clock group when only one non-empty group remains. ["E:/5_FPGA_WORK/7012/Module/204IP/TI204C-IP-Release-v1.10-LATEST_20212/reference_designs/zcu102_8b10b/constraints_ori.xdc":10]

    I think that TI_IP_inst is encrypted, so Vivado tool cannot find the assigned pins.

    Can these critical warnings cause the JESD204B interface to malfunction?

    To remove these warnings, what should I do?

    set_clock_groups -asynchronous -group [get_clocks -of_objects [get_pins TI_IP_inst/mgt_rx_usrclk2]] -group [get_clocks -of_objects [get_pins pll_inst/freerun_clk]]
    set_clock_groups -asynchronous -group [get_clocks -of_objects [get_pins TI_IP_inst/mgt_tx_usrclk2]] -group [get_clocks -of_objects [get_pins pll_inst/freerun_clk]]
    
    # Relaxed timing between rx_sys_clock and rx_usrclk2
    set_max_delay -datapath_only -from [get_clocks -of_objects [get_pins TI_IP_inst/mgt_rx_usrclk2]] -to [get_clocks -of_objects [get_pins pll_inst/sys_clk]] 50.000
    set_max_delay -datapath_only -from [get_clocks -of_objects [get_pins pll_inst/sys_clk]] -to [get_clocks -of_objects [get_pins TI_IP_inst/mgt_rx_usrclk2]] 50.000
    
    # Relaxed timing between tx_sys_clock and tx_usrclk2
    set_max_delay -datapath_only -from [get_clocks -of_objects [get_pins TI_IP_inst/mgt_tx_usrclk2]] -to [get_clocks -of_objects [get_pins pll_inst/sys_clk]] 50.000
    set_max_delay -datapath_only -from [get_clocks -of_objects [get_pins pll_inst/sys_clk]] -to [get_clocks -of_objects [get_pins TI_IP_inst/mgt_tx_usrclk2]] 50.000

  • Hi Jae-heung,

    This seems like the tool is removing / changing the name of the signals during synthesis. Kindly add a dont_touch attribute to the nets mgt_rx_usrclk2 and mgt_tx_usrclk2.

    I am also wondering if you have changed the hierarchy of the TI IP. Is it being instantiated in another module? In that case, the signal pathnames need to be updated.

    Regards,

    Ameet