Design Feature: February 17, 1994

All CAE tools accept PLD-design methods. Thus, using PLD-design methods leads to a very simple method for moving designs to new types of PLDs. Using these methods helps you take advantage of the increased performance and lower cost of newer devices and lets you combine new designs with existing ones.

Each CAE vendor has developed a proprietary database for sharing circuit-design information among its own tool set. To transfer circuit-design information from one vendor's tool set to another's, you must perform a complex translation. This translation may misinterpret or drop information altogether, yielding an erroneous result.

The ostensible "industry-standard" Electronic Design Interchange Format (EDIF) netlist typifies this problem. EDIF can represent circuits at levels ranging from a complete graphical, functional, and parametric representation to only a primitive functional representation. As a result, one vendor's EDIF netlist reader may not totally understand another's EDIF netlist. Consequently, using incompatible netlists would make your translation at least incomplete and at worst inaccurate.

However, translation becomes simple and reliable if you use PLD-design methods to express your design. In particular, most designers use Boolean equations to describe their PLDs' functions because of the AND/OR architecture of PLDs. Fortunately, because PLDs have become extremely popular as a "can-do-anything" circuit element, CAE vendors have integrated PLD-development tools into their CAE tools. These tools produce Boolean equations in various formats, which you can easily translate from one to another, giving an accurate and complete functional description of a circuit.

To illustrate, consider the high-level description of a 10-bit, up/down, preloadable counter in Listing 1 (see EDN BBS). This functional description uses ABEL 4.XX, a device-independent language. A device's description at this level does not translate easily to any specific PLD. However, you can use a PLD compiler to transform the high-level ABEL description into reduced Boolean equations (Listing 2 on EDN BBS)—the fundamental description of a 10-bit up/down counter. Now, you can move this Boolean representation of the counter to virtually any development environment with only minor changes.

Because all mainstream PLD compilers produce reduced equations with virtually identical syntax, migrating these equations from tool to tool is simple. For instance, the PDS tool from Lattice for developing devices in the company's pLSI family has an equation syntax virtually identical to ABEL's reduced-equations syntax. Similarly, the PLA files that ABEL, Minc, and CUPL produce all follow the standard rules for PLA-file syntax.

You can even extend this technique of obtaining reduced, transferable equations from a schematic diagram. Many CAE companies include PLD compilers, with associated PLD libraries, in their design environments. With components from their PLD library, you can use the CAE tools to produce reduced Boolean equations that describe the schematic. You can then integrate these equations with functions expressed in a PLD-description language to form a set of equations that completely describes your circuit. The design tools may produce these equations in the familiar textual form or in an industry-standard format known as PLA (see box, "Interpreting PLA files").

If you capture your old designs in the form of these equations, you just follow a series of basic steps to implement them in a new programmable device:

• Define the I/Os.
• Compile and minimize PLD equations.
• Add MSI and SSI functions.
• Implement 3-state circuits, inversions, and preset/reset.
• Combine all PLD source files into a single file.
• Partition the circuit over the new device's logic blocks.
• Import and verify the design.
• Place and route the design using tools for high-density devices.
• Assign the I/O pins.

An upgraded PLD design begins with defining the I/Os of the new device based on the circuit developed for the old devices. You must first determine if the new design will be pad-limited (the new device does not have enough I/O pins) or gate-limited (the new device does not have enough internal logic).

If the design is pad-limited, you must choose a device with a higher pin count or partition the design among two or more lower-pin-count devices. Using a higher-pin-count device raises the cost of the implementation and typically results in a large amount of unused internal logic. Multiple lower density devices typically incur a lower cost and better utilization of available logic.

A gate-limited design mandates that you select a higher density device. This choice usually leads to unused I/O pins. You can take advantage of the unused pins to introduce additional functions, providing that the design does not become gate-limited again.

As a shotgun approach, you can simply draw a box around a circuit, count the I/O and gate requirements, and select a programmable device meeting this gate and I/O count. However this simple-seeming task can be complex, requiring good engineering judgment of how to best use the high-density device.

Another straightforward method to estimate gate count uses SSI, MSI, and PLD equivalents. By adding the number of these circuit blocks required for a circuit, you can determine if the design fits into a high-density device. For instance, the generic logic block of the pLSI family of high-density devices is roughly equivalent to one-half of a 20V8 PAL device. Extending this approximation, roughly one MSI device or two SSI devices can fit into each logic block.

To partition a circuit implemented with MSI, SSI, and PLDs, look for those nodes that are best suited for interconnection within the new device. These nodes typically travel from one device to only one or two other devices. Assign nodes that connect to many devices to the new device's I/O pins, unless you vacuum all the destination devices into the new high-density device.

This approach eases determining whether you should implement a node within the high-density device or allocate it as an I/O pin. Signals that connect to a device not implemented in the high-density device become I/O pins by default. Naturally, nodes going off-board must become I/O pins of the high-density device.

Clocking can also impact how you partition a circuit. If the circuit requires more clocks than are available in one of the new devices, for example, you should partition the circuit over multiple devices, such that circuits with common clocks are in the same device.

After defining the circuitry to be placed into the new device, you begin converting the design into the new device's format. A typical design contains many PLDs and a few MSI and SSI devices. Most PLDs have an associated source-equation file, the source for design equations to be imported into the device-specific software for the new high-density device.

