You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

Page 1 of 2 12 LastLast
Results 1 to 10 of 17

Thread: Old and New IP in Zynq

  1. #1
    Member
    Join Date
    Mar 2012
    Posts
    8

    Old and New IP in Zynq

    Hi, looking for inputs on how to combine an old design with 5 Microblazes and some 5 proprietary IP blocks (that I have to keep as is) with the ARM system in the Xilinx Zynq with a NOC, design needs to handle Global Memory Address Space, Synchronization, data movement and NOC communication on a real time basis across the old Microblaze and new ARM cores. All inputs are welcome.

    Best Regards
    Bengt


    Last edited by Daniel Nenni; 05-13-2013 at 12:06 PM.

  2. #2
    Blogger John Swan's Avatar
    Join Date
    Dec 2011
    Location
    Silicon Valley
    Posts
    84
    Sounds like you will want to easily and quickly create some virtual prototypes to explore and validate your options! At the Electronic Design Process Symposium (EDPS) in April, Guy Bois presented the SpaceStudio technology, from Space Codesign, on doing this very thing. They support both the Microblaze and Zynq, and demonstrated a design implementation on a ZedBoard at ARM Techcon last fall. Guy Bois is the President of Space Codesign.

    To access the presentation on SpaceStudio, go to the EDPS web site, the Program Info page, and the 2nd presentation by Guy Bois is what you are looking for. It's available there for you to download. Notice the SemiWiki Logo on the EDPS home page - they were proud sponsors of EDPS! ;-)

  3. #3
    Member
    Join Date
    May 2013
    Posts
    2
    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

  4. #4
    Top Influencer LinkedIn's Avatar
    Join Date
    Jul 2011
    Posts
    1,978
    ugh, you likely need PLB-2-AMBA bridge .... or something likes that ...though it looks like that Xilinx tools enable to create PLB-based designs, may be with shared memory IP for your MB-processors. so you need to implement PLB peripherial with RAM interface at PLB side and bus mastering capability at AMBA side, this would replace PLB memory controller for you.

    If I had Zynq or Kyntex eval board I would probably play with coding such a bridge.

    Do that proprietary cores have accessible PLB-IPIF interface signals? If so, you could try to attach them to AMBA-IPIF... in theory! (Xilinx tolls could do many good things, but in theory only )

    Well...I hope that ARM processor shouldn't process interrupts and read/write regs of your IP-cores attached to PLB bus? If it should then it means that you need a full scale
    bridge bitween two busses, so that it may take awhile to debug it.

    Yet nothing extra difficult from the logic point of view, see for example functionality of Xilinx AMBA-2-PCIe bridge and endpoint IP-cores.

    By Alexander Rusev

  5. #5
    Member
    Join Date
    May 2013
    Posts
    1
    Depending upon the strictness of keeping the old design "as is", encapsulating the custom IP blocks into AXI compatible IPs is an option. The Xilinx tools offer a Create and Import Peripheral (CIP) Wizard that helps generate an IP Interface/Interconnect service (IPIC or IPIF) for this purpose. Ideally, the MicroBlaze cores would be upgraded since a newer version will support AXI. And although the processing system (PS) uses AXI3 while the programmable logic (PL) uses AXI4, the Xilinx tools should automatically generate the necessary logic shim to smooth this out.

    However, as noted above by LMoss, this falls under the "textbook answer". So keep in mind the possible issues he so kindly noted.
    Last edited by shaun-emp; 05-21-2013 at 09:17 PM.

  6. #6
    Member
    Join Date
    Mar 2012
    Posts
    8
    Thanks John, very good material that I will have our system engineers take a deep dive into !

    Best Regards
    Bengt

  7. #7
    Member
    Join Date
    Mar 2012
    Posts
    8
    Hi Moss, great answer with a lot of insight ! I have the feeling that the Global memory address space in a distributed shared/private memory architecture will be the most challenching area as you point out in your comments. Will you go to to DAC in June? Would be great to meet you.

    Best Regards
    Bengt

    Quote Originally Posted by LMoss View Post
    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

  8. #8
    Member
    Join Date
    Mar 2012
    Posts
    8
    Thanks Alexander, thanks for your help, unfortunately the ARM processors will need to process interrupts and R/W regs :-( so debugg will be fun :-(

    Regards
    Bengt

    Quote Originally Posted by LinkedIn View Post
    ugh, you likely need PLB-2-AMBA bridge .... or something likes that ...though it looks like that Xilinx tools enable to create PLB-based designs, may be with shared memory IP for your MB-processors. so you need to implement PLB peripherial with RAM interface at PLB side and bus mastering capability at AMBA side, this would replace PLB memory controller for you.

    If I had Zynq or Kyntex eval board I would probably play with coding such a bridge.

    Do that proprietary cores have accessible PLB-IPIF interface signals? If so, you could try to attach them to AMBA-IPIF... in theory! (Xilinx tolls could do many good things, but in theory only )

    Well...I hope that ARM processor shouldn't process interrupts and read/write regs of your IP-cores attached to PLB bus? If it should then it means that you need a full scale
    bridge bitween two busses, so that it may take awhile to debug it.

    Yet nothing extra difficult from the logic point of view, see for example functionality of Xilinx AMBA-2-PCIe bridge and endpoint IP-cores.

    By Alexander Rusev

  9. #9
    Member
    Join Date
    Mar 2012
    Posts
    8
    Hi, thanks for your comments, will be interesting to see how well the tools fix the AXI 3/4 challenge, hopefully automatic and smooth !

    Best Regards
    Bengt

    Quote Originally Posted by shaun-emp View Post
    Pretty new to Zynq myself, but here's my shot at it...

    Depending upon the strictness of keeping the old design "as is", encapsulating the custom IP blocks into AXI compatible IPs is an option. The Xilinx tools offer a Create and Import Peripheral (CIP) Wizard that helps generate an IP Interface/Interconnect service (IPIC/IPIF, ...I'm not sure the difference) for this purpose. Ideally, the MicroBlaze cores would be upgraded since a newer version will support AXI. And although the processing system (PS) uses AXI3 while the programmable logic (PL) uses AXI4, I believe the Xilinx tools automatically generate necessary logic wedges to smooth this out.

    However, as noted above by LMoss, this is part of the "textbook answer". So keep in mind the possible issues he so kindly noted.

  10. #10
    Member
    Join Date
    May 2013
    Posts
    2
    Hi Bengt,

    We will be at DAC 2013 in Austin, Texas and exhibiting at the ARM Connected Community Pavilion, Booth 921. I am sending you a private message to schedule a meeting.

    Best regards,

    Laurent

    Quote Originally Posted by B Edlund View Post
    Hi Moss, great answer with a lot of insight ! I have the feeling that the Global memory address space in a distributed shared/private memory architecture will be the most challenching area as you point out in your comments. Will you go to to DAC in June? Would be great to meet you.

    Best Regards
    Bengt

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •