Updates 2.0.4 issue 153 #164
Conversation
payload.adoc
Outdated
| * Before the first sync packet, in order to ensure the decoder is aware of how the encoder is configured. It is recommended this be sent as soon as the encoder is enabled (*trTeEnable* changes from 0 to 1). This reduces the likelihood of having to generate two packets (support and sync-start) at the point tracing actually starts; | ||
| * When tracing ceases for any reason (*trTeEnable* set to 0, trace-off trigger, halt, reset, loss of filter qualification, etc.), in order to inform the decoder that the preceding packet reported the address of the final traced instruction; | ||
| * If one or more trace packets cannot be sent (for example, due back-pressure from the packet transport infrastructure); | ||
| * If the operating mode of the encoder changes. |
There was a problem hiding this comment.
I'm afraid that a reader might confuse "operating mode of the encoder" with the hart privilege mode. It would help to give an example such as trTeInstNoAddrDiff.
There was a problem hiding this comment.
@pdonahue-ventana that's a fair point. I have reworded.
Co-authored-by: Paul Donahue <[email protected]> Signed-off-by: IainCRobertson <[email protected]>
| * The operating mode changes; | ||
| * One or more trace packets cannot be sent (for example, due | ||
| back-pressure from the packet transport infrastructure). | ||
| * Before the first sync packet, in order to ensure the decoder is aware of how the encoder is configured. It is recommended this be sent as soon as the encoder is enabled (*trTeEnable* changes from 0 to 1). This reduces the likelihood of having to generate two packets (support and sync-start) at the point tracing actually starts; |
There was a problem hiding this comment.
This seems to change the specification. It was previously required to generate Support on trace enable but now its a recommendation. Its unclear why the clause for generating Support on operating mode is dropped.
There was a problem hiding this comment.
I don't believe it changes the spec, and it is certainly not my intention to do so. Bear in mind that when the spec was ratified, the common control spec didn't exist, and there was no trTeEnable bit defined. It was understood that there was some means of enabling the encoder but the precise mechanism was not defined. There are now several aspects to enabling: trTeEnable is the overall enable, but trTeInstTracing must also be set in order to emit any decodable trace packets (e.g. a sync-start). In the context of this section, the intended original meaning was "before any decodable trace is output" but this was not spelled out beyond "when enabled". But now that the control is defined the original wording is not sufficiently precise. What I'm attempting to do here is clarify that.
It's still mandatory to send a support packet before the first decodable trace packet (i.e. a sync-start). I'm simply recommending that it be sent as early as possible after the encoder is enabled.
Awaiting confirmation from Paul and Greg that this addresses their concerns