search

chipsalliance / dromajo

RISC-V RV64GC emulator designed for RTL co-simulation
Apache License 2.0
210 stars 63 forks source link

Dromajo not raising store access fault exception on sc.d #50

Open mysoreanoop opened 2 years ago

mysoreanoop commented 2 years ago

Could be related to this issue

When executing the following test 1406, PC= 0x8000_02dc, instruction = sc.d s11, sp, (sp) Spike (and Rocket, and BlackParrot) both raise a store access fault, but Dromajo doesn't seem to be raising this exception and continues to execute subsequent instructions from which point onwards, cosimulation fails (as an exception handler jump doesn't happen). Attached are the test binary, elf, spike simulation output, dromajo output. The DUT in the bottom right in figure is BlackParrot. (But also verified compliant behavior in Rocket). Dromajo is the only output that's off out of the other 4.

Drive folder

A screenshot to make life easier (Caption in each of the 4 command lines): image

et-tommythorn commented 2 years ago

Thanks for the report. Do you happen to know why access to address 0xff..f7fe00f80 should fail? I'll try to reproduce it, but fixing this will happen sooner if you can help narrow down where the issue is.

mysoreanoop commented 2 years ago

Both Spike and BlackParrot throw store access fault at that address.

et-tommythorn commented 2 years ago

That was given already but why do they throw an access fault?

mysoreanoop commented 2 years ago

My team and I will look into it more and get back to you.

mysoreanoop commented 2 years ago

A few things to note:

  1. In the provided synthetic test case, sc.d instruction is not preceded by a complementing lr.d. Seems to me from the spec, that a dangling sc.d can progress and fail the condition -- as there's no valid reservation by the hart at the address being accessed, correct me if I'm wrong.
  2. From the spec, "For LR and SC, the A extension requires that the address held in rs1 be naturally aligned to the size of the operand (i.e., eight-byte aligned for 64-bit words and four-byte aligned for 32-bit words). If the address is not naturally aligned, an address-misaligned exception or an access-fault exception will be generated." The address being accessed, rs1=sp=0xffffffff7fe00f80, is aligned to 64 bits, so no problem here.
  3. "The access-fault exception can be generated for a memory access that would otherwise be able to complete except for the misalignment, if the misaligned access should not be emulated."
    Not entirely sure what the last part "if the misaligned access should not be emulated" means. And this could be the reason Rocket, and Spike raise a access fault.
et-tommythorn commented 1 year ago

1 and 2 are things we must fix. 3 is unclear to me too, but I suspect it has to do with LR/SC which isn't required to be supported for unaligned access (even if non-atomic memops are), thus it would be up to the implementation. I believe most implementations do not allow misalignment here.