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

Samuel Falvo II sam.falvo at gmail.com
Sat Jun 1 03:30:18 BST 2019

On Fri, May 31, 2019 at 4:16 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
> Ooo so, so, for the CSRs, actually you split them into purposes. It's just
> that they're stored in what APPEARs to be the same "register", but actually
> that's not true, the register is only a few bits.


>  Funny, eh? I just hope it does actually save gates. Or, at least, makes
> for a design that has a really good bang per buck ratio.

Due to the size of the register file, it looks like I will not be
using unary representation except where absolutely necessary.  Plus,
the block RAM that will implement the register file only accepts a
binary representation.

> Pretty much, yeah!  Btw LD/ST needs a bit more attention, there is a
> separate Matrix for it (in addition to the FU which does the actual reg
> adding to calc the address).

I was planning on building the LD/ST unit so that it did its own
effective address calculation.  So, instead of taking 3 or 4 cycles to
complete, maybe it'll take 5 (assuming no external wait-states).  So,
the sequence would be issue, go-read, add, drive-bus, then go-write.
Since it has an adder as part of its logic, it could short-sequence
that whole sequence for adds and subtractions: issue, go-read, add,
then go-write.

> P.s you know I am going to borrow that when it comes to the engine I am
> doing :)

It's open source and under MPLv2 license.  Please enjoy.  :)  It's not
required, but if you can give a brief reference back to the Kestrel
Computer Project as your source of inspiration for that somewhere in
your literature, that'd be appreciated.  :)

One question that might come up over time -- why is TX so much easier
to use than RX?  Well, I *wanted* to make the RX register work
similarly; however, what happens if you never received another byte?
(E.g., this can happen if you put the SIA into loopback mode, then
attempted to receive a byte without first sending one.)  You'd
deadlock the whole processor in a way that only a hard reset can break
out of (unless you included some manner of bus time-out logic
elsewhere in the computer.  This implies that every read of the RX
port can potentially trap!).  So, in the interests of simplicity and
reducing the need for external logic, I regret that I wasn't able to
make the behavior symmetric, but that's the reason why.

Samuel A. Falvo II

More information about the libre-riscv-dev mailing list