The critical path in a hardware-development schedule often involves the development of an ASIC--a gate array, a standard-cell array, a "compiled" silicon device, or programmable ICs, such as a field-programmable gate array (FPGA) or a complex PLD (CPLD). An ASIC that isn't ready on time or that fails to operate in a system (even after passing all of its test vectors) can delay a project by months. You can improve your productivity as an ASIC designer by using a hardware-description language (HDL) and logic synthesis, but HDL requires a new design philosophy to be most effective. A successful transition from schematic- to HDL-based design involves facing a number of different issues.

The transition to HDL-based design isn't difficult, but it does require some planning to avoid unexpected complications. Development of electronic hardware using HDL design techniques is similar to development of software projects using a high-level language. In particular, an object-oriented design philosophy is directly applicable, especially when using VHSIC (very-high-speed integrated circuits) Hardware-Description Language (VHDL).

To make a conscious transition from schematic- to HDL-based design, you must first be fully cognizant of details in the schematic-design process. A schematic doesn't just show how electronic components connect; it also provides information that helps you understand how a circuit operates. This information consists of component functionality, data dependencies or data flow within the circuit, feedback paths, locality of signals, and parallel vs sequential operation. Looking at Fig 1, digital circuit designers will immediately recognize U1 as an AND gate, U2 and U4 as rising-edge-triggered D flip-flops, and U3 as an exclusive-OR gate. Fig 1a shows Mil-STD-806C and ANSI-STD Y32.14 1 standard logic symbols. Fig 1b shows ANSI/IEEE-STD-91-1984 2 logic symbols.

As component complexity increases, representing functionality with visual graphics becomes more difficult. Fig 2's symbols illustrate how complex symbology can get with MSI components. With LSI and VLSI components, symbols indicate only input or output, active-high or -low operation, level- or edge-sensitive triggering, and the type of drivers used for outputs.

Schematics and implicit information

Most good circuit designers provide a lot of implicit information on a schematic. Information flow, for example, normally goes from left to right. Vertical alignment typically represents operations that occur concurrently, although it may also represent independent operations. Many pipelined designs indicate stage synchronization by vertical alignment. Inputs normally appear on the left side of a schematic, and outputs appear on the right. Feedback paths appear as prominent signals that loop from right to left. Short signal lines connect only a few components; longer lines with many connections indicate a signal with greater scope. A special flag symbol indicates that a signal is nonlocal and provides a reference to the page or schematic coordinate of additional signal segments.

Rarely do schematics have attached notes that state any assumptions about the presentation of information. Someone looking at a schematic expects to get a lot of information in an implicit context from a style that designers have adopted via tradition.

Unfortunately, a textual source listing of HDL code doesn't provide all the information contained in a schematic's graphics. Although some of the graphical information is available--you have to provide names of interface signals and the directions of signal flows when you define VHDL components--other information doesn't easily fit into the HDL process. Signal feedback, locality, and sequenced vs parallel operation, for example, have no explicit graphical representation in HDL code. The HDL-development process must recognize these deficiencies and provide a means of compensation. When experienced circuit designers are just becoming familiar with HDL-based design, they often express a feeling of discomfort with the process. However, after being shown methods that compensate for information loss, they realize that information loss was the source of their discomfort.

The fact that missing information is indeed a problem is evident in the popularity of graphical tools as front ends to HDL design. Using graphics to show interactions among blocks or subcomponents of an HDL design is a popular approach. Several tools support transitions between graphical and HDL implementations; other tools translate state diagrams, spreadsheet-style Boolean tables, and other graphical representations to HDL implementations.

Methodology overcomes information loss

You can reduce or eliminate some of the problems that result from information loss by combining features of HDL with a consistently applied methodology. For example, recognition of a signal as input, output, or bidirectional is explicit in VHDL in the port mode declaration, so a naming convention for port signals can provide distinguishing information. For instance, "sname_c" can express a signal name (sname) and a code (c) that represents signal characteristics. A convention for the code could be

