[Libre-soc-dev] gigabit router design decisions

[Luke Kenneth Casson Leighton]

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

On Thu, Nov 4, 2021 at 1:34 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

> 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.

exactly, and because of your track record of not being able to respond
in a time-critical fashion, David and I didn't consult you.

> >
> > > 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

this is complexity.  it is not a "first design".

how many f*****g times do i have to tell you this.

you DO NOT make a complex design as a first iteration under time
pressure.

it is an absolute guaranteed recipe for failure.

please for god's sake listen and stop arguing and wasting 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.

and you have a 100% track record of not listening and to continue to
recommend complex designs which jeapordise timescales.

therefore i have stopped saying "this can be done later" and have
moved to simple "no".



> that's not true. I have been helping quite a bit, I wrote the div FU,

that was *two years ago*.

> and a
> lot of the code that SimdSignal started from,

no: what you did was, you argued that you could do it better,
created unauthorised designs which have absolutely no basis
in reality (wasting time in the process).

one of the pieces of the code that actually has been used had to be
stripped down from 200+ lines to around 50 by removing type checking
and features that would never be used.

you keep doing this and keep thinking it's "helping", but it's actually
causing me more time to firstly understand what you wrote then
remove the parts not needed and then adapt the rest.

> as well as writing a large
> portion of the SVP64 spec, and other things too.

no, what you did was: you started helping early on, then ignored
requests to help further out.

you have perhaps done approximately ten days of writing SVP64
documentation, where i have spent literally months.

again: you can check the commit logs, just like i showed you a
couple of months back.  they will give you an accurate picture of
reality.

>
> 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.

no, because Cesar is already committed to design work, and, frankly,
you can't be trusted to not do something that's so complex that nobody
but you can understand it, and, from experience, it's highly likely to be
4-5,000 lines of code instead of the 500 that's actually needed.

if you had instead said, "IF IT IS OKAY WITH CESAR AND YOU to
take away his task, i will do an in-order pipeline as requested with no branch
speculation or prediction, i will keep you informed of progress, and if
that is completed very quickly i will THEN investigate adding the
branch prediction if that turns out to be the next highest priority
task", then i would have said YES, of course, as long as both Cesar
and I are happy.

once you have demonstrated that you properly understand the realities
like this of working under time pressure, and to respect pragmatic
decisions, i'll be able to trust you.

> 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.

these are self-contained and independent.  the way they were written
was from the bottom-up, by first writing FunctionUnit tests:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/alu/test/test_pipe_caller.py;hb=HEAD

followed by CompUnit tests:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/fu/compunits/test/test_alu_compunit.py;hb=HEAD

and additional Formal Correctness Proof tests:
https://git.libre-soc.org/?p=soc.git;a=tree;f=src/soc/fu/alu/formal;hb=HEAD

followed finally by integrating them into the core, at which point unit tests
can be written which demonstrate their effectiveness (at a given
crypto-primitive
acceleration).

so there is nothing to wait on except for a discussion about what should
be started on, first.

> 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.

why did you not instead write something that was useful and focussed
on the contractual deliverables we are contractually obligated to deliver?

i don't understand why you don't understand the realities of time-critical
risk management.

the only conclusion i can come to is that it must be deliberate.

question - and i am absolutely serious in asking this, but it's important
to ask as a way to shock you into understanding reality: are you deliberately
acting to sabotage the project by not committing to work that is needed?
(this is the only logical conclusion that i can draw from your repeated
inability to focus on what's needed when you're asked to, in fact, focus)

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

that's ok.

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

... yet you have not acknowledged that you are in a Junior Role,
and as such are not part of the decision-making until you have demonstrated
an ability to accept Senior Role responsibility.

this is one of the strange situations outlined in the Charter, Section 3.4:
https://libre-soc.org/charter/discussion/

Role, Seniority and Expertise are all respected.
This can be very challenging, particularly when someone with more
expertise meets someone whose length of service is greater.

you are in the strange position of having a "length of service" greater than
pretty much everyone but me, but the active contribution (when you are
supposed to be full-time) is very very low.

