Test Engine FPGA IP User Guide: Agilex™ 5 and Agilex™ 7 FPGAs

Download PDF
ID 817758
Date 7/08/2024
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
Document Table of Contents x
1. About the Test Engine FPGA IP 2. Test Engine IP - Introduction 3. Parameterizing the Test Engine IP 4. Test Engine IP - Interface Signals 5. Test Engine IP - Software 6. Test Engine IP - Limitations 7. Document Revision History for the Test Engine FPGA IP User Guide
1. About the Test Engine FPGA IP x
1.1. Release Information
2. Test Engine IP - Introduction x
2.1. Test Engine IP Feature Support
3. Parameterizing the Test Engine IP x
3.1. Parameters 3.2. Drivers Parameters 3.3. Remote Access Parameters
3.2. Drivers Parameters x
3.2.1. CSR AXI4-Lite Driver Parameters 3.2.2. Memory AXI4 Driver Parameters 3.2.3. Memory Status Driver Parameters 3.2.4. Memory Reset Driver Parameters 3.2.5. CAM AXI4-Stream Driver Parameters
4. Test Engine IP - Interface Signals x
4.1. Remote Interface Signals 4.2. I/O PLL Interface Signals 4.3. Status Interface Signals 4.4. Global CSR interface Signals 4.5. Memory AXI4 Driver Interface Signals 4.6. CSR AXI-Lite Driver Interface Signals 4.7. Memory Status Driver Interface Signals 4.8. Memory Reset Driver Interface Signals 4.9. CAM AXI-Stream Driver Interface Signals 4.10. Registers
4.10. Registers x
4.10.1. Global Control Registers 4.10.2. Memory AXI4 Driver Registers 4.10.3. CSR AXI4-Lite Driver Registers 4.10.4. Memory Status Driver Registers 4.10.5. Memory Reset Driver Registers 4.10.6. CAM AXI4-Stream Driver Registers
4.10.1. Global Control Registers x
4.10.1.1. version_0 4.10.1.2. version_1 4.10.1.3. ctrl_status_0 4.10.1.4. driver_ctrl_status_1 4.10.1.5. driver_run_bitmask_0 4.10.1.6. driver_run_bitmask_1 4.10.1.7. driver_run_bitmask_2 4.10.1.8. driver_run_bitmask3 4.10.1.9. driver_done_bitmask_0 4.10.1.10. driver_done_bitmask_1 4.10.1.11. driver_done_bitmask_2 4.10.1.12. driver_done_bitmask_3 4.10.1.13. driver_error_bitmask_0 4.10.1.14. driver_error_bitmask_1 4.10.1.15. driver_error_bitmask_2 4.10.1.16. driver_error_bitmask_3
4.10.2. Memory AXI4 Driver Registers x
4.10.2.1. version_lo 4.10.2.2. version_hi 4.10.2.3. ctrl_stat_lo 4.10.2.4. ctrl_stat_hi 4.10.2.5. scratchpad_lo 4.10.2.6. scratchpad_hi 4.10.2.7. wr_log_ram_stat_lo 4.10.2.8. wr_log_ram_stat_hi 4.10.2.9. wr_log_ram_ctrl_lo 4.10.2.10. wr_log_ram_ctrl_hi 4.10.2.11. rd_log_ram_stat_lo 4.10.2.12. rd_log_ram_stat_hi 4.10.2.13. rd_log_ram_ctrl_lo 4.10.2.14. rd_log_ram_ctrl_hi 4.10.2.15. wr_err_counters_0_lo 4.10.2.16. wr_err_counters_0_hi 4.10.2.17. rd_err_counters_0_lo 4.10.2.18. rd_err_counters_0_hi 4.10.2.19. rd_err_counters_1_lo 4.10.2.20. rd_err_counters_1_hi 4.10.2.21. rd_pnf_0_lo 4.10.2.22. rd_pnf_0_hi 4.10.2.23. rd_pnf_1_lo 4.10.2.24. rd_pnf_1_hi 4.10.2.25. rd_pnf_2_lo 4.10.2.26. rd_pnf_2_hi 4.10.2.27. rd_pnf_3_lo 4.10.2.28. rd_pnf_3_hi 4.10.2.29. rd_pnf_4_lo 4.10.2.30. rd_pnf_4_hi 4.10.2.31. rd_pnf_5_lo 4.10.2.32. rd_pnf_5_hi 4.10.2.33. rd_pnf_6_lo 4.10.2.34. rd_pnf_6_hi 4.10.2.35. rd_pnf_7_lo 4.10.2.36. rd_pnf_7_hi 4.10.2.37. rd_pnf_8_lo 4.10.2.38. rd_pnf_8_hi 4.10.2.39. rd_pnf_9_lo 4.10.2.40. rd_pnf_9_hi 4.10.2.41. rd_pnf_10_lo 4.10.2.42. rd_pnf_10_hi 4.10.2.43. rd_pnf_11_lo 4.10.2.44. rd_pnf_11_hi 4.10.2.45. rd_pnf_12_lo 4.10.2.46. rd_pnf_12_hi 4.10.2.47. rd_pnf_13_lo 4.10.2.48. rd_pnf_13_hi 4.10.2.49. rd_pnf_14_lo 4.10.2.50. rd_pnf_14_hi 4.10.2.51. rd_pnf_15_lo 4.10.2.52. rd_pnf_15_hi 4.10.2.53. rd_pnf_16_lo 4.10.2.54. rd_pnf_16_hi 4.10.2.55. rd_pnf_17_lo 4.10.2.56. rd_pnf_17_hi 4.10.2.57. rd_pnf_18_lo 4.10.2.58. rd_pnf_18_hi 4.10.2.59. rd_pnf_19_lo 4.10.2.60. rd_pnf_19_hi 4.10.2.61. ter_dq_mask_0_lo 4.10.2.62. ter_dq_mask_0_hi 4.10.2.63. ter_dq_mask_1_lo 4.10.2.64. ter_dq_mask_1_hi 4.10.2.65. ter_lo 4.10.2.66. ter_hi
5. Test Engine IP - Software x
5.1. Overview 5.2. Python library 5.3. User programs 5.4. System Console library
5.2. Python library x
5.2.1. CSR AXI4-Lite Driver APIs 5.2.2. Memory AXI4 Driver APIs 5.2.3. General compiler APIs
5.2.1. CSR AXI4-Lite Driver APIs x
5.2.1.1. read_cmd 5.2.1.2. write_cmd
5.2.2. Memory AXI4 Driver APIs x
5.2.2.1. dq_alu_echo_op 5.2.2.2. dq_alu_invert_op 5.2.2.3. dq_alu_rotate_op 5.2.2.4. dq_alu_prbs_op 5.2.2.5. data_eq_dq_op 5.2.2.6. data_eq_raw_op 5.2.2.7. data_eq_addr_op 5.2.2.8. data_eq_id_op 5.2.2.9. dm_alu_echo_op 5.2.2.10. dm_alu_invert_op 5.2.2.11. dm_alu_rotate_op 5.2.2.12. dm_alu_prbs_op 5.2.2.13. strb_eq_dm_op 5.2.2.14. strb_eq_raw_op 5.2.2.15. addr_alu_echo_op 5.2.2.16. addr_alu_incr_op 5.2.2.17. addr_alu_rand_op 5.2.2.18. addr_op 5.2.2.19. write_worker_op 5.2.2.20. read_worker_op 5.2.2.21. write_cmd 5.2.2.22. read_cmd 5.2.2.23. wait_writes_cmd 5.2.2.24. wait_reads_cmd 5.2.2.25. sleep_cmd 5.2.2.26. driver_post_cmd 5.2.2.27. driver_wait_cmd 5.2.2.28. parallel_cmd 5.2.2.29. loop_cmd
5.2.3. General compiler APIs x
5.2.3.1. get_drivers 5.2.3.2. attach 5.2.3.3. dump
5.3. User programs x
5.3.1. Programs for Memory AXI4 Driver 5.3.2. Programs for CSR AXI4-Lite Driver
5.3.1. Programs for Memory AXI4 Driver x
5.3.1.1. Basic tutorials 5.3.1.2. Advanced tutorials 5.3.1.3. EMIF traffic patterns (for IO96B architecture) 5.3.1.4. HBM2E traffic patterns 5.3.1.5. MemSS traffic patterns (for IO96A architecture) 5.3.1.6. gencmd
5.3.1.1. Basic tutorials x
5.3.1.1.1. tut1_block_rw 5.3.1.1.2. tut2_byteen_test 5.3.1.1.3. tut3_instr_resume 5.3.1.1.4. tut4_parallel_rw 5.3.1.1.5. tut5_multi_id 5.3.1.1.6. tut6_custom_bw 5.3.1.1.7. tut7_driver_sync
5.3.1.2. Advanced tutorials x
5.3.1.2.1. adv1_basic_rw 5.3.1.2.2. adv2_addr_fields 5.3.1.2.3. adv3_instr_resume
5.3.1.3. EMIF traffic patterns (for IO96B architecture) x
5.3.1.3.1. emif_tg_emulation 5.3.1.3.2. emif_tg_emulation_lite 5.3.1.3.3. emif_tg_emulation_long 5.3.1.3.4. emif_tg_emulation_inf 5.3.1.3.5. emif_narrow_transfer
5.3.1.4. HBM2E traffic patterns x
5.3.1.4.1. hbm_simulation1 5.3.1.4.2. hbm_simulation
5.3.1.5. MemSS traffic patterns (for IO96A architecture) x
5.3.1.5.1. memss_default
5.3.2. Programs for CSR AXI4-Lite Driver x
5.3.2.1. HBM2E traffic patterns 5.3.2.2. MemSS traffic patterns (for IO96A architecture)
5.3.2.1. HBM2E traffic patterns x
5.3.2.1.1. hbm_simulation1
5.3.2.2. MemSS traffic patterns (for IO96A architecture) x
5.3.2.2.1. memss_default
5.4. System Console library x
5.4.1. testengine_num_drivers 5.4.2. testengine_driver_list 5.4.3. testengine_run 5.4.4. testengine_reset 5.4.5. testengine_get_errors 5.4.6. testengine_get_done 5.4.7. testengine_status 5.4.8. testengine_reprogram 5.4.9. testengine_axi4_parse_errors
1. About the Test Engine FPGA IP
2. Test Engine IP - Introduction
3. Parameterizing the Test Engine IP
4. Test Engine IP - Interface Signals
5. Test Engine IP - Software
6. Test Engine IP - Limitations
7. Document Revision History for the Test Engine FPGA IP User Guide

