[libre-riscv-dev] buffered pipeline

[Luke Kenneth Casson Leighton]

On Wed, Mar 13, 2019 at 8:45 AM Jacob Lifshay <programmerjake at gmail.com>
wrote:

> On Wed, Mar 13, 2019, 01:39 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> wrote:
>
> > On Wed, Mar 13, 2019 at 8:27 AM Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > > note that in my pipeline stage design, succ_accepting to pred_accepting
> > > doesn't go through a flip-flop so it isn't delayed a clock cycle,
> meaning
> > > that a stage can block all predecessor stages in a single clock cycle,
> > > eliminating the need to have extra stage registers.
> > >
> > > I didn't include the table in the email, but I did check all
> combinations
> > > of succ_accepting, pred_sending, and data_valid and it works just fine.
> > >
> >
> >  can you please write a unit test (which has the side-effect of creating
> a
> > waveform as output) so that i can take a look?
> >
> sure, I'll do it in the morning though.


ok cool.  you can use either daniel's unit tests or some of mine as a
template.

I had just checked the truth table
> by hand when writing the email.
>
>

(taking daniel off the cc for this one)

this is primarily one of the reasons why unit tests are written, so that
someone else may verify and review the correctness of the code, without
having to replicate (by hand) the truth table.

i already have something like... 30 classes in the FPU.  if we have several
hundred modules there's absolutely no way we can ensure that they're
correct by hand, and we shouldn't have to.

i cannot emphasise enough how critical unit tests are for python.  please
do get into the habit of writing unit tests at the time of writing of the
actual code, to the point of making sure that they're in the same commit.

beyond about 80 lines of code without having written even a first basic
unit test to prove that the code written up to that point does at least
most of what it's expected to do is a serious red flag for the viability of
the project.

yes, it's really that serious.

i worked for two companies that wrote 250,000 line+ python codebases, both
completely and utterly failing to write unit tests.  in one of the
companies, they retrospectively decided to add unit tests: as a result, all
development completely ceased for six months.

five engineers, doing nothing but write unit tests.  as you might imagine,
morale was extremely low.

in the other, the CTO was basically a technically brilliant *programmer*
but managerially incompetent, incapable of listening to advice (because he
"always had the answer"), and unfortunately was in *no way* formally
trained in software engineering.  he considered writing unit tests to "slow
down development".

as a result of his incompetence, he would regularly and routinely make code
changes to critical and fundamental base classes, and expect everyone else
in the team to "clean up the mess".

code that was "broken" was REPLACED rather than fixed... because it was
just impossible to identify the "breakage".  why? because with no unit
tests, it was completely worthless to even try to do git bisect.

in one case, as i worked for 12 to 14 hours a day non-stop for several
weeks, to put unit tests in place, i managed to identify a serious flaw,
fixed it, only to have the unit tests FAIL 24 hours later because the
stupid, stupid "brilliant" CTO had "identified" the same flaw and, WITHOUT
TELLING anyone, had taken it upon himself to create "replacement" code.

of course, this new replacement code neither had the same features as the
original, had no unit tests, and not a single line of the existing codebase
was conformant to this new API change.  yet, *because* there were no unit
tests, we could not even identify the places where the new API was even
being USED!

given that there were absolutely no unit tests - 350 THOUSAND lines of
code! - absolutely nobody had *any* confidence in the code.  at all.

that was fifty engineers, absolutely terrified of making even the simplest
code change.  development progress - for a 50-man team - was shockingly
low.  or, actually, not shockingly low at all: it was just a direct
byproduct of incompetence and lack of absolutely essential software
engineering practices.

l.