[libre-riscv-dev] store computation unit

[Samuel Falvo II]

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 think that's what Mitch
was referring to when he said that the FU logic was colocated with the
scoreboard logic itself; if it's the same logic repeated for every FU,
then it makes sense to just put it into the scoreboard logic itself.
In other words, "the scoreboard" is just "all the FUs + the picker
logic to prevent trunk bus contention + combinatorial resource
tracking".  The only state machine the CU implements is that needed
for what the FU considers the "execute" state, if one is needed at
all.

My from-scratch implementation is, so far, much closer to Thornton's
documented architecture than it is to Alsup's design, ironically.
After having gone through this exercise, I'm finding Thornton's text
to be easier to read and understand, despite the antiquated
terminology.

I'm changing sum_req to go_exec, since it's driven by the FU and
intended for consumption by the CU.  The sequence of operations are:
issue -> read_req -> go_read -> go_exec -> write_req -> go_write.
Note that go_exec always follows go_read one clock cycle.  This lets
go_read drive the (synchronous!) register file inputs while go_exec is
used to capture their results.  It is also responsible (hence its
name) for kicking off the execute stage state machine of the CU, if it
has one.  (For now, I just have it set a register for write_request,
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.

On Fri, Jun 7, 2019 at 11:07 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>
> ok so i have a preliminary unit test up and running, with the two
> memory-based dependency matrices.
>
> * the first matrix is based directly on FU-Regs.  names changed to
> protect the guilty: the unary reg#s became unary FU#s, dest_reg_i
> became ld_fu_i, src2 got deleted, src2_reg_i became st_fu_i.
>
> * the second matrix is the one from section 11.4.12, which
> encapsulates the load-holds-store and store-holds-load rules.
>
> and... i realised i've been a bit of an idiot.  took me a few days to
> recognise it.
>
> i'd *assumed* that the second matrix is equivalent to the FU-FU one,
> which from explorations a few weeks back we learned the hard way it
> expresses result-interdependence.  thus, i could create the first
> matrix on FU-Regs.
>
> wark-wark...
>
> the clue should have been that FU-Regs "forward progress" comes from
> ORing the read register dependencies with the *write* function-unit
> latch information, which is precisely what the second
> (memory-dependency) matrix does (except read-->store and
> write-->load).
>
> the second clue should have been that just as the register
> dependencies are *dropped*, so are the memory dependencies, and, only
> when cleared, do we get an "all clear" signal (a NOR).
>
> so... sigh... i'm now going to try copying and adapting the FU-FU
> matrix instead, and connect that to the MemDep one, and see what
> happens.
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev



-- 
Samuel A. Falvo II