Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
The Intel sign-in experience is changing in February to support enhanced security controls. If you sign in, click here for more information.
19699 Discussions

Read pipelining in AXI-4 interfaces

Seadog
Beginner
139 Views

This question is in regards to AXI-4 slave interfaces, in particular the AXI-4 interface on the HBM2 memory controller (S10 MX devices).

 

AXI-4 specifically supports out-of-order responses to read commands, provided that the ID values for the commands are not the same.  This implies some level of read command pipelining (acceptance of multiple read commands before returning the associated read data).

 

Is there a limit on the number of pipelined read commands the HBM2 controller will accept (with or without the same ID value)?  Is there a similar limitation/capability for write commands?

 

Thanks.

0 Kudos
3 Replies
sstrell
Honored Contributor III
115 Views

I didn't think out-of-order responses are even supported with the Platform Designer interconnect.  Does that work for you?

AdzimZM_Intel
Employee
111 Views

As has been mentioned from sstrell, out of order transaction is not supported.

You can refer to Embedded Peripherals IP User Guide in the link below: https://www.intel.com/content/www/us/en/docs/programmable/683130/22-1/axi-4-interface.html


Seadog
Beginner
105 Views

The document you referenced seems to apply to M20K and MLAB memory applications, and doesn't mention HBM2; the AXI-4 interface for HBM2 includes the ID field, which exists specifically to support out-of-order transactions.  From the AXI-4 standard:

 

The AXI4 protocol supports an extended ordering model based on the use of the AXI ID transaction identifier. See
Chapter A6 AXI4 Ordering Model.

 

But that is not really what I was asking about, which was support of pipelined reads (and writes); I do hope that pipelined reads are supported, because otherwise burst read transactions could be pretty slow (the latency between read address and returned data would be dead time).

 

After thinking about this for a while I realize that knowledge of the read pipeline depth is unnecessary, as the slave can just stop responding to read address transactions once it hits the pipeline depth limit.

Reply