[Libre-soc-dev] SimdSignal library

[lkcl]

On October 1, 2021 8:06:23 AM UTC, Jacob Lifshay <programmerjake at gmail.com> wrote:
>On Thu, Sep 30, 2021 at 11:50 AM Luke Kenneth Casson Leighton
><lkcl at lkcl.net> wrote:
>> On Thu, Sep 30, 2021 at 7:21 PM Jacob Lifshay
><programmerjake at gmail.com> wrote:
>> > > it looks like it's fantastic work - why did you go ahead with it
>without
>> > > discussion?
>> > >
>> >
>> > i did discuss...a week ago:
>> > https://bugs.libre-soc.org/show_bug.cgi?id=708
>>
>> no: you said, "i'm going to do X", and did not respond when i pointed
>> out that it would not be a good idea to ABANDON existing work
>> without first completing it
>
>sorry for not responding till now...the way you phrased it gave me the
>impression that you were totally against working on a version
>including the more flexible SIMD layouts (that support lane-sizes that
>need padding) until the existing less-flexible design was fully
>implemented and tested and documented.

yes, because it is seriously unprofessional to abandon 5 months of work that has not been completed, for no good reason.

if you disagreed you should have said why.

now the *idea* that you came up with is a good one [that needs proper thought and analysis, and i have started bug #713 in order to do that]

just because you had a valuable and important idea that has not been taken into consideration does *not* give you carte blanche to disregard professional engineering practices.


> I'm 100% convinced we will need
>more flexible SIMD layouts when we try to implement SIMD FP, 

a professional response should have been to say so.

now it is one week later and that is one week yet more delay on completing the tasks that need to be completed.


> as well
>as them making most the rest of the code that will need partitioned
>SIMD easier to write

i did an analysis overnight: the gate count is drastically increased.

this will have to be taken into consideration.

regular layouts (no truncation) allows partial results to be created (8 bit usually) and joined together in simple chains that produce quite elegant and efficient gate-level output.

irregular layouts (truncation then padding) unfortunately fundamentally breaks that assumption: where regular 8-bit partial results could be chained to create 16 or 24 bit, if there is say an 11 bit requirement only *one* of the regular 8-bit partial results may be used, the other has to be thrown out and a 3-bit (11-8) result used instead.

this needs to be *properly analysed and discussed* and that discussion needs to take place *long before actually going ahead with coding*.

the absolute top priority task, and you didn't consult me about this, you just went ahead, is NOT to start on a design which entirely disregards and throws out 5 months of work without consultation.

it's to do an extremely rapid throwaway prototype of a SINGLE operator which shows, at the gate level, what is going on.

if you had asked me i would have told you that this was needed, so as to reduce risk of spending time on tasks that would actively harm the project if carried out.

but you did not inform anybody what you were doing, did you?


> -- therefore I think we should work on more
>flexible SIMD layouts now 

this is an unprofessional response.  it completely ignores consequences, risk assessments, budgets and time constraints.

(if you had said, "therefore we should assess how to adapt to flexible layouts" i would know that you had taken on board what i am trying to teach you is critically important professional engineering practices for a project of this magnitude)

> since we would only need to adapt the
>PartitionedSignal code we wrote in the past, 

this is a far larger task than you imagine it to be.

> rather than both in the
>past as well as all the future PartitionedSignal code we will write
>before switching to the more flexible layouts. Therefore, I thought it
>wise to build a small proof-of-concept to demonstrate how the more
>flexible SIMD layouts would work -- that turned into what simd_signal
>is now.

that time spent actively harmed the project because you failed to help accelerate the completion time of the existing design.

we are under serious time pressure.

>> > based on what you have done please can you provide time estimates
>> > > to complete:
>> > >
>> > > * unit tests
>> > >
>> > 2 weeks
>>
>> there's no chance that that's accurate.  it's taken me a day to do
>> Cat, and another day to do Assign.
>
>Well, it took me 1 day (today) to do both SimdCat and SimdRepl with
>both traditional unit tests and formal tests and that's including all
>the time I took building a general tester that supports both Simulator
>and formal testing.

that's great because it demomstrates that if you actually helped with the actual design that is on the critical path you could have helped us to meet our deadlines.

and get paid.

instead you are not getting paid and are actively sabotaging the project's chances of meeting its deadlines before the Grant money is withdrawn in April 2022.


>The actual amount of time needed to add SimdRepl to the test for both
>sim/formal is on the order of 5min (mostly just copy-pasting SimdCat's
>unit test):
>https://salsa.debian.org/Kazan-team/simd_signal/-/commit/b77b188c51c91c3ddfdd6f41c9e22e0bfa5d41e3

that's great: is there anything preventing you from similarly helping write unit tests for PartitionedSignal in 5 minutes?



>> can you please break it down by the list of operators - all of them -
>and give
>> estimates based on a per-operator, per-function, per-unit test basis.
>
>> a *full* list of *all* unit tests planned to be written.
>
>I won't write out a full list of unit tests since that would take
>about as much time as actually writing the unit tests

this is an unprofessional response.

if the list is not written out, it cannot be assessed.

if it cannot be assessed, it introduces huge risk.

risky uninformed decisions when under huge time pressure is why projects fail.

your decisions are therefore actively harming the project.

>.
>I write out the list of operations and test time estimates:
>Note, the following list includes both unit tests and formal proofs
>(yay SimdValueTester class I just wrote that does both!)
>SimdCat, SimdRepl: done.
>SimdValue.bool(): 5min

jacob, it took me about 3 days to do the gate-level analysis for bool xor and some, based on prior work on eq ge and lt that was itself around 3 weeks.

have you remembered to include the time for documenting the requirements and preliminary design analysis (this to be done *before* starting coding)?

have you remembered to include time for posting the links in the bugtracker as the work progresses?

have you remembered to include the time for updating the wiki with the progress and of any design and analysis changes?

have you remembered to take into account gate-level analysis?

it takes well over 5 minutes to even study the yosys "show top" graphviz diagrams (that's after the code is written)

it takes far longer than 5 minutes to discuss the results with me on IRC and the mailing list.

have you included contingency in case the initial design or its implementation (which has not been properly documented or analysed before going ahead), turns out to be inefficient at the gate level?

have you included any time for knock-on ramifications on each task?

your estimates are therefore out by literally two orders of magnitude on what is *actually* needed.


><< >> shift_left shift_right rotate_left rotate_right: 10min total

jacob: shift took *three weeks* to analyse before implementation could begin.  it was of similar complexity to the Wallace Tree multiplier, which if you recall took about 2 *months*

there is *no way* this is realistic.

have you included time to analyse and understand the *existing* design?

>& | ^ implies: 7min total
>== != < <= > >=: 15min total
>abs(): 5min
>slicing: 30min
>as_unsigned(), as_signed(): 5min
>any(), all(), xor(): 5min
>bit_select(), word_select(), SimdPart: 10min
>matches(): 1hr
>Mux(): 5min
>Array(): not supported until we *really* need it...can we skip
>implementing it?

ohh yes.  it's extremely complex.  it's definitely off the list for a first design.

>SimdModule.If/Elif/Else: 2-3 days
>SimdModule.Switch/Case/Default: 4-5 days
>(not actually writing tests): fixing bugs that are revealed by the
>tests: a week or two
>
>>
>> > > * formal correctness proofs
>
>Included in above estimate, since all we need is to call
>SimdValueTester.run_formal instead of SimdValueTester.run_sim

Formal tests require a model against which to check.  from experience we know these take almost as long to write as the original code.


>> > > * where the funding is coming from.
>> > >
>> > we can use the If/Switch budget?
>>
>> then what budget is used to complete the if/Switch work?
>
>idk, the left over part?

none.

because you are not helping with the existing design i have had to call in outside help.

they charge a lot more money.

because they charge a lot more money i may have to pre-empt them and do it myself.

this in turn actively harms the project because there are other higher priorities and committments that i cannot keep.

when speaking with a friend who has been involved with VLSI Project Management for over 25 years, we asked him, "what was the number one cause of project failure in VLSI design?"

he answered immediately: changing the design requirements.

*all* changes need to be properly assessed as to their impact.

you need to understand and appreciate, jacob, that throwing out a design because of an oversight in its requirements is a drastic option that needs careful consideration as to its consequences on the timeline.

l.