[libre-riscv-dev] [Bug 216] LOAD STORE buffer needed

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=216

--- Comment #26 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
Writeup of the interface / API needed for LDST to talk to the LDST
Computational Unit.  Additional signals will come through such as length, type,
atomic etc
these are in order of time sequence

(edit this comment as necessary):

LD
--

* in: is_ld
* in: address
* in: len (1/2/4/8)
* in: go_addr
* out: addr_ok (no exception will occur)
* out: addr_exc (exception type)
* in: exc_ack

* out: ld_data
* out: ld_data_ok
* in: ld_data_ack (acknowledge data)

ST
--

* is_st
* in: address
* in: len (1/2/4/8)
* in: go_addr
* out: addr_ok (no exception will occur)
* out: addr_exc (exception type)
* in: exc_ack

* in: st_data
* in: go_st
* out: st_data_ack

Notes
-----

* both identical up to address exception

* beyond addr_ok the operation MUST be successful.  L1 Cache, TLB etc MUST all
have been done

* after addr_ok sent, LD data can be placed as soon as ready on output bus
without requiring "permission" from a go_ld signal.

* LDSTCompUnit will wait for EITHER addr exception OR data out.

* addr_exc is acknowledged by exc_ack and both LDSTCompUnit and L0 Cache/Buffer
go back to reset.

* ld_data_ok MUST NOT be asserted if addr_exc was asserted

* ld_ack therefore acknowledges data and unit goes back to reset once sent.

* ST on the other hand must have the ADDR checking (and L1 cache line loading)
done separate from the write.

* ST therefore has two phases: addr ok (or not) followed by waiting for
permission to carry out the actual store.

* the ST data in *will* be valid at the clock where go_st is raised.

* go_st will *not* be raised by the LDSTCompUnit until *after* addr_ok/exc

* again: no exceptions can occur after the addr_ok signal is raised.

* data_ack indicates that the ST unit can reset

* the difference is that in LD Mode, the L0 Cache/Buffer is "in charge",
driving the go-ack

* however for ST this is the OPPOSITE, the LDSTCompUnit is "in charge", the
switchover point of who is in charge being after ADDR and TLB checking and
reservation of L1 Cache lines.

-- 
You are receiving this mail because:
You are on the CC list for the bug.