4-stage fetch #308
4-stage fetch #308
Conversation
|
|
||
| dontTouch(f3_fetch_bundle) | ||
|
|
||
| val r_f4_valid = RegInit(false.B) | ||
|
|
||
| // Can the F3 stage proceed? | ||
| val f4_ready = (!r_f4_valid || fb.io.enq.ready) && ftq.io.enq.ready |
There was a problem hiding this comment.
Could this be simpler with a 1-deep queue.
I also think it may be a good idea to make this configurable (for now).
We need to make a graph showing performance impacts of all the random stuff that's changed.
There was a problem hiding this comment.
I had thought about doing that, I can look at it. I held off because these options tend to be messy code-wise, and it takes longer to verify both settings (and we inevitably end up wanting to deprecate them).
There was a problem hiding this comment.
Yeah I agree it's messy,and hopefully we would depreciate it soon.
It's just this may have a noticeable performance impact, and it would be good to document that with a good comparison.
|
Also, depending on what's default, some of the documentation should be updated |
Sure. |
bkorpan
force-pushed
the
f3-split
branch
5 times, most recently
from
0977836
to
5c8b8e6
Compare
Type of change: other enhancement
Impact: rtl refactoring
Development Phase: implementation
Release Notes
Added another stage to instruction fetch. The fetch bundle path is split by an f4 register prior to enqueueing to the fetch buffer. The ftq still enqueues fetch targets in f3, as it is not the endpoint of any long paths.