cad

Dreaming Up a New Methodology for Physical Migration of Hard IP In the quest for the grail of IP reuse, a physical migration software tool outshines simple optical shrinkage in translating hard IP for use in smaller processes. by Jon Levi

Today's deep submicron process technologies offer tremendous performance, power, and footprint dividends. The ability to mount millions of transistors onto a single die, to combine various mixed-signal functions, and to merge logic and memory has opened the door to highly integrated, core-based system-on-a-chip designs.

But as chip complexity explodes and compressed product development cycles relentlessly escalate time-to-market pressures, designers must accomplish more in less time. For an increasing number of designers, the secret to quickly building highly integrated SOCs in a shrinking development cycle lies in the extensive reuse of silicon-proven megafunctions or blocks.

At Cadence Design Services, our design team undertook the building of a new half-million-plus gate modem chip that was based in part on an earlier chip. While the original designers wrote GDS files for a 1-µm CMOS process, our team's task was to combine these various functions into a single piece of silicon that would be manufactured at 0.5 µm.

Figure 1	Retargeting IP
Retargeting existing IP follows one of several well-defined processes, depending on whether the IP is hard, firm, or soft. Dream allows designers to omit both synthesis and LVS.

While a full redesign would have offered the team the opportunity to build the smallest design by taking advantage of new library elements, our designers calculated that recreating the full custom layout of the design from scratch would take up to six months. Implementing a synthesis approach with a new library would also take six months. Neither approach would have allowed us to meet the customer's goals, while a purely optical shrink of the previous design would have produced a chip much larger than necessary. Obviously, we needed a technique that would offer a smaller design than an optical shrink would produce, but without significantly extending the design cycle.

We satisfied both criteria with Design Rule Enforcement and Migration (Dream)--physical design migration software from Sagantec of Fremont, Calif. Operating at the GDSII level, Dream compacts a design without changing the netlist, allowing designers to reuse existing silicon-proven hard IP and to implement a verification methodology. The tool also integrates well with verification tools from a number of vendors, enabling smooth and efficient timing analysis.

Shrinkage-resistant IP

The design presented a range of challenges. Some of the blocks in the chip came to Cadence as pure specifications, some came as RTL specs, some came as gate-level netlists, and still others came as GDS or hard IP.

Interestingly, upwards of 30 percent of the chip consisted of hard IP. The reuse of blocks previously offered in a manufactured and proven physical design was thus essential to meeting time-to-market goals. We found five blocks--representing approximately one-third of the entire chip--particularly ripe for reuse. The blocks included a DSP core, a 32-bit RISC processor core, a DMA, and two small blocks of a few thousand gates each.

Typically, hard IP retains close ties to its original process. In contrast, design rules often differ significantly from one generation to the next, given the rapid evolution of IC process technology. Moreover, some foundries and design houses use the complexity and sophistication of their design rules to differentiate themselves from the competition. Such practices can significantly impede--and even prevent--the migration of hard IP into new processes.

Figure 2	Timing flow
The timing verification followed two paths: Verification of the individual blocks occurred after block layout and parameter extraction; simultaneously, we checked the block timing in a full-chip layout.

While the ability to retarget pre-established design blocks to higher-performance processes promises to enable SOC designs, cut design costs, and increase profitability, deciding how to accomplish that goal is no simple task. A project of this scope, for example, can still require anywhere from 10 to 20 weeks to complete because it involves much more than just conversion, timing analysis, and simulation.

To accommodate the design's complexity, at various times the project employed the talents of close to 30 experienced engineers with expertise in coding, design, verification, timing, and layout. This was no push-button process. For starters, designers had to weigh two competing requirements. On the one hand, the team needed a reuse strategy that would maximize speed of execution and shorten time-to-market. On the other hand, the team needed to achieve as dense a design, or as small a silicon area, as possible--a particularly important goal because one of the functions, the DSP core, included approximately 50,000 gates and largely determined the overall width of the chip.

The quickest solution--a straight optical shrink--would increase the new chip's die size by 20 percent. Designers estimated that with an extensive up-front evaluation phase and some post-process time set aside to rectify a minimum number of errors, they could accomplish a direct shrink in as little as two to four weeks.

