[libre-riscv-dev] pipeline stages controlling delays
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Fri Apr 5 06:29:49 BST 2019
On Fri, Apr 5, 2019 at 6:06 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
> On Thu, Apr 4, 2019, 22:04 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > to support FSMs as pipeline stages (e.g. the FP div unit and others)
> > we will need a way for *stages* to signal that they are ready (or not)
> > to pass on or receive data. i *think* that means that they need to be
> > able to override the PrevControl signals, by capturing and re-routing
> > them.
> 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. 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).
given that there's *two* pipeline types (Buffered and Unbuffered),
the risk is that a Stage would need to know what *type* of pipeline it
was being instantiated with in order to know what (invasive) logic
changes were needed.
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
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
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.
the logic - in ControlBase *not* the stage - would go:
m.d.comb += self.p.actual_o_ready.eq(0)
and likewise for the data valid.
perhaps those tests and settings are the other way round (test if
p.actual_o_ready, set p.o_ready)... hmm....
More information about the libre-riscv-dev