Closed viktoryou closed 1 day ago
https://github.com/riscv/riscv-isa-manual/blob/main/src/sstc.adoc?plain=1#L183 says:
When this extension is implemented and STCE in menvcfg is zero ... STIP in mip and sip reverts to its defined behavior as if this extension is not implemented.
That means that STIP goes from being a read-only value that comes from the stimecmp comparison to being a writable bit that has no relation to stimecmp. The only question is what is the state of this bit when it goes from previously being hidden to suddenly becoming visible. If this extension were controlled by misa and/or if the bit had never been written by software since reset then it would definitely be UNSPECIFIED. If STCE had previously been 0 and mip.STIP had been initialized, then STCE had been 1, then STCE becomes 0 again then I'm pretty sure that the intention is that STIP is UNSPECIFIED but I did a quick search and didn't see anything that directly says that.
Paul is correct. The spec doesn't explicitly say anything further about what the state of STIP can and cannot be after clearing STCE. So one has to assume the state is UNSPECIFIED. Ideally that would have been explicitly stated, but then again one can view clearing STCE as equivalent to coming out of reset with the extension not implemented, i.e. STIP is UNSPECIFIED.
The CSR field modulation rule addresses this case:
If a write to one CSR changes the set of legal values allowed for a field of a second CSR, then unless specified otherwise, the second CSR’s field immediately gets an UNSPECIFIED value from among its new legal values. This is true even if the field’s value before the write remains legal after the write; the value of the field may be changed in consequence of the write to the controlling CSR.
I think I'm beginning to like this rule....:-)
On Thu, Sep 12, 2024 at 12:25 PM Ved Shanbhogue @.***> wrote:
The CSR field modulation rule addresses this case:
If a write to one CSR changes the set of legal values allowed for a field of a second CSR, then unless specified otherwise, the second CSR’s field immediately gets an UNSPECIFIED value from among its new legal values. This is true even if the field’s value before the write remains legal after the write; the value of the field may be changed in consequence of the write to the controlling CSR.
— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/1636#issuecomment-2347073586, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJV43SICEITO3O3FMJLZWHTDHAVCNFSM6AAAAABOCN4G2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBXGA3TGNJYGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thanks for the help. How about changing the bit (mip.stip) from visible to hidden state? In such a case:
then the value of mip.stip is also intended to be UNSPECIFIED, according to the CSR field modulation rule, right?
Seems the answer is naturally "yes" and I would close the issue.
Take stip as an example. As the spec said, when Sstc is implemented and menvcfg.stce is set, "a supervisor timer interrupt becomes pending whenever time contains a value greater than or equal to stimecmp", also "this timer interrupt signal is cleared by writing stimecmp with a value greater than the current time value." Would a supervisor timer interrupt keep pending when menvcfg.stce gets clear? (Same question arised in virtual supervisor timer interrupt case.) That is to say,
I could not get a clear description from the spec of Sstc. Since STCE means STimecmp Enable, should a clear STCE also imply any interrupt pending relative to STimecmp register could never happen? Or the supervisor timer interrupt would keep pending until an operation of clearing mip.stip?