2010년 2월 14일 일요일

Partitioning an ASIC Design into Multiple FPGAs

CMP - United Business MediaProgrammable Logic DesignLine

February 10, 2010

By Juergen Jaeger, Synopys Inc.

Most of today's system-on-chip (SoC) designs rely on field-programmable gate arrays (FPGAs) as a way to accelerate verification, start software development early and validate the whole system before committing to silicon. The FPGA may be an intermediate or, because tough economic realities cannot justify $1M+ in non-recurring engineering charges for an ASIC, initial implementation platform for the SoC design.

Today's FPGAs are large enough to contain a complex system-level design. It's practical, however, for these designs to be partitioned among several FPGAs for various reasons. For example, you may invariably need external components in your system. Also, using several smaller devices can enable a more cost-effective solution than using one big FPGA.

But, integrating your design into several FPGAs can create interesting partitioning problems, especially for larger and/or highly connected designs.

What are the Major Partitioning Considerations?

The most obvious problem for any design is the answer to the question: Will it fit into your FPGA prototype? If you have a very small design, you may fit everything onto a single, large FPGA and you technically won't have a real partitioning problem.

Figure 1: ASIC design start sizes

A note of caution: even though you may think that your design fits based on the ASIC gate count, your design may still need to be partitioned because of the resources available on the target FPGA. Memory or DSP-intensive ASICs frequently fall into this category of design.

Based on the current design sizes as shown in Figure 1, one-third to one-half of ASIC designs will fit into one of today's large FPGAs. Assuming that you have a bigger design and partitioning is required, you need to carefully estimate the number of FPGAs required in your prototyping hardware.

When you must partition, the three big concerns to keep in mind are:

  1. Which blocks need to fit into which FPGA so that you do not exceed the capacity or other resources of the FPGAs in your hardware-prototyping system?
  2. How do you interconnect the FPGAs? Most ASIC designs will exceed the number of available I/Os in the FPGA. Pin availability is further compounded by trying to meet timing.
  3. Finally, ASIC designs often include elements that need to be converted to an appropriate form for an FPGA implementation, such as ASIC memories or gated-clock tree structures.

Compounding these concerns is the decision of whether you want to partition the design at RTL or later in the design phase, such as at the gate level. Both approaches have advantages and disadvantages and are also, in part, dependent on the rest of your design flow.

Partitioning at What Level?

One of the first questions to ask when you partition is whether you want to partition at a netlist-level abstraction or a higher level of abstraction. There are advantages and disadvantages to both. The primary advantage of partitioning at the netlist level is that the area estimations are easier to calculate and more accurate since your design is largely implemented with the optimizations already taken into account. So, it is easier to accurately estimate the gate count and know how much room you will need. Conversely, dealing with a very large database may make partitioning difficult to perform. For example, a design with 90,000 lines of RTL may have a file size of 3.5 Mbytes, while the same design in netlist format may be 6.4 Mbytes in size. The difference could be significantly greater if there is a significant amount of instantiated blocks in the RTL; a 4x difference would not be unusual. In addition, for debugging purposes, it is very difficult to discern from the large, flat netlist database what the problems are in the original RTL. Many things will have changed as the design went from an RTL implementation to a netlist implementation, including netlist names.

Manual Partitioning

Historically, many designs were partitioned manually. There are two major reasons for this. First, it may simply be standard procedure, the way things were always done. This is often the case when the new design has only minor changes from the old design, and partitioning may not be that difficult. The second reason for manual partitioning may be a lack of budget or time to invest in adding a new tool to a flow that already works. It is not uncommon to see designs partitioned in Microsoft Excel' with mapping to see the pin and trace assignments.

If you decide to partition manually, keep these factors in mind:

  1. You need to perform a chip floor plan to ensure that the partitions revolve around the design's bus structures and data paths. In other words, you need to make sure that timing-critical modules are kept together and in close proximity.
  2. You need to ensure that extra logic does not need to be placed next to multiplex signals when there are not enough I/Os between FPGAs. You also must have intimate knowledge of the FPGAs that you will be using to ensure that the correct resources are available for your partition to function as expected.
  3. Finally, you need to perform gated-clock conversions, such as the conversion shown in Figure 2, to ensure that your ASIC design uses the primary FPGA clocks without introducing skews or timing issues.

Figure 2: Gated clock conversion

