[xbar,rtl] support fifo_depth>1 #28841
Open
+19
−3
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gautschimi
force-pushed
the
xbar_fifo_depth_support
branch
from
3bd1706 to
2972f23
Compare
gautschimi
requested review from
Razer6,
andreaskurth,
meisnere,
rswarbrick and
vogelpi
This commit adds the possibility to increase the fifo depth in the xbar to values > 1 to support multiple outstanding transactions. Why this is beneficial: The ibex instruction cache issues two 32b requests to the flash controller. Inside xbar_main a pipeline register is added to break the critical path to the flash. The pipeline register is added with a fifo of depth=1 for req and rsp data and effectively inserts a bubble after each request and response because the fifo is immediately full. Ibex and flash_ctrl can deal with up to 2 outstanding transactions. The impact on performance is low because the instruction cache reads the critical word first and hides the additional latency that is inserted by the fifo with depth=1. Nonetheless, in phases with many cache misses, the performance can be improved at the price of an additional fifo entry. Signed-off-by: Michael Gautschi <[email protected]>
gautschimi
force-pushed
the
xbar_fifo_depth_support
branch
from
2972f23 to
40202d2
Compare
Contributor
Author
|
master: Requests every 2nd cycle, 1 bubble after each request and response. fifo_depth=2 Requests are granted in two cycles in a row to access a full cacheline. No more bubbles in between cacheline requests and responses |
vogelpi
reviewed
Nov 28, 2025
Contributor
vogelpi
left a comment
vogelpi
left a comment
There was a problem hiding this comment.
Thanks, this looks good and it seems like a nice improvement!
Two questions:
- Could you observe any performance improvement e.g. for CoreMark?
- Shall we also enable this for Darjeeling (executes from a big SRAM but also has the I-Cache present)?
| rsp_fifo_pass = True | ||
|
|
||
| # FIFO depth option. default is 1 | ||
| # If pipeline is false or req/rsp_fifo_pass are true, this field has no meaning |
Contributor
There was a problem hiding this comment.
Why does the depth have no meaning if the either of the pass options are true? I guess it's just a limitation of the current implementation, right?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit adds the possibility to increase the fifo depth in the xbar to values > 1 to support multiple outstanding transactions.
Why this is beneficial:
The ibex instruction cache issues two 32b requests to the flash controller. Inside xbar_main a pipeline register is added to break the critical path to the flash. The pipeline register is added with a fifo of depth=1 for req and rsp data and effectively inserts a bubble after each request and response because the fifo is immediately full. Ibex and flash_ctrl can deal with up to 2 outstanding transactions.
The impact on performance is low because the instruction cache reads the critical word first and hides the additional latency that is inserted by the fifo with depth=1. Nonetheless, in phases with many cache misses, the performance can be improved at the price of an additional fifo entry.