Skip to content

Issue 244 #245

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

Issue 244 #245

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d0f0f4f
Added details of how to handle partial encapsulation timestamps
IainCRobertson Aug 1, 2025
623cb62
Added details of how to handle partial encapsulation timestamps
IainCRobertson Aug 1, 2025
c2164ca
Added details of how to handle partial encapsulation timestamps
IainCRobertson Aug 1, 2025
7e378a8
Added details of how to handle partial encapsulation timestamps
IainCRobertson Aug 4, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions timestamping.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,3 +50,8 @@ 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.

Where packets are encapsulated according to the https://github.com/riscv-non-isa/e-trace-encap/releases/latest/[Unformatted Trace & Diagnostic Data Packet Encapsulation for RISC-V Specification], this includes provision for an optional N-byte timestamp within the encapsulation itself. This can be used to include a timestamp value with any of the trace packets defined in this specification. It is not usually desirable to include full timestamps (e.g. up to 64-bits) in each packet, as this adds a significant overhead, and the difference in timestamp values between successive packets is usually quite small. Using smaller, partial encapsulation timestamps (e.g. 16 bits) is typical.

With partial encapsulation timestamps, software can reconstruct the full timestamp value of any packet, provided that it initially receives a full timestamp (either in a sync packet, or possibly a dedicated timestamp packet), and then the interval between successive packets carrying only a partial encapsulation timestamp is less than 2^N^*8 ticks of the timestamp clock. The lower 2^N^*8 bits of the reconstructed timestamp are taken directly from the encapsulation timestamp. If the encapsulation timestamp value is smaller than the previous one, software can deduce that time has moved forward by an additional 2^N^*8 ticks, and add this to the reconstructed timestamp.

However, this reconstruction process fails if the interval between packets exceeds 2^N^*8. To prevent this, if the interval between packets does exceed 2^N^*8, the first packet sent subsequently must contain a full timestamp. This is typically a sync packet, but could be a dedicated timestamp packet. Requesting the insertion of packets containing full timestamps should be automatically managed by the packet encapsulation process.