[libre-riscv-dev] KCP53000B micro-architecture thoughts

[Samuel Falvo II]

On Fri, May 31, 2019 at 8:37 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>  iknowiknowiknow, it's the one thing i don't like, and there are a

It's the curse of tiny FPGAs.  If I were targeting a $500 Xilinx
monster chip, I probably wouldn't care much at all.  ;)

>  for RISC-V there *are* no 2-reg LD ops, however if you are planning
> to do a hybrid "can be used as an ADD unit as well" thing, the
> capability of that diagram will be pretty much what you'll need.

That's my goal -- minimize LUTs.  :)

> * Issue will close the opcode latch and OPEN the operand latch AND
> trigger "Request_Read" (and set "Busy")
> * Go_Read will close the operand latch and OPEN the address latch AND
> trigger "Request Address".
> * Go_Address will close the address latch and OPEN the result latch
> AND trigger "Request Write"
> * Go_Write will close the result latch and OPEN the opcode latch, and
> reset BUSY back to OFF, ready for a new cycle.

I'm using ring counters driven by a gated clock, so I don't have a
strict need for request/ack handshakes for each step along the way.
For example, GO_READ in my design will cause the FU (not the CU!) to
/gate/ the source register addresses onto the trunk so that the
register file can deliver their values in the /following/ cycle (since
block RAM is fully synchronous in the FPGA I'm targeting).
Immediately after GO_READ, therefore, GO_SUM is asserted causing the
CU to register the result of the adder in the next cycle (since we
know that the trunk's register value buses will hold the requested
data; also, which conveniently is when either GO_WRITE or CMD_PENDING
will be asserted).

Although I'm not exploiting it, I should note that this design seems
to be pipeline-ready.  Instead of a simple 1-hot ring counter, a
multi-hot ring counter (or the logical OR of several ring counters,
such as what you'd have if you allocated one FU per pipeline stage,
which I believe you and Mitch Alsup discussed earlier, and is
documented in Alsup's chapters) can be used to parastaltically drive
data through the CU.

-- 
Samuel A. Falvo II