You should reminimize the old equations in the original PLD design before converting them into the high-density device's format. While designing with PLDs, you typically use only Boolean reduction. Advanced reduction algorithms available with standard third-party compilers can further reduce the number of product terms required for a function. These reductions produce a lower gate count and easier implementation into the high-density device.

In some cases, the original design's documentation may not be available. In such a case, you may have only to access a JEDEC fuse map for some PLDs. You must decompile this fuse map into the source equations and reminimize the equations. The decompilers produce raw equations that have generic names for the equation's variables and parameters:

Although functionally correct, these equations are difficult to read. Using the "search-and-replace" function available on word processors, you can recast the generic signal names to match those on your schematic. Signal naming is important because development software and high-density development software connect signals with common names.

At this point, you should add any MSI and SSI functions that you want in your revised design. You can easily integrate MSI and SSI functions into the new device by creating a PLD-design file that emulates the functions and importing that file into the device's design software. Most MSI functions fit neatly into a PLD, especially when a designer uses a PLD such as a 22V10 PAL device whose flexible architecture simplifies I/O and product-term allocating. The same procedure for SSI devices is applicable, but combining AND, OR, and INVERTERS into the MSI- or PLD-design equations should be very simple.

By using the same names on the inputs and outputs of the MSI PLD as on the schematic, the resulting file becomes ready for converting and importing.

An alternative method for implementing these functions is to find the closest equivalent circuit to the desired function within the macro library provided with the high-density-device software. Both of these techniques aim to develop functionally correct equations that best utilize the pLSI's architecture.

You can then add PLD files containing MSI and SSI functions to the files containing the converted PLD equations. The goal is to derive functionally correct equations in standard compiler format.

Trying to implement 3-state buses within an ASIC or high-density devices can create problems, such as causing outputs to go undefined. In fact, many high-density devices can't implement internal 3-state buses at all. As a solution, you can implement 3-state functions with a 1-of-N select function (Ref 1). The inputs to the selector are the signals that would be tied together on the 3-state bus. The select lines of the selector are the individual 3-state enable signals. This technique, commonly used in ASICs, appears in Fig 1.

You would rewrite the 3-state equations for a 1-of-N selector this way:

Assuming that the SIG_1A and SIG_2A expressions use typical PAL-type equations, they would have this AND/OR structure:

Given the wide variety of device architectures, you should investigate active-high vs active-low internal signals to achieve the highest utilization of the device's resources. The following equation is an example:

If you can't implement this equation with a hardware inverter, you can use Boolean expansion to produce an alternative:

This equation requires seven product terms as opposed to two when implemented into a PLD-type device architecture like that in the pLSI devices (Fig 2). The expanded Boolean equation also requires two extra feedback terms to implement the OR-AND function in an AND-OR device architecture.

A frequently neglected, but nonetheless necessary, requirement for digital designs is a reset mechanism. All state-machine designs should have a known power-up state. If you attach a reset line to all your state-machine registers, such a line would unnecessarily use significant routing resources. The reset mechanism should take advantage of the hardware-reset resources available in the new device. You should remove individual reset signals from your design equations and instead use hardware reset.

Many programmable-device architectures provide only reset and no preset mechanism. In these cases, you can complement outputs requiring a preset signal and still use the hardware reset. Alternatively, you can make the preset function synchronous by adding a preset term into the design's equations.

Last, when placing new logic in the high-density device, you should partition that logic into available logic resources. For the pLSI family, you simply write Boolean equations or use the available macros. With the exception of a few keywords, you can enter the equations just as you would using third-party design tools.

The *.DOC files produced by third-party compilers come in an industry-standard format. These files contain reduced equations derived from the source file, JEDEC maps, high-level state-machine language, truth tables, and standard equations. You should combine all the individual PLD and MSI *.DOC files into a single source file for partitioning over the high-density device.

Using a pLSI device as an example, you can collect equations into groups of four outputs to partition the PLD equations to fit into the four outputs of the pLSI device's logic blocks (Fig 3). (You must place headers and trailers around the four equations to direct the pLSI design software to partition the equations into a particular logic block.)

The software then maps the equations into the logic block's 18 inputs, 20 product terms, and four registered or combinatorial outputs. Additional logic capacity results from product-term sharing among the four outputs and an optional exclusive-OR gate fed by a product term and an AND-OR term.

The final conversion step is defining the I/O cells. The I/O cell for the pLSI device's definition is

Once you have partitioned your design over the new device(s), you must import the device's source file into the design software for verifying, placing, and routing. You then follow the steps outlined for the device's development environment.

This technique for creating a design for a programmable device builds upon PLD-design methods. In summary, the following guidelines can simplify your efforts:

• Decide if the design is I/O- or gate-limited.
• Choose the appropriate new device.
• Use as many of the original Boolean functions from low-density source files as possible.
• Convert 3-state outputs to 1-of-N multiplexer outputs.
• For reset functions, use the global reset for the entire device or asynchronous reset for specific logic resources.
• Remain within the logic resources when partitioning the circuit.

Following this method brings you the significant manufacturing benefits of new generations of programmable devices: smaller boards, simpler test procedures, faster development, and fewer parts in inventory and assembly. e

Author's biography

Mike Trapp is a field applications engineer for Lattice Semiconductor in Irvine, CA. He has worked at his present job for three and one-half years. He obtained a BSEE form the University of Colorado, Boulder. In his spare time, he enjoys soccer and other outdoor sports.

Reference

1. Small, Charles H, "Where CMOS rules, multiplexers slave," EDN, August 5, 1993, pg 57.