Bug 1163

Summary: add unit tests for PowerDecoder2 that check that it decodes all the stuff the same way insndb encodes it
Product: Libre-SOC's first SoC Reporter: Jacob Lifshay <programmerjake>
Component: Source CodeAssignee: Jacob Lifshay <programmerjake>
Status: CONFIRMED ---    
Severity: enhancement CC: libre-soc-bugs, lkcl, programmerjake
Priority: ---    
Version: unspecified   
Hardware: PC   
OS: Linux   
See Also: https://bugs.libre-soc.org/show_bug.cgi?id=1161
NLnet milestone: --- total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0 parent task for budget allocation:
child tasks for budget allocation: The table of payments (in EUR) for this task; TOML format:

Description Jacob Lifshay 2023-09-18 20:52:35 BST 
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.