Published on March 31st, 2009
Typically, a particular FPGA device is chosen not only for its logical functionality, but also because FPGAs in general are the right solution for the realities of low-volume production and late-cycle design changes.
But changes in product requirements or market dynamics can sometimes prompt a re-evaluation of this choice. It may be necessary to switch to an entirely different FPGA family such as one that offers size advantages or superior performance. Or sometimes an ASIC is a better choice due to its suitability for higher volumes and mass customization.
The key to success is flexibility, and the key to flexibility is to use a target-independent design methodology. Fortuitously, the design methods that allow easy migration from one FPGA architecture to another are similar to those that permit expedient porting to and from an ASIC or structured ASIC.
Using a target-independent design approach keeps one's options open and leaves room for architectural changes in the future.
Defining timing constraints is nearly as critical to describing a design as the RTL itself, and the code can be just as complicated. Nothing is more frustrating than getting trapped in a vendor's proprietary syntax, particularly when equivalent industry-accepted methods exist. Proprietary constraint syntax may be part of a vendor's strategy to "lock in" customers or it may be used for strictly technical reasons. In either case it complicates the effort to move to an ASIC if the project demands it.
In the ASIC world, the de facto standard for timing is the Synopsys Design Constraint (SDC) format. Leading FPGA synthesis tools have adopted this syntax to facilitate the migration of an ASIC design to an FPGA (either for production or prototyping) or conversely, from an FPGA to an ASIC.
Converting constraint syntax to and from SDC is typically more than just a Find/Replace exercise in a text file, which can be cumbersome in and of itself. Often there are constraints that lack a clear translation from SDC to a particular proprietary syntax. Likewise, there may be proprietary syntax that is equally difficult to translate in the opposite direction.
It is also worth pointing out that when an FPGA vendor uses its own language for timing constraints, this syntax ultimately must be fed to place-and-route. FPGA vendors own that part of the flow and there is no way around it. An advanced synthesis tool, however, can translate any imported or generated SDC file into vendor's format and pass it to place-and route. This way, a user can adhere to industry standards at the front and let the synthesis flow manage file formats under the hood.
This methodology works well when migrating between an ASIC and an FPGA, since the FPGA synthesis flows essentially borrowed the constraint format from the ASIC world.
On FPGA platforms, designs are implemented using a combination of technology independent RTL (Verilog, SystemVerilog, or VHDL) and/or technology cell instantiation. The latter method, though, is discouraged and its use best kept at a minimum.
Designers have a choice: either specifically instantiate certain technology cells or let the synthesis tool automatically infer the functions based on generic coding guidelines. Technology cells refer to primitive components such as multiplexers, buffers, memories, multipliers, or DSP blocks. Availability of these primitives depends on the FPGA. Figure 1 shows a conventional FPGA architecture with configurable logic blocks for standard logic, and embedded regions of the chip for memory and DSP functions, and clock management circuitry.
Figure 1: Standard FPGA architecture
Instantiation of primitive components allows the user to control the implementation of your design, but it requires commitment to a target architecture up front. For example, instantiating a Xilinx-specific DSP cell means re-coding that part of the HDL file with a different instantiation and understanding the differing details its architecture should it become necessary to move to a different platform.
An alternative –and recommended– approach is to write generic RTL and let the synthesis tool infer the appropriate FPGA implementation. If it becomes necessary (or desirable) to move to a new target architecture, the RTL typically remains unchanged and the synthesis tool manages the new implementation. The code in Figure 2 depicts a simple multiplier-accumulator that is inferred by the synthesis tool to the specialized DSP blocks in the target FPGA device.
Figure 2: Synthesis tool infers DSP using RTL
This concept of generic RTL coding is not new. In fact, it is commonly recommended because it simplifies the migration from one FPGA family to another, for example moving from a Xilinx family to one from Altera.
Importantly, the generic RTL coding approach is just as beneficial when migrating between FPGAs and ASICs. Generic RTL is understood in an ASIC synthesis flow, which means that few if any RTL changes need to be made when generic coding guidelines have been followed.
But not all functions can be defined in generic RTL. Digital clock management is one notable exception. The task of multiplying clock rates or shifting clock phases within a design is best handled by the PLLs or DLLs (phase-lock loop or delay-lock loop, respectively) built into the FPGA silicon. This is done usually by means of technology instantiations as opposed to generic RTL.
Specialized I/O cells are another example of instantiation-only components. These IP blocks are best managed by instantiating them at the design top level to keep any edits down to that one file, and by using wrappers and compiler directives to select the appropriate code. Wrappers can be used to interface the specialized resources with the rest of the RTL as shown in Figure 3. Here, the switch from Xilinx DCM to Altera PLL would be specified at the synthesis command level.
Figure 3: Wrappers used around clock management circuitry
Memories, on the other hand, are best placed throughout the design, not just at the top level. By adding a generic wrapper to the technology-specific memory instance and then keeping those technology-specific memory instances in a separate file, the designer needs only two versions of the memory file – one for each technology. At compile time, only the memory file that matches the technology target is used, and the design compiles seamlessly.
Note that generic wrappers need to know the specific memory size in question, as opposed to assuming conventional FPGA sizes. For example, consider a design module that needs a 512 × 16 single-port RAM. Imagine further that the designer wants to implement this memory as a 512 × 16 1PSRAM in the ASIC, and as an 18 Kb block RAM in the FPGA. The design module RTL needs to call a memory instantiation that is a 512 × 16 single-port RAM. In the ASIC-specific memory file, this is matched up to a compiled ASIC memory of that exact size. In the FPGA-specific memory file, the generic instance is wired to an FPGA-specific block RAM instead. By including only the right memory file, the design compiles correctly for each technology.
Admittedly, additional work must be done for a new target. But the method just summarized makes it possible to keep one HDL source for multiple targets.
The logic functions described here can be considered "building block" IP, as many of them are used to create a design. The use of larger IP models, such as processors, interface controllers, or bus logic is a different matter with different considerations...
FPGA and ASIC capacity continues to increase, and design sizes are also growing through increased integration and increased functionality. More and more frequently, demand is being met with purchased blocks. For the purposes of this discussion on design portability, these IP blocks can be classified into three categories:
FPGA IP in proprietary formats, provided by FPGA vendors: This category is inherently not portable and includes processors like MicroBlaze and NIOS. Changing technologies for designs using proprietary IP requires very significant effort to replace the proprietary functions. For example, changing a processor would also mean changing all the software written for that processor.
Open-market IP in RTL format: This type can be targeted at multiple technology platforms. This category may require no changes at all to the design, but the IP business license may have to be modified for the second use. An RTL block, for example, can be re-synthesized in a new technology.
IP with industry standard interfaces which can be swapped for similar cores: This class encompasses IP such as PCI Express, which has an industry-defined interface known as PIPE (PHY Interface for PCI Express) between the PHY and the control logic. If the designer's RTL ends in a PIPE interface, then it can be ported. If, for example, a PIPE-compliant FPGA transceiver element is used in the FPGA, then an equivalent PIPE-compliant transceiver can be licensed separately for use in the ASIC design, or vice versa. Other portable IP examples and their respective interface standards include DDR (DFI), USB (UTMI), SATA (SAPIS), and 10Gb Ethernet (XGMII).
Design portability may be the key to turning a hot-running FPGA device into a market-conquering standard product. By using SDC constraints, inferred primitives, wrappers around technology-specific functional blocks, and open-market IP, designers can open the door to multiple FPGA and ASIC technologies.
In doing so, they can make their products flexible enough to adapt to the most cost-effective and profitable implementation, regardless of changing requirements. Figure 4 summarizes the concept in simplified form. Today's engineers can lay the groundwork for design home-runs by carefully planning for future portability.
Figure 4: Target-independent methodology
Colin Baldwin is the director of marketing at Open-Silicon, Inc. He has 16 years of ASIC design and sales experience with Texas Instruments, Arrow Electronics, and Open-Silicon. Currently, Colin is focused on marketing and business development activities for Open-Silicon. He received both BEE and MSEE degrees from Georgia Tech.
Ehab Mohsen is a technical marketing engineer for the FPGA synthesis division of Mentor Graphics. Prior to joining Mentor Graphics, Ehab worked at Aptix Corporation as a technical marketing engineer. Ehab holds a BSEE from the University of California, Berkeley.