[Libre-soc-dev] gigabit router design decisions

[Luke Kenneth Casson Leighton]

On Tue, Nov 2, 2021 at 12:13 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> On Tue, Nov 2, 2021 at 12:03 PM Cesar Strauss <cestrauss at gmail.com> wrote:
> >
> > 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

fortunately, the Pipeline API has the "stages" (combinatorial logic)
separated from "control-signalling" (ready/valid/muxid/other) in
such a way that Global Cancellation and other signals can be
added without disrupting the "stages".

12+ months ago i experimented in nmutil with "cancellation" and in its
simplest form it was successful.

therefore, yes, it should be easy to add at the control side the necessary
"cancellation" and other control signals, by designing and deploying
an alternative mix-in class.

therefore, yes, we can save time by designing code entirely without
branch prediction and indeed add it easily later, if we have time.

mostly it is not about the branch prediction code itself: a plan will have to
be written as to how to actually test the branch prediction.

time estimates will need to be given as to how long it will take to:

* write the alternative mix-in class
* test the alternative mix-in class
* implement the branch prediction code
* integrate the branch prediction code
* think through any adverse implications
* write a unit test plan
* implement the unit tests

by simple estimates of allocating approximately 3-4 days per task
this places branch prediction at somewhere between 21 to 28 days
to complete.

that's excluding any bug-tracking due to unforeseen issues

that is a whopping EIGHTEEN percent of the available 150 days
(if weekends are included)

if weekends are excluded it is only 107 working days, meaning that
adding branch prediction would be a massive TWENTY FIVE PERCENT
of available time.

that is why it has not been added as a first priority.

l.