Phil Simpson

Altera - Sr. Manager, SW Product Planning


Focused on design flows for FPGA devices.

Web Links


EEWeb Stats

Is Your FPGA Design Reusable? (A Design Checklist)

h2. A checklist for creating reusable FPGA design blocks.
By Phil Simpson, Altera Corporation

Design and intellectual property (IP) reuse can improve the quality of your FPGA design, shorten your design and verification cycle and allow faster time-to-market. However, creating IP for design reuse comes at a cost; there is extra effort involved in making a design reusable.

If design engineers do not see the value that design reuse provides, why expend the effort in making a design block reusable? Formal development policies within a company can help to establish a design reuse methodology across a company. After the initial challenges in implementing a design reuse process on the first project, the benefits will become apparent on future projects. The following checklist is a good starting point for creating a design reuse policy and can be used as a reference by engineering teams developing reusable FPGA designs.

  1. The IP specification lists the requirements and details the feature set, performance expectations, size, usage model, etc. Not all design blocks need to be reusable, the specification must state whether a design is being architected as a reusable block.
  2. The specification has been officially reviewed by all interested parties. This increases the likelihood that the design block can be reused elsewhere in the company.
  3. Existing libraries of components have been reviewed to identify if existing IP with similar functionality already exists, i.e. practice reuse in the development process.
  4. The IP core name follows your company’s naming conventions. The name of the core should be description of designs function, e.g. AXI4 Clock Crossing Bridge.
  5. Signal and parameter naming conventions are followed. Signal and parameter names should be descriptive of the functionality. This makes it easier for end users to understand the impact of these parameters and signals on the design block.
  6. The IP core has default parameter values. Parameters provide the simplest way to create reusable design blocks. IP features, ports and functionality can all be parameterized for maximum flexibility. The default values should be the most common usage model for the design block.
  7. The IP uses standard interfaces. Adopt a common interface protocol on all of IP. The use of standard interfaces simplifies the interconnection and management of functional blocks that make up a design. It ensures compatibility between IP blocks from different design teams, simplifies the integration of individual design blocks into a full system design and enables “plug and play” interoperability of IP.
  8. The IP core meets the timing specification and all timing violations have been addressed. The IP core includes a full set of timing constraints.
  9. The IP passes LINT tests per your company’s established coding rules. It is recommended that you invest in a LINT to enforce coding guidelines and that it is fully integrated with version control/design check in process.
  10. The verification of the IP meets the functional, assertion, and line coverage goals as specified in the test plan. Note that the test plan should be developed at the same time as the functional specification for the design.
  11. The IP is adequately tested to cover the parameterization space and both expected and unexpected data patterns. Users of IP tend to be suspicious of other peoples design. There’s nothing gained in debugging someone else’s code.
  12. Provide a user interface and/or script for end users to instantiate the IP in their design. The interface should make it easy for the user to understand any applicable constraints. At a minimum, the IP should come with a documented command-line script that enables users to pass values to the parameters in the IP. Ideally it should come with a simple graphical user interface (GUI) to help users get started (see Figure 1).
  13. Design files and all packaging files adhere to your company’s standard version-control directory structure. If users know where the applicable files are located, it provides the user with confidence that the designer of the IP has thought through the process of reuse.
  14. Testbench and reference designs are available for use with the core. This is a “nice to have” feature that provides new users an easy way to get started with a design.
  15. IP cores, example designs and test benches can be simulated in company simulators. Users should be able to run the scripts and see the basic functionality of the design.
  16. Release notes detail all supported devices, FPGA device families, and versions of the EDA tools used on the design.
The Component Editor from the Qsys Tool is Used to Parameterize IP Targeting Altera FPGAs

The Component Editor from the Qsys Tool is Used to Parameterize IP Targeting Altera FPGAs

Now ask yourself, is your FPGA design reusable?

Further details on creating reusable FPGA designs are available in the book “FPGA Design: Best Practices for Team-Based Design“ by Phil Simpson. Springer Publishing, 2010.

Tags: FPGA, design, IP,

Comments on this post:

There are currently no comments.

Login or Register to post comments.
Click Here