Debug Boot code
#1
Hi,

I migrated pulpissimo simulation env to a synthesizable env. I removed tb part so there is no JTAG action (but I confirmed the clocks are all fine in the system). bootsel has been set to 1'b1.
Even without the JTAG action, I expect at least boot-code can run correctly.
But, via compare PC (tb_pulp.i_dut.soc_domain_i.pulp_soc_i.fc_subsystem_i.FC_CORE.lFC_CORE.id_stage_i.pc_id_i[31:0]) value in golden simulation and my simulation. I found that after several instructions, my simulation jumped to another branch, like:
golden sim: .... 0x1a0002dc -> 0x1a0002de -> 0x1a0002e0 -> 0x1a0002e4 -> 0x1a0002e6 -> 0x1a000316 -> .....
my sim:      .... 0x1a0002dc -> 0x1a0002de -> 0x1a0002e0 -> 0x1a0002e4 -> 0x1a0002e6 -> 0x1a0002e8 -> .....
before that, the PC value and sequence is exactly the same

Now my problem of debugging it is: ./sim/boot/boot_code.cde is already made as hex file. I can find the src boot-code at https://github.com/pulp-platform/boot-code, but when I try to make executable, it is invoking "pulp-runtime/install/rules/pulp_properties.mk" but it's not there... (I want to make exe and then objdump it to debug with disassembly)

Can you please point me how to generate the corresponding disassembly to boot_code.cde? Or can you simply help me figure out why my simulation fails with the PC sequence I provided? 

Thank you!
Reply
#2
Update:

If I add the JTAG part testbench (reuse the initial block in tb_pulp.sv), looks like the PC sequence during boot is ok... Why? It's a bit confusing. I can't see anything may impact that at the beginning of testbench...
Reply
#3
(04-16-2020, 04:07 AM)ninipa Wrote: Hi,

I migrated pulpissimo simulation env to a synthesizable env. I removed tb part so there is no JTAG action (but I confirmed the clocks are all fine in the system). bootsel has been set to 1'b1.
Even without the JTAG action, I expect at least boot-code can run correctly.
But, via compare PC (tb_pulp.i_dut.soc_domain_i.pulp_soc_i.fc_subsystem_i.FC_CORE.lFC_CORE.id_stage_i.pc_id_i[31:0]) value in golden simulation and my simulation. I found that after several instructions, my simulation jumped to another branch, like:
golden sim: .... 0x1a0002dc -> 0x1a0002de -> 0x1a0002e0 -> 0x1a0002e4 -> 0x1a0002e6 -> 0x1a000316 -> .....
my sim:      .... 0x1a0002dc -> 0x1a0002de -> 0x1a0002e0 -> 0x1a0002e4 -> 0x1a0002e6 -> 0x1a0002e8 -> .....
before that, the PC value and sequence is exactly the same

Now my problem of debugging it is: ./sim/boot/boot_code.cde is already made as hex file. I can find the src boot-code at https://github.com/pulp-platform/boot-code, but when I try to make executable, it is invoking "pulp-runtime/install/rules/pulp_properties.mk" but it's not there... (I want to make exe and then objdump it to debug with disassembly)

Can you please point me how to generate the corresponding disassembly to boot_code.cde? Or can you simply help me figure out why my simulation fails with the PC sequence I provided? 

Thank you!

Hi ninipa,

The bootcode is supposed to be built as part of the pulp-sdk. If you already installed and compiled the pulp-sdk you should find the compiled ELF binary and corresponding source code under: pulp-sdk/runtime/boot_code_pulpissimo/build/pulpissimo/boot-pulpissimo/boot-pulpissimo


However, be aware that the boot_code.cde file you found in the pulpissimo repository is quite old and most likely not in sync with the source code and compiled ELF binary in the boot-code repository. If you want to create a new CDE file in order to synthesize a rom you have to do some roundabouts by  first converting the ELF to S19 format: 

riscv32-unknown-elf-objcopy --srec-len 1 --output-target=srec boot_code.elf boot_code.s19

Then you can use the two scripts these two scripts: 
.zip   scripts.zip (Size: 2.69 KB / Downloads: 24)  

and convert it to binary CDE format for ROM generation:

