PC becomes 0x00000000 after jump to 0x80000000 to execute auipc instruction

[zhangkanqi]

Modifications made to RSD:

• Let PC_GOAL=0x80000370
• Comment define RSD_NARROW_PC in MemoryMapTypes.sv in order to let pc be 32-bit

Test program: I set bootrom code block in ROM, and then jump to RAM to execute instructions. The disassembly code of test program is as follows:

Results: No more instructions are submitted after jumping to pc=0x80000000(including instruction at pc=0x80000000 ), and RSD reports deadlock. I find that the pc pushed to activelist becomes 0x00000000 after the last pc 0x80000000. That's the reason why it will report deadlock.

Question: Why pc becomes 0x00000000 and how to address this problem?

Here is the waveform used for debugging. https://transfer.pcloud.com/download.html?code=5Z2w4X0ZdESCcBq5M9pZWfR3Z56T52K9ksCBqvRc36Fd9UjQhBBpk

[shioyadan]

Check what instruction code is fetched from address 0x80000000. It may not be the AUIPC you placed. Also, as mentioned in issue #73, check the contents of code.hex.

Thank you.

[zhangkanqi]

So you mean it's permissible to put Instruction at RAM in RSD? I will check code.hex right away.

[zhangkanqi]

I modify my program, putting all instructions and data in RAM(starts with 0x80000000, ends with 0x80008000). And successfully generate the right code.hex. However, I find that RSD doesn't support mainMemWordSize=0x80008000/4. The mainMemWordSize is 0x800000 getting from the following code.

    size_t mainMemWordSize = sizeof(top->Main_Zynq_Wrapper->main->memory->body->body__DOT__ram->array) / sizeof(uint32_t);

Could you please tell me how to modify RSD to let mainMemWordSize be 0x80008000/4? In other words, how to set TOP__Main_Zynq_Wrapper__main__memory__body__body__DOT__ram.array ?

[shioyadan]

As I wrote previously, the part of code.hex after 64KB is loaded into the RAM area started from 0x80000000. Thus, I think that you do not need to change mainMemWordSize.

I suspect that the issue is due to the placement in code.hex. Check the contents of your generated code.hex. The first 64KB of code.hex is loaded into the ROM area and the rest into the RAM area (0x8000000000>=). You need to be aware of this when creating binaries.

Check the implementation of load_hex(). It does not use mainMemWordSize. https://github.com/rsd-devel/rsd/blob/3d13af1bc14d2b34a546754973d832d0309d118e/Processor/Src/SysDeps/Verilator/TestMain.cpp#L178

Also, when you put all your instructions in the RAM area, you may need to change the initial values when the PC is reset.

[zhangkanqi]

Get it! There is something wrong with my elf file, I ignore AT>ROM in rsd-ld.script.

Thanks for your reply :)

[shioyadan]

I'm glad to hear your issue was resolved. If you have any more questions, please don't hesitate to ask.

I may be busy at times and it may take me a while to respond, but I will do my best to accommodate you.

Thank you.

[zhangkanqi]

Thanks a lot! Actually if i want access PC/addr at RAM, I must pad code.bin to 128KB(64KB for ROM and 64KB for RAM). That's the underlying reason. AT>ROM is insignificant.