Click or drag to resize

15 TraceBuffer Configuration and Usage

The SP-ICE-3 Card's TraceBuffer facility provides the means to selectively enable recording of a variety of TraceEvents which occur in the card's firmware and hardware.

The events which can be recorded include scanner positions and state-changes for signals generated or detected by the card.

The recorded events may be used, for instance, to analyse the performance or integrity of an end-user application.

Lists of recorded events can be retrieved from the card's firmware, via appropriate calls to the TraceBufferClient API, by a client program running on a Host-PC.

  • Although the card allows the individual event sources for the TraceBuffer to be selectively enabled as and when required, large amounts of event data may still be generated.

    To mitigate the impact of event data collection on jobs being processed by the card's firmware, the card runs an independent TraceBuffer-Server with a lower process priority than that of the rest of the firmware.

    Client applications on the Host-PC should use the SP-ICE-3 TraceBufferLib (which is independent of the SP-ICE-3 ClientLib) to interact with the TraceBuffer-Server.

Event Timestamp

Every recorded TraceEvent contains a 56 bit timestamp field with a resolution of 15.625ns (1/64MHz).

The timestamp clock is reset to zero whenever the card is (re-)booted, but it will only overflow after about 35 years of continuous operation.

TraceBuffer-Server Overhead on the Card

The TraceBuffer on the SP-ICE-3 Card is enabled whenever at least one TraceEventType is specified in the active TraceBufferConfig.

  • When the TraceBuffer-Server is streaming events to the client, the creation of each individual event record requires some work by the card's CPU, so there is a certain overhead associated with active use of the TraceBuffer, which may degrade the ultimate command processing performance of the SP-ICE-3 Card's firmware.

  • Consequently, we strongly recommend that your application makes use of Stop and Start, to ensure that the TraceBuffer overhead is only incurred when absolutely necessary.

    This will also help to prevent unnecessary network traffic between the TraceBuffer-Server (on the card) and the TraceBufferClient (on the Host-PC), because the server's output stream is also stopped and started by these APIs.

See Also