The optical approach, however, presented certain liabilities. For one, the method offered little flexibility, shrinking all parts of the design and all process rules by the same magnification factor, with only slight variations to minimize violations. Unfortunately, a new process based on a purely optical shrink rarely exhibits a minimal number of violations. Specific design tolerances change at different rates than others--allowing, for example, a greater shrink factor for gates than metals. Without extensive edits, massive violations occur well before the process reaches the maximum possible shrinkage, unless the original designers created the target process to allow for shrinkage.

The team quickly discovered that certain aspects of this particular design presented more than a few obstacles to an optical shrink. While the original GDS structures targeted a 1-µm process, one rule in the 0.5-µm process was larger than the 1-µm rule. A linear optical shrink thus promised only a small reduction in size, a major cost consideration for a chip targeted for high-volume production.

Life could be a dream

So we turned to Dream. Since we had never used Dream, the team underwent a learning process. The original designs used many custom design tricks to make the design small and fast. Unfortunately, the tricks--such as 45-degree transistors and bent gates--also made the designs difficult to migrate. When checked, first passes revealed large error structures. We finally developed a design flow that helped us to complete this project successfully--one that we now use universally on other projects as well (see Figure 1).

The first step was to screen the library used in the GDS for the special rules or tricks we used in layout. The project team ran Dream on these cells to see what would happen. In most cases, errors that we would have seen at the end of the full design run appeared at this level. We fixed the errors by manipulating the input database. Once we had addressed all the cell issues, we sized the block for the tool. We could run small blocks as a single entity, but we also ran several large blocks--blocks of up to 200,000 transistors.

We partitioned these large blocks by physically partitioning the GDS and labeling each net on both sides of the line, or by using the slicing routines in Dream. The slice allows the tool to break the design into columns and rows that the software then compacts and reassembles. Dream finished the blocks when the DRC error level was zero--or at an acceptable level for editing. This result completed the Dream runs.

Unlike a linear approach that is limited to the first breach of design rules in the target process, Dream can adapt a physical layout design from one process technology to another, non-linearly, by repositioning the individual polygon edges. The end result is a DRC layout that offers substantially better results than a traditional linear shrink.

The flexibility of a physical design migration tool can also contribute significantly to a more optimized compaction. In deep-submicron designs, the physical aspects of interconnect typically begin to dominate chip performance. To maximize performance on the new design, we needed to perform detailed polygon analysis and make slight modifications. For example, to minimize RC delays we sometimes had to design metal lines wider than the design rules would normally allow for--or had to space them further apart than minimal requirements usually dictate. If analysis showed that an IR voltage drop created speed or functionality problems, we could direct the tool to enlarged power buses with minimal designer intervention.

Dream on

Two engineers on the design team began using Dream by loading the database constraints associated with their targeted 0.5-µm process design rules for the foundry they were using. Next, they loaded into Dream the physical layout of each block they planned to compact. Running on 10 Sun Microsystems UltraSparc II workstations linked in parallel, the tool then moved individual edges in the polygon geometries of the design closer together until they met the constraints of the targeted process.

To accomplish that task, Dream first automatically compacted each block to satisfy the minimum design rules of the target process. The software then relaxed the layout in both the X and Y directions until it eliminated all violations of the design rules governing the new process.

To speed development, the team decided to partition some of the core into smaller blocks before migration so that the Sun workstations could process them in parallel. For example, we divided the DSP up into five pieces--and subdivided the DMA, which contained a RAM, by function. In contrast, we were able to accelerate processing on the RISC microcontroller block simply by striping it into columns and rows.

Still, the team had to compensate for a few peculiarities in the design before the migration could succeed. Initially, for instance, 45-degree angles created some design flow problems. When the engineers began using Dream, they could not undersize 45-degree angles and had difficulties calculating the correct gate sizes when connecting through 45-degree angles. Fortunately, with the help of Sagantec, the team quickly identified a series of procedures that they could use up front to screen for conditions in the design cycle. Since then, Sagantec has integrated those capabilities into Dream.

