Deep-Submicron Special Section

Designers Talk about Deep-Submicron Design

Deep-submicron processes require new design approaches and new design tools.

by Jonah McLeod

Today, the vast majority of available fabrication capacity is at 0.5 µm and migrating toward 0.35 µm and below. These deep-submicron geometries make possible chips of a million gates or more, thus enabling designers to create complete systems on a chip with clock frequencies of 100 MHz or higher. Invariably, such chips, built under tight time-to-market constraints, reuse existing circuits, or high-level functional blocks, one or more of which are programmable devices: microprocessors, microcontrollers, and digital signal processors.

These capabilities create their own set of problems for designers taking advantage of them. As a result, new tools are emerging and tools that weren't widely used before are being adopted. Some allow software development to occur in conjunction with the larger ASIC hardware design. Others use software techniques or formal methods to speed verification. And with designs reusing numerous modules, version control software is growing more important. Also, with million-gate designs, floorplanners, which have seen limited use up to now, are becoming essential.

How are designers using these tools to create complex circuits within tight time-to-market windows? The experience of several designers building chips using deep-submicron process rules illustrates the changes taking place in the way ASIC design is done.

Going off half-cocked Because deep-submicron processes enable designers to construct entire systems on a chip, says Janick Bergeron, director of technology at Qualis Design Corp. (Beaverton, Ore.), specifying the system correctly is the first big hurdle. "Some designers are still starting to code without an accurate system specification, and the final specification comes out with the chip. This culture needs to change," he says. "Marketing needs to describe the function to the system architect, who in turn must turn the description into an unambiguous specification."

Bob Zeidman, president of Zeidman Consulting in Cupertino, Calif., concurs. "Misunderstanding of the specification causes many spins of a chip design," he notes.

This misunderstanding results, explains Benny Schnaider, a design engineer at Cisco Systems Inc. (San Jose), because the specification is typically a document written in English or some other spoken language that can run hundreds of pages.

Schnaider wants an alternative language that is unambiguous and deterministic so that there is only one interpretation. Such a language would eliminate bugs before they appear as faults later in the design cycle. C, C++, and the behavioral languages now available don't fill the bill.

Tackling concurrent software development Despite this shortcoming, designers must still develop a complete and functional design. In deep-submicron circuits, the design entry task increases in complexity because the circuit typically includes a programmable microcontroller or DSP core. Because of time-to-market constraints, programs for the core are written at the same time that the ASIC hardware behavioral description is being simulated.

An interpreted event-driven Verilog simulation executes at an unacceptable rate of one instruction cycle per second. Compiled event-driven Verilog simulators such as VCS (Verilog Compiled Simulator) from Viewlogic Systems and cycle-based simulators such as Polaris CBS (Cycle Based Simulator) from Avanti run at 10 to 100 cycles per second. Though better, the higher rates are still not acceptable to most software developers, who are used to the number of cycles per second available with software development tools.

Figure 1. The illustrations show predicted interconnect lengths as a function of layout (A), the average value of capacitance assigned as a function of fanout and overall block size in gates (B), and the disparity between the predicted delay and the actual delay in a final block (C).

Hardware modelers only offer a speed comparable to the 10 to 100 cycles per second of a compiled event-driven or cycle-based simulator, Schnaider says. The reason is that they're tied to the clock of the design that is fixed by the simulator. Nevertheless, he points out, hardware modelers continue to be used because they provide the highest degree of accuracy.

To achieve the speed needed to run software on a simulation requires at least 100,000 cycles per second. Schnaider and his associates created just such a tool at Cisco. Called Virtual CPU, it's now being commercialized by Simulation Technology. The tool works "above the behavioral level," says Schnaider, executing the software code on the host workstation at full processor speed and slowing to the simulator's speed only when it receives an input from or provides an output to the simulated circuits surrounding the processor core. Achieving this high level of performance, however, comes at some loss in accuracy.

Several benefits accrue from being able to co-design software and hardware, not the least of which is faster time to market. In addition, co-design allows the design team to repartition the design between hardware and software. A frequently executed piece of software might be implemented in hardware to speed up execution, for example. Finally, finding bugs earlier in the design process eases the task of hardware-software integration.

Catching self-induced bugs Hardware-software co-design tools notwithstanding, deep-submicron designs with over a million gates create a verification challenge for engineers, says Bob Zeidman of Zeidman Consulting. A full two thirds of the development time for any new IC design being built with a deep-submicron process is consumed by design verification, estimates Gary Smith, principle analyst at market researcher Dataquest.

This statistic points to the increased problems associated with multiple complex blocks interacting with one another and sharing the same resources. Invariably, one controller will destroy a variable intended for another and the designer is helpless to anticipate the set of events that will precipitate the fault. This class of problem has called into existence a new start-up, 0-In ("zero-in") Design Automation of San Jose.

The company's assertion synthesis and directed search technologies find these bugs without any design, testbench, or simulation changes. Assertion checkers detect conflicts on resources that are shared between controllers. Such conflicts are early warning signs for complicated errors, like protocol violations and cache coherency problems. Currently, the 0-In tool checks for conflicts on shared registers (register leaks, or the loss of data before the intended recipient receives it), multiplexers and buses, memories, and counters.

Figure 3. Floorplanning can dramatically improve the routability of a design (A) by showing the designer the rat's nest of congested wires that results from block placement (B). Rearranging blocks (C) simplifies the interconnections (D), thus making routing easier.

Revision control In addition to new tools emerging for design verification of deep-submicron circuits, Qualis's Bergeron cites a number of existing tools that ease the design verification task as well. One that designers are not using as much as they should is version control software.

