tdata3 availability clarification

[lbmeng]

Both current riscv-debug-stable.pdf and the old v0.13.2 release say the following about tdata3:

This register is accessible as tdata3 when type is 2, 3, 4, 5, or 6

So this means type 2 trigger can support tdata3.

But experiment on SiFive Unleashed shows that when reading tdata3 it just hangs the system.

The U54-MC core complex manual lists tdata3 as a supported CSR in chapter 12.1, but in chapter 12.2 it describes tdata3 as "Reserved" whose meaning is unclear.

Since U54-MC only implements two type 2 triggers, I suspect it does not utilize tdata3 for its functionality hence trying to read something from the type2 trigger through tdata3 will cause hardware to malfunction??

@timsifive would you confirm this hardware behavior? I believe we should clarify such in the debug spec as well.

[ernie-sifive]

I can confirm that HiFive Unleashed implements v0.13 of the debug spec and does not support any triggers that include tdata3. In 0.13, tdata3 is a WARL (optional) feature. As required by the Architecture, when a CSR is not implemented, accessing it results in an illegal instruction trap. That is not a "malfunction" or "hang". Your code must be written to accommodate illegal instruction traps during the trigger discovery process.

[lbmeng]

Thanks for the quick reply. So U54-MC manual lists tdata3 as a CSR is wrong then?

Regarding the hang behavior, we tested reading tinfo CSR which is not listed in the U54-MC manual and it can trigger the illegal instruction exception, but not with tdata3. But we will double check.

[ernie-sifive]

Again, all trigger registers are WARL. In HighFive Unleashed (circa 2017), accesses to both tinfo and tdata3 should generate illegal instruction exceptions. The U54 manual mentions tdata3 in a general section, but also mentions that the implementation conforms to v0.13 of the debug spec, wherein tdata3 is defined as optional. Anyway, an access of tdata3 in HighFive Unleashed will result in an illegal instruction exception and it is up to the discovery code to handle that.

[pdonahue-ventana]

This wasn't my understanding. It says that tdata3 is "optional if no implemented triggers use it" which means it might or might not trap if no triggers use it. Otherwise I thought it must be implemented. There's nothing indicating that accesses to tdata1/2/3 trap based on the value of tselect. I think it comes down to whether you consider that the CSR access is to a singular tdata3 (which is implemented and thus mustn't trap and which has the effect of accessing some underlying state) or if the CSR access is to the underlying state (which is not implemented and thus must trap). My assumption (based on the fact that it's not required to trap if there are no triggers that implement it) was the former and that triggers that don't have textra would treat it as WARL which essentially means tied to 0. Same for tdata2 on triggers that only support icount.

[lbmeng]

Is there a way to know which trigger implements tdata3 except the way of trying to read and checking the exception type after?

Say if tdata3 is optional for an implemented type 2 trigger, the software needs to not rely on such optional trigger functionality to provide the debug support.

[lbmeng]

This wasn't my understanding. It says that tdata3 is "optional if no implemented triggers use it" which means it might or might not trap if no triggers use it. Otherwise I thought it must be implemented. There's nothing indicating that accesses to tdata1/2/3 trap based on the value of tselect. I think it comes down to whether you consider that the CSR access is to a singular tdata3 (which is implemented and thus mustn't trap and which has the effect of accessing some underlying state) or if the CSR access is to the underlying state (which is not implemented and thus must trap). My assumption (based on the fact that it's not required to trap if there are no triggers that implement it) was the former and that triggers that don't have textra would treat it as WARL which essentially means tied to 0. Same for tdata2 on triggers that only support icount.

Yep, my understanding is the same as you. Current spec is unclear about this.

Say if a type 2 trigger does not implement tdata3 but a type 3 trigger implements tdata3, accessing tdata3 for the type 2 trigger via tselect will trap but it won't for the type 3 trigger ???

If it is confirmed that the hardware should really behave like this way that the tdata3 is an indirect access window to the underlying real register of the trigger selected by tselect, such should be clarified.

At least the U54-MC manual makes me believe it is not like this way.

[pdonahue-ventana]

If it is confirmed that the hardware should really behave like this way that the tdata3 is an indirect access window to the underlying real register of the trigger selected by tselect, such should be clarified.

tdata3 is definitely an indirect access window to the underlying real register of the trigger selected by tselect.

I've been thinking recently that one reason that it took me so long to understand the TM is that mcontrol, mcontrol6, icount, itrigger, etrigger, tmexttrigger are really CSR formats but not actual CSRs (though the spec says that they are CSRs). You could have a trigger where tdata1 supports multiple formats (e.g. tdata1 with the same tselect behaves like both mcontrol and etrigger). And you can have more than one trigger that supports a particular format (so mcontrol certainly isn't "a" CSR). And textra32 and textra64 are also formats but are similarly not "a" CSR.

[lbmeng]

I've been thinking recently that one reason that it took me so long to understand the TM is that mcontrol, mcontrol6, icount, itrigger, etrigger, tmexttrigger are really CSR formats but not actual CSRs (though the spec says that they are CSRs). You could have a trigger where tdata1 supports multiple formats (e.g. tdata1 with the same tselect behaves like both mcontrol and etrigger). And you can have more than one trigger that supports a particular format (so mcontrol certainly isn't "a" CSR). And textra32 and textra64 are also formats but are similarly not "a" CSR.

Yep, so I think it's worth clarifying in the spec.

One more thing, if the type 2 trigger never uses tdata3, should we update the spec to remove mentioning tdata3 for type 2 trigger?

[pdonahue-ventana]

It's not that it "never" uses tdata3, it's just that SiFive chose not to. Trigger type 2 is allowed to have tdata3. But none of the triggers that are allowed to have tdata3 are required to do so. As the top of the chapter says, pretty much everything is optional.

[timsifive]

Looks like the only way to discover whether tdata3 is implemented is to try and access it. If it's not implemented, you might get an exception which you'll have to catch. If/when we ever get a configuration structure then this information can be in the debug schema. (I thought this was complete, but this particular information appears to be lacking.)

[timsifive]

So we need some language that makes it clear that trigger CSRs are really windows into underlying trigger registers. If a window is needed, then it's WARL. If a window isn't needed then accessing the CSR may trap.