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

[Paul Mackerras]

On Fri, Aug 28, 2020 at 11:50:36AM +0100, Luke Kenneth Casson Leighton wrote:

> i will need to alter the pseudocode so that it no longer has
> "undefined" behaviour, simply selecting the highest priority (one-hot)
> and always placing a value into CR. there should be no need to have a
> new field (modify section 1.6.9).
> 
> likewise the mfocrf pseudocode would need altering to ignore "if count
> = 1" and always select a one-hot.
> 
> am i right in thinking that the for-loop does not need altering?  that
> it can just be this:
> 
>     do i = 0 to 7
>       if FXM[i] = 1 then
>         n <- i
>     CR[4*n+32:4*n+35] <- (RS)[4*n+32:4*n+35]
> 
> or does it need to be:
> 
>     do i = 7 to 0       # inverted order
>       if FXM[i] = 1 then
>         n <- i
>     CR[4*n+32:4*n+35] <- (RS)[4*n+32:4*n+35]

Assuming the indexing of FXM uses big-endian bit numbering, then you
want the second version, since n will be set to the index of the last
bit that the loop sees is set, and you want that to be the most
significant set bit.

Strictly speaking you should have a test that FXM is non-zero as well,
otherwise n would be undefined.  I don't know what P9 does with
FXM=0.  The comment in microwatt's fxm_to_num implies that existing
hardware will update cr7 in that case.  Initializing n to 7 in your
pseudocode would match that behaviour.

Paul.