Reference word for test 'rv32e_unratified/C/cswsp-01' is address-dependent

[cgroux]

I've run all 'rv32e_unratified' tests, from folders 'C' and 'E'.
All reference values, except the one I mention, are independent of the absolute mapping of the memory.

However, in case of the 'cswsp-01' test, at label 'inst_3:', the code stores its current stack pointer (x2) into the signature area:

Here is the source code, from cswsp-01.S:

// rs2==x2, rs2_val == -536870913, 
// opcode:c.swsp; op1:x2; op2:x2; op2val:-0x20000001; immval:0x2c
TEST_STORE(x4,x5,0,x2,x2,-0x20000001,0x2c,12,c.swsp,0)

And the corresponding disassembly, for my platform:

  ca:	e0000137                lui	sp,0xe0000
  ce:	fff10113                addi	sp,sp,-1 # dfffffff <fromhost+0xddfffaff>
  d2:	00c20113          	addi	sp,tp,12 # c <rvtest_entry_point+0xc>
  d6:	02c00293          	li	t0,44
  da:	40510133          	sub	sp,sp,t0
  de:	d60a                	sw	sp,44(sp)       <-- Saves a memory-mapping-dependent value into the signature
  e0:	0001                	nop
  e2:	0001                	nop

As consequence, the signature for this particular test will only match the reference (0x800021e4) for a precise memory layout.

While this is not strictly-speaking a bug, it would be cleaner if all tests are performed in a way that do not depend on absolute memory adresses.

[pawks]

This seems to be an error in the coverage definition for the c.swsp instruction. rs2==x2 should not be considered as a coverpoint for c.swsp due to it being used as the base address i.e rs1 in this case.

[cgroux]

Thanks for the reply. I am not familiar with 'coverpoint', and how it is defined, or when it is applied. For now, I am just comparing raw signature from RAM with '.reference_output' files. Maybe there is some scripts above, which I don't know and don't call, which would discard the mismatch I observe. If so, then I apologize for this irrelevant issue report.

[pawks]

The issue is completely relevant. The test instance generated is wrong and hence the source files used for generating these tests will have to be changed. The tests and the coverage reports will have to be regenerated to fix this issue.

[neelgala]

@cgroux thanks for reporting this. What pawan was referring to is that we use coverpoints to generate tests using CTG. So effectively the coverpoints used to generate this particular tests were wrong.

@bilalsakhawat-10xe This line needs to be rv32e_regs_mx2 as is done here.

I would suggest fixing the cgf in ctg, and then regenerating this test and all its collaterals as a separate PR.

[bilalsakhawat]

@neelgala sure will do ASAP.

[neelgala]

fixed in #210

[gdi-sc]

I experienced exactly the same situation in the 'cswsp-01' test, but now at label 'inst_4:'
I use tests from Release 2.5.1 for 'rv32e_unratified' tests, from folder 'C'.
Source code cswsp-01.S

inst_4:
// rs2==x2, rs2_val == -268435457, imm_val == 8
// opcode:c.swsp; op1:x2; op2:x2; op2val:-0x10000001; immval:0x8
TEST_STORE(x8,x9,0,x2,x2,-0x10000001,0x8,16,c.swsp,0)

And corresponding disassembly, for my platform:

40000424:	f0000137          	lui	sp,0xf0000
40000428:	fff10113          	addi	sp,sp,-1 # efffffff <__C_STACK_TOP__+0xaffcffff>
4000042c:	01040113          	addi	sp,s0,16
40000430:	00800493          	li	s1,8
40000434:	40910133          	sub	sp,sp,s1
40000438:	c40a                	sw	sp,8(sp)
4000043a:	0001                	nop
4000043c:	0001                	nop

Signature doesn't match reference (8000220c) in my case because of different memory layout. STACK_TOP is at 0x4002FFFF in my system. And stored value physically can't be at higher address than STACK_TOP.

[bilalsakhawat]

It looks like, I accidentally uploaded the wrong cswsp-01.S file in #210. I'll fix it ASAP. Sorry for the inconvenience.

[bilalsakhawat]

Fix in #219

[neelgala]

@gdi-sc can I request you to try out #219 and let me know if it works ?

[gdi-sc]

I've run this test and now it working good.
Thanks for your support.

[neelgala]

PR merged.. thanks for reporting.. closing the issue.