Boot procedure bare-metal

[bnkla]

Hi, I have troubles understanding the code execution of bare-metal programs for the lowrisc project. In my understanding, we have a BRAM, where the instructions are stored. When generating a bit file with a program (e.g. make hello), the content of the BRAM is set with the instructions of the hello program. After a reset, the core starts fetching instructions from 0x40000000 (BRAM base in consts.vh).

But when I hook up a on-chip debugger, the program counter starts from 0x20000000, but I don't understand why. Whats the purpose of the bootrom in the Rocket Chip?

Kind regards

[bnkla]

I managed to enable the simulator in Vivado and there I also have a strange behavior . As you can see in the screenshot, the program counter starts, as expected, at 0x40000000. The first problem is that the reset of the Rocket Chip is still at 1, but the PC changes from 0x40000000 to 0x40000004 - shouldn't it start when reset=0? When reset is 0, I get XXX for PC. Nevertheless, fetching the instructions from BRAM works, the data (=instructions) in bram_rddata_a matches. Is this a problem with wrong reset polarity?

[jrrk]

In the out of box Rocket design, the bootrom that comes with it just hangs waiting for the debugger to connect. This is inconvenient in a standalone context, so our version of Rocket was changed to allow the boot address to be supplied externally. You can still use the bootrom to report the memory size and addresses of the built-in peripherals (PLIC etc) in the form of a device tree blob. Because we add external devices in Verilog then this is insufficient, but our version of Berkeley Boot loader(BBL) has been modified to incorporate a different blob that knows about external Ethernet, SD-Card, VGA etc. The correct blob will be passed to Linux.

Obviously it would be inconvenient to rebuild the Rocket every time an external peripheral was added or changed.

On 15/03/2019 15:01, bnkla wrote:

Hi, I have troubles understanding the code execution of bare-metal programs for the lowrisc project. In my understanding, we have a BRAM, where the instructions are stored. When generating a bit file with a program (e.g. make hello), the content of the BRAM is set with the instructions of the hello program. After a reset, the core starts fetching instructions from 0x40000000 (BRAM base in consts.vh).

But when I hook up a on-chip debugger, the program counter starts from 0x40000000, but I don't understand why. Whats the purpose of the bootrom in the Rocket Chip?

Kind regards

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/109, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF10YEv3hckdR6oQ_0fabu5r_rlCnoks5vW7XSgaJpZM4b2qam.

[bnkla]

Thank you for your answer and sorry for the edit and second post.

I still do not understand, why on my FPGA board with debug scope enabled the start PC is 0x20000000. In my understanding, in io_reset_vector the start address is defined as 0x40000000 and this should be taken in NPC generation after system reset.

Maybe you have an idea what goes wrong in my Vivado simulation?

[jrrk]