For the most minor of changes to an existing design, the completely manual approach may be feasible, especially if done by an expert designer at the RTL level. But, for anything more complex, the manual option is not really "manual". Manual gated-clock conversion for a multi-million gate ASIC is impractical and is usually done through a script or user-written program. Similarly, the logic to multiplex signals between the FPGAs is also done through a user-written program. It would be very difficult to keep all the variables in mind without also writing error-checking routines to ensure that you have used the proper number of resources on the FPGA. It is also doubtful that floor planning can be done manually at the netlist level because of the database sizes and the fact that the design is already near a final implementation phase.

Remember, too, that the cost of using the manual partitioning approach is not just the cost of doing things manually, but also the cost of writing and maintaining the conversion and checking programs that need to be written to make the partitioning of a large ASIC feasible. For large designs, except for companies with large internal CAD teams, it is quite likely that the cost in terms of time and support will be prohibitive.

Automatic Partitioning

A small number of vendors offer automatic partitioners. Any automatic partitioning tool should offer the following features:

  1. The ability to consider and optimize for both area and pin requirements to reach a viable solution.
  2. The ability to run at both an RTL and a netlist level of abstraction (An existing design requiring minor changes might be done at the netlist level, while a new design might be at the RTL level.)
  3. Quick area-estimation capability to give you a general feel and confidence that your design will fit onto your prototyping board.
  4. Understanding of the functionality and capabilities of your prototyping board. For example, if your prototyping board has dedicated high-speed clock lines, the partitioning tool's ability to recognize and utilize this functionality greatly enhances your ability to meet system timing.
  5. The ability to set threshold levels to control the amount of logic allocated to each FPGA. You want to be able to set the lowest threshold possible because a near-capacity FPGA may lead to long place and route times. Conversely, you may want to set a high threshold if you have a very large design and have a limited number of FPGAs on your prototyping board.
  6. The ability to have your automatic partitioning tool run on a board design with undefined traces. This allows you to determine if it is feasible to fit a design within the intended pin and area constraints before investing in the purchase or development of a board. Running on a board design with predefined traces produces a comprehensive signal-to-trace assignment report for detailed analysis.

Even with the features described above, it is unlikely that you will be able to fully automate the partitioning of a design without some prior knowledge or intervention. There are two major stumbling blocks to automation that most current tools do not address: (a) the ability to handle black box IP and (b) the ability to optimally utilize all the features within the FPGA such as block RAMs and DSP blocks.

The most efficient route to partitioning is to have a partitioning tool that has both manual and automatic features, such as the one shown in figure 3. Using this interactive flow, you can partition some sections of the design automatically while partitioning other sections manually, especially if you have design-specific information in mind.

Figure 3: Interactive partitioning

Integration Considerations

Up to this point, partitioning has been presented as an individual task in the verification flow. To successfully verify a design, a partitioning tool needs to easily fit into your team's existing flow. While a GUI is important, it is important that your tool be able to support TCL commands and create scripts as many ASIC designers script most of their designs. Support for standards like Synopsys Design Constraints (SDC) is also important. SDC support allows you to use your existing ASIC constraints to drive the partitioning process and ensures that your prototype system complies with other design requirements.

Debugging is a necessary step in ASIC verification. Your partitioning tool must be able to define probe points to allow internal signals to be monitored as part of the I/O interface. Integration with the most common FPGA debugging tools such as Xilinx's Chipscope, Altera's SignalTap and Synopsys' Identify greatly help the debugging effort and allow users to use the tools they are most familiar with. <.p>

Another key capability of a partitioning tool is that it supports the FPGA devices on the prototyping board. This may seem obvious but is often overlooked. While most commercially available partitioning tools support the largest Altera and Xilinx FPGA devices, some partitioners may not support legacy FPGAs or devices from other vendors. This additional FPGA device support gives you greater flexibility to build or buy FPGA hardware prototyping systems from vendors offering the best functionality or price for your needs.

Sound Partitioning Decisions

There are many ways to partition a design to fit into your FPGA prototyping hardware, and partitioning can be done at various phases and at different levels in the design process. With the exception of the most basic designs, a tool that offers both manual and automatic partitioning functionality can play an important role in your overall success. Equally important, this tool must be able to integrate into the overall design flow.

Yes, partitioning a large ASIC design into multiple FPGAs can be challenging. Doing some upfront planning and selecting the right tool flow can make it a lot easier, assure success and achieve the desired result: a thoroughly verified ASIC and first-silicon success.

All materials on this site Copyright © 2010 TechInsights, a Division of United Business Media LLC All rights reserved.

==========

출처: http://www.pldesignline.com/222700643

댓글 없음: