https://lists.libre-soc.org/pipermail/libre-soc-dev/2023-September/005647.html

>> maybe we should add a test that just creates a PowerDecoder2 by itself
>> and just attempts to decode insns assembled by insndb? that way we can
>> test decoding CR fields above 8 without needing to modify the whole
>> simulator.
>
> it's a really great idea that is much more complex than that:
> PowerDecoder2 is augmented by SVP64DecodeExtra (something
> like that), you'll have to dig into the source code of
> TestIssuer to find the way the mappings actually work
> and are stitched together.

my plan is basically to copy caller.py and just keep removing stuff until we're left with only the decode stuff, I expect that won't be as hard as trying to find all the right PowerDecoder2-related classes and mushing them together...

>
> basically the prefix goes into one HDL-class-instance
> (SVP64RMDecode i think),
> the suffix into PowerDecoder-with-Regfield-filters which
> then gathers information to provide to PowerDecoder2,
> *and* then the SVP64 RM-Decode "EXTRA" information, which
> can only be decoded when the PowerDecoder tells you
> the SVP64 Mode Type (NORMAL, CROPS, BRANCH, LDSTIMM, LDSTIDX),
> can finally be *also* pushed into PowerDecoder2 and
> *only then* can you get the full 7-bit register numbers out.
> 
> it is... seriously involved and extracting it into a single
> "easy to test" unit would indeed be a quite important
> (and quite big) task all on its own.