[Libre-soc-dev] gigabit router design decisions

[Jacob Lifshay]

On Tue, Nov 2, 2021, 04:57 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Tue, Nov 2, 2021 at 1:10 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > > this is an optimistion, and it is scope-creep.
> > >
> >
> > Well, I disagree...afaict we never actually decided as a project what
> exact
> > kind of cpu we want for the gigabit router...
>
> no: and you were not part of the team (because you had effectively
> left, by working for 18 months full-time on Rust, unpaid), and also
> because i had only 48 hours notice in which to complete the Grant
> Application
>
> did you help with that Grant Application?
>

no, but iirc i did read it and give feedback (though I could be
misremembering). I mostly left it to you because I have essentially no
experience whatsoever writing grant applications and I didn't want to risk
me messing it up.

>
> > which means no branch prediction (which I disagree with)
>
> this is purely pragmatic, and, once again, you are failing to acknowledge
> the logic behind this decision, which is not a decision, it is a practical
> pragmatic roadmap.
>

Ok, i understand where your coming from, however, I know, from how the API
is designed, that it should be pretty easy to integrate the branch
predictor I wrote (actually it's technically just a branch target buffer,
along with next-pc logic) since you just replace the fetch pipe's logic for
deriving the addresses to read from with the branch predictor pipe stage

I DID NOT SAY THAT UNDER NO CIRCUMSTANCES will branch
> prediction not be added
>

ok.

>
> i said VERY SPECIFICALLY THAT IT SHOULD BE ADDED IF AND ONLY
> IF THERE IS TIME.
>
> why are you not listening to what i say?
>

because you worded it in a way such that it was easy to infer you didn't
want branch prediction.

>
> > even if it's quite easy to integrate
>
> jacob: because you have not been part of the team, you have zero
> practical experience in working with others, and with the team.
>

that's not true. I have been helping quite a bit, I wrote the div FU, and a
lot of the code that SimdSignal started from, as well as writing a large
portion of the SVP64 spec, and other things too.



How about this idea:

>
how about letting me try to implement the fetch & decode & issue pipe and
if I can't get it mostly working by monday Nov 8 (which I think is probably
feasible if I start working on thursday), then i'll go work on something
else and you and cesar can do it however you all like, i'll keep my nose
out of it.

I'd guess the bitmanip instructions might take that long to get started on
anyway due to waiting on others, so I'm likely not delaying that by working
on fetch/decode/issue first.

> because I already wrote a fully operational branch predictor.
>
> question: why did you spend time writing that code rather than
> asking "what are the most urgent time-critical tasks that will
> help us to fulfil our CONTRACTUAL obligations?"
>

cuz the time I spent writing it was mostly going to be a day off for me
anyway (iirc it was on a sunday)...it didn't detract from the rest of the
project.

>
> > You
> > then proceeded to reject all conversation about what cpu design would be
> > best because it detracts from the plan you unilaterally came up with.
>
> you are completely misreading the situation.
>

ok, yeah. I did misunderstand somewhat. Sorry for accusing you of something
you didn't do.

>
> > Please don't reject cpu design conversation, remember this project is a
> > community effort, not just you dictating top-down design decisions.
>
> reality is, Jacob, that you left the team.  you left me to be the sole
> exclusive
> developer making decisions.  i had to make those decisions, and they
> are decisions that, for historical reasons, cannot be changed.
>

the decision to switch to a simple in-order cpu was quite recent, well
after I was working on the hdl full time again.

>
> now you are coming back to the team, you need to accept the reality
> that you are a Junior team member, with no working knowledge of the
> code, and no experience in working on time-pressured team projects.
>
> therefore, you need to respect that i, as the sole exclusive team member
> with the practical knowledge and experience,

that's not true, many others have lots of experience in libre-soc, such as
cesar and me.

> and a full understanding
> of the project,

that's also not true, we all have knowledge that covers different areas of
the project:
I know all of Kazan's code, and most of the hdl code. you know nearly all
the hdl code and likely not a huge amount of kazan.

> who made the Grant Application, who has got the
> funding, who has been left to make the decisions, has in fact made
> those decisions, and they are:
>
> 1) in practical pragmatic and historic terms, not up for discussion
>
> 2) even if they were, the timescales would (after several weeks of
>    discussion which would be detrimental and counterproductive)
>    leave us with the EXACT SAME DECISION
>
> the amount of time that you are spending fighting this, and not
> listening, over the past 6 months, has been considerable and
> alarming.
>

I could say likewise...I go to that much effort to try to convince you
because I think the project will be better off (timewise, as well as
otherwise) because of changing some parts where there are design flaws,
sometimes catastrophic.

>
> i appreciate that you loved working on rust, and greatly enjoyed
> the community there.  reality is:  nobody in the rust community is
> under a CONTRACTUAL deadline to complete set tasks.


that's not true, a good example is gcc-rs, the wip rust frontend for gcc.
the main developers are sponsored and from what I can see, it seems like
they have contractual milestones.

example:
https://github.com/Rust-GCC/Reporting/blob/main/2021-10-monthly-report.org


right now, you have a ONE HUNDRED percent track record
> of not listening and not respecting the decisions that have to be
> made.
>

that's false. there are many instances of me listening and following the
decisions you and others have made, such as putting off full SIMT-ification
of SimdSignal (david helped convince me), and when I XLEN-ified the BCD
instructions' pseudo-code.

Jacob