Our testbench methodology supports FPGA boards with both senses of reset. You need to choose the correct one. Also you need to add `define instructions to ensure the simulation does not go to X

These are:

define RANDOMIZE_REG_INIT define RANDOMIZE_MEM_INIT

If you got isim to work with this design well done, because it's support and maturity is known to be a bit limited. External simulators are also possible but their use can be complicated because of conflicting LD_LIBRARY_PATH settings.

On 15/03/2019 15:10, bnkla wrote:

I managed to enable the simulator in Vivado and there I also have a strange behavior Screenshot from 2019-03-15 16-04-47 https://user-images.githubusercontent.com/35634992/54441070-3c7dd480-473c-11e9-8596-fba9b876854f.png . As you can see in the screenshot, the program counter starts, as expected, at 0x40000000. The first problem is that the reset of the Rocket Chip is still at 1, but the PC changes from 0x40000000 to 0x40000004 - shouldn't it start when reset=0? When reset is 0, I get XXX for PC. Nevertheless, fetching the instructions from BRAM works, the data (=instructions) in bram_rddata_a matches. Is this a problem with wrong reset polarity?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/109#issuecomment-473323793, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF1yE-itiMZ0XKj_u1YJVMSing8BT6ks5vW7flgaJpZM4b2qam.

[jrrk]

The start PC is determined by the following code in chip_top.sv

  reg [31:0] io_reset_vector;

   always @*      begin         casez (i_dip[1:0])           2'b?0: io_reset_vector = 32'h40000000;           2'b01: io_reset_vector = 32'h80000000;           2'b11: io_reset_vector = 32'h80200000;         endcase // casez ()      end

I can't comment on the use of ChipScope because its use interferes with the use of the RISCV/openocd debug methodology (as modified by use for the Nexys4DDR). You need to make some changes to free up some user scan chains. This is more of an advanced topic.

On 15/03/2019 15:18, bnkla wrote:

Thank you for your answer and sorry for the edit and second post.

I still do not understand, why on my FPGA board with debug scope enabled the start PC is 0x20000000.

Maybe you have an idea what goes wrong in my Vivado simulation?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/109#issuecomment-473326633, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF1_vtL11zqkjQghl-CI3VEdI1FqB5ks5vW7mtgaJpZM4b2qam.

[bnkla]

I am a bit lost with the Vivado simulation, maybe you quickly see what is going wrong? I configured the rst_top as Active High (as my real FPGA board) and I get this picture: The Rocket Core starts fetching with reset = 1 from 0x4000 0000 and sets the ram_en signal. When reset = 0, the core stops. Shouldn't it the other way around? I expected the Rocket Core to be Active High. However, data fetching from BRAM works, the first instruction (0x4d01....) is fetched. So I swap the rst_top to Active Low: Now the core starts after the reset, but the ram_en signal is never set. Why is this happening? As with the first case (rst_top Active High) BRAM fetching works, I just swap the reset of the rocket core: Any idea what is going wrong? Which lines would you recommend to get more information debugging the system? Is there maybe a difference when using the Rocket Core in a simulation?

[jrrk]

Did you take on board the previous comment about

`define RANDOMIZE_REG_INIT `define RANDOMIZE_MEM_INIT

without this you will very likely see things go to X very quickly.

[bnkla]

Yes, these two defines are enabled in my TB. What do you mean with "go to X"?

[jrrk]

It is preferable to put global defines on the command line because you do not necessarily know which order module will be read. Once an X gets into a register, it has a tendency to propagate to all downstream registers. If you aren't familiar with this phenomenon, I suggest you start with a 2-state simulator such as Verilator for your investigations.

[bnkla]

Hm I set the defines now in consts.vh and rebuild the project. On the fpga my core is working, e.g. I get UART output. However, in the testbench the same problem. Maybe any other ideas? Simulating the Rocket Core itself works with verilator, but I also want to simulate the periphery.

[jrrk]

Dear bnkla,

There is a limit to the amount of support that can be effectively delivered by email, and I think you have reached it. Frankly the only forward is for you to do a deep dive and become sufficiently experienced yourself to address any issues as they crop up. It was never realistic to address all issues that can crop up just with simulation, that is why we use FPGA as a kind of simulator in the first place. Every methodology has its sweet spot, FPGA has software proving as its raison d'etre, simulation has block level design as its focus, static timing analysis and formal verification have a checking role to play as well, and of course ASIC has low cost and power consumption, and ultimate performance as its goal.

One of the goals of our project as an educational institution is to empower the generation of engineers and computer scientists with freely available tools and IP. We can't be responsible for the way it is used outside of our specific tutorial instructions. The Rocket IP does not lend itself to 4-state simulation, it was not designed that way in the first place. The random initialization is a workaround that gives more test coverage in simulation, it is not a panacea. At this time we don't have a methodology of any kind that can do 4-state full-chip simulation with realistic accuracy.

Regards,

Jonathan

On 19/03/2019 10:22, bnkla wrote:

Hm I set the defines now in consts.vh and rebuild the project. On the fpga my core is working, e.g. I get UART output. However, in the testbench the same problem. Screenshot from 2019-03-19 11-20-05 https://user-images.githubusercontent.com/35634992/54598619-2e300100-4a39-11e9-8a90-3857d94ab6f7.png Maybe any other ideas? Simulating the Rocket Core itself works with verilator, but I also want to simulate the periphery.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/109#issuecomment-474289580, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgF11hMKoJ5fEN0Is64oCWN_TTxW6O7ks5vYLpXgaJpZM4b2qam.