Issue 244

[IainCRobertson]

Draft PR with informative clarifications on partial timestamps in packet encapsulation.

[pdonahue-ventana]

Typo:

Suggested change

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. When a packet is received with a timestmap value smaller than the previous one, software can deduce that time has moved forward by an additional 2^N^*8 ticks.

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. When a packet is received with a timestamp value smaller than the previous one, software can deduce that time has moved forward by an additional 2^N^*8 ticks.

Also, I don't think that time has moved forward by an additional 2^N*8 (which is a fixed amount) but rather that bit N*8-1 overflowed. The saved value of [63:N*8] should be incremented from the previous value and then the timestamp of width N*8 should be pasted onto the bottom in bits [N*8-1:0]. (There has to be a more concise way to say this.)

[IainCRobertson]

Actually, I think all that was missing from the description was to make it explicitly clear that the bottom bits of the reconstructed timestamp are taken from the encapsulation timestamp. I've updated it, and hopefully it's clear now (and still reasonably succinct)?

[IainCRobertson]

Paul, Thanks – you are right. That is what I meant to say but failed. As you say there must be a more concise way to say it. My attempt was clearly too concise 😊. I’ll think on it and reword. Iain From: Paul Donahue ***@***.***> Sent: 01 August 2025 17:48 To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW EDA DDCP TST RD SLE EAH) ***@***.***>; Author ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] Issue 244 (PR #245) @pdonahue-ventana commented on this pull request.

________________________________ In timestamping.adoc<#245 (comment)>:

@@ -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<https://github.com/riscv-non-isa/e-trace-encap/releases/latest/%5bUnformatted> 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. When a packet is received with a timestmap value smaller than the previous one, software can deduce that time has moved forward by an additional 2^N^*8 ticks. Typo: ⬇️ Suggested change

…

-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. When a packet is received with a timestmap value smaller than the previous one, software can deduce that time has moved forward by an additional 2^N^*8 ticks. +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. When a packet is received with a timestamp value smaller than the previous one, software can deduce that time has moved forward by an additional 2^N^*8 ticks. Also, I don't think that time has moved forward by an additional 2^N8 (which is a fixed amount) but rather that bit N8-1 overflowed. The saved value of [63:N8] should be incremented from the previous value and then the timestamp of width N8 should be pasted onto the bottom in bits [N*8-1:0]. (There has to be a more concise way to say this.) — Reply to this email directly, view it on GitHub<#245 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSUN6AG3YJCOUOQTFXD3LOK4RAVCNFSM6AAAAACC4O3X26VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTANZZHEYTCMRTGI>. You are receiving this because you authored the thread.Message ID: ***@***.******@***.***>>

[bcstrongx]

LGTM