The first 32-bit word of a HLTM message contains the header and the remainder of the HLTM is the function specific trace data from the source. The end of the HLTM is defined when the source asserts the last data payload word on the VBUSP slave. The maximum number of 32-bit data payload words allowed in a HLTM is 31.
Figure 13-3 shows the HLTM format.
The HLTM header is defined by the following fields:
- [31-16] Time
- Corresponds to the 16 LSBs of the global debug time, captured by the trace source when the HLTM was created
- These LSBs are combined with the current global debug time that aggregator has sampled
- If a time-stamp is requested (via TS field), the resultant 48-bit time is presented to the STP format and export logic when the last data of the HLTM is transferred
- This field is valid for any HLTM, even HLTMs with Err or Overflow
- [15-9] MsgType
- The trace source uses this field to designate which type of HLTM is being transferred
- The mapping is specific to the type of trace source and up to 128 different message types can be supported
- The value in this field is presented to the STP format and export logic for every transfer cycle associated with this HLTM
- This field is valid for any HLTM, even HLTMs with Err or Overflow asserted
- [8-6] Master
- The trace source uses this field to designate a hierarchical master space
- This field is only useful when the trace source sits behind a second level of trace source merge
- The value in this field is combined with the port number in to create an 8-bit master identifier. The resultant master value is presented to the STP format and export logic for every transfer cycle associated with this HLTM
- This field is valid for any HLTM, even HLTMs with Err or Overflow asserted.
- [5-4] Rsvd: Reserved
- [3] TS
- The trace source sets this bit if it wants to associate a global debug time with the encoded HLTM
- If set, a 48-bit time will be constructed (see Time field). This value is presented to the message interface on the STP format and export logic. The time-stamped data request is made when the last data of the TLTM is passed to the STP format and export logic
- If TS is 0, then no TS reconstruction is required
- This field is valid for any HLTM, even HLTMs with Err or Overflow asserted.
- [2] Overflow
- The trace source sets this bit to indicate that some data loss has occurred in the source, but the error is recoverable
- Any data associated with this HLTM is discarded and a MERR message is stimulated from the STP format and export logic
- The trace source may send subsequent data after an HLTM with Overflow set. These will be processed normally, and the decode SW in the tooling should consider messages received after the MERR to be valid
- Err and Overflow shall never be asserted in the same HLTM. Behavior is undefined in this scenario
- [1] Err
- The trace source sets this bit to indicate that a fatal error has occurred in the trace source
- Any data associated with this HLTM is discarded before forwarding to STP format and export logic and a FLAG or FLAG_TS message is stimulated from the STP format and export logic
- The trace source may send subsequent data after an HLTM with Err set. These will be processed normally, but the decode SW in the tooling may choose to ignore them since a fatal error has been flagged
- Err and Overflow shall never be asserted in the same HLTM. Behavior is undefined in this scenario
- [0] Final
- The trace source sets this to indicate that this HLTM is the final data associated with an outstanding flush request
- The STP glue logic will then assert a flush request to the message interface of the STP format and export logic when the final data word of the last pre-flush HLTM (from all sources) is transferred across this interface
- Final is valid for any HLTM, even HLTMs with Err or Overflow asserted