When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address.  However, the spec also says:

  Implementations may convert some invalid address patterns into other invalid addresses prior to writing them to xTVAL.

The purpose of this statement is to allow implementations to reduce the number of xTVAL storage bits when addresses are smaller than XLEN.  (If your implementation implements all XLEN bits of mtval, this point is moot, and you can skip to the last paragraph.)

We propose to constrain this behavior to simplify the task of compliance-testing the xTVAL registers.  In particular, allowing implementations to arbitrarily convert any invalid address to any other invalid address is impractical to test.

Some implementations, including the Rocket core, make xTVAL a two's complement value that's just 1-bit wider than the largest virtual address.  This allows xTVAL to represent all valid virtual addresses with the minimal number of physical storage bits, yet still allows it to distinguish properly sign-extended VAs from improperly sign-extended VAs.  

The scheme replaces improperly sign-extended bits with the inverse of a properly signed address[VA] bit. Or (in pseudo code):

  xTVAL[XLEN-1:VASIZE] = (address[XLEN-1:VASIZE] == sign_extend( address[VASIZE-1]))

    ?    sign_extend(address[VASIZE-1]

    :   ~sign_extend(address[VASIZE-1]; 

 The effect of this scheme is that valid virtual addresses are always preserved, whereas invalid virtual addresses always remain invalid, even though their MSBs are discarded.

We are proposing to restrict xTVAL implementations with fewer than XLEN physical storage bits to support only this invalid address conversion scheme.

-->   If your implementation conforms to this scheme, or if your xTVAL register can represent all XLEN bits unconditionally,  please select (reply with X following) "Yes."  

-->  If your implementation doesn't conform to this scheme, but still conforms to the ISA spec, please select (reply with X following) "No", and carefully explain in the comments field how your implementation recodes invalid addresses.  

"No" responses without a sufficient explanation in the comments will not be considered.

Yes: ___ (our implementation conforms to this constraint or implements XLEN bits)

No:  ___ (our implementation is ISA compliant but doesn't conform to this constraint)

Comment (if you select "no" above):