S2C Limited.
S2C Limited.

How Do I Choose Which Solution to Implement?

How Do I Choose Which Solution to Implement? Jan 31, 2023

Now that you understand when and why you need FPGA prototyping, you need to know the various FPGA prototyping solutions that you can employ to maximize your investment. To set up your analysis for the various FPGA prototyping options, you have to consider your design size and application, design stage, and resource management requirements. You'll also need to take a look at your FPGA prototyping specifications and then various options in terms of off-the-shelf or building your own.


Design Specifications


For the size of your design, think in terms of capacity. Without enough gate-level capacity to accommodate your design, you can't build a prototype. Most systems need adequate memory too, so having sufficient memory available is critical.


You also need to think about the type of application you are building. Is it IoT, Automotive, Super Computing, Data Storage, Cloud Computing, Image Processing, a Communication Network, or is it something else?


Is it a design that contains a large number of DSPs or does it require a lot of logic resources or memory resources? Is it based on a specific protocol like PCIe or a particular bus standard like AXI? There are many different types of prototyping hardware and software solutions that cater to these different application types. Some hardware boards are flexible enough to scale with your design and allow you to adapt to different design types through extensions and daughter cards while others do not.


The design stage refers to when within your design methodology flow you'll implement FPGA prototyping. We talked earlier about the FPGA prototyping sweet spot being used during software testing and validation and that it is well suited for designs that are fully rendered in RTL that can be mapped to an FPGA. However, recent advances in FPGA prototyping technology have extended its value into other areas. For example, many designs may not be completely mapped to an FPGA and may be only partially available as behavioral models in descriptions such as C++ or SystemC.


In these cases, transaction-level interfaces play a critical role in being able to bridge the abstraction level between behavioral models and live hardware. Transactors offer a way to communicate between software running on a host and an FPGA-based prototyping platform that often includes memories, processors, and high-speed interfaces. These transactors can be implemented over a well-known bus protocol such as AXI or an industry-standard transaction protocol such as SCE-MI. Transactors extend the functionality of the system allowing it to be used for algorithm/architectural exploration, system integration with virtual prototypes, and exhaustive testing through software generated corner tests.


An often-overlooked aspect of design and verification is the management of hardware, software and personnel resources to maximize efficiency. This not only includes the assignment of tools to key engineers throughout the flow but also includes the behavioral reporting of these assets. In today's connected world, companies now have the luxury of taking advantage of engineering talent across the globe. Because of this, many design teams are geographically dispersed.


Access to FPGA prototyping systems have typically been constrained by the use of localized systems that require local management and control. This limited access has presented a significant hindrance to modern SoC design teams – especially software development teams – which again are often globally distributed. There are advances in FPGA technology to alleviate these circumstances to allow for wide distribution of hardware and management software resources through the cloud. If you are working with a globally dispersed team, this will be a factor in choosing the right FPGA prototyping platform for you and your team.


FPGA Prototyping Specifications


There are a number of FPGA prototyping solutions on the market. The above analysis will impact your decision on which one you choose. First, let's take a look at how your design size factors into the specific FPGA prototyping solutions. Individual FPGA capacity has increased significantly over the years reducing the number of FPGA devices needed. The vast array of FPGA options on the market span a wide range of capacities to fit your design size requirements. The larger your design, the most likely you'll need an FPGA or FPGAs with the capacity to follow suit. Today's FPGAs can handle designs of up to 50 million gates. Even with these high-capacity FPGAs you must keep in mind that the usable capacity of an FPGA is roughly 50-70% when incorporated into an FPGA prototyping environment regardless of the FPGA prototyping solution that is chosen. Given this fact and that most designs scale beyond the limits of a single FPGA, a multiple FPGA prototyping solution is the norm.       


Choosing an FPGA prototyping solution that can scale with your design's needs is preferred. To get the most from your prototyping solution, you must consider how easily the prototyping environment can scale. Does the architecture of the prototyping solution accept additional hardware be it more prototyping boards or specific daughter cards geared for a particular design type or design characteristic? Moreover, does the prototyping solution have the necessary integrated components to scale with your design? Some designs are so large that only a handful of FPGA prototyping solutions have the scalable architecture to keep pace.


Multi-FPGA prototyping platforms do have significant issues when it comes to I/O count and performance. Not only is mapping large multi- million gate designs to multiple FPGAs a challenging task, but performance may suffer because of timing delays between the FPGAs. Therefore, it becomes apparent that choosing a platform with the ability to handle complex partitioning is essential to reduce repartitioning and maintain proper real-time performance.


Multi-FPGA platforms also come with the added difficulty of debugging. It used to be that signals internal to an FPGA could not be probed unless they were brought out through the I/O. Fortunately, major FPGA vendors have internal logic analyzers to address the visibility issue. However, many of these internal logic analyzers have several limitations, including support for only single FPGA debug, limited memory size using FPGA internal memory, and long place-and- route times to change probes.


