[libre-riscv-dev] store computation unit
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sat Jun 8 22:37:56 BST 2019
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.
> 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
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*
> The only state machine the CU implements is that needed
> for what the FU considers the "execute" state, if one is needed at
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.
> 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
More information about the libre-riscv-dev