Question About LR/SC Failure Behavior in Spike for Specific Address

[Guruprasad-r-44]

Hi everyone,

I am implementing and verifying an RV32A Atomic extension in a 5-stage pipelined RISC-V core using Spike as the reference model.
I observed a mismatch between my RTL and Spike for the following instruction sequence:

lr.w.rl zero,(tp)
sc.w.rl s7,t1,(tp)

In this case:

* Spike returns:
  s7 = 1


  indicating SC failure and suppressing the store.
* My RTL returns:
  s7 = 0

  and performs the store successfully.

However, I observed that a very similar sequence passes successfully in Spike:


lr.w.rl zero,(sp)
sc.w.rl a3,s2,(sp)


In this case:

* Spike returns success (`rd = 0`)
* Store happens correctly.

From the Spike log:

Failing case:

Address = 0x80015e94
Spike WB = 1
Store suppressed

Passing case:

Address = 0x80015d3c
Spike WB = 0
Store successful

My questions are:

1. Is this behavior expected according to the RISC-V A-extension specification?
2. Can Spike legally fail an SC instruction spuriously even when no obvious conflicting write exists?
3. Is there any address-dependent reservation invalidation behavior in Spike?
4. Does the `.rl` variant affect reservation behavior in this scenario?
5. Should RTL verification allow SC failures even without visible interference?

I understand that SC failure may be implementation-dependent, but I would like clarification on whether this specific Spike behavior is expected and spec-compliant.

Thank you.

<img width="446" height="239" alt="Image" src="https://github.com/user-attachments/assets/df38146c-4bf9-45f6-a822-dc669ec295b0" />
<img width="449" height="257" alt="Image" src="https://github.com/user-attachments/assets/2eefb7d4-929c-4962-a214-1c2247a2ba44" />

[aswaterman]

The ISA spec allows a great deal of flexibility in implementing LR/SC. Yes, this behavior is legal, and an implementation is entirely within its rights to fail an SC even if there's no obvious conflicting write. The requirement is that forward progress is eventually made in the context of constrained LR/SC loops. In the absence of conflicting writes, the SC in a constrained LR/SC loop is allowed to fail a bounded number of times before it eventually succeeds.

Spike only allows LR/SC on memory regions (i.e. not I/O). It implements an exact physical address check but does not check to make sure the size of the SC matches the size of the LR. All of this is valid.

The rl annotation doesn't do anything special in Spike.

And finally, yes, in a cosimulation situation, you'll surely need to tolerate some disagreement between Spike and your RTL. Just as Spike might fail in some situations your RTL won't, your RTL is likely to fail in some situations where Spike won't (e.g. because of speculation causing cache state transitions).

[Guruprasad-r-44]

is it normal, or i need to change the RTL code according to the spike

[Guruprasad-r-44]

I understand that Spike is the official RISC-V ISA simulator, but my doubt is: how can Spike itself go wrong?

In cosimulation, we usually treat Spike as the reference model for ISA behavior. So if there is a mismatch between Spike and RTL, how do we determine whether the issue is in the RTL or due to limitations/behavior differences in Spike?

[aswaterman]

how can Spike itself go wrong?

I see no evidence that Spike is going wrong. The ISA spec's requirement is that constrained LR/SC sequences eventually succeed, and no evidence has been presented to the contrary.

In cosimulation, we usually treat Spike as the reference model for ISA behavior. So if there is a mismatch between Spike and RTL, how do we determine whether the issue is in the RTL or due to limitations/behavior differences in Spike?

Not to be too glib about it, but welcome to the fun world of verifying processor designs. LR/SC is only one case where you'll inevitably observe differences, and it isn't even the most challenging one. Answering your question is what a lot of people spend a lot of time doing.

[Guruprasad-r-44]

While running regression on this Atomic core, I found that this is the only failing test case and all other cases are passing, so I raised this question here.

According to the spec, the SC instruction should succeed as long as the reservation address is still valid. In this failing scenario, there are consecutive load and store operations using the same memory pointer, so the store is expected to succeed. However, in Spike, the store is failing.

At this point, I am not sure how to proceed further. Should I ignore this failing scenario assuming it is an implementation-specific behavior, or should I continue debugging it as a potential issue in the core or testbench?

Could you please suggest the right approach and what checks I should do next?

[aswaterman]

As I’ve said already, I suspect both Spike’s behavior and your core’s behavior are both correct. It’s up to you to decide what to do with my assessment.

[Steven-Li-Xiaogang]

I understand that Spike is the official RISC-V ISA simulator, but my doubt is: how can Spike itself go wrong?

In cosimulation, we usually treat Spike as the reference model for ISA behavior. So if there is a mismatch between Spike and RTL, how do we determine whether the issue is in the RTL or due to limitations/behavior differences in Spike?

Spike is just one legal implementation, and it's an architecture function model, is not care about the micro-architecture.
You can't expect Spike lr/sc result as golden in co-simulation, because lr/sc is affected by the design (such as lr monitor might be broken by speculative load/store or cache probe event, and these behavior is not predictable in Spike)