Intermittent Tracing

Brought to you by Adapticom, Inc., and Sublogic, Inc.

With the use of our tools and tracing techniques, it is not difficult to collect over 4 billion bus cycles for use in trace driven simulations. There are two techniques for increasing the quantity of data collected:

Increasing memory depth in the real-time storage device
Halting the processor/s on the Device Under Trace and other associated machines in the test bed.

In this document we will focus on the second technique. A common technique in the industry is to utilize logic analyzers to collect trace data. The obvious problem with this mechanism is that there is a relatively small amount of memory in even the most robust analyzer, resulting in only a small snapshot of bus activity to be recorded. Certainly not nearly enough to be useful in trace driven simulations. Albeit cumbersome, there is a work around for this problem; when the analyzer becomes full, it signals the DUT and via special code in the kernel of the OS, stops the processor in the DUT and all associated machines in the test bed. Then, while the DUT is halted for several minutes to an hour, the stored data in the analyzer is downloaded to another storage system and then the processor in the DUT is allowed to resume. At this time information about the OS, state of the machine, etc. can be written to the analyzer before allowing it to resume its normal activities and allowing other machines in the test bed to resume.

In some cases the information about the OS, state of the machine, and other data is so valuable, that it must be collected even if there is no other need to halt the DUT.

Such an invasive set of procedures creates numerous accuracy problems for the trace data and those will be discussed in another document. Our intent here is to outline techniques to minimize any such effects. By the use of our tools and techniques, there is no longer a need to halt the DUT. After a user defined period of time, a signal is sent to the DUT causing the machine to service a small, high priority routing which writes out the data of interest to user specified memory areas. If a large amount of data is to be written, the other clients and associated machines in the test bed can be halted to maintain their state. However, we expect empirical measurements to indicate that the amount of data written out is small enough not to warrant a halt of the clients. As a result, there is only a tiny blip of non-benchmark related activity in the trace. Furthermore, this activity is marked by a flag in the trace stream which notifies post processing software that the bus cycles are non-benchmark related special cycles. With the setting of this flag, the trace tool begins storing data from the DUT data bus which will contain the OS and machine state data of interest. When the service routine ends, normal processing resumes.

After approximately four billion or so bus cycles (dependent on memory storage device) another similar signal is sent to the DUT and associated machines. In this case all the associated machines are halted while the realtime storage system downloads its data. When the storage unit is empty, normal processing resumes. While there are definitely negative effects on trace data accuracy from halting all the machines. If such halting only occurs every four or five billion bus cycles, the effects will be minimal and the result will be relatively accurate traces of almost infinite length.

Comments to:

http://www.adapticom1.net/mailto