Closed zhangdujiao closed 4 months ago
This new signal is a very recent proposal, and will require an incremental update to the trace spec. This will require at best a fast-track process and realistically will take many months to complete.
There has been discussion about this on the External Debug Security email list.
From the encoder's point of view, when this signal is high the encoder behaves exactly the same as if the halted input were high. It is recommended that if the encoder does not have this new signal that it be simply ORed into the halted input.
Iain
From: zhangdujiao @.> Sent: 29 April 2024 08:09 To: riscv-non-isa/riscv-trace-spec @.> Cc: Subscribed @.***> Subject: [riscv-non-isa/riscv-trace-spec] sec_check optional sideband signal mentioned in RISC-V External Debug Security Extension (Issue #105)
Chatpter 3.2. Trace mentioned: "The extension requires that trace availability from each hart is constrained by default. When Zedsec is supported, the optional sideband signal to trace encoder, sec_check[i] [2], must be implemented for each hart i, and this signal must be reset to 1. "
But I didn't see the optional sideband signal: sec_check[i] signal from https://github.com/riscv-non-isa/riscv-trace-spec in Chapter 4.2.3..
- Reply to this email directly, view it on GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/105, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSVNKK6O5G463XL3ZDLY7XWYHAVCNFSM6AAAAABG5YHQXSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3DQMRYG44DMMQ. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>
Thanks a lot! That is to say, sec_check sideband signal will be added to the ingress port eventually, and it may takes months to finish.
This will require at best a fast-track process and realistically will take many months to complete.