Choosing the Right FPGA Prototyping Environment for Your Juno-Based Design |
 |
Rob van Blommestein, S2C Inc. 2016-10-19 19:38:00 ARM Processors
Prototyping an ARMv8-based design is similar to prototyping any other design. FPGA prototyping for these types of application is generally used to validate the hardware quickly to head into the software development stage sooner and accelerate the software development.
Whether you need scalability for your current design as you move through the design and verification process or whether you need your FPGA platform to be reusable and able to scale for future designs that may be larger than your current one, it all starts with identifying and selecting the ideal building blocks. The foundational prototyping board you choose must have flexibility to expand so a custom platform is usually out of the question as a custom board requires even greater customization to grow. When crafting your platform, there are three initial FPGA building blocks to evaluate: Single FPGA boards, Dual FPGA boards, and Quad FPGA boards.
Selecting either a single, dual, or quad board depends on your design’s size, memory requirements, and the number of inter-FPGA connections and external I/Os that will best fit your needs. The chart below provides an example of the differences in these board types based on S2C’s solutions for its Virtex UltraScale Logic Modules.
These comparisons don’t tell the whole story though. You must take a closer look at the architecture for each of these solutions. Besides the number of physical interconnections between FPGAs, the type (e.g. DDR3, DDR4) and capacity (e.g. 4GB, 8GB) of on-board memory is equally important to your design. Of additional interest should be the number of high-speed gigabit transceivers and their performance level. The diagrams below provide in-depth comparisons of each of the architectures for single, dual, and quad FPGA prototyping boards.
Diagram of a single FPGA module architecture
Diagram of a dual FPGA module architecture
Diagram of a quad FPGA module architecture
The type of I/O connectors used in the FPGA module may have a big impact on your design mapping and performance. First, they must be optimized for FPGA I/O banks, and even the FPGA die, in case some FPGAs have multiple internal die. In addition, having I/Os from different die will decrease performance. All traces from the FPGA to the same I/O connector should have the same trace length to increase bus performance. Connector performance itself may also play an important role especially if the connectors are optimized for running high performance LVDS (e.g. over 1GHz).
It's All About Flexibility
The foundational prototyping board is the first step in building scalability. Each solution whether a single, dual, or quad system must allow you to grow, you must be able to have the flexibility to grow your single system into a dual, quad or beyond. Likewise your dual system should allow you to stitch together other systems of the same FPGA type and architecture to create a quad system.
Even with this flexibility, there are some implications to the number of interconnects and I/Os when stitching together these systems so careful consideration must be given to which system you initially choose. You will notice in the following diagrams that building these multi-FPGA systems require the ability for the boards to be connected via cables or interconnection modules. These systems will also need some sort of external module to manage global clocking and reset mechanisms.
Connection of two single FPGA prototyping modules
Connection of 4 single FPGA prototyping modules
Going Beyond 4 FPGAs
What happens if your design needs require going beyond the use of either 4 single FPGAs, 2 dual FPGAs, or a quad FPGA system? This increase in complexity triggers a whole new set of scalability questions. These questions can be broken down into several categories.
Space
How big of a desk or lab area do you need to work with a large number of FPGAs?
Although you can continue to stitch together multiple prototyping boards to expand beyond a quad system, your physical lab space may be limited making the connections of these boards much more complicated. Not only will you be dealing with space issues, but also the cabling of these systems will become very unwieldy.
Scalability & Flexibility
What if you require more logic and memory capacity or the system interfaces or memory types change?
Can you configure the large number of FPGA resources for multiple designs?
Because of the investment into large multiple board systems, these reusability type questions become important. It is much easier to invest in single board systems if the expectation is that the board will have limited use beyond the initial design, but when the initial design require the use of a larger prototyping system, your investment must consider possible changes in the prototyping environments and future project uses.
Global System Control
How do you provide low-skew clocks and resets to a large number of FPGAs that you are using for the same design?
Is there a way to easily download to FPGAs remotely and how fast is it?
Lower-end software can provide some sort of support for these questions but may miss some basic requirements. Furthermore, the larger the overall hardware system, the more difficult it is to control such things as clocks and resets. Downloading for larger systems can be a cabling nightmare. Higher-end systems that offer complete runtime support and chassis with minimal cabling help reduce the pain dramatically.
Power Supply
How do you provide power to a large number of FPGAs?
Can each FPGA be individually controlled (On/Off/Recycle)? Is there a power-monitoring feature that you can employ?
Providing power individually to each board can impose even more physical lab space issues not to mention complicating the management of powering each board.
Reliability?
How do you verify that all your clocks and interconnections are correct?
Is there an easy way to monitor the system as well as the individual FPGA statuses?
Making sure a complex prototyping system as large as 32 FPGA works correctly is extremely difficult without automation. If a design isn’t running correctly, a great deal of time can be wasted trying to manually determine if the error is due to the design itself or the FPGA system. Software that provides automated self-test capabilities as well as automated voltage, current, and temperature monitoring with shut down will provide much needed peace of mind.
Seeing FPGA Prototyping for Juno In Action
S2C will be demonstrating their latest Prodigy Juno ARM Interface Module for FPGA prototyping at the upcoming ARM TechCon 2016 so that you can get a close up view of how FPGA prototyping is done for a Juno-based design.
S2C provides a complete easy set up reference design as part of the Prodigy Juno ARM Interface Module package. It connects S2C Prodigy Virtex UltraScale and Kintex UltraScale Logic Modules with the Juno ARM Development Platform. The reference design shows:
1. Comprehensive self-testing between the two environments
2. Expanded FPGA capacity
3. Early porting of OS kernel or driver code for ARMv8-A processors
4. High-speed DDR4 memory access between the Logic Module(s) and Juno ARM Development Platform
This site uses cookies to collect information about your browsing activities in order to provide you with more relevant content and promotional materials, and help us understand your interests and enhance the site. By continuing to browse this site you agree to the use of cookies. Visit our cookie policy to learn more.
-383.png)