• b--active-high bidirectional
• c--active-low bidirectional
• f--falling-edge input
• i--active-high input
• j--active-low input
• n--active-low output
• o--active-high output
• r--rising-edge input.

Comment statements in an HDL listing can supply other missing information. For example, a short comment on each signal can indicate the signal's purpose and its intended source or destination(s). You should also document feedback paths with comments. In some cases, the use of good comments actually overcomes some schematic shortcomings. With comments, you can explain why you selected a particular design approach, something that a schematic doesn't easily allow. Likewise, you can list other design approaches and explain why you rejected them.

HDL-based design can also free you from some unnecessary details. In schematic-based design, you work with available components in design libraries; even with ASICs and FPGAs, there is an underlying library of cells or macros. The HDL hides this library, freeing you from the details of clock-enabled flip-flops, active-high or -low presets or clears, and the number of inputs available for various gate functions. Your logic-synthesis tool accounts for these details much as a high-level-language compiler generates appropriate addressing modes in machine language from high-level source-program input.

The freedom from these structural details, however, does increase your responsibilities in some ways. For example, you must remember to provide for initialization of your implementations without the obvious reminder of an unconnected reset pin "dangling" on a schematic. You must also determine which signals should be stored and which signals are combinatorial. You must describe an interface in sufficient detail to distinguish correct and incorrect usage. These problems are not normally evident in small designs; they appear in the integration stages of large designs.

Get it right the first time

Two major productivity factors apply to large designs. For initial developments, getting the design right the first time is the most important factor, and the costly mistakes are those that impact interfaces. You can't discover an error until you integrate the components that use that interface. Then, when you make the design changes required to fix the error, you invalidate earlier tests, requiring their repetition. You might even need another pass of silicon for the ASIC, with a tremendous impact on cost and schedule.

For subsequent derivative developments, the most important productivity factor is reuse of prior effort. Every reuse of a tested component from a prior design reduces the cost, schedule, and risk of a current effort. This factor applies equally for schematic- and HDL-based designs. The reuse of bigger components provides larger reductions in schedule, cost, and risk. One of the main reasons for using HDL and logic synthesis in development is to generate larger ASICs. Therefore, most designers making the transition from schematic- to HDL-based design are also generating larger ASICs. The opportunities for the reuse of larger components increase with larger ASICS.

The key to getting a large design right the first time is verification of results for each step, or phase, of development. In software development, the increased complexity of products has led to increased formalism and documentation of these phases, an approach that hardware engineers would do well to consider for designs with increasingly large gate counts.

Typically, the phases of a development process are requirements analysis (or definition), design, implementation, test, and integration. In a hierarchical development, each of these phases applies to each level of the hierarchy. Software engineers formalize the hierarchy levels as units, components, and configuration items. Units, the lowest level of the hierarchy, get implemented directly in the source code. To implement components, which represent one or more intermediate levels of hierarchy, software engineers integrate collections of units to obtain higher levels of capability. The top-level hierarchy, called a configuration item, results from assembling components into a complete software product.

Each of these levels of software development has a set of documentation that includes requirements, design, implementation, test, and integration. The configuration-item documentation for contracted efforts is usually a deliverable product that is contractually controlled. Often, government projects also require the delivery and control of component-level documentation. In hardware development, however, many customers of commercial development efforts consider documentation complete if they get a released schematic drawing. Even government contracts rarely require more than configuration-item documentation for hardware. Successful, well-organized, HDL-based designs should use a simple, inexpensive method of documenting requirements and design at the component hierarchy.

Some commonly recognized steps of a typical development process are:

• the generation of a schematic (considered to be design)
• fabrication of a circuit board (implementation)
• making the board operational in the laboratory (test)
• plugging the board into a box (integration).

These steps do not constitute the lowest level of a development hierarchy, however. The design, implementation, test, and integration efforts of the lower hierarchy levels rarely get formalized. Design, for example, occurs when you partition boards and ASICs into smaller units and determine the interfaces among the units. Block diagrams represent these designs, and very large designs have multiple levels of block-diagram hierarchy.

