Open flaviens opened 1 month ago
Hi again! I could reduce the code a bit and make a few observations.
Here is the new code, with a similar mismatch:
.section ".text.init","ax",@progbits
.globl _start
.align 2
_start:
# Make sure we start at 0x80000000 and not at 0x0 in case the memory aliases.
li sp,1
slli sp,sp,0x1f
addi sp,sp,16
jr sp
# Some init
lui t6,0x80000
mv t6,t6
slli t6,t6,0x20
srli t6,t6,0x20
csrw medeleg,zero
csrw mtvec,zero
csrw stvec,zero
lui t4,0x2
csrw mstatus,t4
li ra,0
fscsr ra
srli s10,t4,0x5
csrs mstatus,s10
li t5,-1
slli t5,t5,0x20
not t5,t5
# Load floats and ints. The floats are not used but seem to be necessary to cause the issue.
add tp,zero,t6
addi tp,tp,128 # 0x80
fld ft0,32(tp) # 0x20
fld ft1,40(tp) # 0x28
fld ft2,48(tp) # 0x30
fld ft3,56(tp) # 0x38
fld ft4,64(tp) # 0x40
ld ra,0(tp) # 0x0
ld sp,8(tp) # 0x8
ld gp,16(tp) # 0x10
ld tp,24(tp) # 0x18
jal first_block
# Some dummy data
.insn 2, 0x0
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0
.insn 2, 0x3334
.insn 2, 0xb56d
.insn 4, 0xc9ac9f77
.insn 2, 0x5db5
.insn 4, 0x09df2983
.insn 2, 0x664e
.insn 2, 0x989c
.insn 4, 0xfaad7697
.insn 4, 0x31b4373b
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
.insn 2, 0x0000
# The alignment of this block matters. For example, an alignment of 0xc1c will show the bug, but not an alignment of 0x1000.
.section ".text.firstblock","ax",@progbits
.globl _start
.align 2
first_block:
# Dump the register values
lui t5,0x0
addi t5,t5,16 # 0x10
fence
sd ra,0(t5)
fence
sd sp,0(t5)
fence
sd gp,0(t5)
fence
sd tp,0(t5)
fence
# This code here is actually what will be stored into `tp`.
.rept 32
nop
.endr
# Add 1 to the value and store it, to see if it's a problem of register valuation, or or in the store operation.
# The conclusion is the former.
addi tp, tp, 1
sd tp,0(t5)
fence
# Complete the testbench.
lui t5,0x0
mv t5,t5
sd zero,0(t5) # 0x0
fence
# Infinite loop
infiniteloop:
j infiniteloop
Some observations:
first_block
section.tp
takes the value of some code following the store.Anyone observed something similar?
Thanks! Flavien
Also, there are occurrences that do not imply floating-point operations or floating-point loads.
Hi there!
I encountered an issue that is hard to justify at the moment, but I cannot formally exclude that it is related to my setup.
When I execute the snippet below, I get a mismatch with spike. The discrepancy disappears when replacing the (unused) floating-point loads with nops. The mismatch is the following:
Expected:
Got:
Snippet:
In terms of address map, I'm hardcoding the dummy config as follows in
C910_RTL_FACTORY/gen_rtl/mmu/rtl/ct_mmu_sysmap.v
:Is this a known issue / can someone else reproduce it?
Thanks! Flavien