[libre-riscv-dev] pipeline sync issues

Jacob Lifshay programmerjake at gmail.com
Wed Apr 10 05:45:05 BST 2019


I think the problem derives from using code that has slightly different
semantics around ready/valid. The semantics I used for the code I wrote are
(copied from the proposal I'm writing):
        ready_to_prev is a signal that is set by this stage to indicate that
        data can be transferred from the previous stage to this stage at the
        next clock edge if valid_from_prev is asserted.

        valid_from_prev is a signal that is set by the previous stage to
        indicate that data can be transferred from the previous stage to
this
        stage at the next clock edge if ready_to_prev is asserted.
        valid_from_prev should not be combinationally dependent on
        ready_to_prev to avoid logical loops.

Note how all the data transfers logically occur at a clock edge, not
in-between clock edges. I think the semantics you were using are that ready
and valid defines if a data transfer can occur in the next period
in-between clock edges, which is different from the semantics I was using
in that, in the code you wrote, ready has to be asserted earlier than in
the code I wrote.

Jacob

On Tue, Apr 9, 2019 at 9:30 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> http://bugs.libre-riscv.org/show_bug.cgi?id=57#c6
>
> ok i think i have the answer as to why UnbufferedPipeline (CombStage),
> and UnbufferedPipeline2 (BreakReadyStage) etc. are not working.
>
> i wrote out the truth table and found that UnbufferedPipeline does not
> take into consideration p_o_ready.
>
> setting p_o_ready on any given cycle is a *contract* that says that,
> on the *next* cycle, if n_i_valid is true the stage *WILL*, without
> fail, be ready to accept the input.
>
> to reiterate: that's on the *next* cycle it will be ready to accept the
> input.
>
> in terms of e.g. the nmigen FIFO code, it's similar to as if
> write-enable were ignored.
>
> by contrast, the truth table for SimpleHandshake respects p_o_ready.
> it takes into account all four signals, and is a 16-way table.
> UnbufferedPipeline is only 8, which is a clear indicator of the source
> of the issue.
>
> 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