[libre-riscv-dev] buffered pipeline

Jacob Lifshay programmerjake at gmail.com
Thu Mar 14 18:28:10 GMT 2019

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

> 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

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

More information about the libre-riscv-dev mailing list