[libre-riscv-dev] buffered pipeline

[Jacob Lifshay]

On Thu, Mar 14, 2019, 06:52 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>
> https://git.libre-riscv.org/?p=ieee754fpu.git;a=blob;f=src/add/test_buf_pipe.py;hb=HEAD#l89
>
> yay, that works! split out send from receive, on their own separate clocked
> co-routines.  Simulation() takes care of multiplexing / synchronising them,
> based on the clock "yield" timing.
>
> without such an approach it's almost impossible to manually interleave the
> send/receives (or other interactions, of which there could be potentially
> dozens) in a way that can be interpreted and understood by looking at the
> code.
>
> so, for example, jacob, i notice that the unit test that you wrote, there
> are two yield statements: one on "set data" and the other on "clear data
> valid":
>
>                     # set data
>                     yield test_stage.input.data.eq(0xAAAA)
>                     yield test_stage.input.sending.eq(1)
>                     yield test_stage.output.accepting.eq(1)
>                     yield
>                     yield delay_into_cycle
>                     # clear data_valid
>                     yield test_stage.input.sending.eq(0)
>                     yield test_stage.output.accepting.eq(1)
>                     yield
>                     yield delay_into_cycle
>
> what that means is: the data is only sent every *two* cycles, which means
> that the pipeline is only 50% utilised... in turn, that means that
> potential conditions where it could fail (lose data, or data corruption)
> are not being tested.
>
they are still being tested since the next clock cycle optionally fills the
simple pipeline stage, then the cycle after is the cycle where all the
combinations are covered.

>
> a split sender co-routine as separate and distinct from the receiver
> co-routine would allow the sending to potentially occur on every clock.
>
> i like the idea of comprehensive coverage of data valid, sending and
> accepting: my only concern is that they're regularly scheduled.  as in: the
> possible permutations of the *order* in which the combinations of
> data-valid / sending / accepting can occur (be set and unset) has not been
> covered, leaving the possibility that some combinations might fail as being
> unconfirmed.
>
I can add another test that dumps random data through the pipeline (using a
lfsr or something to obtain reproducible results).

>
> that was why i used a random setting of the accept and send conditions, but
> also varied the distribution of time that each could spend set / unset (see
> send_range and stall_range).
>
> what that does is: sets up between 1 and 10 cycles where (potentially) the
> sender is mostly idle and the receiver is mostly accepting, and then on the
> next 1-10 cycle group, it could be the other way round.  then, also,
> sometimes, there's no stalling and the receiver is never busy.
>
> repeat for 10,000 values and we have a high degree of confidence that the
> buffered pipeline (and a 2-stage chain) works as advertised.
>
ok, though the test I have already tests all combinations of internal state
and external inputs (except that the input data doesn't cover all 2^16
values).

I can add tests that test a longer pipeline if you like.

>
> l.
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>