To verify the compacted design, the team characterized blocks and then constructed hierarchical timing models (see Figure 2). Once the compaction was complete, we characterized the interior of the block by running vectors in timing mode at the transistor level with Timing Mill from Synopsys. Cadence's Pearl tested the timing inside the block at the transistor level, then generated a timing model of the exterior of the block to allow hierarchical timing analysis at the next level. Pearl also confirmed hierarchical chip-level timing.

Ending the reuse nightmare

SOC designs often contain a large variety of IP source materials. Frequently, the designers of the IP have left the company, while blocks provided by a third party may omit critical information that the designers can't regenerate. Such problems forced us into a hierarchical design style, since creating the upper-level information is faster and easier than re-engineering blocks.

Most well-established design houses have legacy IP designed and incorporated into a variety of applications in prior technologies. Problems arise because most of these IP blocks were not designed for reuse--if they had been, then documentation and timing-path information would be readily available to any engineers who need to use these functions in their designs. Since such information is often difficult or impossible to obtain, we had to expend significant additional energy to create and standardize the data needed for reuse to occur. We treated these large complex blocks as library elements that fit into the design system, including all the views--functionality, synthesis, timing (I/O), and physical views (router and GDS)--that the design system required.

Figure 3	Hierarchical timing flow
To enable and expedite detailed timing analysis at the full-chip level, the team developed accurate timing models for each block.

The block-level timing model posed the biggest challenge (see Figure 3). Timing analysis of the block at the transistor level is difficult, particularly if the block exhibits asynchronous behavior and includes gated clocks and latches. We had to find all state elements and propagate the clocks to the state elements, then establish and validate paths to inputs and outputs to ensure that the paths indeed existed. When the I/O paths were correct, the creation of models took only the push of a button. The addition of input capacitance enabled synthesis and timing.

Once the design system absorbed a block, porting the design to a different technology required changes only to the timing and physical views. Of course, efficient reuse always requires the designers to take time to document the block, treating it as if it were a library element.

Another goal for this project was to allow reuse of pieces in other chips. Therefore, we kept the layout of all blocks distinct. To accomplish this task, we block-routed and timed each standard cell module, then created an upper-level model to use in top-level timing. We assembled these blocks with other Dream-compacted blocks to create the top level. As a final check, we performed layout parameter extractions with the data plugged into a full transistor-level netlist and then rechecked.

While the team added no new functionality to the compacted blocks, it did make a small modification at the customer's request. After the first pass of the chip, the customer wanted to speed up a clock signal that was buffered through a cell in one of the blocks compacted by Dream, which then fed the clock to logic on the other side. To resolve the issue, we went into the block and jumpered around a couple of inverters to accelerate the clock.

Eventually, the design team ended up with a new GDS file that conformed to the new design rules--without making functional or topological changes to the original design. Although the original designers estimated that in this case an optical shrink would produce little, if any, size reduction, Dream allowed us to compact the design of the blocks by an impressive 72 percent.

Originally selected for its capacity, the tool quickly became an important part of the design process, clearly more efficient than the massive effort required to lay out the design by hand. The process was the equivalent of taking a 40,000-transistor DSP core and laying it out again from scratch, minus the significant risk of human error normally associated with that effort. In comparison, using Dream posed little risk. The tool automatically resized the devices according to the team's calculations of the changes needed to meet timing requirements.

Since we migrated the new design from an earlier silicon-proven design, the new block functioned essentially in the same way that the old block did, greatly simplifying the verification process. The logical verification of the functionality of this complex system ended up being the determining factor in the schedule of the overall chip. Dream allowed us to migrate the blocks according to the original schedule--and before the rest of the design was ready.

Jon Levi is a project manager at Cadence Design Services' San Diego Design Center (formerly part of Unisys Corp.) where he's worked for the past 20 years. He started his career doing bipolar design, then moved to CMOS design.

To voice an opinion on this or any Integrated System Design article, please email your message to jeff@isdmag.com.

integrated system design  May 1999