High Bandwidth Memory (HBM2E) Interface Intel Agilex® 7 M-Series FPGA IP User Guide

ID 773264
Date 12/04/2023
Public

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

Document Table of Contents

5.3. User AXI Interface Timing

This section explains the interface timing details between user logic and the HBM2E controller via the hard memory NoC. User interface signals follow the AXI4 protocol specification while passing data to and from the HBM2E controller.

The AXI interface consists of the following channels:

  • Write Address channel – Master (user logic or target NoC interface unit) provides relevant signals to issue a write command to the slave (initiator NoC interface unit or HBM2E controller).
  • Write data channel – Master provides the write data signals corresponding to the write address.
  • Write response channel – Slave provides response on the status of the issued write command to the master.
  • Read Address channel – Master provides relevant signals to issue a read command to the slave.
  • Read data channel – Slave provides read data and read data valid signals corresponding to the read command to the master.

All transactions in the five channels use a handshake mechanism for the master and slave to communicate and transfer information.

Handshake Protocol

All five transaction channels use the same VALID/READY handshake process to transfer address, data, and control information. Both the master and slave can control the rate at which information moves between master and slave. The source generates the VALID signal to indicate availability of the address, data, or control information. The destination generates the READY signal to indicate that it can accept the information. Transfer occurs only when both the VALID and READY signals are HIGH.

Figure 16. AXI Protocol Handshake Process

In the figure above, the source presents the address, data or control information after T1 and asserts the VALID signal. The destination asserts the READY signal after T2, and the source must keep its information stable until the transfer occurs at T3, when this assertion occurs. In this example, the source asserts the VALID signal prior to the destination asserting the READY signal. Once the source asserts the VALID signal, it must remain asserted until the handshake occurs, at a rising clock edge at which VALID and READY are both high. Once the destination asserts READY, it can deassert READY before the source asserts VALID. The destination can assert READY whenever it is ready to accept data, or in response to a VALID assertion from the source.

AXI IDs

In an AXI system with multiple masters, the AXI IDs used for the ordering model include the infrastructure IDs that identify each master uniquely. The ordering model applies independently to each master in the system.

The AXI ordering model also requires that all transactions with the same ID in the same direction must provide their responses in the order in which they are issued. Because the read and write address channels are independent, if an ordering relationship is required between two transactions with the same ID that are in different directions, then a master must wait to receive a response to the first transaction before issuing the second transaction. If a master issues a transaction in one direction before it has received a response to an earlier transaction in the opposite direction, there is no ordering guarantee between the two transactions. An AXI master can also issue several transactions with different IDs, indicating that the HBM controller can re-order these transactions. This usually enables the HBM controller to make more efficient accesses to the memory device.

AXI4-Lite transactions have no associated ID and are always handled in order.

AXI Ordering

The AXI system imposes no ordering restrictions between read and write transactions. Read and write can complete in any order, even if the read address AXI ID (ARID) of a read transaction is the same as the write address AXI ID (AWID) of a write transaction. If a master requires a given relationship between a read transaction and a write transaction, it must ensure that the earlier transaction is completed before it issues a subsequent transaction. A master can consider the earlier transaction complete only when one of the following is true:

  • For a read transaction, it receives the last of the read data.
  • For a write transaction, it receives the write response.