Debugging a design partitioned across multiple FPGAs is all but impossible without a tool that helps set up probes and makes signals easy to track based on their RTL-level names. Debugging should use FPGA I/O efficiently and maintain a useful debug trace.


Of equal importance is the ability to reuse a prototype (or even part of one) to save development time and lower implementation risk for future projects. But this is difficult to achieve with a board built for a specific project. As SoC designs grow in size, they may no longer fit in older FPGAs. If the interface to an external system is built directly on the prototyping board, it can't be reused for projects in which the interface is different. The ability to reuse your prototype platform enhances its usefulness, speeds the process of developing new prototypes, and reduces overall costs.


The first option is a full custom board often referred to as a build-your- own platform. The connections for custom platforms for both inter- FPGA and the external interfaces are very specific to a particular design, which is their advantage. The nature of these platforms lends itself well to increased performance and maximized use of external interfaces. Creating a custom platform is an extremely time-consuming endeavor resulting in an eventual reduction in productivity. The expertise necessary to create and implement such a solution can be daunting and not necessarily in the “wheel house” of most prototyping teams. Beyond this limitation, there is the fact that most custom platforms cannot be reused for other projects due to the specificity of project(s) they were designed for. When you factor in the time, energy, and risks associated with unproven build-your-own boards the expense get be quite high.


A second option is the off-the-shelf platform that is comprised of a pre- built prototyping board with fixed connections for communication between each FPGA as well as the external interfaces. This type of board is often referred to as an application-specific FPGA board. These can be comprised of a single FPGA or multiple FPGAs. Examples include Xilinx and Altera evaluation boards and many PCIe-based FPGA boards. The advantages of using an off-the-shelf solution are reliability and faster time-to-market. These solutions have been thoroughly tested to avoid bring-up errors when deployed in the field. The real differences between the various off-the-shelf solutions depend on the following:


  • The type of FPGA that is used,

  • How many FPGAs are used,

  • What external interfaces are on the board,

  • What expansion capabilities are there for the board,

  • Does the board come as a reference design?


These systems typically lack support for partitioning and debug. Scalability is usually not an option, often resulting in having to toss out the system when the design expands or external interfaces change.


The third option is a scalable or modular approach where cabling and connectors are used to connect multiple off-the-shelf FPGA boards. The connections for both inter-FPGA and external interfaces are user- defined. The benefit of this solution is that performance may be enhanced by the varying distribution of the interfaces and cables. This approach also fits most design needs in terms of capacity and external interfaces. These are reusable platforms, scalable and flexible as designs grow and design specifications change. When it comes to partitioning across multiple FPGAs (covered in depth later), the interconnections can be adjusted through cables and/or interconnection modules for higher performance. The flexibility with this approach is inherent, but along with it comes an enormous amount of cables to manage scaling beyond 4 FPGAs. There needs to be a balance between utilizing on- board interconnections versus cables. Should you use Single, Dual, or Quad FPGA modules as a basis to scale? As one of top FPGA prototyping market leaders, S2C offers comprehensive FPGA prototyping solutions, including partitioning software, multi-FPGA debug and a vast library of daughter boards to accelerate deployment.

Back to list Back to list
Related S2C Complete Prototyping Solutions
Neuro
Neuro enables users to quickly access FPGA computing power and CPU cluster resources deployed in data centers or company computer rooms through various terminal devices.
Connector Connectivity
Prodigy Interconnection Module Type CConnects 144 GPIO and 4 SerDes between two Prodigy I/O connectors.The spacing between two connectors is 75mm.Available TypesReference ClockP-PM-IMCFixed 100MHzP-PM...
Arria 10
S2C's Arria 10 Prodigy Logic systems offers low-profile chassis design with Intel Arria 10GX1150 FPGA.
What's New at S2C
Request for Quote
What type of chip are you designing
What is the capacity of the ASIC gate included in the design?
5 million-20 million
20 million-50 million
50 million-100 million
100 million-1 billion
More than 1 billion
Which FPGA do you prefer to use?
Xilinx VU440
Xilinx KU115
Xilinx VU19P
Xilinx VU13P
Xilinx VU9P
Intel S10-10M
Intel S10-2800
Not sure, need professional advice
What kind of FPGA configuration do you need?
Single FPGA
Dual FPGA
Four FPGAs
Eight FPGAs
Not sure, need professional advice
What kind of peripheral interface do you need?
How many prototype verification platforms do you need?
Do you need the following tools?
Segmentation tool
Multiple FPGA debugging tools
Co-modeling tool (allows large amounts of data to interact between FPGA and PC host)
When do you need to use our products?
0-6 months
6-12 months
More than 12 months
Not sure
Any additional comments?