Hi all,
I see that the Arty A7-100T has 256MB of DDR RAM (besides the 4860Kb of Block RAM), but I don’t know how to access it. When I change the amount of RAM on the linker script, the initialization functions crash. All I can use is 16KB (the original value on the linker script).
Please, do I need to change the freedom repo and re-program the board? Have anyone been able to use more RAM?
Additional information: I’ve been trying to put FreeRTOS to run on Arty, and that’s why I need more RAM. I’m porting FreeRTOS v10.2 into freedom-e-sdk@dca1dfa (https://github.com/sifive/freedom-e-sdk/tree/dca1dfaf1cfb80ec30a7a16b899efa1040e3451d - before the introduction of Metal, which would increase the complexity of such porting). Comments and suggestions are welcome!
Thanks!
Putting in other words:
The memory map on https://sifive.cdn.prismic.io/sifive%2Fb06a2d11-19ea-44ec-bf53-3e4c497c7997_sifive-e31-manual-v2p0.pdf, chapter 4 shows:
0x8000_0000 0x8000_FFFF RWX A Data Tightly Integrated Memory (DTIM) (64 KiB)
My linker script has a line like this:
ram (wxa!ri) : ORIGIN = 0x80000000, LENGTH = 16K
And if I try to increase from 16 to 32 or 64, it crashes.
So how can I access more memory?
DTIM and ITIM are very fast static memory attached close to the processor core, and can be accessed in one or two clock cycles.
The 256 MB of DDR RAM on the Arty is on a different chip on the board. It not only takes much longer to access, it also requires adding a special and proprietary DDR IP block (supplied by Xilinx for use with MicroBlaze or even hard-wired FPGA designs) into the FPGA RTL.
We do support using the Arty RAM with FPGA bitstreams for cores designed to run Linux, but as far as I know we don’t support it for embedded cores. The DDR controller requires quite complex initialisation which normally takes place in a Linux bootloader.
It should be possible to increase the DTIM size in an Arty 100T, but that requires building a bitstream supporting that, not only changing the link script for the program. I thought newer E31 eval bitstreams already supported 64 KB but I could be wrong.
Okay, I understand. Thank you very much for clarifying it. Now it makes sense.
So let’s increase DTIM from 16KB to 64KB!
This is the configuration I think Arty uses:
So I guess this is DTIM’s configuration:
I’ll be trying to reprogram it with:
nSets = 1024, // 64Kb scratchpad
instead of
nSets = 256, // 16Kb scratchpad
Please, does it all above seem correct?
I’ve never looked at this stuff. Is a DTIM generated as a degenerate dcache? I don’t know. Maybe. If you increase the number of 4 KB pages from 4 to 16 then it stands to reason you’d need to also increase nTLBEntries from 4 to 16. But is there even a TLB in this design?
Hey @nickolas, @HEX-Five has done some similar work and ported FreeRTOS into one of the zones running on MultiZone, check https://github.com/hex-five/multizone-secure-iot-stack/ for the software related side. You’re right that more RAM was needed and @HEX-Five developed their own E300 variant, the X300 - https://github.com/hex-five/multizone-fpga. You can look at the specific changes at how the RAM was increased and what other modifications were useful. Here’s a brief comparison of the E300 and the X300:
| E300 | X300 |
|---|---|
| RV32ACIM | RV32ACIMU |
| 32.5 MHz clock | 65 MHz clock |
| 2 HW breakpoints | 8 HW breakpoints |
| no Ethernet core | Xilinx EthernetLite Ethernet core |
| 1-way icache | 4-way icache |
| no ITIM | ITIM at 0x0800_0000 |
| 16 kB DTIM | 64 kB DTIM |
| no perf counters | 2 perf counters, hpmcounter3 and hpmcounter4 |
| no CLICs | 3 CLICs (BTN0, BTN1 and BTN2) |