• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 3 answers
  • Subscribers 12 subscribers
  • Views 618 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

AFE7950: 4T4R2F 8b10b 2.4576 Gbps Config not synchronizing

AFE7950: 4T4R2F 8b10b 2.4576 Gbps SERDES JESD link not always initializing properly

Jesse Hobart
Prodigy 40 points
Part Number: AFE7950

Tool/software:

Hello,

My configuration procedure and setup is the same as my prior forum post: https://e2e.ti.com/support/rf-microwave-group/rf-microwave/f/rf-microwave-forum/1452860/afe7950-4t4r2f-8b10b-2-4576-gbps-config-not-synchronizing :

JESD204B, 8b10b SERDES
4 Rx
2 Fb
4 Tx
ADC Fs   = 2949.12,  Decimate by 48
ADCFb Fs = 2949.12,  Decimate by 24
DAC Fs   = 11796.48, Interpolate by 96
SERDES rate = 2457.6

Use the AFE7950EVM on-board oscillator/PLL
Updates to jesd_link_params.vh to match configuration and ZCU102 SERDES mapping

Upon attempt to bring up design per TI204c-Setup.docx, I follow this order of operations:

  1. Power on ZCU102
  2. Power on AFE7950EVM
  3. Open Latte
  4. Run setup.py
  5. Run devInit.py
  6. Run 4T4R2F_2p4576.py
  7. Program FPGA
  8. Release master_reset_n -> 1
  9. Release tx_reset -> 0
  10. Run ConfigAfe.py
  11. Release rx_reset -> 0

I am able to get the JESD link to synchronize in both directions only sometimes, and I usually am required to issue one or more Latte JESD resync commands (TI_IP_AfeJesdReSync.py) and use the vio module to reset the FPGA one or more times.

My setup is with the AFE7950EVM connected to J4 of the Xilinx ZCU102 development board.  Source baseline code is the TI reference design: C:\Users\jhobart_reliable\Downloads\TI_AFE7950\TI204C-IP-Release-v1.12-LATEST\reference_designs\zcu102_8b10b with TI204C-IP-Release-v1.12-LATEST\TI-204c-CoreIP\Vivado_2022_and_Newer\rtl\TI_204c_IP.svp with the following modified parameters:

MGTREFCLK=184.32 MHz
sys_pll outputs 184.32 MHz sys_clk and 30.72 MHz mgt_freerun_clk
MGT rate 2.4576 Gbps

I have modified jesd_link_params.vh to match the zcu102 to afe7950evm interface with F, K values to match my configuration.

My jesd_link_params.vh, constraints, and script files are attached.  Please let me know whether I need to consider additional factors when de-asserting reset in this design.

files_e2e_1452860.zip

After TI_IP_ConfigAfe.py:
###########Device DAC JESD-RX 0 Link Status###########

lane0 Errors=0b1111; Got errors: 8b/10b disparty error; 8b/10b not-in-table code error; code synchronization error; elastic buffer match error. The first no-/K/ does not match 'match_ctrl' and 'match_data' programmed values;

lane1 Errors=0b1111; Got errors: 8b/10b disparty error; 8b/10b not-in-table code error; code synchronization error; elastic buffer match error. The first no-/K/ does not match 'match_ctrl' and 'match_data' programmed values;

lane2 Errors=0b1111; Got errors: 8b/10b disparty error; 8b/10b not-in-table code error; code synchronization error; elastic buffer match error. The first no-/K/ does not match 'match_ctrl' and 'match_data' programmed values;

lane3 Errors=0b1111; Got errors: 8b/10b disparty error; 8b/10b not-in-table code error; code synchronization error; elastic buffer match error. The first no-/K/ does not match 'match_ctrl' and 'match_data' programmed values;

CS State TX0: 0b10001001 . It is expected to be 0b10101010

FS State TX0: 0b00000000 . It is expected to be 0b01010101

resync did not help, so I put the FPGA back into reset (master_reset_n=0, tx/rx_sync_reset=1) and ran the config again:

###########Device DAC JESD-RX 0 Link Status###########

CS State TX0: 0b10101010 . It is expected to be 0b10101010

FS State TX0: 0b01010101 . It is expected to be 0b01010101

Could get the link up for device RX: 0

###################################

###########Device DAC JESD-RX 1 Link Status###########

CS State TX0: 0b10101010 . It is expected to be 0b10101010

FS State TX0: 0b01010101 . It is expected to be 0b01010101

Could get the link up for device RX: 1

###################################

Then I set the rx_sync_reset to '0', but rx_lmfc_to_buffer_release_delay[9:0] does not change values, and rx_lane_data_valid is always low.  I toggled rx_sync_reset several more times, and eventually saw rx_lane_data_valid start toggling.

Note:  Once the link is established in both directions, the JESD link remains stable.

