Simulation Debug - 13.0 English - PG074

Lanes and Channel Do Not Come Up in Simulation

• The quickest way to debug this issue is to view the signals from one of the GT transceiver instances that is not working.
• Ensure that the reference clock and user clocks are all toggling.
  Note: Only one of the reference clocks should be toggling, the rest are tied Low.
• Check to see that recclk and txoutclk are toggling. If they are not toggling, it might be necessary to wait longer for the PMA to finish locking. Wait for lane up and channel up. It might be necessary to wait longer for simplex/7 series FPGA designs.
• Ensure that txn and txp are toggling. If they are not, make sure to wait long enough (see the previous bulleted item) and make sure that another signal is not driving the txn/txp signal.
• Check in the <user_component_name>_support module whether the pll/mmcm_not_locked signal and the reset signals are present in the design. If these are being held active, the Aurora 64B/66B module cannot initialize. Ensure that the power_down signal is not being asserted.
• Ensure that the txn and txp signals from each GTX or GTH transceiver are connected to the appropriate rxn and rxp signals from the corresponding GTX or GTH transceive on the other side of the channel.
• Instantiate the "glbl" module and use it to drive the power_up reset at the beginning of the simulation to simulate the reset that occurs after configuration. Hold this reset for a few cycles. The following code can be used an example:

  /Simulate the global reset that occurs after configuration at the beginning
  //of the simulation.
  assign glbl.GSR = gsr_r;
  assign glbl.GTS = gts_r;
  
  initial
    begin
      gts_r = 1'b0;
      gsr_r = 1'b1;
      #(16*CLOCKPERIOD_1);
      gsr_r = 1'b0;
  
  end

• If you assert rx_reset while using Timer mode and simplex configuration, you should also assert tx_reset. This is to ensure that the core transmits the required initialization patterns for the rx_lane_up and rx_channel_up to come back. However, because of Simplex auto recovery logic, the RX could attain the rx_channel_up state if you wait for sufficient time. In this scenario, the TX transmits periodic patterns that aid in recovering links automatically.
• If you are using a multilane channel, make sure all of the transceivers on each side of the channel are connected in the correct order.

Channel Comes up in Simulation but s_axi_tx_tready is Never Asserted (Never Goes High)

1. If the module includes flow control but it is not being used, make sure that the request signals are not currently driven High. s_axi_nfc_tx_tvalid and ufc_tx_req are active-High. If they are High, s_axi_tx_tready stays Low because the channel is allocated for flow control.
2. If the module includes USER-K blocks but they are not being used, make sure the s_axi_user_k_tx_tvalid is not driven High. If it is High, s_axi_tx_tready stays Low as channel is allocated for USER-K Blocks.

Bytes and Words are Being Lost as They Travel Through the Aurora 64B/66B Channel

1. If using the AXI4-Stream interface, make sure to write data correctly. The most common mistake is to assume words are written without looking at s_axi_tx_tready. Also, remember that the s_axi_tx_tkeep signal must be used to indicate which bytes are valid when s_axi_tx_tlast is asserted.
2. Ensure to read correctly from the RX interface. Data and framing signals are only valid when m_axi_rx_tvalid is asserted.

Problems While Compiling the Design

Ensure to include all the files from the src directory when compiling. Check if the simulator and libraries are set up properly. Check if the simulator language is set to mixed.

Next Step

Open a support case to have the appropriate AMD expert assist with the issue.

To create a technical support case, see the Service Portal web page.

Items to include when opening a case:

• Detailed description of the issue
• Results of the steps listed previously
• Attach a value change dump (VCD) or wave log format (WLF) dump of the observation.
• Attach the XCI/XCO file from the IP.
• If any modifications are updated to the IP generated out of Vivado and reasons for doing the changes.
• The .ila dump of the Hardware captures optionally, if available.