Astrobe Forum

Practical projects need BRAM aside of program memory; so, use 96% or more of available BRAM is prohibitive. For example, if I try to test a FIR in hardware the embedded OS does not
have enough BRAM available for data buffer and coefficients storage. Also due to BRAM tiles in different FPGA architectures some RAM configurations could have collateral side effects.

The question is, could the compiler handle variable memory maps ? For example 8K, 16K, 32K... 32 bits address range.

Good question1 Yes, you could quite easily reduce the amount of BRAM used by Oberon.

NOTE: The following information applies to the Arty implementation but a similar technique can be used for other boards but the details would be slightly different.

If you run Test.Watch at startup time you will see that the embedded version of the Project Oberon OS uses:

56000 Bytes for globals and program
2336 Bytes for the heap
396 Bytes for the stack

So 68% of the 192KBytes of RAM allocated to the processor is unused. You could reduce the amount of BRAM allocated to the RISC5 processor to 160KBytes or 128KBytes fairly easily and still be able to run reasonably-sized Oberon applications.

If you want to reduce the amount of BRAM allocated to the OS:

1. Modify the Verilog source RAM.v. This is currently implemented as six blocks of 32KBytes so the easiest change would be to reduce the allocation by 32KBytes (or 64KBytes) by removing block 5 (and block 4).

2. Modify the CONSTs MemLim and stackOrg in the boot loader BootLoad.Mod (included with the Verilog files) so that MemLim corresponds to what you have allocated in RAM.v.

MemLim is the maximum address (e.g. 030000H = 192K)

stackOrg is the top of the Stack / bottom of the Heap. This is currently set to 028000H (160K) which allows 32K for the Heap. The stack grows downwards until it eventually would crash into the space used by the currently loaded modules. System.ShowModules shows the RAM occupied by each loaded module.

e.g. possible CONST values are:
or
or whatever you want it to be.

3. Compile BootLoad.Mod.

4. Rename BootLoad.mem to prom.mem

5. Regenerate the bitstream file and reprogram the development board using your board's Verilog build and deploy system (i.e. Xilinx ISE, Vivado etc.)