System Design

The IC design industry is slowly falling behind in meeting the demand for new, deep-submicron products. Designers can't assemble enough million-gate designs fast enough.

The main stumbling block is the lack of a design infrastructure to handle the complexity of million-gate designs. Our work at Lucent Technologies' Microelectronics Group has clarified the root cause for the dearth of IC infrastructure and is beginning to provide an answer.

Design infrastructure depends on three elements: design portability, design locality, and design hierarchy. The most fundamental is an adequate design hierarchy, and that's currently lacking as well. We've discovered that hierarchical IC design and layout are capturing the wrong hierarchy. The tools need to capture information in two-dimensional, portable form, instead of one-dimensional, fixed form, and our work suggests that that can be done by using a technique similar to "packing" a workstation graphics window.

Contrasting the software and IC worlds Design hierarchy has been employed for decades in the software world. Nearly everyone believes it's a key ingredient, because it naturally simplifies many parts into a single whole. But applying hierarchy to IC design has been and continues to be problematical for several reasons, including limited design reuse, the difficulty in porting designs, and the excessive effort of placement and routing.

Consequently, IC design hierarchy has been confined primarily to the role of a work-around for the limitations of the existing design tools. As a result, the available infrastructure for hierarchical IC design is virtually nonexistent when compared with the infrastructure found in the software world.

Software development enjoys a comparatively rich infrastructure, comprising many systems--operating, windowing, and network operating systems--that almost all software relies on, uncountable applications, and development environments ranging from general-purpose to niche tools. In contrast, there is a dearth of hierarchical IC design infrastructure. There are no systems, only a few applications, such as cores and macros, and the development environments are few and basically the same.

Despite the different infrastructures, design hierarchy is still the fundamental mechanism for resolving complexity by allowing higher levels of abstraction. In the software world, complex systems are architected, synthesized, and implemented with a profound reliance on hierarchy (see Table 1). Software architecting chooses modules from the infrastructure; synthesis hierarchically and automatically compiles each module; and implementation, or linking, automatically ties them all together.

The steps of architecting, synthesizing, and implementing ICs stand in stark contrast to the parallel steps for software development. IC architecting chooses modules to design, not to select from the infrastructure; synthesis is much more interactive and doesn't solve as much of the problem; and implementation--that is, placement and routing--is therefore difficult, requiring much interactive attention.

That these differences exist is somewhat surprising when you consider the tangible benefits of hierarchical design, any one of which should motivate designers to make better use of hierarchical IC design. These benefits include design reuse, the ownership and exploitation of intellectual property, opportunities for parallel development, optimized design methods applied only to relevant blocks, the easy accommodation of late changes, increased design capacity, and rapid prototyping using off-the-shelf functions.

Some of the difference between the two infrastructures can be explained by the fact that IC manufacturing has only recently removed the limits that have kept ICs much less complex than software systems. For purposes of comparison, standard cells and machine instructions can be considered equivalent basic logical units. In the past, above design rules of about 0.25 µm, ICs were limited to about 100,000 standard cells. At about the same time, software systems were developed having 1 million to 10 million machine instructions.

With the complexity of ICs a tenth to a hundredth that of software systems, IC design required less help. However, IC manufacturing has now removed those limits with 0.25-µm technology, which can support designs in excess of 1 million standard cells, placing IC design complexity on a par with software design complexity. Yet, given the parity of "manufacturable" complexity, combined with the benefits of a rich IC design infrastructure, why isn't the IC infrastructure larger?

Design portability: prerequisite for infrastructure To answer that question requires a review of the technical factors that make a rich design infrastructure possible. A key characteristic in the emergence and development of design infrastructure is portability (see Figure 1). In the software world, portability typically means that programs and procedures can work across different processors or different operating systems. The important point is that the software investment holds its value rather than quickly becoming obsolete.

In the IC world, portability means that IC designs and functions would be able to work across different fab processes or libraries. The value of the design investment would be preserved rather than lost, so that a new fab process wouldn't make the design obsolete.

Porting software simply requires a new, fast, automatic compiling and linking of the source code. In the IC world, though, even most of today's reusable cores can't claim that degree of portability. At the very least, they require much more interaction in the synthesizing phase and a second, large dose of attention in the physical implementation.

This difference in the automation of porting is consistent with the difference in design infrastructure. Software porting is relatively easy and inexpensive, yielding more infrastructure. IC porting is difficult and expensive, resulting in much less infrastructure.

Several decades ago, portability was a sticking point in software development, but standards have lead software development to the point where portability can often be assumed. As a result, the IC industry has paid attention to standards for years now. Nevertheless, porting in the two worlds is still very different. Is there another technical reason for the difference?

Design locality: prerequisite for portability Standards are one prerequisite for portability, but not the only one. A second prerequisite is a good solution to the locality problem, which isn't often discussed in the software world any more, because for all practical purposes, it's been solved. Nevertheless, locality is still an important property. In software development, it tells which machine instructions and data belong on the same page of memory. If locality is violated, then programs thrash or worse.

In the IC world, a similar property, which can be called "IC locality," tells which standard cell instances belong in the same vicinity on a chip. If IC locality is violated, critical paths fail timing and silicon area is wasted. IC locality, better known as the IC placement problem, hasn't been solved.

The difference between the solved nature of software locality and the unsolved nature of IC locality is consistent with the differences in portability and infrastructure. Can the two locality problems be so different that the portability and infrastructure of the entire IC industry have suffered?

Locality differences: software vs. ICs There are important differences between the locality problems of software and IC design. The most basic is the nature of the two problems, particularly their dimension. Software locality is a one-dimensional problem: memory in a computer is a one-dimensional space; instructions and data come either before or after each other. IC locality, on the other hand, is a two-dimensional problem: the vicinity of a chip for any standard cell is a two-dimensional space; each cell can be above or below, as well as to the left or right of, other cells.

Figure 1. Design infrastructure rests on portability, locality, and hierarchy. Software locality is basically a one-dimensional problem, whereas IC locality is a two-dimensional problem. However, today in both software design (A) and IC design (B), hierarchy generally captures only 1-D information. In the future (C), hierarchy will be two-dimensional, supporting the development of a rich infrastructure.

However, in both software and IC design, hierarchy captures 1-D but not 2-D information. (There are a few exceptions, discussed below.) Consequently, compilers have sufficient information to solve the software locality problem quickly and automatically. IC design, though, requires the expensive process of interactive placement and routing.

The root cause Essentially, infrastructure must be supported by portability (see Figure 1 again); without it, infrastructure investments aren't worthwhile. Portability requires not only standards, but also an inexpensive solution to the locality problem. IC locality doesn't have an inexpensive solution because, as noted, it's a 2-D problem, and traditional hierarchy captures only 1-D information.

In other words, today's hierarchy hampers the development of a locality solution; without a locality solution, portability suffers; and with limited portability, the IC design infrastructure suffers.

Proposed solution Since the problem is that present-day hierarchical IC design and layout are capturing the wrong hierarchy, they must be changed. A redefined hierarchical methodology for IC architecting, synthesis, and implementation must not only solve the 2-D locality problem for each circuit, but also capture the 2-D solution in a portable form to simplify ports to new processes and new designs. Two-dimensional information must eventually be captured in a portable manner with the same ease as that of the current 1-D modularity capture in software development. But can the necessary information be captured in a portable, 2-D form?

Our studies at Lucent Technologies' Microelectronics Group have uncovered the relationship among hierarchy, locality, portability, and infrastructure. The same work also is beginning to provide an answer. We've employed an evolutionary strategy, using existing tools--creating new ones only when absolutely necessary--and starting with the perceived industry de facto methodology, then studying and refining it. The refinements have only begun, but they suggest that the necessary 2-D information can be captured in a portable form.

Figure 2. Using "packing" (A), an approach that allows workstation graphics windows to expand and contract smoothly, new tools could not only produce an initial floorplan (B), but also capture 2-D information that would allow macros and blocks to be resized automatically if cells are added for a new design (C).

In the hierarchical methodology employed at Lucent, a floorplanner is used that does a good job of capturing 2-D information. However, the captured information isn't very portable. It doesn't include what should happen when the situation changes, even though accommodating some changes is required for portability. Responses to small changes in the sizes of circuit blocks must be anticipated and captured. Capture must also be simple and succinct: a complex program of logic shouldn't be required to specify what happens when a macro grows or shrinks.

One experience at Lucent that suggests that those requirements can be met is the capture of floorplans using a technique similar to "packing" a workstation graphics window. Workstation graphics windows must expand and contract elegantly and are programmed--actually packed in many cases--to make that possible. Usually one simple packing command per major block can capture the interrelationship of the blocks, as well as what to do if they change. The same approach can be taken with the "packing" of macros and blocks in a floorplan (see Figure 2).

Another experience suggests that much of the same technology can be used to place pins around a block. In this case, additional portable, 2-D features are required. A useful portable, 2-D method is to compute the projection of blocks or macros onto the boundary of a larger block. These projections can then be used in a similar packing process to place pins in the right portable, 2-D position. These positions will then automatically adapt to changes in the size of the macros.

Looking ahead Other 2-D information must be captured, and in a portable form. This information includes synchronization information, power and ground routing, hierarchical connectivity verification aides, testability features, and version management of the 2-D information. The question remains whether all of it can be captured two-dimensionally in a portable form, and we believe that the answer is yes.

Some available tools are good at portable information, but they ignore the 2-D features. And despite the earlier generalization, a few are indeed good at capturing 2-D information, but they capture it in fixed coordinates. None can mix the two characteristics together. The change to so many tools is daunting but necessary.

Some complex, theoretical problems will affect this work, and they can benefit from a reformulation of the portable, 2-D paradigm. Both hypergraph partitioning and standard-cell placement can gain from a portable, 2-D perspective, each getting more input but in turn being required to deliver higher-quality results.

With this perspective, we can expect exciting new developments in the future. In addition to the emergence of a rich IC design infrastructure, we can also expect tools and development environments that support the infrastructure. One that comes quickly to mind would be a spatial HDL--Verilog or VHDL embellished with the portable, 2-D information required to easily solve the locality problem, make portability possible, and make the design in such a language part of the IC design infrastructure.

The need for a grand IC design infrastructure is so great that the industry has been actively removing barriers for years. Now, another barrier has been identified and is being removed--but it must be removed in many places. The last barrier to fall will potentially release a flood of pent-up infrastructure development. *

Mark Vancura is a member of the technical staff/ASIC methodologist at Bell Labs in Allentown, Pa., part of Lucent Technologies, Inc.'s Microelectronics Group.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to miker@isdmag.com.

integrated system design  January 1998