Last week, I discussed the AXI Protocol and explained why understanding the valid-ready handshake is the first step in learning it. Today, I want to cover another important aspect of AXI—the ID field.
The AXI protocol has separate channels for conveying write addresses, write data, read addresses, read data, and write responses. Each of these channels includes an associated ID field, allowing the manager (requester) and subordinate (completer) to identify transactions. Additionally, the ID fields not only aid in transaction identification but also enable high-performance interconnects.
How does AXI ID help with performance?
Assigning each transaction an ID enables out-of-order completion, as both the requester and completer can rely on the ID field to identify transaction components. This allows them to handle transactions in any order (provided the transaction doesn't mandate any ordering constraints).
This means that transactions to faster memory regions can complete without waiting for earlier transactions to slower memory regions. This feature is useful and enables the implementation of high-performance interconnects. However, it also introduces hardware complexity, especially when some transactions can complete out of order while others cannot.
The AXI ID Ordering Constraints...
Adding the ID field with the transaction allows the system to process transaction in any order. However, not every transaction can be processed in any order - some may have specific ordering requirements associated with them.
A transaction might have an ordering constraints where it can only be processed once all the older transactions have completed.
This might be needed by a transaction so that the effects of all the previous transactions are visible before the current transaction is processed. Now, combining these strict ordering requirements with the potential of handling some transaction in out-of-order fashion does introduce hardware complexity. Here's a sample take of one such problem 👇
Consider a system where a transaction could potentially be sent out of order as soon as it is retired. However, there could be restrictions on the system requiring that a certain transaction governs strict ordering requirements, not allowing any younger transaction to be processed until all the older transactions have retired.
System with different ordering requirements
The system buffers requests between the incoming valid-ready RX interface and the outgoing valid-ready TX interface. Each request on the RX interface can only be sent to the TX interface once it has retired and met its ordering constraints.
Requests without ordering requirements can proceed to the TX interface as soon as they retire, even if there are older pending requests. However, requests with ordering requirements must wait for all older buffered requests to retire and be accepted on the TX interface before being processed.
How would one design such a system such that it meets maximum performance while maintaining the ordering requirements?
A Potential Solution
One design choice could be to treat each transaction with strict ordering requirements and process them one by one. However, to design a high-performance system, transactions without any ordering requirements should be processed out of order.
Processing transactions out of order would be straightforward if none of the requests were subject to ordering constraints, allowing the system to potentially send out requests as soon as they retire. However, with some transactions having ordering requirements while others do not, additional hardware is needed to track the relative age of requests as they are accepted on the RX channel. This can be achieved by introducing hardware to track relative age ordering so that any transaction with strict ordering requirements still honors all ordering constraints.
Age Matrix
The above image shows how hardware can track the relative ages of requests by maintaining an ‘Age Matrix.’ This matrix helps determine the relative ages of each request, allowing the hardware to identify the oldest transaction that can be processed while ensuring that ordering constraints are met.
But the next big question is: How does one design an Age Matrix in hardware?
Age Matrix...
Designing such a system isn't that hard but definitely needs some microarchitectural break down to understand how these different pieces interact together to build a high-performant system. In my Hands-on RTL Design course, where I dissect a similar system and go deep into the finer microarchitectural details while sharing the line-by-line RTL code for each component.
PS: We are running a massive limited time discount offer. Use referral code: QS-DIWALI24 to get 20% off!