SPRUI30H November 2015 – May 2024 DRA745 , DRA746 , DRA750 , DRA756
The block diagram shown in Figure 8-24 is a generic example to show the main concept of SMSET. Software messages are initiated by processors. Basically, a processor is writing a message to the trace receiver through STM. SMSET is performing arbitration between hardware messages and software messages.
Software messages and system event messages can be interleaved. Software messages do not require a sequence of write accesses; therefore, the SMSET is can switch to the system event detection as soon as the event is detected.
In case of conflicting accesses between software message and detection of system events, the SMSET can switch to the system event detection as soon as the event is detected. Software messages are never lost. Therefore, an SMSET buffer allows absorbing instrumentation accesses peaks, which prevents stalling the processor originating the message.
In case of a platform implementing several SMSET instances, the priority is arbitrated by the instrumentation NoC at SoC level.
It is possible to program the sampling window size to exchange STM bandwidth for time-stamping accuracy. All the events detected within the sampling window are considered close enough and packed in the same message as concurrent events and therefore reported in the trace log with the same time stamp. In case a selected event has been captured but not yet written to the STM queue, the system event trace module shall not wait for the sampling window boundary to write the pending packet to the STM. This results in two separate messages reporting the first and second pulse of the selected event. System events are considered synchronous to the SMSET functional clock. The sampling window size granularity is one SMSET cycle. The size ranges from 1 to 256 cycles.