[libre-riscv-dev] pipeline sync issues
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
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.
On Tue, Apr 9, 2019 at 9:30 PM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> 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
> 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.
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
More information about the libre-riscv-dev