Design implementation occurs when you produce the next lower level block diagram, when you draw schematics, or when you write HDL programs. Testing at the lowest level occurs via simulation of individual blocks or HDL code sections. Integration consists of reconstructing your block diagrams, using schematics or HDL code sections, and testing the connected blocks as larger units. After the completion of each level of integration, development continues with the next higher level of the hierarchy. Treating the block diagram as a formal design step in the development process is a concept that is initially awkward for many designers, but it is a key concept for successful top-down development of large designs.

Design reuse boosts productivity

The largest potential productivity gain comes from reusing design pieces. To reuse a design piece, you must be aware of what pieces exist, what functions they provide, what prerequisites they need, what limitations they have, and what testing they have undergone. An original design that requires a 19,200-baud asynchronous serial channel with 7 bits and odd parity would not be reusable for a design that needed a 38,400-baud asynchronous channel with 8 bits and no parity. However, if the first design implemented an asynchronous serial interface with programmable bit length, parity, and baud rate, the first design would be directly reusable by the second design.

Schematic-based development doesn't guarantee reusability, however, even when you build in provisions for reuse. Incompatible library elements can result from changing ASIC vendors or even a technology change from the same vendor. With HDL-based design and logic synthesis, however, dependence on vendor and technology implementation practically disappears from a design. The situation is analogous to the use of a high-level language for software development. In fact, HDL-based hardware development is so similar to software development that the dominant HDLs are based on successful software languages such as C, Pascal, and Ada. Logic-synthesis tools accept the HDL definition and generate gate-level implementations, much like a computer-language compiler produces machine instructions from source code.

Like structured programming in the 1970s and early 1980s, HDL-based design has been accompanied by top-down design with limited success. But, like structured programming, top-down design isn't necessarily bad, just insufficient by itself. In software development, object-oriented development provides some important missing details.

With schematic-based hardware development, designers have been constrained to producing object-oriented designs. Schematics, after all, are composed of an interconnection of library component objects. The advent of ASICs and HDL-based logic synthesis, however, allows the hardware engineer to escape the bounds of object-based development and get mired in the swamp of unstructured implementations.

Object vs function

Often, the distinction between an object-oriented design and a functionally oriented design is subtle. Consider, for example, an eight-channel, multiple-protocol serial interface with DMA. A possible first-level design of the device (Fig 3a) places all of the DMA logic in a block, all of the serial logic in a block, and all of the interrupt control in a block. When labeled as DMA controller, serial interface, and interrupt controller these blocks seem like a good set of objects. They seem reusable any time you need an eight-channel DMA controller. The original purpose, however, was not to build a universal DMA controller, but to build eight channels of serial interface. The software interface for the new design would be awkward, because the various registers for the channels would have addresses that are intermixed (Fig 3b).

A better organization for the registers, shown in Fig 4, allows the software to encapsulate the serial-interface control into a single Ada record, a C structure, or a C++ object. (The implementation of this design could also encapsulate the interface control into a VHDL record.) Each interface channel comprises five smaller objects: two single-channel DMA controllers, serial input, serial output, and channel controller. Reuse of components can be applied at several levels, making the generation of a 6- or 11-channel device much easier than using the original design.

Another advantage of this partitioning is the reduction in global wiring for interconnecting blocks. The interconnection and routing of long signals in ASICs can consume a large amount of silicon and time. Minimizing global interconnect or top-level wiring results in smaller, faster devices, corresponding to the software guidelines of maximum cohesion and minimum coupling. A quick metric for partitioning evaluation is the sum of the ports at a hierarchy multiplied by the hierarchy's distance from the bottom. Larger values for this number represent more dif- ficult routing of the design. This partitioning also reduces the possibilities of inadvertent interactions among the channels.

You should apply the principles of object-oriented design at each level of the hierarchy, such that the final object, the ASIC, is composed of smaller objects. Each of the smaller objects, in turn, is composed of even smaller objects, continuing until each object is small enough for easy implementation as an HDL unit such as a VHDL entity. The resulting structure is easier to implement, test, and integrate, and it provides objects that are reusable in future projects.