search

riscv-non-isa / riscv-trace-spec

RISC-V Processor Trace Specification
https://jira.riscv.org/browse/RVG-88
Creative Commons Attribution 4.0 International
152 stars 47 forks source link

1st qualified definition #124

Closed zhangdujiao closed 1 month ago

zhangdujiao commented 2 months ago

For figure 9.1, "qualified" means an inst. that meets the filtering criteria is qualified, and will be traced. In the actual implementation, can qualified be regarded as trace_on = 1?

trace_on = trTeActive && trTeEnable && trTeInstTracing && (!sec_check) && qualified

which trTeActive, trTeEnable and trTeInstTracing are configured by reg, sec_check is defined by 《RISC-V External Secure Debug v1.0》, qualified is derived from filter as defined above.

Can "1st qualified" can be regarded as trace_on 0->1?

IainCRobertson commented 2 months ago

Yes, if there is no filtering support, if filtering is disabled, or when filtering is enabled, if the first instruction for which trace_on is matches the filtering criteria.

Iain

From: zhangdujiao @.> Sent: 25 June 2024 10:10 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.***> Subject: [riscv-non-isa/riscv-trace-spec] 1st qualified definition (Issue #124)

For figure 9.1, "qualified" means an inst. that meets the filtering criteria is qualified, and will be traced. In the actual implementation, can qualified be regarded as trace_on = 1?

trace_on = trTeActive && trTeEnable && trTeInstTracing && (!sec_check) && qualified which trTeActive, trTeEnable and trTeInstTracing are configured by reg, sec_check is defined by 《RISC-V External Secure Debug v1.0》, qualified is derived from filter as defined above.

Can "1st qualified" can be regarded as trace_on 0->1?

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

zhangdujiao commented 2 months ago

What if the instruction flow (t0~t3) below: t0: unqualified t1: qualified t2: unqualified t3: qualified Can both t1 and t3 be regarded as 1st qualified?

IainCRobertson commented 2 months ago

The support packet with qual_status = 0, reporting which trace features are enabled should be sent prior to the sync-start packet resulting from t1. The spec doesn't say rexactly when but I would recommend sending it as soon as trace is enabled.

A support with qualstatus = ended* should be sent after the format 1 / 2 reporting the final traced instruction at t2.

There is no need to send a support packet associated with t3. The triggering conditions are:

Iain

From: zhangdujiao @.> Sent: 27 June 2024 03:12 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] 1st qualified definition (Issue #124)

What if the instruction flow (t0~t3) below: t0: unqualified t1: qualified t2: unqualified t3: qualified Can both t1 and t3 be regarded as 1st qualified?

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

zhangdujiao commented 2 months ago

thanks! Which made me clear on support packet trigger condition. I am still confused on 1st qualified definition. For the trace on/off is controlled by filter simply, each time unqualified causes trace off, could the next qualified be considered as 1st qualified? and send the sync-start packet.

There is no need to send support packet and sync-start at t3?

There is no need to send a support packet associated with t3.

IainCRobertson commented 2 months ago

It simply means when tracing starts: instruction X is traced but instruction X-1 was not. The objective is to give the decoder all the information it needs to be able to start decoding the trace.

Iain

From: zhangdujiao @.> Sent: 28 June 2024 02:35 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] 1st qualified definition (Issue #124)

thanks! Which made me clear on support packet trigger condition. I am still confused on 1st qualified definition. For the trace on/off is controlled by filter simply, each time unqualified causes trace off, could the next qualified be considered as 1st qualified? and send the sync-start packet.

There is no need to send support packet and sync-start at t3?

There is no need to send a support packet associated with t3.

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

zhangdujiao commented 2 months ago

t0: unqualified t1: qualified t2: unqualified t3: qualified

so for this condition, t1 will issue support and sync-start, t2 will issue support due to trace off, and t3 will issue support and sync-start, am I right?

IainCRobertson commented 2 months ago

You could do this, but it's not quite what I would do. The point of the support packet is for two purposes:

A support packet is not required to tell the decoder that tracing has started - the sync-start or sync-trap does this. With this in mind, in your sequence, what is required is:

Iain

From: zhangdujiao @.> Sent: 29 June 2024 03:07 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] 1st qualified definition (Issue #124)

t0: unqualified t1: qualified t2: unqualified t3: qualified

so for this condition, t1 will issue support and sync-start, t2 will issue support due to trace off, and t3 will issue support and sync-start, am I right?

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

zhangdujiao commented 2 months ago
  • t3: no support is needed here. It's harmless, and allowed by the standard, but is a waste of bandwidth in my view.

OK I got it, the support packet only issues when the configuration of encoder is changed or trace has ended. Could TE issue sync-start at t3? since trace-off at t2 and trace-on at t3

IainCRobertson commented 2 months ago

Yes, it must issue sync-start or sync-trap at t3.

Iain

From: zhangdujiao @.> Sent: 01 July 2024 11:20 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] 1st qualified definition (Issue #124)

OK I got it, the support packet only issues when the configuration of encoder is changed or trace has ended. Could TE issue sync-start at t3? since trace-off at t2 and trace-on at t3

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

zhangdujiao commented 2 months ago

got it, many thanks!

zhangdujiao commented 1 month ago
  • Tracing ends Trace is lost The trace encoder is enabled * The trace encoder configuration changes (and it is enabled after the change)

Is the "The trace encoder is enabled" condition reasonable? trace_enable = trTeActive && trTeEnable && trTeInstTracing, which the "(!sec_check) && qualified" are not included.

For the "Tracing ends", Is the following definition reasonable? tracing end means (!trace_on), trace_on = trTeActive && trTeEnable && trTeInstTracing && (!sec_check) && qualified

IainCRobertson commented 1 month ago

See inline

Iain

From: zhangdujiao @.> Sent: 25 July 2024 07:57 To: riscv-non-isa/riscv-trace-spec @.> Cc: Robertson, Iain (DI SW ICS DDCP TST RD EAH) @.>; Comment @.> Subject: Re: [riscv-non-isa/riscv-trace-spec] 1st qualified definition (Issue #124)

Is the "The trace encoder is enabled" condition reasonable? trace_enable = trTeActive && trTeEnable && trTeInstTracing, which the "(!sec_check) && qualified" are not included.

[Iain] In my view the definition is correct. It's reasonable to send this packet as soon as the Trace Encoder is capable of outputting trace, even if it is not yet doing so because of the filtering conditions (i.e. not qualified). The purpose of this packet is to give the decoder the information it needs to correctly configure the decoder (which optional modes are enabled). The sync-start packet will indicate when tracing actually starts.

For the "Tracing ends", Is the following definition reasonable? tracing end means (!trace_on), trace_on = trTeActive && trTeEnable && trTeInstTracing && (!sec_check) && qualified

[Iain] Yes. I view sec_check as being factored into qualified so doesn't need to be called out explicitly in this statement. Halted is also factored into qualified. The important thing here is to tell the decoder that tracing has stopped and the final traced instruction has been reported.

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

zhangdujiao commented 1 month ago

Tracing ends

From the spec, the support packet is issued when: -trace is enabled or disabled etc. Trace is enable can be defined by trace_enable = trTeActive && trTeEnable && trTeInstTracing. That is to say support will be issued even when secure check has not passed. Should !sec_check be added to trace_enable?

IainCRobertson commented 1 month ago

Yes, but updating to include this will be handled as part of the ratification process for the Sdsec ISA extension.

Iain

From: zhangdujiao @.> Sent: 29 July 2024 08:57 To: riscv-non-isa/riscv-trace-spec @.> Cc: Robertson, Iain (DI SW ICS DDCP TST RD EAH) @.>; Comment @.> Subject: Re: [riscv-non-isa/riscv-trace-spec] 1st qualified definition (Issue #124)

Tracing ends

From the spec, the support packet is issued when: -trace is enabled or disabled etc. Trace is enable can be defined by trace_enable = trTeActive && trTeEnable && trTeInstTracing. That is to say support will be issued even when secure check has not passed. Should !sec_check be added to trace_enable?

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