[libre-riscv-dev] store computation unit
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Sat Jun 1 20:52:09 BST 2019
On Sat, Jun 1, 2019 at 5:09 PM Mitchalsup <mitchalsup at aol.com> wrote:
> Luke,
>
> You have a "logically sound" design.
>
> But, due to the latency through the stages, you might want to release FU_AGEN
> as you latch the address at/near the cache and tread the second 2 stages as if they
> were a different FU. CDC 6600 actually did part of this as outlined in my writings.
ok. so, actually make the address computation its own unit
(particularly as it can be used as an ADD-immediate ALU), i would
prefer that as the graph's getting on the large side for this unit.
i was however planning to add concurrency (like in 11.4.11.3 "4-way
concurrent cache"), as a 2nd phase, get things working initially, so
that i have a firm basis on which _to_ add the concurrency. i still
have to add a memory test unit, and so on.
am having minor difficulty thinking through the difference between
"as if the latter stages were a different FU" and "actually making
them a different FU".
my mind wants to treat the address output as if it was an *actual*
register, to create effectively micro-code splitting the
address-calculation and the actual LD/ST as two separate instructions,
with their own "Dependency Matrix" kicking off, and at that point the
amount of thought and work required makes me rebel :)
i'll add in the testing infrastructure, get this working first, and
then see about splitting it and adding concurrency.
l.
More information about the libre-riscv-dev
mailing list