From d0f0f4f3f947ab94823548745d255a8edec279d5 Mon Sep 17 00:00:00 2001 From: Iain Robertson Date: Fri, 1 Aug 2025 12:04:25 +0100 Subject: [PATCH 1/4] Added details of how to handle partial encapsulation timestamps --- timestamping.adoc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/timestamping.adoc b/timestamping.adoc index 6b15694..8c13781 100644 --- a/timestamping.adoc +++ b/timestamping.adoc @@ -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. 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. + +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. \ No newline at end of file From 623cb62aaaba47b5cb4d72b09ede7f6ebe8f231d Mon Sep 17 00:00:00 2001 From: Iain Robertson Date: Fri, 1 Aug 2025 12:08:48 +0100 Subject: [PATCH 2/4] Added details of how to handle partial encapsulation timestamps --- timestamping.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/timestamping.adoc b/timestamping.adoc index 8c13781..d2b7c71 100644 --- a/timestamping.adoc +++ b/timestamping.adoc @@ -54,4 +54,4 @@ Where packets are encapsulated according to the https://github.com/riscv-non-isa 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. -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. \ No newline at end of file +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 contianing full timestamps should be automatically managed by the packet encapsulation process. \ No newline at end of file From c2164cafe005f6073d1c5ba17e24346c0787ccc2 Mon Sep 17 00:00:00 2001 From: Iain Robertson Date: Fri, 1 Aug 2025 12:09:22 +0100 Subject: [PATCH 3/4] Added details of how to handle partial encapsulation timestamps --- timestamping.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/timestamping.adoc b/timestamping.adoc index d2b7c71..29d2cae 100644 --- a/timestamping.adoc +++ b/timestamping.adoc @@ -54,4 +54,4 @@ Where packets are encapsulated according to the https://github.com/riscv-non-isa 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. -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 contianing full timestamps should be automatically managed by the packet encapsulation process. \ No newline at end of file +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. \ No newline at end of file From 7e378a8da5dc2b97ac4ff3eade9eb599e2aeae94 Mon Sep 17 00:00:00 2001 From: Iain Robertson Date: Mon, 4 Aug 2025 10:13:19 +0100 Subject: [PATCH 4/4] Added details of how to handle partial encapsulation timestamps --- timestamping.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/timestamping.adoc b/timestamping.adoc index 29d2cae..62f0303 100644 --- a/timestamping.adoc +++ b/timestamping.adoc @@ -52,6 +52,6 @@ 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. 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. 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. \ No newline at end of file