DRA829V: Use trace information for WCET measurement

Hello Thomas,

 

Which CPU core/s do you need to get some level of certification against?  Several cores do provide instruction trace information Cortex-M3:ITM, Cortex-R5:ETM, Cortex-A72:ETM, DSP-C7x:ProcessorTrace, DSP-C6x:Processor trace.  Trace is most commonly used in development for debugging and profiling, however, more formalized code coverage package are available from 3rd parties.  I would recommend reviewing this tool kit: https://www.lauterbach.com/frames.html?trusted_tools.html it leverages trace and comes with the necessary collateral for use certifications in avionics, medical, industrial and automotive.

 

I have used the DRA829V hardware trace in working with a customer who was developing a QNX safety-based product where WCET timing was critical.  In that instance trace was used to help verify timing and identify issues, however, it was not used in the final certification process.  However, I have heard of customers which have used trace in that phase but I am not aware of the details of that process.  As I understood the scenarios, in one instance the customer streamed the information to their PC's hard drive where after an extended run MC/DC code coverage could be shown complete, in another instance, the customer only needed to certify a narrow region of memory, and they used ETM filtering to focus capture and validation.

 

The DRA829V emits trace into small (64K) internal buffers or to an off-chip trace receiver.  The internal buffers are small and to use them often some kind of filtering is needed.  The capture size of an internal buffer is measured at the ~10mS range of instructions (depending on activity and compression).  Alternately, the trace can stream to a large many-GB receiver or stream to a hard drive (bandwidth allowing).

 

The timing resolution possible will depend on the core which needs tracing and the external receiver.  Timing information can be inserted in the stream by the cores, the trace infrastructure, and it can be also applied to bundles by the tool at the trace receiver.  To have an understanding of the timing modes it’s good to review this: https://www2.lauterbach.com/pdf/trace_arm_etm.pdf#page=81 . A lot of the standard ARM ETM information is part of their CoreSight documentation for their core.  The DRA829 trace infrastructure applies a 64bit global time stamp to packets emitted by cores, this timestamp is based on the 'GTC' IP which is typically set to 200MHz or 250MHz.  In addition to the infrastructure timestamp, a core may insert more events to allow cycle-accurate measurement of instructions.   From a user perspective, a person is able to see some events in the 10's of nS range, but there can be 'jitter' of sorts.   Information becomes more regular in the uS ranges and very regular in the mS ranges.   If this is good enough for your application really depends on what granularity your WCET is being measured against.

 

I will attach an example ETM capture taken from a DRA8xx R5 running a version of Vector's AutoSAR.  In this case, the report is a simple functional trace and one of the timing reports.  Much more detailed application-specific reports can be derived by using timing analysis packages from Vector.  I would recommend asking your SW vendor about what reports they support by default.

Regards,

Richard W.