[libre-riscv-dev] [Bug 64] data handling / io control / data routing API needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=64

--- Comment #5 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
i thought about the FSM case, that the stb/ack is at a "disadvantage"
due to it being 2-cycle acknowledgement... and it occurred to me
that this is just a natural consequence of an FSM within a ready/valid
prev/next pair.

in other words: even a FSM placed within a ready/valid prev/next pair
*has* to fall back to 2-cycle behaviour, and, in fact the names stb/ack
*are* ready/valid.

this down to the fact that the FSM must *only* permit a single clock
of "ready/valid" on its input, and must *only* permit a single clock
of "ready/valid" on its output.

so... i believe it will be safe to proceed with an example FSM
that's derived from ControlBase, that (unfortunately) has to handle
the ready/valid signalling itself.

if that is successful, it *may* be possible to then morph it to use
the stage-overloads d_ready and d_valid.  d_ready being raised on
the "incoming" (idle) state, and d_valid being raised on the "outgoing"
(final, data-delivery) state.

at that point, if *that* is successful, the FSM control/data block will
become *independent* of ControlBase, and may potentially be split out
to derive from Stage/StageCls and handed in as an argument to ControlBase
derivatives such as SimpleHandshake

once this is done it will be possible to place fpdiv into an ALU block,
and general development of the OoO design can proceed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.