Possible error on Reset and AUIPC behavior

[yliu-hashed]

Hello, I found some strange behavior on how Darkriscv does resets. It seems like after a reset, the instruction at the reset location will never be executed. For example, if I define __RESETPC__ as 0, the instruction at address 0 will not be executed after a reset.

I also noticed that the AUIPC instruction gives an address 4 bytes smaller. For example, if I have a AUIPC x3, 0 instruction at address 0x4, 0x0 will be put into the x3.

The JAL instruction also seems to give an address 4 bytes smaller. JAL also seems to accept a 4 bytes smaller address as a jump target. This may be linked to the faulty reset behavior, where the first instruction is not executed.

Everything like call and return runs fine, but PC relative addresses are always 4 bytes smaller.

Maybe I am absolutely wrong, but I don't think those are expected behaviors. If you need more information, I can write some Verilog test cases later, but for now, I don't have enough free time. Thanks

[samsoniuk]

Hmmmm that is very strange... I tested here w/ a lui a1,0x80000 at boot:

00000000 <_start>:
0: 800005b7 lui a1,0x80000
4: 0025c603 lbu a2,2(a1) # 80000002 <_global+0x7fffe976>

and, in the simulation, it appears to be okay:

In depth: the external RES activates the internal XRES, which make the NXPC2 = 0 and FLUSH = 2. After XRES is released, it NXPC2 will start increment, but the instruction 0 is already registered on IDATA, XLUI, LUI, etc... when the FLUSH is zero, LUI is executed, which is confirmed by the value 0x80000000 on register x11.

Well, a way to test it is load the FW on a different location so, as long it is position independent, it must adapt to the different location and run the same way:

    $readmemh("../src/darksocv.mem",MEM,10);

Will skip 10x32-bit and load at address 40... oh well, the C code works fine, but not the asm code:

The trick here is the text vs. data segment so, commenting the .rodata section on boot.s:

not sure there is any collateral effect, but it will works fine (note the text@552, meaning that the entire image is dislocated from the original text@512):

So, since the code is working, I assume that auipc is correct too! :)

[samsoniuk]

just in case, I tested add an "auipc x3,1" as 1st instruction of the code... and it appears to work fine too:

but note that "auipc x3,0" really write zero on the x3 register! :)

[yliu-hashed]

Thanks for the fast respond. I don't know why it's not running in my setup. GTK Wave doesn't run on MacOS 14, so it's really hard to debug this thing. I am going to do more testing on my end later. Thanks again

[yliu-hashed]

My bad. This is the biggest bruh moment in my life. I assumed that the instruction memory is combinational, like assign IDATA = memory[IADDR[31:2]]. No wonder why everything is offset.

Really thanks for the double checking

[samsoniuk]

No problem, that is part of the knowledge cycle! :)

In your case, possible ways to workaround the lack of gtkWave are:

• run a linux VM on virtualbox + Xquartz, so is possible ssh -Y to the linux VM exporting the Xquartz and see the gktwave window on macos.
• add $display() debug prints on the code, so you can see the instruction pipeline.

Case you need any additional information, you are always welcome!