Design Feature: May 9, 1996

So many design tools are available that you might question the need for yet another one. However, a relative newcomer, the Library of Parameterized Modules (LPMs) is proving its worth by providing a path for users to adopt a high-level design methodology using (conceptually) low-level techniques.

The first taste

Consider where LPMs fit in the big picture before examining them in detail. In electronics, devices and methodologies tend to appear, disappear, and reappear in different guises. Many industry observers would say that ASICs emerged in the early 1980s, but the concept actually originated 15 years earlier, thereby predating the introduction of conceptually much simpler PLDs.

In 1967, Fairchild Corp (Hasbrouck Heights, NJ) introduced the Micromosaic, which contained a few hundred transistors. The key feature of the Micromosaic was that the transistors were unconnected. A designer used a computer program to specify the function the device was required to perform, and the program then determined the necessary interconnections and generated the masks required to complete the device. The Micromosaic, therefore, was the forerunner of modern ASICs and was one of the first real applications of computer-aided design. This device also exhibited one of the first examples, albeit rudimentary, of high-level design coupled with logic synthesis.

Schematic-only techniques

Had designers pursued the concepts behind Micromosaic, high-level design techniques would almost certainly have enjoyed widespread acceptance much sooner than they did. Unfortunately, however, this technology faded into the background for a while. When the use of ASICs became more commonplace in the early 1980s, designers based the devices' design on traditional methodologies and techniques that had been established for circuit boards. Thus, the designers of early ASICs used schematic capture to describe the function of their circuits as primitive logic functions and the connections between those functions.

The schematic approach does convey certain advantages, not the least of which is that it reflects the way in which designers think at the lowest level of abstraction. The approach also allows expert designers to handcraft extremely efficient functions. However, entering gate-level schematics is time-consuming, and this approach doesn't lend itself to what-if analysis at the architectural level. Also, verification using simulation is extremely CPU-intensive at the gate level, and it is difficult to retarget gate-level schematics to new device technologies because of the different symbols and design rules.

Because early ASICs typically supported only 2000 to 5000 primitive gates, the schematic-capture approach was at least tenable, and it remained in force throughout most of the 1980s. However, as gate counts continued to rise through 10,000, 15,000, and 20,000, it became increasingly difficult to design these devices using traditional techniques. Thus, the tail end of the 1980s and the beginning of the 1990s saw the emergence of language-driven design (LDD), which combines hardware-description languages (HDLs) and logic-synthesis technology.

Examining LDD

The early examples of LDD involved proprietary languages, but the industry eventually standardized on VHDL and Verilog. HDLs are appropriate for describing both control and datapath logic at a reasonably high level of abstraction. Using this technique allows designers to concentrate—in the early stages of a project—on the architecture of the design rather than implementation details. Simulating designs is more efficient at a high level of abstraction than at the gate level, and it is easier to perform what-if analysis at the architectural level. Synthesis technology then allows designers to migrate these high-level representations to the implementation level, and this approach facilitates design reuse by letting you retarget the design to alternative implementation technologies.

General studies show that LDD techniques increase designer productivity in terms of gates per day by a factor of at least 10 compared to designing at the gate level. Based on these promises of delectation and delight, several early adopters became overenthusiastic, in that they decided that LDD was the only way to go and discarded schematics as being "yesterday's technology." In reality, nothing comes for free, and LDD methodologies have their own problems, such as the fact that describing a design using an HDL doesn't usually reflect the way in which the designer thinks. In addition to learning the HDL along with software-design techniques and disciplines, the designer also has to learn how certain constructs and statements affect the synthesis tool. Today's synthesis tools are reasonably powerful and may help you to obtain good results. Using these tools, however, can allow designs to get out of control. Writing the code in two ways that simulate exactly the same in register-transfer level can synthesize to radically different gate-level implementations.

Even worse, portions of designs may be unamenable to logic-synthesis techniques; you must capture these portions inherently at the gate level. Thus, the industry came to realize that schematics still had a role to play: First, you can use schematics to graphically describe the design in terms of high-level functional blocks and the connections among them, and, second, you may be obliged to use schematics to describe certain portions of the design at the gate level. The resulting "mixed-level" design style offered the best of both worlds by allowing designers to mix schematic and HDL representations.

