[libre-riscv-dev] [Bug 318] fix LDSTCompUnit

[bugzilla-daemon at libre-soc.org]

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

--- Comment #7 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
On Sun, May 17, 2020 at 1:59 PM Cesar Strauss <cestrauss at gmail.com> wrote:

> I think I have enough information available, to proceed. I'm beginning
> already to have some understanding of the problem at hand.

there are *eight* possible input-combinations that the FSM has to
handle, based on:

* op: LD or ST
* mode: immediate or indexed address-calculation (termed "Effective Address")
* update: EA is to be outputted as a *SECOND* register yes/no

these 8 permutations make the FSM riiiiidiculouslly complicated and
there's really nothing that can be done about it: we need to be
compliant with POWER9 requirements.

* op LD/ST will cause the FSM to ignore operand3 if op == LD.

  this has to include *NOT* requesting operand3 (not setting rd.req[2])

  however because it is a LD, the LD data will be latched from the
  L0CacheBuffer port: thus when that happens, wr.req[0] MUST send out
  a request for the REGFILE write port.  when this is available,
  wr.go[0] will be activated for ONE cycle.

  after that one cycle, wr.req[0] MUST be dropped.

* if op == ST, operand 3 contains the value to be stored, so must be
  rd.req[2]-ested.

  however because it is a ST, there is no LD data to output, and therefore
  wr.req[0] must not be activated.

* immediate-mode will cause the FSM to use the immediate *instead* of
  operand2.

  therefore, in immediate-mode, operand2 must *NOT* be requested
  (rd.req[1] must never be set).

* update=TRUE will cause the FSM to activate wr.req[1] and wait for wr.go[1]
  when wr.go[1] is activated, this indicates to the FSM that the latched
  address (EA) in addr_o is being broadcast onto a REGFILE WRITE port.

  it will get *one* chance to do that (one cycle), and MUST drop wr.req[1]
  on the next cycle: its job is then "done"

  this is *independent* of the logic that manages / monitors the LD/ST
  Port (!)

  why? because the address computation (EA) is an independent parallel
  path from actual LD/ST


it's... just... ridiculously complicated.

at the very least if you can review it, and greatly improve the unit
tests, it would be fantastic.

as i said i *might* have got it working, 10 minutes ago, however the
complexity is so high i am not in the slightest bit confident of that,
nor of the correctness of the unit tests.

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