6. Test Engine IP - Limitations

The Test Engine IP supports both simple usages and complex stress-testing traffic patterns.

The following are known limitations in the current version of the Test Engine IP:

  • Only one instance of the Test Engine IP is supported within a design at any given time. Two or more Test Engines result in errors or unexpected behavior in traffic pattern compilation and System Console interaction.
  • Read-data and write-data ports should have identical widths; only symmetric read/write data widths on the same driver are supported.
  • Address ALU argument width parameter affects the number of bits that the Address ALU can change; the default value is 16 bits. If the desired address space isn't supported by the specified value, you will loop back to first address causing early address looping to occur. For example, if you have an address space of 16 bits. you can only affect these 16 bits. You can increase this value to allow wider ranges or address sweeping per command.
  • The maximum iteration value that you can use within one command (i.e., gencmd() API function) is 65536 or 2^16. If you want to use more than 65,536 iterations, you can stack one command after the other and use the resume feature to chain the commands to output a continuous address and data pattern. The maximum number of commands supported in a program is 512.

  • The Test Engine IP supports a custom bandwidth on the AXI command channels and custom backpressure on the AXI response channels. On the response channels, the custom bandwidth becomes active after a certain delay following reception of the first response. If the delay is undesirable, you can prelude it using a dummy read/write command to configure the backpressure. Inject some delay after receiving the responses to the dummy command, to ensure that backpressure is active.

  • Write Data Width and Read Data Width parameters support non-power-of-two data widths, where the remaining bits are mapped to WUSER/RUSER ports of the AXI4 Bus. These ports are controlled by same data logic as the regular data path.
  • WSTRB is unusable with non-power-of-2 data widths and is terminated to all 1s.
  • Integer values for data and strobe values in the gencmd() API function must have enough DQ/DM ALUs to support the number of bits without being aliased. If the data and strobe values are too large, the gencmd() API issues a warning that the integer values will be clipped and not represented in their entirety. To prevent this, you must increase the number of DQ/DM ALUs. The maximum number of bits that ALU supports is 32.
  • The read response channel (AXI R channel) will backpressure during burst length 1 traffic, even with the response channel bandwidth (resp_bw) set to (1,1). This does not affect other burst lengths.
  • Address channel bandwidth control causes the AxVALID signal to de-assert while the AxREADY signal is low; this does not follow the VALID/READY handshake rules of the AXI4 specification. This behavior affects primarily low-performance AXI4 subordinate interfaces.
  • During 100% expected efficiency traffic, the Test Engine IP applies backpressure to the R channel by a maximum of approximately 40% of the traffic duration. This backpressure makes the Test Engine IP the bottleneck of the system, resulting in inaccurate performance metrics, such as reduced Read efficiency and throughput metrics. To ensure accurate performance metrics, use a burst length of 2 or higher; this prevents any backpressure on the response channels.
  • Low-level read and write APIs only check that the traffic pattern is executable by the hardware, but not if the traffic pattern itself is correctly structured.

  • High-level read and write APIs check that the traffic pattern is well-structured, for example if it's AXI compliant.

    Note: All traffic programs using high-level API functions within the traffic_patterns.py file must pass all checks regardless of whether they are in use or not.
Level Two Title