[Libre-soc-dev] [OpenPOWER-HDL-Cores] mfocr and mtocrf v3.0B spec ambiguity

[Luke Kenneth Casson Leighton]

got it, paul :)

firstly i apologise that it took several re-readings of
cr_helpers.vhdl to spot that fxm_to_num is a completely different
function from num_to_fxm.

it was only after i found an actual instruction in tests/1.bin that
had a zero value for FXM that i finally noticed

this command gives the dump file:
powerpc64le-linux-gnu-objdump --disassemble-zeroes
--architecture=powerpc:common64 -M power9,64,any,raw -D -b binary -EL
1.bin > 1.dump

then instruction at address 0x14928 is the mtocrf with FXM=0:
# mtocrf 0,16     14928:   21 09 10 7e     .long 0x7e100921

(that instruction has to be decoded by hand because bit 31 is set,
making objdump unhappy with it).

here's the relevant output from microwatt when running core_tb:

cr_file.vhdl:64:17:@341565ns:(report note): Writing 30000000 to CR
mask 80 3F089F7F
register_file.vhdl:69:13:@342935ns:(report note): Reading GPR 10
000000000001C020
cr_file.vhdl:64:17:@343015ns:(report note): Writing 0001C020 to CR
mask 01 3F089F70

all good, there:

* initial value of CR going into "mtocrf 0,16" is 0x3f089f7f
* register 16's value is 0x1c020
* FXM is zero therefore the "mask" is set to 01 (representing CR7)
* therefore the least significant nibble of CR is set to zero

so we have several things confirmed, here:

* the pseudocode you helped me with last week for mfocr is confirmed
functional (even when FXM=0)
* microwatt concurs with that pseudocode
* so does libresoc

the only thing really left on the list - just to be absolutely sure -
is to run "mtocrf 0,16" on an IBM POWER9 machine.

l.