Write and Read Commands - 1.0 English

AXI High Bandwidth Memory Controller LogiCORE IP Product Guide (PG276)
Document ID
PG276
Release Date
2022-11-02
Version
1.0 English
txn_count
The transaction count field can be set to the number of times a specific command definition is to be repeated, or a specific amount of data to be transferred. To truly model a full application load in a steady-state system, specify a transaction count number rather than a fixed amount of data. Specifying a fixed amount of data can result in a short burst of activity which the traffic generator attempts to service as quickly as possible.

If the intent is to model a busy traffic master that is constantly requesting data, or a low-bandwidth master that periodically makes requests, always use the transaction count. The rest of the available command fields should be used to pace the behavior of the master. The start_delay field can be used to specify the Write/Read stream bandwidth, or the inter_beat_delay can be used to throttle the master to decrease bandwidth or make the accesses more periodic. A low transaction count does not model steady state performance and will give inaccurate results.

start_delay
The start delay field can be used to delay the start of a traffic generator by a specified number of clocks, or it can be used to specify the bandwidth of the traffic master. For most applications it makes sense to specify the bandwidth of the traffic master, otherwise the traffic generator attempts to service the data payload request as fast as possible which might not represent the traffic master in application. Along with the clock delay, similar functionality can be achieved by using the WAIT or START_LOOP/END_LOOP commands.
inter_beat_delay
Use this command to model a slow or periodic traffic master.
wdata_pattern, rdata_pattern, wdata_pat_value, and rdata_pat_value
Here you can test if data coherency is being maintained by the user logic when it is not using the AXI reordering queue by having unique settings per traffic master. This is also a good mechanism for ensuring that the traffic masters are generating addresses correctly when global addressing is enabled.
data_integrity
Enable this setting to check traffic master behavior when global addressing is enabled or if the traffic masters are responsible for data coherency.
addr_incr_by
When there is a specified number of transactions in the txn_count field, the AXI address increments by the value specified here. For ideal performance, remember that the traffic masters should always use an aligned 32-byte address to the HBM memory space to prevent unaligned accesses. Unaligned accesses can cause a 50% or 75% performance drop depending on the use case. If you are not specifying the number of transactions, set this to auto_incr for linear accesses through the memory map. If a random addressing mode is used, this can be set to a PRBS seed value. If a random addressing mode is used, the bandwidth of the HBM is low while the latency is high. Additional considerations need to be made for the traffic masters or the specifics of the random addressing mode if this is the intended use case for the HBM.
dest_id
This can be used for more dynamic traffic generator configurations which use variables or fixed values to target specific slaves.
base_addr
The starting AXI address for a traffic generator, which can be anything from the base address of the HBM pseudo channel attached to the AXI port, or any other destination address in the HBM, if global addressing is enabled. When the high_addr is reached, the traffic generator starts again from the base_addr.
high_addr
The high address or the end address range for a traffic generator. When this is reached, the traffic generator starts again from the base_addr.
axi_addr
This is one of the most important fields to understand for adequately modeling a realistic workload with HBM. If the txn_count is a non-zero value, the next address is calculated by the addr_incr_by field with axi_addr being the start address. It is important to ensure that the traffic masters are making aligned accesses by aligning to the HBM 32B burst boundary. For example, if the starting address is 0x1000_E0C0, this is aligned to the 32-byte boundary. If the starting address is 0x1000_E010, this is not aligned and likely subsequent accesses will not be aligned based on the addr_incr_by field. This means an immediate efficiency loss of 50% to 75% depending on the remaining details of the use case and IP configuration.
  • Setting this field to random also results in low efficiency due to the high amount of protocol overhead because every access has a very high probability of a page miss resulting in Precharge and Activate commands. Additionally if the address is completely random there is an extremely high probability of an unaligned access resulting in more efficiency loss.
  • The random_aligned option has the same issues as the random setting, except the access is aligned to the HBM burst boundary. This still results in low efficiency due to the high number of page misses but every Write/Read access is fully used, which results in higher efficiency than the random setting. This represents one of the better random traffic masters in a system.
  • The random_unaligned option is similar to the random setting, but every operation is guaranteed to be unaligned. This results in slightly lower efficiency than the random option.
  • The random_uniform option also generates a low-efficiency access pattern because this is still a random address with a high probability of unaligned accesses.
  • The random_uniform_aligned option can be used to generate the access pattern for a well-behaved random traffic master because it moves randomly through the base_addr and high_addr ranges, but always remains aligned.
  • The random_uniform_unaligned option behaves similarly to random_uniform_aligned except every access is unaligned, thus further lowering efficiency.
axi_len
AXI transaction length. Supported values are 0x0 through 0xF.
axi_size
The AXI transaction size is expected to be 0x5.
axi_id
This can be set to a fixed value, which results in AXI ID blocking, or it can be set to auto_incr, which starts at 0x0 and increments by 1 for every transaction up to a value of 0x3F before returning to 0x0.
axi_burst
Only INCR and WRAP transactions are allowed.