Bare-metal application with custom Peripheral

[munozher]

Hi Eugene,

thanks a lot for this awesome repository. I added a custom core to your base design. I am using a bare-metal approach, and I used IO/UART as an example. The bitstream gets generated without critical warnings. I compiled my application according to your bare-metal/hello-world example. After executing an application I can see (through control signals) that my IP core finishes executing all commands, but unfortunately with incorrect data (I am running a very simple application in my IP which copies some data from one part of the memory to another).

I was wondering if you had some insights regarding custom peripherals having access to the memory, because it looks like my IP is sending read requests to the processor, but nothing comes back. Maybe there are some configuration steps I am missing?

I am using a rocket32s1 configuration. If I needed to add another AXI-slave interface to the Rocketchip IP, how could I approach this? Is it enough to modify src/main/scala/rocket.scala?

A bit more details on my custom IP:

• My core has one slave and one master AXI interface, with a clk and reset signal. The slave is for controlling execution of applications in my IP, and my IP can access the memory through its master interface (through a processor).

• I've tested my IP successfully in a ZYNQ environment in the past, so I know it works.

• My core is mapped to address 0x60060000 following the default memory addressing from other peripherals.

Sorry for the long post, but any information would help. Best regards and thanks again, Hector

[eugene-tarassov]

I was wondering if you had some insights regarding custom peripherals having access to the memory, , because it looks like my IP is sending read requests to the processor, but nothing comes back.

You can use Vivado debugger. Mark AXI master port of your IP for debugging and collect waveforms.

Maybe there are some configuration steps I am missing?

Perhaps you have not assigned address range for your master. Check Vivado address editor tab. Note that RISC-V memory starts at 0x80000000.

If I needed to add another AXI-slave interface to the Rocketchip IP, how could I approach this?

You can modify src/main/scala/rocket.scala to add ports. However, an easier way is to connect the IP to existing AXI interconnects in the IO block.

[munozher]

Hello, thanks for your quick reply. I changed the master base address of my IP to 0x80000000 with 1GB of range, but the result was still the same.

Also, I am debugging (with ILA IPs) the master of my IP which is connected to the slave interface of an interconnect. The master of this Interconnect is connected to the DMA_AXI4 interface of the Rocketchip. I am also debugging this signal. At the moment I am able to see some ARADDR requests comming out of my IP, but strangely enough, I can't see anything in the ARADDR channel from the cable connecting the Interconnect with the rocketchip.

Would you happen to have a clue of whats going on? In the meantime, I will continue to debug, perhaps I am not debugging properly.

Thanks again!!

[munozher]

BTW, do you know if the config rocket32s1 has caches? I've seen that other versions have a L2 cache. Also do you know how to flush the cache? I've seen functions for flushing the icache but not for dcache. Would a fence instruction be a good solution instead? (fence iorw,iorw for example). Thanks again!

[eugene-tarassov]

BTW, do you know if the config rocket32s1 has caches?

Yes, it has L1 i-cache and d-cache.

I've seen that other versions have a L2 cache.

The L2 cache is optional, and it does not make much sense to add it in a single core config.

Also do you know how to flush the cache?

The Rocket Chip implements cache coherence, including DMA bus access. So explicit d-cache flush is not needed and not supported.

[munozher]

Thank you so much for your time and your answers. I finally got my design working with a mix of your answers, and handling priorities in the interconnects where my IP is connected. Also using fence instructions when writing the C++ application helped. A bit more testing is needed, but I don't see a point in keeping this issue opened at the moment. Thanks!