Bill Kafig and Praveen Venugopal, Xilinx
3/28/2013 12:03 PM EDT
The Xilinx Zynq-7000 All Programmable SoC already has plenty of processing power onboard. But the presence of powerful twin Cortex-A9 processors and associated peripherals in Zynq's application processing unit (APU) should not keep you from adding one or more MicroBlaze processors in the same package, if your application would benefit from them.
Why might you want to add a MicroBlaze to a solution already endowed with serious processing clout? First there is the issue of reliability. Single-threading dramatically improves reliability. You can cleanly place one thread per Cortex-A9 (for computationally intensive tasks), and instantiate as many MicroBlaze processors as you need for other threads. Second, you can farm out any housekeeping chores that don't require the power of a Cortex-A9 to a MicroBlaze, thus saving critical performance cycles for the jobs that need them most.
Here's an example that covers both of the above situations. Consider a task that requires long stretches of intense computing while monitoring user input. Here the MicroBlaze could manage the user input (lower frequency, non-computationally intensive) and write into the APU's memory space so that when the APU "comes up for air" – that is, completes its processing task – It can see what information it needs to process next.
Once you've made the decision to include a MicroBlaze processor in your Zynq-based design, several issues become immediately apparent. First and foremost is the question of how the APU will communicate with the MicroBlaze, and what processing system (PS) resources are available for the MicroBlaze. Many boards, such as the ZC702 and Zedboard, map many of the peripherals directly to the pins connected to the PS. These pins are not directly accessible to the MicroBlaze in the programmable logic (PL). The PS also contains a variety of timers and interrupt sources. Is there any way to access them from the domain of the MicroBlaze?
Click here to read more ...