Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Feature: Support early write response #14

Open
dpretet opened this issue May 29, 2024 · 0 comments
Open

Feature: Support early write response #14

dpretet opened this issue May 29, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@dpretet
Copy link
Owner

dpretet commented May 29, 2024

To improve overall system performance, an AXI intermediate component can issue a write response before the request reaches the destination. From AMBA AXI specification:

Response before the endpoint
To improve system performance, it is possible for an intermediate component to issue a response to some transactions. This action is known as an early response. The intermediate component issuing an early response must ensure that visibility and ordering guarantees are met.

Early write response
For Bufferable write transactions, an intermediate component can send an early write response for transactions that have no downstream observers. If the intermediate component sends an early write response, the intermediate component can store a local copy of the data, but must propagate the transaction downstream, before discarding that data.
An intermediate component must observe ID ordering rules, that means a write response can only be sent if all earlier writes with the same ID have already had a response.

After sending an early write response, the component must be responsible for ordering and observability of that transaction until the write has been propagated downstream and a write response is received. During the period between sending the early write response and receiving a response from downstream, the component must ensure that:
• If an early write response was given for a Normal transaction, all subsequent transactions to the same or overlapping Memory locations are ordered after the write that has had an early response.
• If an early write response was given for a Device transaction, then all subsequent transactions to the same Peripheral region are ordered after the write that has had an early response.

When giving an early write response for a Device Bufferable transaction, the intermediate component is expected to propagate the write transaction without dependency on other transactions. The intermediate component cannot wait for another read or write to arrive before propagating a previous Device write.

A possible implementation could be to forward the write request to the switch stages from the slave interface, but keep internally a FIFO to forward back-to-back the early response to the master agent. Must take in account the ordering rules, if the same ID could be used among several slaves, and also the nature of the destination described by ACACHE.

Must be study and defined carefully.

@dpretet dpretet added the enhancement New feature or request label Jun 28, 2024
@dpretet dpretet self-assigned this Oct 8, 2024
@dpretet dpretet changed the title Feature: Support Early Write Response Feature: Support early write response Oct 14, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant