Clarify effect of tdata1 write with zero when only one trigger type supported

[JamesKenneyImperas]

Section 5.7.2 says (about tdata1):

Writing 0 to this register must result in a trigger that is disabled. If this trigger supports multiple types, then the hardware should disable it by changing type to 15

If the trigger doesn't support multiple types, can you clarify how this should work? Does the observed value of the trigger change because of this write? Is there a hidden disabled bit associated with it? Can software tell whether a trigger is active or disabled by reading the tdata1 value?

Thanks.

[pdonahue-ventana]

If you write 0 to tdata1 and, for instance, it's hardwired to type=6 (mcontrol6) then you end up writing 0 to bits m, s, u, vs, vu which disables the trigger in all modes, thereby disabling the trigger and complying with that sentence. The same is true for all of the other standard types (either disabling all modes or disabling all external triggers).

[JamesKenneyImperas]

Ok, but is it your expectation that this is true only for the special value zero as a whole? For example, if the written value was all zeroes except for a single non-zero bit (in the m field position, say) then what would happen?

Normally I would expect the legality of a write as a whole to be conditioned by the trigger type, because this obviously determines what the field positions mean. Therefore, if the trigger type is unsupported, I would expect the entire write to be rejected. So this case is special because the type zero write is not rejected.

Thanks.

[JamesKenneyImperas]

Also, in some implementations we have seen the mode bits such as the m bit are not writeable. This is very typical in machines that only support M mode. What happens then?

[JamesKenneyImperas]

I think the behavior should be described explicitly. Is it this:

For a write of 0 to tdata1 when trigger type 15 is not supported, the effect is to preserve the current trigger type and set all other writeable bits for that type to zero.

Thanks.

[pdonahue-ventana]

Ok, but is it your expectation that this is true only for the special value zero as a whole? For example, if the written value was all zeroes except for a single non-zero bit (in the m field position, say) then what would happen?

As with all WARL registers, if you have a mcontrol6-only trigger and you write type=0 and m=1 then it will turn type into the only legal value of 6 and it will write m=1 because that was a legal value.

Normally I would expect the legality of a write as a whole to be conditioned by the trigger type, because this obviously determines what the field positions mean. Therefore, if the trigger type is unsupported, I would expect the entire write to be rejected. So this case is special because the type zero write is not rejected.

That isn't how WARL normally works. You're allowed to write any value and it must return a legal value on subsequent reads. If the only legal value is type=6 then writing type=0 will cause type=6 to be seen on subsequent reads. Furthermore, if the only legal value is type=6 then the field locations are predetermined so if you write 0x00000001 then you'll end up with type=6 and load=1. Whether the software knows how to parse the fields that it's writing doesn't matter. The hardware register (or the register object in the case of a simulator) that's being written knows how to parse those fields and knows what's writable, what's legal, etc.

Also, in some implementations we have seen the mode bits such as the m bit are not writeable. This is very typical in machines that only support M mode. What happens then?

If m is hardwired to 0 and only M mode is supported then this trigger seems useless because it can never fire. If m is hardwired to 1 then I don't think that it complies with the reset value in the spec. But if we ignore that fact for a minute, it would still work for mcontrol6 because writing all 0 would set execute=load=store=0 which would prevent the trigger from firing. I think that any implementation would have to allow writing the m bit in icount because there is no secondary way to disable icount (and because of the reset value thing).

I think the behavior should be described explicitly. Is it this:
For a write of 0 to tdata1 when trigger type 15 is not supported, the effect is to preserve the current trigger type and set all other writeable bits for that type to zero.

That's probably true if type is hardwired (which is the common case). But if the set of legal types is {3,6} then it's not true.

My expectation is that the hardware looks at the type field in the write data. If writedata.type is a legal value then it writes that value to trigger[x].type. If writedata.type is not a legal value then it picks a legal value (WARL) and writes that to trigger[x].type (and there may only be one legal value). The rest of the bits of writedata are parsed based on the value that was just written to trigger[x].type.

In the {3,6} example, if you write 0 then it depends on the WARL logic. It might end up as a icount trigger with 0 in m,s,u,vs,vu,pending,count,etc. Or it might end up as a mcontrol6 trigger with 0 in m,s,u,vs,vu,load,store,execute,etc.