[Libre-soc-dev] gigabit router design decisions

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Tue, Nov 2, 2021 at 12:03 PM Cesar Strauss <cestrauss at gmail.com> wrote:
>
> Em 01/11/2021 22:21, Jacob Lifshay escreveu:
> > On Mon, Nov 1, 2021, 18:09 Jacob Lifshay <programmerjake at gmail.com> wrote:
> >
> >> Please don't reject cpu design conversation, remember this project is a
> >> community effort, not just you dictating top-down design decisions.
> >>
> >
> > To be clear, this isn't merely about having a branch predictor or not, but
> > about us cooperating as a community to come up with the best design. I will
> > be fine if we decide we don't want a branch predictor, but that should be a
> > community decision.
> >
>
> My proposal is to plan ahead, and:
>
> 1) Design the pipeline *without* branch prediction, but in a way which
> is compatible with easily adding one.

yes. sensible

> This involves using a "predict always not taken" approach, with the
> ability to flush the Fetch/Decode stages if, after executing a branch,
> Issue's idea of the next PC disagrees with the one at Decode.

a next advanced feature would be to read the branch conditional hint
field, and base the decision on that.  (p33 v3.0B Book I section 2.4)

> This involves just a correct PC x actual PC comparator at Issue, a flush
> input signal on Fetch/Decode, and a "PC override" port on Fetch. No
> complex speculative logic, and no need to panic and restart whenever
> Decode sees a Branch.

currently, the TestIssuer FSM has a "snoop" on a dedicated port to
the STATE Regfile, which is exclusively dedicatedt to PC writing.
when it notices the write (by any ALU) it can make the decision
not to overwrite that with the pre-prepared "PC+4" value.

it means stalling until a branch is executed, but this is dead simple
and extremely easy to implement right now.

anything involving branch prediction *inherently* and automatically
implies speculative execution, and we simply don't have time for that.

> 2) As we (hopefully) reach the baseline ahead of schedule, we can
> prioritize additional features.

yes.  by keeping - using - the ReservationStations, any kind of
speculative behaviour may be added without having to rip up
entire swathes of code.

if however we decide to start from too complex a base, we risk
not being able to complete at all.

(i have just realised, yesterday night, that ReservationStations,
one of the fundamental critical components, needs a redesign.
this is slightly freaking me out)

> By then, simply inserting a branch
> predictor to the "PC override" Fetch port can be seen as "low hanging
> fruit" and "nice to have", not being canceled due to throwing away
> months of existing code.

yeyeh.

l.