[libre-riscv-dev] pipeline stages controlling delays

[Jacob Lifshay]

On Thu, Apr 4, 2019, 22:30 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> On Fri, Apr 5, 2019 at 6:06 AM Jacob Lifshay <programmerjake at gmail.com>
> wrote:
> > 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
> them.

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
> together.
>
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
CombStage.

>
>  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.

Jacob