In large systems, the full chip design comprises many individual modules, some of which are reused extensively throughout the design. Keeping track of which versions of the modules are used becomes a management nightmare.

Revision control tools are supplied with or available for most Unix operating system environments, Bergeron notes, citing as examples Source Code Control System (SCCS) from Sun Microsystems and Revision Control System (RCS), a package in the public domain. He estimates, though, that only a tenth of the designs his company has consulted on have actually used software management tools.

Bergeron praises another software tool--Verilint from interHDL, which checks Verilog designs for semantic errors and questionable constructs for synthesis. At the same time it performs a thorough sifting of the design and posts warnings regarding coding practices that may lead to problems in simulation and synthesis.

Finally, the designers at Qualis also use code coverage tools to their advantage. VEDA Design Automation markets a tool developed by TransEDA called VHDLCover. It thoroughly tests a VHDL description, so any coding errors are caught early in the design cycle.

Another type of verification tool currently finding growing use is equivalence checkers, such as Design Verifyer from Chrysalis Symbolic Design. These tools ensure that once an HDL specification is completed, subsequent changes in gate-level implementations are equivalent to the original golden specification.

Though such companies as Cray, Digital, HAL Computer, and Nortel have adopted equivalency checking (Design Verifyer) for their designs, at least one engineer at a major PC company­who asked to remain anonymous--questions the efficacy of this type of tool. "An equivalence checker is employed when the functional verification is complete through thorough functional testing, which accounts for over 90 percent of the verification cycle; after which the RTL stays frozen," he says. "That being the case, the usefulness of equivalence checkers is exaggerated, as they only account for time savings in about two regression runs, and the time and effort spent on getting the tool working may not be worth the savings."

The emergence of floorplanning Once a behavioral description of a deep-submicron design is created and verified, the next hurdle the designer faces is getting the circuit to meet its timing specifications. With process technologies of 0.8 µm and larger, most circuit delays occurred through the gate and not in the interconnect. With deep submicron, the reverse is true. As a result, designers must floorplan their design and extract timing delays in longer nets to ensure that the design meets the timing requirements.

Floorplanning is a necessity, asserts James Vig Sherrill, vice president of engineering at ASIC International. "Eight years ago, the floorplan was done by the ASIC vendor. Today, the system designer is taking on the task," he notes."Furthermore, before only ASIC vendors provided floorplanners, whereas today, designers are increasingly using commercially available tools. We use Planet from Avanti," he says.

To understand the need for floorplanning requires a brief description of the estimated delays the ASIC vendor supplies to the synthesis tool. In his newly released book, Application-Specific Integrated Circuits (Addison Wesley Longman, Reading, Mass.), Michael John Sebastian Smith describes predicted capacitance as a function of fanout and circuit block size (see Figure 1).

For a large ASIC, designers partition the circuit into more manageable blocks. In Smith's example, an average partition is a block of 20,000 gates. For this size block, the ASIC vendor predicts some average net capacitance for gates that drive different numbers of fanouts (1 through 5 in the figure).

These predictions are based on Manhatten routing estimates, says Kurt Baty, president of WSFDB Consulting. The name results from the street grid that characterizes most of Manhatten Island. The assumption is that every interconnect in an ASIC traverses a right angle of some length and height. This statistical approximation has proven effective for process geometries above deep submicron.

However, notice that both net A and net B in the figure have an estimated capacitance of 0.9 pF. The actual capacitance is considerably different, though, owing to the length of interconnect. Net A has a standard load of 0.009 pF, whereas the longer net B has an actual capacitance of 0.03 pF, yet the estimated capacitance for both is the same in the fanout table.

Inside those blocks, the estimations are being further compromised because of the changes in block shape, Baty asserts. The assumption has been that each of these blocks of logic is a square. However, to achieve a better floorplan, the aspect ratio of the blocks are increasingly becoming rectangular.

The approach that most ASIC designers are taking is to create a floorplan after synthesis. A floorplan is created to minimize possible routing congestion that produces excess heat and signal crosstalk. As shown in Figure 3, the original floorplan of six blocks produces a rat's nest of wiring. However, rearraging blocks greatly eases the amount of congestion.

After synthesis, there are bound to be a number of critical paths that fail to meet time. ASIC International's Sherrill explains that a floorplan can illuminate the faults and help minimize these failures. The adjusted floorplan is returned to the synthesis tool, which then attempts to eliminate timing errors in critical paths by resizing buffers in the circuit.

The problem with floorplanning after synthesis is that the synthesizer has no idea of the relative placement of blocks before it creates a gate-level description. Ann Spratt, an engineer at Adaptec, says that designers at her company are floorplanning before synthesis using Design Planner from HLD Systems (now part of Cadence Design Systems). With this tool, the synthesizer has more accurate estimates of the delays of the interconnect between blocks. Spratt reports far fewer design iterations after synthesis and says that they testify to the efficacy of the tool.

With the advent of ever smaller process geometries, designers create ever more complex systems on silicon. The problem, however, is that design tools are hard-pressed to keep pace with manufacturing capability. Designers are building 0.25-µm circuits using tools that can only take advantage of 0.5-µm processes, says Dataquest's Smith--and he sees no improvement in this lag for the foreseeable future. *

Acknowledgement Figures 1 and 2 are from M.J.S. Smith, Application Specific Integrated Circuits (Figs. 16.6 and 16.4). © 1997 Addison Wesley Longman Inc. Reprinted by permission of Addison Wesley Longman Inc.

Jonah McLeod is editor-in-chief of Integrated System Design.

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

integrated system design  September 1997