[Libre-soc-dev] gigabit router design decisions

[Jacob Lifshay]

On Thu, Nov 4, 2021, 11:24 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Thu, Nov 4, 2021 at 5:13 PM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > Ok, I did not realize the extent of conflict and stress that luke and my
> > argument was causing, I apologize for that.
>
> Jacob you should have listened to the fact that it was causing *me*
> distress,
>

Well, not that it's a decent excuse, but luke, your the primary one making
decisions, so your the one who has to convince everyone that your decisions
are the best, part of that is discussing with people who think things would
work out better if done somewhat differently.

this is disrespectful and distressing *to me*!
>

Sorry that I appeared to disrespect you, that was not my intention.

>


> > I guess no one's willing to trust me when I confidently say that I can
> > write the code that we desperately need, this is quite disappointing
>
> ok, if you would like to use "desperation", we need to invent two levels
> of "desperation".
>
> "desperation level 1" - code, documentation and unit tests with branch
> prediction
> "desperation level 2" - code without.
>
> when "desperation level 1" adds a whopping 25% to the completion time
> of a time-pressured project, it should be blindingly f*****g obvious that
> it is completely suicidal and destructive to the entire project to attempt
> it.
>

well, I've been pushing for it cuz: 1. I'm pretty sure it will have a much
lower impact on completion time, around 3-5% or so (mostly taken up by
extra testing needed, the testing is not on the critical path since other
parts of the cpu can be worked on simultaneously by using either the
existing simple fetch/issue logic or by using the new fetch/issue while
tests are being developed). 2. it will make the resulting processor run 50%
(!!) faster, which is highly significant.

>
> desperation level 1: something that is so long it can't be completed in
> time
> desperation level 2: something that's sub-optimal but allows us to
> complete the contract.
>
> which do you think is more important?
>

2 is, but only if you accept the likely flawed assumption that adding a
branch predictor falls into category 1.

compared to "a little desperation" the consequences of "just put this
> code in it will only increase the timescales by 25%" seems to be
> pretty frickin stupid, would you not agree?
>

yes, if your flawed assumption that it really increases timescales by 25%
is accepted as fact.

>
> > (especially considering that the charter explicitly says decision making
> > should be unanimous),
>
> yes... except because you effectively left and re-joined (as far as writing
> HDL is concerned), you're on "probation".
>

I don't recall the charter having an "except your on probation"
exception...therefore logically decision making should be unanimous 100% of
the time as stated in the charter (though people are free to delegate or
abstain, as also mentioned in the charter).

If that's not workable, we need to change the charter until it is workable.

To be clear, I've given up on branch prediction, so we currently are
unanimous on this particular decision.

>
> over time you'll be able to properly guage time and risk, but to do
> that properly you need to *listen* to people who have 20+ years
> experience in doing that, ok?
>

yeah, I'm listening, however I will point out that I have a lot of
experience in how fast I can write code (waay more than your experience in
my code writing speed), which is where my time estimates come from.

Jacob