cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
2,641 Views
Registered: ‎05-01-2018

Use of Microblaze cache

Jump to solution

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.

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
2,818 Views
Registered: ‎02-01-2008

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.

View solution in original post

0 Kudos
3 Replies
Highlighted
Xilinx Employee
Xilinx Employee
2,599 Views
Registered: ‎02-01-2008

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.

0 Kudos
Highlighted
Visitor
Visitor
2,574 Views
Registered: ‎05-01-2018
I have indeed looked at the example bootloader design, but it doesn't suit my requirements. I want to execute large programs, so I want to execute directly from DDR, so that I can dump the program directly to the particular DDR address from the running linux on SoC. I don't understand why do we need to load the program to FLASH which then copies to DDR memory.

The purpose of ZYNQ SoC is mainly to utilize full-fledged Linux running on ARM (PS) to coordinate with PL, so please let me know if there is any design in which I can run the programs directly from DDR.

Thanks.
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,819 Views
Registered: ‎02-01-2008

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.

View solution in original post

0 Kudos