- Update the trace description by removing the interface signal details

[AoteJin]

Per issue #48

[IainCRobertson]

mtrcen is another signal. I thought the intent was to remove references to signals and focus on the behavioural requirements (hence removing references to sec_check). How is mtrcen supposed to be controlled? This is what should be described in my view.

[AoteJin]

The spec defines the mtrcen to indicate that the M-mode trace capability is granted by higher-privileged entity than M-mode SW (e.g. a fuse or BROM to toggle the signal and lock it). To avoid ambiguity, we explicitly name the signal. I will add a note to describe how it is controlled, as you suggested.

[bcstrongx]

This is a good point by Iain. Is there a requirement that the hart implements this mtrcen signal interface, or does there just need to be a way to disable tracing in M-mode? When I look at the RV debug spec, it never specifies a haltreq signal from the DM to the hart, it could instead be transported by a bus request, or something else. Those are implementation details. In this case, mtrcen could be established via a handshake between the hart and the RoT, rather than via a wire routed to each hart, right? Obviously all of this would apply to mdbgen too.

Also, there's a typo:

controls the availability of M-mode tracing

[AoteJin]

Correct, the intention here is not to define an interface, but rather to explicitly highlight that the debug/trace capability of M-mode is provided by the RoT. I agree that this could potentially be broadcasted via a protocol, depending on the implementation. The key point is to convey this idea in a straightforward manner, similar to how MEIP/SEIP interrupts are described. By using terms like "signal" or "port," the reader can easily visualize the concept.
What do you think about adding a non-normative description to explain how this is controlled and how it might be implemented differently up to the HW choice?

[bcstrongx]

I would suggest replacing line 99 with something like:

Each hart will add a new state element, mtrcen, which controls the availability M-mode tracing. mtrcen may be controlled via a new input port to the hart, or by handshake with the system Root of Trust, or by other methods. Setting mtrcen to 1 enables trace for both M-mode and the supervisor domain. Conversely, setting mtrcen to 0 disables trace output when hart i is running in M-mode.

The same could be done for mdbgen. This allows using these m*en names to simplify references to the enables, without appearing to dictate the implementation.

[AoteJin]

Thanks for the suggestion. I updated it accordingly in latest commit below.

[bcstrongx]

One nit (a mistake in my suggested text), I would replace "hart i is running" with "the hart is". And the "Conversely, " seems unnecessary. Otherwise all looks good!

[AoteJin]

Thanks for pointing it out. Updated and merging