Flow charts and state diagrams

The early mixed-level design tools allowed designers to create a schematic of functional blocks and the connections among them; in these schematics, each block represented a functional unit. The designer could then "push" into a block and describe its contents as a gate-level schematic or as a textual HDL using an appropriate editor. However, problems still remained: The designer had to learn the HDL in question, and numerous subtle tricks of the trade existed for creating the HDL in such a way that it synthesized efficiently.

Thus, the current generation of mixed-level design tools augment the schematic and textual capabilities of the first generation by supporting more sophisticated graphical-entry mechanisms, such as VeriBest Inc's (Boulder, CO) flow charts and state diagrams (Figure 1). Again, designers can commence by creating a block-level schematic at a high level of abstraction, but, on "pushing" into the block, they can represent its contents as a flow chart or state diagram. Designers can then process these graphical representations to automatically generate VHDL or Verilog in a form that is guaranteed to simulate and synthesize efficiently.

Other advantages of the graphical-flow-chart and -state-diagram techniques are that they closely reflect the way in which designers visualize the control portions of their designs, and designers lacking expertise or even familiarity with the HDL in question can use these techniques. These graphical tools can also serve as training aids, because designers can gain familiarity with a language by analyzing the generated code.

Unfortunately, although flow charts and state diagrams are ideal for describing control functions, neither is well-suited to representing datapath logic. Another problem with LDD is that most of today's synthesis tools target and work best with fine-grained architectures, such as those on ASICs. "Fine-grained" devices are those that the synthesis tool "sees" as primitive logic gates and simple register elements.

Toward the end of the 1980s, a new breed of devices—FPGAs—emerged. Although some FPGAs are fine-grained, others are constructed around different flavors of coarse-grained architectures (Figure 2). The problem with FPGAs is that each vendor can sport radically different architectures. Each of the programmable logic blocks contains several primitive gates and registers; in some architectures, the primitive gates essentially implement small truth tables. The inputs and outputs from the programmable logic blocks connect to programmable connection matrices, which, in turn, connect to programmable switching matrices. This type of FPGA is strongly layout-dependent in terms of functionality and propagation delays, and these devices require special "fitting" software to map the design into the device.

A designer could create an HDL representation either manually or using a graphical technique and subsequently could migrate this representation to a gate-level netlist via logic synthesis. Then, unfortunately, after the fitting tool performs task, the final result is typically nonoptimal in terms of resource usage and timing. In other words, if the designer could work at a slightly higher level of abstraction, such as multibit multiplexers, registers, counters, and adders, then the fitter could recognize and treat as special cases these higher level functions. The benefit of this approach is that the fitter could contain handcrafted algorithms for each of these higher level functions and could, therefore, return better results.

LPMs to the rescue

In a rare example of cooperation, a group of EDA vendors and chip manufacturers met in October 1990 to hammer out the details of an alternative design methodology. Their main goals were to offer a vendor-independent methodology that didn't target a specific FPGA architecture, oblige the user to learn an HDL, or require any investment in synthesis technology. LPMs were the result. The idea behind LPMs was to use graphical techniques based on a library of high-level, parameterizable building blocks, similar in concept to connecting SSI and MSI devices at the board level. The basic idea behind LPMs is not radically new, and a number of proprietary implementations of template-driven approaches are available, such as DMAG and AutoLogic Blocks from Mentor Graphics (Wilsonville, OR), Synthetic Libraries from Synopsys (Mountain View, CA), and XBLOX from Xilinx (San Jose, CA). However, one of the key differentiators of the LPM approach is that it is part of a nonproprietary industry standard. The group that originally described LPMs presented a preliminary version of this standard to the Electronic Design Interoperability Format (EDIF) Committee in March 1991. The EDIF Committee subsequently adopted it as an extension to the EDIF 2.0.0 standard (EIA-548-A). The result was a generic set of 25 parameterizable templates for some of the most common datapath functions in digital design. These templates allow designers to represent complex behavior without worrying about implementation-specific details and comprise the following functions: