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

ID 817758
Date 11/04/2024
Public
Document Table of Contents

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.
  • 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.
  • 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.