Change the reference model to one that supports misaligned lw/sw

[aignacio]

Hey guys,

thanks for nice work with RISCOF framework!, I'd like ask you if there's a way to use spike isa-sim or another RV simulator as a reference model that supports misaligned lw/sw. I discovered recently that there's a way to enable misaligned support on Sail RISC-V C-simulator but the problem is that it seems to not be fully working as per ticket down below. If there's an alternative for it'd be really great.

https://github.com/riscv/sail-riscv/issues/156

I've attached my report to show that only misaligned-sw are currently failing with this model.... report.html.zip

[neelgala]

in the config.ini you can use spike_parallel as the reference plugin and it should generate the reference signatures. Let me know if that fails.

[pawks]

You will also have to modify this line to add the necessary argument which enables hw misaligned accesses.

[aignacio]

Thanks @neelgala and @pawks,

@pawks you mean adding --enable-misaligned to the line you mentioned?

[pawks]

Thanks @neelgala and @pawks,

@pawks you mean adding --enable-misaligned to the line you mentioned?

Yes.

[neelgala]

I think you will need to re-build spike while configuring with --enable-misaligned. I don't see a cli arg to enable misaligned.

[neelgala]

you may need to specify ispec and psec which could just be copied from lines 11 and 12 - they will be ignored by spike when cofigured as reference model.

[aignacio]

Thanks @neelgala,

just discovered that spike needs to be rebuild with --enable-misaligned but you don't need to specify any runtime option in the python scripts, once it's compiled with the argument. I re-run my tests using spike-parallel and I'm observing the same signature of the sail c simulator. Could you help me to explain how this test can generate such signature like for instance the line 0000be00 instead of 0000beef?

[pawks]

The 00 you see at the start of the line is infact the last byte of the store from the previous word. Let us consider the instruction 80000138, it is a sw instruction with the address 80002216. So it should modify bytes 80002216 through 8000221b, which is infact the 2 bytes to the left on line 3. This particular store can also be looked at as a sequence of instructions which generate the same result.

  sh a1,2047(a0)
  addi a0,a0,2
  srli a1,a1,16
  sh a1,2047(a0)

It looks like your implementation is not updating the bytes of the next word in case of a misaligned sw instruction. This would have been a legal output incase the store of the bytes in the next word violated any security permissions but the implementation has to attempt to store 4 bytes.

[aignacio]

Hey @pawks,

thanks for the answer, I was indeed concluding the same yesterday. It took me some time to realize that because it sounds a bit strange this behaviour, even more when you consider standard protocols such as the ones in the AMBA family where the size of the transfer usually needs to be aligned with the address. Anyway, it is what it is, thanks again for the help.