Open dnjayasinghe opened 5 years ago
Dear dnjayasinghe,
This procedure is not necessary because you can use the boot loader to load an arbitrary sized bare-metal program instead of BBL (the Linux boot loader). Just put your program on the SD-Card instead of BBL (and keep the same name so the bootloader can find it). We have not seen a necessity to increase the boot loader size even in the forthcoming v0.7 release, even though it supports SD-Card, Ethernet and QSPI booting. If however you want to increase the boot memory size (bearing in mind in an ASIC this would be a fixed overhead) for development purposes, then you need to change widths in several places. First of all the Chisel code has to be changed to make this extra area of memory executable, then you need to review the Verilog to check all busses are still wide enough, then you need to change the build scripts to take account of the larger sizes of memory, and finally the data2mem procedure which updates the boot memory contents in an existing bitstream needs to be changed to recognise the larger size of the memory. It seems like it is the last of these which is tripping you up at the moment, I can't really comment further because we have updated the way we do this in newer releases. Suffice to say, a TCL script dumps the RAM locations from Vivado, this is then processed with a Python script to generate the syntax that data2mem (A Vivado SDK executable) expects.
Regards,
Jonathan
On 03/07/2019 03:46, dnjayasinghe wrote:
What is the correct procedure to increase the block ram in lowrisc version 0.2 to run large bare metal applications? I changed |localparam BRAM_ADDR_WIDTH = 16;| to |localparam BRAM_ADDR_WIDTH = 17;| Everything compiles and I can see FPGA utilization has increased. When I complie the baremetal program I get this error in bmm2mmi
|WARNING: [Vivado 12-180] No cells matched 'ram_reg_15'. ERROR: [Common 17-55] 'getproperty' expects at least one object. Resolution: If [get
] was used to populate the object, check to make sure this command returns at least one valid object. | — 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-fpga/issues/10?email_source=notifications&email_token=AAEALV3B6ZZOPOC2DD4AXFLP5QHJ7A5CNFSM4H5BLYLKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G5AWYZQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEALV6NGI6NPE5XSQ6766TP5QHJ7ANCNFSM4H5BLYLA.
Thanks for the reply Jonathan. What you explained make sense and I though increasing the BRAM address width would solve the issue. Putting the executable into the SD sounds good and suits for my needs. Is there any document which explains how do it (Im still a noob)?
Just follow the tutorial recipe for building BBL, but use your own source code instead, or just remove anything that you don't want. For example if you want support for misaligned accesses, they have a routine for that which you can leave in. You can also make use of the 'dummy payload' functionality if you want to run in supervisor mode but still it can be bare metal.
On 03/07/2019 12:03, dnjayasinghe wrote:
Thanks for the reply Jonathan. What you explained make sense and I though increasing the BRAM address width would solve the issue. Putting the executable into the SD sounds good and suits for my needs. Is there any document which explains how do it (Im still a noob)?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-fpga/issues/10?email_source=notifications&email_token=AAEALV4BZOVCZUOCHKVK7CDP5SBQBA5CNFSM4H5BLYLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZEC6TA#issuecomment-508047180, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEALVYUWVJVLWLPR4MKIT3P5SBQBANCNFSM4H5BLYLA.
Thanks.
What is the correct procedure to increase the block ram in lowrisc version 0.2 to run large bare metal applications? I changed
localparam BRAM_ADDR_WIDTH = 16;
tolocalparam BRAM_ADDR_WIDTH = 17;
Everything compiles and I can see FPGA utilization has increased. When I compile the bare metal program I get this error in bmm2mmi