a reminder of the commits:

* me: 3,000 commits (appx)
* you: 250 commits (appx)
* Cesar: 300 commits (appx)

Cesar, despite being part-time and having a full-time job, and joining
long after you did, *exceeds* you in total number of committed contributions.

* me: 4 years (appx)
* you: 3.5 years (appx) - excluding a 1.5 year break working on rust
* cesar: 2 years (appx)


> > 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.

Jacob: you did not help - at all - with TestIssuer

you did not help - at all - with the litex peripherals.

you did not help - at all - with the ls180 layout.

all of this was done during the time that you decided to work full-time
unpaid on rust.

all of these things are the relevant DIRECT first-hand experienced
required and necessary to fully comprehend the timescales involved.

i have that experience.

you do not.

therefore when you advocate some particularly complex additional
task, it is **ME** who understands the timescales involved, **NOT YOU**

i do not understand why you do not understand or accept this,
and force me to repeat it time and time again, wasting yet more
time and thus jeapordising time completion.

hence why i am concluding that you must be deliberately acting
to sabotage the project.

are you acting to deliberately sabotage the project by wasting
time arguing and not accepting that we are under time pressure?

you are certainly not acknowledging the reality of your inability
to estimate timescales accurately.  i think you still genuinely believe that
you can do so, despite repeated demonstrations that you cannot.


> > 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.

yet you did not write it, therefore you have no realistic idea of how long
things actually take.

> you know nearly all the hdl code

and i know how long it took to write.  this gives me an accurate ability
to estimate how long it will take to write NEW code.

you DO NOT KNOW how long that takes because you DID NOT
WRITE THE CODE.

i have told you multiple times that "writing code" is not the key
part of any Project Management.

you still have not acknowledged or accepted this.

> and likely not a huge amount of kazan.

correct.  and it would take many months (probably even a year)
for me to even become vaguely comfortable making even one
single commit to it.

from a Project Planning perspective, it would be disastrous
for me to even begin taking on Kazan coding.

knowing AND ACCEPTING this, i stay AWAY from coding on
Kazan.

you see how that works?

i accepted the reality of what i can and cannot do.


> 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.

and this myopic perspective - and it is myopic - is down to complete
lack of experience of working under time pressure and because you
don't have any "handles" on how long things actually take.

therefore, letting you make decisions based on complete lack of
experience of how long they *actually* take is a sure-fire recipe for
total disaster.

Cesar is old enough and experienced enough, and has actively
contributed to TestIssuer.

he knows how long things take.

did you read what he wrote?
http://lists.libre-soc.org/pipermail/libre-soc-dev/2021-November/004019.html

> 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.

that's great: you however get the idea, but i cannot assume, from your response,
that you understand the point i am making, because you cite an
irrelevant sub-project
counter-example as if it invalidates the point i am making.

let me ask another way - and please answer yes or no:

is the entire Rust Project and all of its sub-dependencies under hard
contractual
obligation to meet absolute hard immovable deadlines?


> > 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.

yes, you have some _small_ instances of listening, which is great.
it is encouraging.

however the very fact that on the big things, on the time-critical ones,
despite mentioning repeatedly that it is critical-path, you fail not only
to listen but you actively work to aggravate the time-critical task by
arguing for features that extend it!

so not only:

1) do you waste critical time by arguing for something that ITSELF
    would extend the completion of the critical path task

2) you waste critical time by not DOING the time-critical task

which is pretty frickin ironic and making me pretty angry that you
keep on doing this.  and then not listening when i tell you that
you are, repeatedly, aggravating the project.

and, also, by being repeated behaviour, by logical deduction i can only
conclude that your intent is - consciously or unconsciously -
sabotage of the project.

now, i know that cannot be true, because you understand the project's
importance and its goals.  therefore, there is something else, that you
urgently urgently need to resolve, in your mind, what it is.

but, please do not for goodness sake spend another 2.5 to 3% of
the available time (150 days) working out what that is.  which is
what you've done already so far.

l.