Trouble with resizing a smaller Scratchpad Memory

[Will Raulston]

Hello,

I am doing a tapeout of a RocketChip in one of my classes this semester. We pretty much have everything dialed in for our configuration, but we are running into issues with getting a correct size for our scratchpad memory. 

Our configuration uses the L1 I and D caches but removes the L2 and MemPort in favor of a large scratchpad (16KiB). This is due to the area limitations that we have for our design. We have run into an issue however, as when we configure the scratchpad to be 16KiB instead of 256KiB, none of the simulations run. I believed that this was a linker script issue, as when I ran a spike simulation on the hello.riscv program I got these three buckets:

Memory Address Access Data:
Bucket 0x8002a000 - Count: 399, Min: 0x8002ada8, Max: 0x8002aff8
Bucket 0x80002000 - Count: 1189, Min: 0x80002000, Max: 0x80002480
Bucket 0x80001000 - Count: 4710, Min: 0x80001d30, Max: 0x80001fe0

The first of these three buckets is out of the address range 0x80000000-0x80003FFF available in our configuration.
We do understand that the RocketChip is typically not used with this small of a memory, but that is what we have been constrained to with the time and area allotted.
I have looked into the htif.ld script that exists in the /chipyard/tests/ directory and created a modified version that attempts to limit the memory space to 16KiB with no luck.

If anyone has any ideas of how we could solve this issue, I would be very grateful. Our tapeout deadline is in around 3 weeks. I am relatively confident that the hardware is still in a working condition and it is just a matter of resolving the linker script to get it programmed properly, but I do not want to take unnecessary risks because this tapeout is quite expensive.

I have attached the CustomAbstractConfig that we are using as well as the CustomRocketConfig. I have both memory configurations in there, so you can see exactly what I am talking about when I say that one size does not work and one size does.

I have been using Chipyard version 1.12.0 and the VCS simulator for everything.

Thanks,

-Will

[Jerry Zhao]

Most likely the RTL elaborated correctly, This seems like you are describing a SW issue, where your SW is accessing regions outside the valid physical memory space.

You can adjust the physical memory region in Spike with the -m flag, to make it match your configuration. Then, you can debug your SW working on Spike before deploying it on the RTL simulation of your system.

-Jerry

--
You received this message because you are subscribed to the Google Groups "Chipyard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chipyard+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/chipyard/85eec8ea-d449-4f4c-9688-52ba70485342n%40googlegroups.com.

[Will Raulston]

Hey Jerry, thanks for the reply.

Actually, right after my initial post, I found this post ( I sent a reply but accidentially did it privately ): (https://groups.google.com/g/chipyard/c/yBUkT6NG5AY/m/YW8AoBKjAgAJ) which led me to look in the htif.ld script. I was able to simply resize the stack and heap to fit within my SRAM and my tests began passing again.

On Apr 2, 2025, at 1:51 PM, 'Jerry Zhao' via Chipyard <chip...@googlegroups.com> wrote:



You received this message because you are subscribed to a topic in the Google Groups "Chipyard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chipyard/6WGYbF4Gpdc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chipyard+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/chipyard/CAC%2BpDSG4JSQ-ZYOS2s6L4Ne%2BZnbaY6iZmrtJ0Lx8uCVRKfJ-ew%40mail.gmail.com.