python2 s19toboot.py boot_code.s19 patronus #This generates boot_code.cde in Hexformat and boot_code.sv 
python3 cdeHexToBinary.py boot_code.cde boot_code_binary.cde  #Convert Hex representation to binary representation

Greetings,
Manuel
Reply
#4
(04-16-2020, 09:15 AM)meggiman Wrote:
(04-16-2020, 04:07 AM)ninipa Wrote: Hi,

I migrated pulpissimo simulation env to a synthesizable env. I removed tb part so there is no JTAG action (but I confirmed the clocks are all fine in the system). bootsel has been set to 1'b1.
Even without the JTAG action, I expect at least boot-code can run correctly.
But, via compare PC (tb_pulp.i_dut.soc_domain_i.pulp_soc_i.fc_subsystem_i.FC_CORE.lFC_CORE.id_stage_i.pc_id_i[31:0]) value in golden simulation and my simulation. I found that after several instructions, my simulation jumped to another branch, like:
golden sim: .... 0x1a0002dc -> 0x1a0002de -> 0x1a0002e0 -> 0x1a0002e4 -> 0x1a0002e6 -> 0x1a000316 -> .....
my sim:      .... 0x1a0002dc -> 0x1a0002de -> 0x1a0002e0 -> 0x1a0002e4 -> 0x1a0002e6 -> 0x1a0002e8 -> .....
before that, the PC value and sequence is exactly the same

Now my problem of debugging it is: ./sim/boot/boot_code.cde is already made as hex file. I can find the src boot-code at https://github.com/pulp-platform/boot-code, but when I try to make executable, it is invoking "pulp-runtime/install/rules/pulp_properties.mk" but it's not there... (I want to make exe and then objdump it to debug with disassembly)

Can you please point me how to generate the corresponding disassembly to boot_code.cde? Or can you simply help me figure out why my simulation fails with the PC sequence I provided? 

Thank you!

Hi ninipa,

The bootcode is supposed to be built as part of the pulp-sdk. If you already installed and compiled the pulp-sdk you should find the compiled ELF binary and corresponding source code under: pulp-sdk/runtime/boot_code_pulpissimo/build/pulpissimo/boot-pulpissimo/boot-pulpissimo


However, be aware that the boot_code.cde file you found in the pulpissimo repository is quite old and most likely not in sync with the source code and compiled ELF binary in the boot-code repository. If you want to create a new CDE file in order to synthesize a rom you have to do some roundabouts by  first converting the ELF to S19 format: 

riscv32-unknown-elf-objcopy --srec-len 1 --output-target=srec boot_code.elf boot_code.s19

Then you can use the two scripts these two scripts:  

and convert it to binary CDE format for ROM generation:

python2 s19toboot.py boot_code.s19 patronus #This generates boot_code.cde in Hexformat and boot_code.sv 
python3 cdeHexToBinary.py boot_code.cde boot_code_binary.cde  #Convert Hex representation to binary representation

Greetings,
Manuel

Hi Meggiman,

Thank you so much!
First of all, about the boot issue, the root cause may be that I floating JTAG interface in the standalone running (I can't 100% make sure, but it's very possible).
After adding the JTAG part testbench in my simulation, it works well now.
--- I stubbed FLL subsystem, so I hacked a bit in soc.c 

A further question is:
I went through Readme of pulpissimo so looks like pulp-sdk was not created during Readme flow. You mentioned the default one in pulpissimo is quite old, what is the potential risk to use the old one? 

Greetings
Reply
#5
(04-16-2020, 12:01 PM)ninipa Wrote:
(04-16-2020, 09:15 AM)meggiman Wrote:
(04-16-2020, 04:07 AM)ninipa Wrote: Hi,

