05-01-2018 01:43 PM
I am profiling the cache performance of Microblaze soft-core processor.
In the current configuration, I am using 128KB unified instruction and data memory. For this configuration, I have enabled both data and instruction caches. When I tried to profile some application for different sizes of cache (2KB to 64KB), the performance (run-time) for the applications remains almost same with a minor change in terms of microseconds. All the memory is implemented on ZYNQ fabric as BRAMs.
What don't I get is, what is the use of providing the cache module to the Microblaze processor? One scenario I can imagine where cache is helpful is if the code is executed from an external peripheral like DDR/ flash memory. But still, for the configuration available in Vivado, there is no support for executing applications from external peripherals other than to build the custom bootloaders. So, my question still remains unanswered.
05-09-2018 07:50 AM
You need some method to get the microblaze's application placed in DDR. Lets call this 'method' your bootloader. Since you have a PS, there are many 'methods' available as a bootloader for your microblaze running from DDR.
Probably the simplest 'method' is to use the FSBL as the microblaze bootloader. The microblaze elf would be added to a partition within BOOT.BIN, and the FSBL, which runs on the A9, would copy the microblaze elf from BOOT.BIN to DDR. Then, it is up to you how to startup the microblaze. FSBL will power up the PL and remove the PL reset. You need to make sure the microblaze doesn't try accessing DDR until it's application has been written to DDR. Refer to the info here: http://www.wiki.xilinx.com/Execute+Microblaze+Application+from+PS+DDR and take note of the 'reset_mode' config for microblaze.
I expect BOOT.BIN will be located in QSPI Flash or equivalent so that covers your statement "I don't understand why do we need to load the program to FLASH which then copies to DDR memory". The 'bootloader' doesn't need to run on the microblaze.
Or another option is that your microblaze bootloader is actually an application running on Linux. The application could copy the microblaze elf (converted to bin) from ethernet, flash, external drive, etc, to a fixed location in DDR. Then the app would take the microblaze out of reset.
05-03-2018 08:58 PM
I would expect this result since the microblaze cache uses BRAMs.
Cache is normally used when executing and moving data to/from DDR. Cache also can be useful for slow memory since the microblaze caching interfaces will exercise AXI4 burst transactions.
The SDK application templates include an example bootloader design which, last time I looked, ran from LMB, and copied a .mcs from FLASH to DDR, and then started executing from DDR.
And there are other cases where the DDR is initialized by zynq or mpsoc PS, or an external house keeper initializes DDR before releasing microblaze from reset.
05-09-2018 03:46 AM
05-09-2018 07:50 AM