[libre-riscv-dev] store computation unit

[Luke Kenneth Casson Leighton]

On Sat, Jun 8, 2019 at 5:45 PM Samuel Falvo II <sam.falvo at gmail.com> wrote:

> I've been slowly evolving my design as well, and I'm having some
> revelations of my own.

 hurrah.

> The logic of the AddStoreFU unit, while it has /some/
> AddStoreUnit-specific logic, is 99.9% generic across all other units I
> intend on implementing.  So, I'll definitely be refactoring that logic
> into a single module that can be implemented either as a base-class
> for specialization, or to be reused as-is.

 i came to the... wait, do you mean AddStoreFU or do you mean AddStoreCU?

> In other words, "the scoreboard" is just "all the FUs + the picker
> logic to prevent trunk bus contention + combinatorial resource
> tracking".

 yyup.  it only knows about registers from the bit-vectors (or binary
versions of them aka Q-Table), it *refers* to resources (buses,
regfiles, memory), it does *not* actually do anything to or *with*
those resources.

> The only state machine the CU implements is that needed
> for what the FU considers the "execute" state, if one is needed at
> all.

 yyep.  historically in the 6600 the CU was located in a completely
different cabinet a looong way away from the FUs and scoreboard in
general.  hence the need for the extra [half] clock.

 conceptually however, following the lead there makes i feel for a
much cleaner and clearer design.

> My from-scratch implementation is, so far, much closer to Thornton's
> documented architecture than it is to Alsup's design, ironically.

 interesting.

> which triggers the go_write event.)  I'm finally happy with this
> naming system, as now all "requests" are located in the CU, and all
> "go" signals are in the scoreboard logic.  There's no mixing between
> them.

hurrah.

l.