timestamping.tex

\chapter{Timestamping} \label{ch:timestamping}

The support for Timestamps is optional and so the contents of this chapter are informative only.


In many systems it is desirable to periodically insert a
timestamp packet into the trace stream, effectively marking that point
in the stream with a time value.

This can be used to judge "time" between various point in the trace
stream and, more notably, to be able to correlate trace streams from
different harts (i.e. this point in hart A's stream occurred at
roughly the same time as that point in hart B's trace stream).  The
former helps one to judge performance of sections of code execution
(to the granularity of timestamp insertion). The latter helps
debugging multi-hart MP problems.

An implementation may have the following: 

\begin{itemize}
\item
A timestamp is (up to) a 64-bit time value. 
\item
Configurable options for generating timestamp values such as a hart's 'time' values or 'cycle'values. 
\item
Options could may also include things like taking 'time' values with the low 4 or 8 bits dropped off which would create a coarser granularity time values
\item
Timestamp generation may be enabled or disabled.  If enabled, a
timestamp packet would be generated periodically which may be based on 
configurable interval or rate, e.g. once every 2\textsuperscript{n} items where
'n' and 'items' are configurable among some limited set of
choices. The choices could be:
\begin{itemize}
\item
Time
\item
Time scaled down. An implementation specific scaled or divided down derivative of time. This may be useful in providing a smaller coarser graularity values
\item
Time Interpolated up. An implementation specific interpolated up derivative of time. This may be useful in providing higher resolution time values
\item
Cycle
\item
Implementation specific
\end{itemize}
\item
A timestamp packet may also be generated in conjunction
with a sync packet 
\item
Timestamp packets are highly compressible and variable in size
depending on the number of low bits of the current value that have
changed wrt the last emitted timestamp value.  If timestamp packets
are emitted rarely (but not as rare as sync packets), then they will
tend to be, say, 2-4 bytes in size (still much less than the full up
to 64-bit size).  If timestamp packets are emitted somewhat
frequently, then they will tend to be 1-2 bytes in size.  If timestamp
packets are emitted very frequently, then they will tend to be <1 byte
in size.  Timestamp values associated with sync packets would always
be the full implemented size.
\end{itemize}