Hi Bengt,
Xilinx Zynq chips offer novel design challenges and opportunities with their mix of hard-core Processing System (PS, based on the ARM Cortex-A9) and FPGA Programmable Logic (PL, which can contain soft-core processors and hardware IPs). Here are some pointers on migrating a legacy MicroBlaze + IP FPGA design to the Zynq.
The old design (MicroBlazes + MicroBlaze software + IP blocks) would be realized inside the Zynq PL. The new design (ARM software) would be realized inside the Zynq PS. Glue logic inside the PL would likely be needed to assist communications between the old and new system. For example, the PS can access the PL through AMBA AXI ports. The glue logic could have the old system provide an AXI interface to the new system. The glue logic could also send interrupts to the old and/or new systems for synchronization purposes (assuming matching interrupt handlers and device drivers inside the ARM and MicroBlaze software).
Given a requirement to keep the old system "as is", the naive textbook answer is to consider the whole old system (MicroBlaze, software, IP blocks) as a single fixed black box IP (e.g., a netlist + HDL entity). This black box IP could then be accessed as an AXI slave and/or master by the new system. Reusing the old system "as is" might be as easy as that. Per Murphy's Law, several issues might block that happy path (non-exhaustive list):
* The PS has fixed constraints on its memory address space and the old system might have an incompatible memory address space. Given a requirement for global memory address space, what you expect to be I/O between the PS and PL might result in bus errors or other byzantine failures.
* Various functional bugs may surface (e.g., old system being used outside its original context, development of the new system, integration of the two systems). In such cases, root cause analysis of bugs in a complex architecture (6 processors + IP blocks) might prove challenging with limited on-chip debug visibility or slow RTL simulation speeds.
* Considering that the hard-core ARM Cortex-A9 processor is so much more powerful and efficient than a soft-core MicroBlaze processor, using several MicroBlaze processors in a Zynq might be suboptimal in terms of performance, area and/or power. If meeting non-functional requirements proves a challenge, performing micro-optimizations by tinkering with the ARM software of the new system might fail to address the issue. It might turn out that macro-optimizations need to be performed, such as moving some old system functionality from the MicroBlazes to the ARM Cortex-A9 (and then eliminating one or more MicroBlazes). In terms of development effort and risk management, it is by far preferable to determine whether such macro-optimizations are necessary, and to perform them, at the start of the project than at the end.
I work for Space Codesign, which John introduced above. We offer tool solutions (SpaceStudio) which address the problems you might encounter while targeting the Zynq. In particular, we have features (code generation, HDL generation, design rule checks, fast simulation, full-visibility virtual platforms, debuggers) which speed up the analysis, design space exploration, development, debug and realization of functionality and communications (including glue logic, interconnect interfaces and device drivers) in systems targeting the ARM Cortex-A9, MicroBlazes and IP blocks on the Zynq.
I wish you success in your project. Let me know if you would like more information on our solutions.
www.spacecodesign.com
)