Any ideas will be appreciated.  I'm going to focus on the slow mgt_freerun_clock and see whether having a slower clock means that I need to handle reset differently.

  • 0
    Prodigy 40 points

    As a side question:  Why is tx_lane_data_ready always high in this configuration?  I would expect tx_lane_data_ready to be high 1/6 of the time:
    Note - I have added the signal explicitly to the ila_link_tx_inst:

    ila_link_tx_inst (
    .sys_clock (tx_sys_clock),
    .tx_lane_data (tx_lane_data),
    .tx_lane_data_ready (tx_lane_data_ready),
    ...

  • 0 in reply to Jesse Hobart
    TI__Genius 17671 points

    Hi Jesse,

    One potential issue here is the sys_clk frequency. The DAC JESD link has a strict requirement where the tx_sysclk must be equal to LaneRate/80. In this case you are using a frequency that is 6x, can you change the PLL to output 30.72MHz for the sys_clk and see if that helps with the link bring up issues?

    Regards,

    David Chaparro 

  • 0 in reply to David Chaparro
    Prodigy 40 points

    David,

    Thank you for your quick answer.  This has indeed fixed the initialization issue with one caveat.  On 8 out of 10 tries, I had to assert then de-assert master_reset_n after AFE.deviceBringup() since de-asserting rx_sync_reset did not bring up the AFE->FPGA link (data valid remained low). On the other two tries, de-asserting rx_sync_reset did establish the AFE->FPGA link. My full procedure:

    Run setup.py, devInit.py, 4T4R2F_2p4576.py
    Program FPGA
    de-assert master_reset_n
    de-assert tx_sync_reset
    Run TI_IP_ConfigAfe.py (FPGA->AFE links come up every time now)
    de-assert rx_sync_reset (AFE-FPGA links are usually not established.  rx_lmfc_to_buffer_release_delay[9:0] remains 0, data valid remains low, rx_sync_n goes high, but one or more lanes have errors)
    assert, then de-assert master_reset_n
    AFE->FPGA links come up and operate error-free

    I really appreciate the quick solution!

    Jesse

  • 0 in reply to Jesse Hobart
    TI__Genius 17671 points

    Hi Jesse,

    Glad that this fixed part of the issue. One question that I do want to ask is, does your system require deterministic latency? If so then we do not recommend having a PLL on the sys_clk and instead I can help with LMK settings that will allow you to generate exactly the needed frequencies to the FPGA. 

    For the other problem can you please share the 'TI_204c_IP_ref.sv' file? I would like to take a look at a couple of settings to see if there is anything that could be causing this problem.

    Regards,

    David Chaparro 

  • 0 in reply to David Chaparro
    Prodigy 40 points

    Hi David,

    Yes, we do require deterministic latency for our design, so it will be good to hear your recommendations.  One thing to note is that we have already fabricated our PCB and are awaiting assembly, so adding another clock input may not be possible until a respin.

    Here is my TI_204c_IP_ref.sv file:

    TI_204c_IP_ref.zip

    Thank you,

    Jesse

  • 0 in reply to Jesse Hobart
    TI__Genius 17671 points

    Hi Jesse,

    For the clock recommendation, I would suggest to provide an external clock to the LMK and using the LMK in divider mode to provide a lower frequency clock.

    It looks like TI_204c_IP_ref file may be out of date. Can you please replace your file with the one from the TI204C-IP-Release-v1.12 folder? The only additional changes that you would need to make are to update the '8B/10B protocol related PARAMeters' section file. 

    Regards,

    David Chaparro 

  • 0 in reply to David Chaparro
    Prodigy 40 points

    Hi David,

    Thank you for that info.  I started my design with TI204C-IP-Release-v1.12-LATEST/reference_designs/zcu102_8b10b/rtl/TI_204c_IP_ref.sv which does include an instance of sys_pll.  I believe your recommendation is to remove sys_pll and directly source LaneRate/80 clock.  Is that correct?

    Thank you,

    Jesse

  • 0 in reply to Jesse Hobart
    TI__Genius 17671 points

    Hi Jesse,

    My recommendation was to update the LMK to produce the LaneRate/80. If this is not possible then another test that can be done is to change the source of the tx_sys_clock from 'sys_clock' to 'mgt_tx_usrclk2'. Please note that this would only be to test the design as when you use this clock as the source deterministic latency is not supported.

    Regards,

    David Chaparro 

  • 0 in reply to David Chaparro
    Prodigy 40 points

    Hi David,
    Thank you for this reply.  At this time, we do not have an additional clock source to provide to our FPGA on our custom board.  We will continue testing as you have recommended and add the LaneRate/80 clock when we re-spin the module.

    I am still not understanding why the ADC/Rx side does not fully operate after de-asserting rx_sync_reset, but instead requires an additional assert/de-assert of master_reset_n to operate.  Note, we are using a PLL-locked 250 MHz source for pulling the samples from the JESD core at 1/8 data valid cadence.

    Thank you,
    Jesse

  • 0 in reply to Jesse Hobart
    TI__Genius 17671 points

    Hi Jesse,

    The reason for the additional reset is caused by having an older version of the 'TI_204_IP_ref.sv' file. If you make the below change in the file you should no longer have the issue. Please note that the reference designs in the TI204c IP folder have been updated to have this fix.

    Replace line 380, 'assign mgt_gpio_in = 16'd0;', with the below lines:

    assign mgt_gpio_in[0] = rx_sync_reset;
    assign mgt_gpio_in[1] = tx_sync_reset;

    assign mgt_gpio_in[15:2] = 14'd0;

    Regards,

    David Chaparro