I migrated pulpissimo simulation env to a synthesizable env. I removed tb part so there is no JTAG action (but I confirmed the clocks are all fine in the system). bootsel has been set to 1'b1.
Even without the JTAG action, I expect at least boot-code can run correctly.
But, via compare PC (tb_pulp.i_dut.soc_domain_i.pulp_soc_i.fc_subsystem_i.FC_CORE.lFC_CORE.id_stage_i.pc_id_i[31:0]) value in golden simulation and my simulation. I found that after several instructions, my simulation jumped to another branch, like:
golden sim: .... 0x1a0002dc -> 0x1a0002de -> 0x1a0002e0 -> 0x1a0002e4 -> 0x1a0002e6 -> 0x1a000316 -> .....
my sim:      .... 0x1a0002dc -> 0x1a0002de -> 0x1a0002e0 -> 0x1a0002e4 -> 0x1a0002e6 -> 0x1a0002e8 -> .....
before that, the PC value and sequence is exactly the same

Now my problem of debugging it is: ./sim/boot/boot_code.cde is already made as hex file. I can find the src boot-code at https://github.com/pulp-platform/boot-code, but when I try to make executable, it is invoking "pulp-runtime/install/rules/pulp_properties.mk" but it's not there... (I want to make exe and then objdump it to debug with disassembly)

Can you please point me how to generate the corresponding disassembly to boot_code.cde? Or can you simply help me figure out why my simulation fails with the PC sequence I provided? 

Thank you!

Hi ninipa,

The bootcode is supposed to be built as part of the pulp-sdk. If you already installed and compiled the pulp-sdk you should find the compiled ELF binary and corresponding source code under: pulp-sdk/runtime/boot_code_pulpissimo/build/pulpissimo/boot-pulpissimo/boot-pulpissimo


However, be aware that the boot_code.cde file you found in the pulpissimo repository is quite old and most likely not in sync with the source code and compiled ELF binary in the boot-code repository. If you want to create a new CDE file in order to synthesize a rom you have to do some roundabouts by  first converting the ELF to S19 format: 

riscv32-unknown-elf-objcopy --srec-len 1 --output-target=srec boot_code.elf boot_code.s19

Then you can use the two scripts these two scripts:  

and convert it to binary CDE format for ROM generation:

python2 s19toboot.py boot_code.s19 patronus #This generates boot_code.cde in Hexformat and boot_code.sv 
python3 cdeHexToBinary.py boot_code.cde boot_code_binary.cde  #Convert Hex representation to binary representation

Greetings,
Manuel

Hi Meggiman,

Thank you so much!
First of all, about the boot issue, the root cause may be that I floating JTAG interface in the standalone running (I can't 100% make sure, but it's very possible).
After adding the JTAG part testbench in my simulation, it works well now.
--- I stubbed FLL subsystem, so I hacked a bit in soc.c 

A further question is:
I went through Readme of pulpissimo so looks like pulp-sdk was not created during Readme flow. You mentioned the default one in pulpissimo is quite old, what is the potential risk to use the old one? 

Greetings

The reason the pulp-sdk is not mentioned in the README is that we are currently in a transition to use a much simpler bare metal SDK for PULPissimo since the current one (pulp-sdk) is quite a handful to setup correctly. Nonetheless, right now the most feature complete software environment is the pulp-sdk which you can install following the REAME page on:

https://github.com/pulp-platform/pulp-sdk

Make sure to checkout tagged releases from the master branch only (i.e. 2019.12.06 currently is the most up to date one) as occasionally (although we try to prevent that) the master branch is not stable.


The problem with using the CDE you have right now is that, if I am not mistaken, the feature to select the boot mode via the boot pin was not part of the boot firmware from the beginning. It was added around 1 1/2 years ago. You might end up with a version of the bootcode that can only boot if a JTAG Master is connected that tells PULPissimo the desired boot mode via the PULP JTAG config registers. This might actually be the reason why your Testbench is only working when you execute the JTAG initialization steps in the pulp TB. I strongly suggest you to simulate your chip in a verification environment that comes as close to the actually desired use case of the chip and make sure that you are able to boot your target applications on PULPissimo. According to the guy on our side that developed the bootcode we should consider the firmware in this repository more like a good example but should not use it for production without extensive verification. That doesn't mean the bootcode in this repository does not work. In fact, we use slightly modified version of it (custom-tailored to the specific chip) in most of our tape-outs. But you should not just use it (especially an unknown old precompiled version) without being very careful if you plan to do an actual tape-out since you no longer have to possibility to change the boot ROM after the fact.

Greetings,
Manuel
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)