[Libre-soc-bugs] [Bug 583] Implement simple VL for-loop in nMigen for TestIssuer

[bugzilla-daemon at libre-soc.org]

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

--- Comment #38 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
https://libre-soc.org/irclog/%23libre-soc.2021-02-23.log.html#t2021-02-23T10:44:23

some notes:

* Fetch reads PC, MSR and SVSTATE.
  - MSR is needed to determine LE/BE of EXT01
  - SVSTATE may safely be passed to Issue

* Issue will immediately trigger Execute
  - monitoring of completion may involve
    updating (writing) of SVSTATE.srcstep
  - setvl, branch or trap NEVER involve
    a SVP64 Loop.
  - completion of execution will need
    + comparison against SVSTATE.vl
    + check if PowerDecoder2.no_out_vec
    + pc_changed or sv_changed which will
      indicate EXCEPTION
  - increment SVSTATE.srcstep WITHOUT
    needing to read it again (that was
    done in FETCH), EXCEPT if sv_changed
    because this was EXCEPTION.

* Execute *MAY* involve branch or trap or setvl
  - PC MSR and SVSTATE *may* be written
  - BUT, crucially, NEVER by an SVP64
  - therefore writing of PC or SVSTATE 
    indicates exit from loop
    (back to fetch)

basically there are two mutually exclusive situations:

1) setvl, branch or trap, any of these write to PC, MSR and SVSTATE.

  here is "Scalar Identity behaviour".
  illegal instruction if attempted to
  add an SVP64 prefix

2) everything else.

   here it is perfectly safe to read PC
   MSR and SVSTATE in FETCH FSM because
   they will never be written to.

   ISSUE can safely increment and write
   (except for an Exception, hence
    sv_changed detects that)

this will mesh well with speculative behaviour, and OoO, so we should recognise
that even in the FSM because it will guide incremental development for
pipelines and OoO.

of course only some instructions raise exceptions but we deal with that later.

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