[libre-riscv-dev] pipeline stages controlling delays
programmerjake at gmail.com
Fri Apr 5 07:00:50 BST 2019
On Thu, Apr 4, 2019, 22:30 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> On Fri, Apr 5, 2019 at 6:06 AM Jacob Lifshay <programmerjake at gmail.com>
> > that's why I had put the control signals as members of Stage.
> ... which isn't needed in the majority of cases, hence why i separated
which is why I made CombStage, to handle all the boilerplate code needed
for the most common cases.
plus, if they're part of the Stage, the temptation will be to
> override the *entirety* of the logic (or, worse *require* overriding
> all of the logic).
which is entirely feasible in the code I wrote because of separation of
concerns between RegStage and CombStage, so every Stage instance has a
uniform ready/valid interface, whereas BufferedPipeline and
UnbufferedPipeline make Stage have an interface that changes semantics
depending on how it's used.
what i believe all that is needed is just to create a surgical break
> in the p_o_ready and n_o_valid signals, and provide a couple of
> functions (in the stage instance) to connect the pairs of signals
Note that the BUF gates that yosys shows between wires should be optimized
out by the synthesis toolchain, so there is no penalty (except increasing
compile time by a little) to having long chains of signals that are wired
directly. That's part of why there is no problem routing ready/valid
through every stage instance.
> the Stage doesn't need to know, and definitely doesn't need access
> to, the p_i_valid or n_i_ready for example. if those are part of the
> Stage, the Stage *will* have access to them, and may interfere
> unnecessarily with their operation.
or, the end-user might *think*
> they have to interfere with their operation, because it's part of the
> "exposed API".
that's why the documentation should/will explicitly state that CombStage
handles prev/next ready/valid.
If a stage does something special with ready/valid, then it shouldn't be a
> hmm... given that the pairs of signals need to be treated identically
> in all cases (i think), it *might* even be possible to just return
> code-snippets (similar to how process() returns something that is eq'd
> into the register) and have ControlBase not even pass the pairs of
> p_o_ready and n_o_valid signals into the Stage.
I think that may be an unnecessary complication. If a stage needs to handle
ready/valid signals in a way that's different, it should just handle them
directly. We could make a helper class FSMStage if that makes it easier.
More information about the libre-riscv-dev