[Libre-soc-dev] SVP64 auto-generated table for microwatt decoding

[Luke Kenneth Casson Leighton]

Paul as promised a first cut at the SVP64 decode table -
auto-generated - from the CSV files which, ha ha, were originally
created from decode1.vhdl.  links to files and context here
https://bugs.libre-soc.org/show_bug.cgi?id=586#c1
https://libre-soc.org/openpower/sv/implementation/

as i am not a VHDL expert i am "writing blind" by pattern-matching to
make a file that "looks" like it ought to.  can i possibly ask for
some help in reviewing and correcting, perhaps a "version of how it
should really look like"?

also please feel free to ask questions even "what the heck is *this*??"

some explanation of what's going on:

* sv_analysis.py was written to help identify which v3.0B instructions
could be vectorised
* they were "grouped" by register profile.  everything with 2 GPR
source 1 GPR dest in one group, etc.
* they were then "categorised" as to whether it was appropriate to
make them single-predicated, twin-predicated and how much bit-space
was available
* this information was outputted to auto-generated CSV files

so the CSV files (originally microwatt decode1.vhdl) auto-generate
*more* CSV files (which Libre-SOC uses to get the SVP64 Vector
Context) but of course with Microwatt that has to be done in VHDL
hence the simultaneous auto-generation of sv_decode.vhdl.

also as mentioned last week, Paul: in Libre-SOC we don't use "CR in =
0/1" or "CR out = 0/1" i've gone to the trouble of creating the same
Enum type that RA/RB (etc.) have, these are BFA / BA_BB / BT / CR0 /
CR1 etc. rather than have hard-coded (manual) recognition of which CR
fields to read/write i created a DecodeCRIn/Out class just like there
is a DecodeA class.

for convenience and also because they are needed (because CR fields
are *ALSO Vectorised* and extended to 128 entries) i output these two
columns (BFA/CR0/CR1) which are simply duplicates of the same columns
in LibreSOC's CSV files.  without them you'd have to do a manual
identification of SVP64 CR-extension and that would be a royal pain in
the neck.

the columns D_RT, S_RA, S_RS etc. these are to be cross-referenced
against the in1/in2/in3/out columns (and the CRin/out) to let you know
which registers should be extended from 0-31 out to 0-127 and whether
it should be treated as a Vector or not.  this is explained in "Extra
Remapped Encoding"
https://libre-soc.org/openpower/sv/svp64/

there was unfortunately not enough room (bits) to actually contain
*in* the Remapped Encoding "hey man this EXTRA field indexed 1 refers
to RA" because that would require a whopping 3-4 bits *per register*,
RA/RB/RC/RS/RT, FRA-FRT, BFA, BA, BB, BT etc. etc.

instead we have to do this trick of effectively extending
decode1.vhdl, and of it being like.... SV-X-Form extending X-Form and
so on, and so the knowledge "EXTRA field indexed 1 refers to RA" is
instead encoded *in sv_decode.vhdl*.

l.



---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68