ILA Core and Timing Considerations - 2024.1 English

The configuration of the ILA core has an impact in meeting the overall design timing goals. Follow the recommendations to minimize the impact on timing:

• Choose probe width judiciously. The bigger the probe width the greater the impact on both resource utilization and timing.
• Choose ILA core data depth judiciously. The bigger the data depth, the greater the impact on both block RAM resource utilization and timing.
• Ensure that the clocks chosen for the ILA cores are free-running clocks. Failure to do so could result in an inability to communicate with the debug core when the design is loaded onto the device.
• Close timing on the design prior to adding the debug cores. AMD does not recommend using the debug cores to debug timing related issues.
• If the design does not meet the timing requirements after adding debug cores and the timing failure is in the ILA or AXIS-ILA core, try increasing the number of input pipeline stages (C_INPUT_PIPE_STAGES).
• If the design does not meet the timing requirements after adding debug cores, and the timing failure is in the AXIS-ILA core, try changing the storage target to UltraRAM (URAM), as this can ease the timing requirement for BlockRAM (BRAM) control signals.
• If the design does not meet the timing requirements after adding debug cores and the timing failure is in the ILA or AXIS-ILA core, try a different implementation strategy such as Performance_Explore or Performance_ExtraTimingOp.
• Make sure the clock input to the ILA core is synchronous to the signals being probed. Failure to do so results in timing issues and communication failures with the debug core when the design is programmed into the device.
• For Versal architectures, if a timing failure is observed after adding debug cores try using a clock with a frequency between 100 MHz and 250 MHz for the clock connected to the AXI4-Debug Hub as this eases the timing requirements for the AXI4-Stream connectivity on all debug cores connected to this AXI4-Debug Hub.
• Make sure that the design meets timing before running it on hardware. Failure to do so results in unreliable results.
• For Non-Versal architectures, ensure that the clock going to the dbg_hub is a free running clock. Failure to do so could result in an inability to communicate with the debug core when the design is loaded onto the device. You can use the connect_debug_port Tcl command to connect the clk pin of the debug hub to a free-running clock.
• For Non-Versal architectures, if you still see that timing has degraded due to adding the ILA debug core, and the critical path is in the dbg_hub, perform the following steps:
  1. Open the synthesized design.
  2. Find the dbg_hub cell in the netlist.
  3. Go to the properties of the dbg_hub.
  4. Find property C_CLK_INPUT_FREQ_HZ.
  5. Set it to frequency (in Hz) of the clock that is connected to the dbg_hub.
  6. Find property C_ENABLE_CLK_DIVIDER and enable it.
  7. Re-implement design.