What! How big did you say that FPGA is? (Team-design for FPGAs)

Design flows
There are always trade-offs to maneuver when prioritizing design requirements, such as clock speed, power and size. Top-down synthesis, with placement and routing, generally provides the best quality of results (QoR), but often disturbs areas of the design that have already been validated. This can result in time-consuming re-spins of those affected areas. Bottom-up synthesis placement and routing allows sections of a design to be locked-down for predictability and stability, but may cause a penalty in overall QoR. Wouldn’t it be nice to have it both ways? Ideally, achieving all goals without making big trade-offs is preferred. To do this, designers need the following:

• Mixed top-down and bottom-up methodology
• Fast turnaround and maximum QoR
• Integration with FPGA vendor tools

A mixed top-down/bottom-up design methodology allows multiple team members to work independently on their portion of the design while giving the top-level integrator options to tune the overall design for highest QoR. Certain timing-critical blocks that have already been developed and tested may be “locked down” so there are no changes made to them, while others can remain soft so that optimization across these soft blocks can be performed. Optionally, a final top-down synthesis run may be performed to achieve optimal QoR. Floorplanning can be difficult and yield unpredictable results, so, while necessary for some designs, it should not be a requirement. Self-contained functional blocks that include RTL and associated design constraints are highly desirable in a team-design methodology and also support design/module re-use.

Fast turnaround through synthesis and place-and-route is a top issue as FPGAs move from 40-nm into the 28-nm process. Runtimes of 20 hours or more are not acceptable in most cases. Whether the design is broken into sub-blocks manually by an engineer or automatically by the tools, taking advantage of multi-processor computers to perform parallel processing is becoming a must-have capability.

Tight integration with FPGA vendor place-and-route tools is also important. To achieve optimal results, constraints created by synthesis or physical synthesis tools should be communicated to the place-and-route tool in a reliable, efficient way. Additionally, the synthesis tools should work in conjunction with FPGA vendor tools, such as Xilinx EDK or Altera SoPC Builder, for processor-based FPGA designs. Embedded processor subsystems created using EDK or SoPC Builder may be easily integrated into the synthesis flow by instantiating the vendor-generated embedded subsystem into the top-level HDL design.

QoR is always important, especially for the FPGA intended for use in an end product. Providing designers with a mixed top-down/bottom-up approach enables the appropriate trade-off between design stability and performance to be made. Prototypers not as concerned about timing performance can lock down most blocks for a high level of predictability, while FPGA designers can lock down only the most critical blocks and let the tools optimize across some block boundaries for improved timing performance.

Debug has become an increasingly difficult task, especially when using traditional approaches, such as observing pins in an operating FPGA with a logic analyzer or inserting an embedded logic analyzer into the FPGA itself and observing selected signals with tools like ChipScope-II or SignalTap. In addition, it is very difficult to keep track of the signal names that synthesis runs may have changed when debugging a netlist. A better and far more productive approach is to instrument and debug directly in the RTL source code, with which the designer is much more familiar. The more complex the FPGA functionality, the more sophisticated the triggering mechanisms need to be to observe design behavior. Having the ability to trigger on a state machine, for example, can be extremely useful. In this case, the number of states can be defined during instrumentation. Then, at debug time, the user can define what happens in each state and transition depending on the pattern matches computed by the trigger conditions. This greatly assists in discovering those difficult-to-find bugs in the design.

Tracking and reporting
There are several tracking and reporting capabilities that can assist project leaders who are tasked with integrating multiple sub-projects and keeping each team on schedule. Of great value is the ability to run a report that concisely shows the current status of all the components of the full design with problem areas highlighted, such as timing not being met or an area-budget overflow. Reports should be flexible and customizable so that they can be tailored to the specific needs of the project team. In general, here are a few of the key things to look for in tracking and reporting tools:

• An engineer or team leader should be able to generate a report at both the sub-block and top-level of the design. This allows individual team progress to be evaluated and tracked, as well as the overall project.
• Key pieces of information to be included in reports are things like paths with negative slack, FPGA resource utilization (RAM, DSP and LUTs) and other custom information that might be desirable, such as a specific type of compiler warning.
• A certain HDL coding style may need to be enforced, so a warning message that flags deviation from the policy is very useful.
• Since there are potentially many (hundreds or even thousands) of warning messages that can appear during implementation, it is far more helpful to be able to filter out messages that have already been reviewed and accepted so that only new ones appear in subsequent runs.
• The ability to sort error messages by type provides a more efficient way to go through large numbers of error and warning messages.
• A team member or team leader should have an easy way to compare and analyze the different implementations that have been performed on a particular sub-block and the top-level design. The ability to track and store results for the various implementations of a block allow a designer to more easily determine the best implementation and have all the associated tool settings and constraint files necessary to reproduce the desired results.

Conclusion
Larger teams of engineers are increasingly required to design and verify FPGA devices. Moving from one or two engineers on a project to a team of 10 or more has pushed the limitations of design tools that are created for smaller engineering teams to the breaking point. As a result, there is a need for new team-design capabilities, such as mixed top-down and bottom-up flows, distributed development methodologies, faster tool iterations and advanced project reporting at the sub-block and top-level of the design. These topics should be considered before embarking on a large FPGA design to help achieve the best results.

About the author
Jeff Garrison is Director of Marketing, FPGA Implementation at Synopsys. Jeff brings more than 20 years of experience in marketing and software engineering to his role as director of product marketing for FPGA implementation at Synopsys, Inc.  In this role, Jeff's responsibilities include product strategy, definition, and launch for Synopsys' FPGA products including Synplify, Synplify Pro, and Synplify Premier.

Prior to joining Synopsys, Jeff worked as senior director of product marketing at Synplicity, Inc., which was acquired by Synopsys in May 2008.  Jeff also held positions as a senior product marketing manager for several IC design products at Cadence Design Systems, product engineering and technical support for VLSI Technology and worked in the software support division of Hewlett Packard.

Jeff holds a bachelors degree in computer science from Indiana University.