[libre-riscv-dev] store computation unit

[Luke Kenneth Casson Leighton]

hi mitch,

i decided to have a go at piecing together a store "computation unit",
and wondered if you could take a look?  the sequence is:

* issue
* go_read (activated on rd_req)
* go_addr (activated on addr_req)
* go_write (activated on rel_req)

the latches:

* opcode latch is:
- open by default (after RST)
- open on (Go_Write | Go_Die)
- closed by Issue

* operand1 latch is:
- treated exactly like the opcode latch if the opcode is an "Immediate".
- opened on Issue *IF* the opcode is NOT an "immediate"
- closed by (Go_Read | Go_Die) *IF* the opcode is NOT an "Immediate"
- closed by default (after RST)

* operand2 latch is:
- opened on Issue
- closed by (Go_Read | Go_Die)
- closed by default (after RST)

* addr latch is:
- opened on Go_Read
- closed by (Go_Addr | Go_Die)
- closed by default (after RST)

* result latch is:
- opened on Go_Addr
- closed by (Go_Write | Go_Die)
- closed by default (after RST)

Notes:

i used the two-ANDs-plus-OR to select either the operand or the
immediate, and replicated the same selection mechanism to choose when
to gate the operand-or-immediate capture latch.

thus it is assumed that the opcode and the immediate are provided in
the *same cycle*.

Go_Die resets all SRLatches to closed with the exception of the opcode
latch, which is reset to OPEN.

i like the idea of having the go_read matched with a read_req, it
seems symmetrical and sane.  i am still having difficulty with the
logic behind not having a read_req associated with go_read, when
go_write has req_rel (aka write_req), so have kept it... for now...
and also followed through (logically) with, on go_addr, a
corresponding addr_req.

all the XX_reqs are *DISABLED* by "Busy", which stops things going awry.

the MEM unit is where exceptions can be generated, which will cause
Go_Die to be called on this and all shadowed instructions, however
it's part of the MEM unit, so the exception generation isn't shown
here.


does there look like there's anything spectacularly stupid or just
completely illogical?

l.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: st_comp_unit.jpg
Type: image/jpeg
Size: 32787 bytes
Desc: not available
URL: <http://lists.libre-riscv.org/pipermail/libre-riscv-dev/attachments/20190601/124e8190/attachment-0001.jpg>