Relationship between time field in packet and optional 16bit timestamp in ATB encapsulation

[zhangdujiao]

Format 3 subformat 0/1/2 include the time field, witch is from the time signal of ingress port, right? For ATB encapsulation in Chapter 7, witch contains 2-byte timestamp. How to capture the 2-byte TS? from LSB of time (ingress port)? or from trTsCounterLow and trTsCounterHigh registers?

Every packets need to contain TS, so 2-byte TS is necessary. Many Thanks!

[IainCRobertson]

There are a couple of alternative options for including time: either as an optional field in format 3 packets, or as part of the overall packet encapsulation. The charter for E-trace was to define the packet payload formats only, and as such the examples in chapter 7 were illustrative only. However, subsequently the E-Trace Encapsulation TG has formalized the encapsulation, which you can find here:

https://github.com/riscv-non-isa/e-trace-encap/releases/download/v1.0.0-rc1/e-trace-encap.pdf

(this spec is in the final stages of ratification and expected to be an official spec by end of June).

I would recommend including the timestamp as part of the encapsulation, as this allows it to be included with every packet type, rather than the optional field in format 3 packets.

As to where to source the time value from, that depends. As stated in the Common Control spec, there are multiple options for time support. If there is an integrated timestamp unit with the encoder, the time value which can be read from trTsCounter* would be used. If time is sourced externally, it will be input to the encoder via the time input.

Iain

From: zhangdujiao @.> Sent: 29 May 2024 04:31 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.***> Subject: [riscv-non-isa/riscv-trace-spec] Relationship between time field in packet and optional 16bit timestamp in ATB encapsulation (Issue #111)

Format 3 subformat 0/1/2 include the time field, witch is from the time signal of ingress port, right? For ATB encapsulation in Chapter 7, witch contains 2-byte timestamp. How to capture the 2-byte TS? from LSB of time (ingress port)? or from trTsCounterLow and trTsCounterHigh registers?

Every packets need to contain TS, so 2-byte TS is necessary. Many Thanks!

- Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/111, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSSH7U2JMP5EBDHJ7Z3ZEVDW7AVCNFSM6AAAAABIOCKIACVHI2DSMVQWIX3LMV43ASLTON2WKOZSGMZDEMRXHA2DSMA. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

[zhangdujiao]

I would recommend including the timestamp as part of the encapsulation, as this allows it to be included with every packet type, rather than the optional field in format 3 packets.

Thanks Iain, Yes, this is a better choice. While we are planning to use ATB encapsulation rather than Siemens Messaging Infrastructure as shown in https://github.com/riscv-non-isa/e-trace-encap/releases/download/v1.0.0-rc1/e-trace-encap.pdf. For ATB encapsulation, it only contains "an optional 2-byte timestamp", witch may not be enough... How to solve this problem?

[zhangdujiao]

For ATB encapsulation, it only contains "an optional 2-byte timestamp", witch may not be enough...

Is there another solution? or, should we choose Siemens Messaging Infrastructure to encapsulate the packet to support larger TS

[IainCRobertson]

The encapsulation defined in the E-Trace Encapsulation spec is suitable for ATB and Siemens infrastructure. For ATB, the SrcId in the encapsulation would typically be 0-bits long (i.e. omitted) because it is carried instead by the ATID sideband signals.

Also note that the timestamp is defined as being any number of bytes in length - it is not limited to 16-bits.

Iain

From: zhangdujiao @.> Sent: 31 May 2024 04:13 To: riscv-non-isa/riscv-trace-spec @.> Cc: Robertson, Iain (DI SW ICS TST RD EAH) @.>; Comment @.> Subject: Re: [riscv-non-isa/riscv-trace-spec] Relationship between time field in packet and optional 16bit timestamp in ATB encapsulation (Issue #111)

For ATB encapsulation, it only contains "an optional 2-byte timestamp", witch may not be enough...

Is there another solution? or, should we choose Siemens Messaging Infrastructure to encapsulate the packet to support larger TS

- Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/111#issuecomment-2141158483, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSQCQ65BRDMG7YQJXZLZE7TCDAVCNFSM6AAAAABIOCKIACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBRGE2TQNBYGM. You are receiving this because you commented.Message ID: @.**@.>>