[Libre-soc-bugs] [Bug 588] add SVP64 to PowerDecoder2

[bugzilla-daemon at libre-soc.org]

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

--- Comment #7 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Cesar Strauss from comment #5)

> Or, will it be split in two stages, so you first decode the prefix (if any),
> then you take the result and use it to post-process the result of the scalar
> decoder?

first thing: identify the prefix using this:
https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=9cc04f05fff07d38c685614190007e107ee8b891

then if that is successfully identified as an svp64 instruction, pass in
the next 32 bits *and* the 24-bit ReMap into PowerDecoder2.

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/decoder/power_decoder2.py;h=2f6c0bdec572db0ab605e83087ec7b72758e704c;hb=9cc04f05fff07d38c685614190007e107ee8b891#l793

now, in theory this could be done in 1 clock cycle, with some MUXes. but for
the FSM it is perfectly fine to take more.

note however:

* the SVP64PowerDecoder2 is used in the *first* FSM (simply to identify
  "is this instruction 32 or 64 bit").

  - if it identifies an svp64 prefix it stores the 24-bit ReMap field
    in a latch, then reads *another* 32 bits

* PowerDecoder2 is used in the *second* FSM, receiving zero in the RM
  field if the *first* FSM identified a 32-bit operation.

first FSM reads from instruction fetch and identifies length.

second FSM does decode-and-execute *only*.


but, long before that is done, the split into two FSMs, and processing of
32-bit instructions *only*, must be carried out.  no involvement of svp64 at
all.

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