Hierarchical Design Techniques

Vijay GullapalliSenior Design Consultant, Synopsys Professional Services Kaijian ShiPrincipal Consultant, Synopsys Professional Services

January 2004

2004 Synopsys, Inc.

Hierarchical design flow offers many benefits that can result in improved productivity when designing complex digital chips. Depending on specific designs goals, hierarchical design practices and techniques are especially important in managing design constraints and static timing analysis (STA), but the effects of hierarchical design must also be considered in tasks such as static crosstalk analysis, clock-tree synthesis and design for test. As chip complexity continues to grow, these techniques become increasingly important in helping hierarchical flows fulfill their promises of reduced turnaround times and predictable schedules for timing closure. The traditional flat ASIC flow avoids the effort of setting up hierarchy, but it carries a higher risk of having to iterate all the way back to the architecture design to correct timing problems that appear after routing. The flat ASIC flow is also subject to memory limitations and long runtimes in multi-million-gate designs. Establishing a hierarchical flow enables efficient timing closure of multi-million-gate designs as well as allows incremental functional and timing fixes of individual blocks after timing closure. Hierarchical design does have limitations that can lead to difficulties with timing closure. This paper explains some of those limitations and provides a general solution to overcome some of those limitations. This paper describes a variety of practical hierarchical design techniques based on Synopsys Professional Services extensive experience in complex chip design, but does not advocate the use of hierarchical or flat design flows for any given design. The approach selected depends on the design characteristics and goals. In general, however, the more complex and larger the design, the greater the benefits of a well-implemented hierarchical design flow.

Hierarchical Basics
Interconnect delays dominate the timing of very deep submicron (VDSM) designs and it is crucial to optimize logic structure, cell placement and routing to achieve timing closure. However, applying traditional flat optimization methods to highly complex and multi-million-gate designs becomes impractical. There is a practical limit to the size and complexity of the designs to which flat optimization methods can be applied due to memory limitations and runtimes of the tools. To resolve these issues, various hierarchical design methods have been developed. The basic premise of hierarchical design is simple. By dividing a design into multiple blocks (sometimes referred to as sub-chips, sub-blocks, lower-level blocks, modules, hierarchical blocks, etc.), designers can work on the blocks separately and in parallel from RTL through physical implementation. Working with smaller blocks keeps tool runtimes short, and block-level timing closure should be relatively easy to achieve compared to the timing closure for the entire chip in a flat optimization approach. Once all the blocks are finished, they are integrated to create the final chip implementation, where the blocks are modeled as black boxes. (These black-box models can include timing, physical, test, interface and I/O information. See the descriptions later in this paper for Interface Logic Models and Extracted Timing Models.) Final timing closure is more assured on the first iteration, because block-level timing has already been acheived; only inter-block connections must be checked and optimized where required. Figure 1 shows a simplified physical design flow for hierarchical design.

2004 Synopsys, Inc.

Figure 1. The steps in a hierarchical design flow are straightforward but often require the application of techniques such as partitioning to physical blocks and extracting block timing models that may be unfamiliar if you have only handled flat designs.

Although the general idea of this design approach is fairly simple, the details are often challenging. Designers must weigh the tradeoffs involving the extra work of managing the hierarchy versus the benefits of shortening runtimes and preventing major design iterations. The extra work includes creating the hierarchy, managing appropriate design constraints, configuring static timing analysis to work with the hierarchy, etc. This paper outlines methods for accomplishing many of the necessary tasks, though the treatment of these issues here is not exhaustive. The goal is to provide useful techniques and insight for better efficiency of hierarchical design. Note that the hierarchy referred to in hierarchical design is physical hierarchy, which differs from logical hierarchy. The latter is based on the function of the design modules/blocks, which is usually determined by the designers and their HDL coding methods. Physical hierarchy is based on back-end considerations such as cell placement, I/O placement, macro placement, interconnect routing and associated timing issues. The two hierarchies, therefore, may not have much in common. Whatever the correlation, designers evaluate placement/timing issues as part of design planning to determine how to group certain cells into hierarchical blocks that reduce the time needed to achieve timing closure.

2004 Synopsys, Inc.

Choosing Hierarchical vs. Flat

When should hierarchical design be used? The answer depends on many considerations, including design size, complexity, environment and schedule. In design practice, a decision is often made based on some of the following criteria: If the design is so large and complex that running it flat will exceed physical memory space, then hierarchical design methods are recommended. If a large design takes too long for the tools to run as a flat design on a given computer with available physical memory space, then applying a hierarchical design methodology will help. The large design can be partitioned into sub-designs that can be designed separately and in parallel. If a chip consists of a number of sub-designs that are designed at multiple sites, hierarchical design is usually a natural choice. If designers anticipate that a number of blocks may have problems and slip schedule, using hierarchical timing closure allows individual blocks to be fixed efficiently, and whenever needed, and integrated into the top-level design without re-running timing closure of the whole design. If a large design is too complex for designers to define complete constraints efficiently, partitioning the design into manageable sub-designs and applying a hierarchical methodology may be a better choice. If a design includes mature cores that have proven implementation methodologies and flows as well as constraints and models, it is a good idea to close timing on the mature cores and then integrate them into the design via a hierarchical design methodology. When evaluating whether to invest in creating a hierarchical design methodology, bear in mind that it is not necessary to support a separate methodology for flat designs. A hierarchical methodology will also support flat designs by considering an entire chip design as a single block. It is also worth noting that even flat design flows must support some degree of physical hierarchy due to the need to manage cell libraries and hard intellectual property (IP) macros such as RAMs.

Design Planning
In a hierarchical design flow, design planning must come earlier in the process and is more important than in flat designs. In design planning, blocks are sized and placed in a floorplan so that the timing of top-level interconnect can be estimated. Timing budgets are allocated to each block based on the top-level timing estimation. Floorplanning can be an iterate/refine process in which blocks are re-shaped and re-placed, timing budgets are re-allocated, and top-level timing is re-checked until an optimal floorplan is reached. For more information on design planning, please consult the Synopsys Professional Services white paper Design Planning Strategies to Improve Physical Design FlowsFloorplanning and Power Planning (http://www.synopsys.com/cgi-bin/sps/wp/designplan1.cgi).

Setting Good Constraints

The key part of design planning for efficient hierarchical design is to set block-level physical and timing constraints that allow parallel implementation of each block. Each blocks physical constraints, such as size, shape and pin placement, are derived from top-level floorplanning. The blocks internal physical constraints, such as memory placement, blockages and regions, can be defined locally in the same way as in a flat design. The top-level physical constraints include block placements and inter-block repeater distributions. It usually takes a few iterations in floorplanning to derive high-quality physical constraints for the blocks and top level. These iterations usually include both top-down and bottom-up approaches. In the top-down approach, block partitioning, size, shape and placement are driven by top-level design specifications such as die size, shape and pin positions. In the bottom-up approach, the size, shape and pin positions of off-the-shelf hard IP macros usually drive the top-level floorplanning.

2004 Synopsys, Inc.

Somewhere between the extremes of the ideal top-down and bottom-up approaches lie the various real-world methodologies that work for different designs. For example, designers can run a quick synthesis of soft macros in an early-stage design to get initial gate counts for top-level chip size estimation, even though these macros might not have been finalized in RTL. For incomplete or missing blocks, designers must rely on judgment and experience to estimate sizes based on design characteristics and inter-block connections. Margins are usually added to the initial estimated chip and block sizes. Block timing constraints are also derived in a top-down and bottom-up iteration process. The block I/O constraints are usually derived by top-level block timing budget allocations, which can be done either manually by designers based on their understanding of the design, or automatically by tools such as Design Compiler using Automated Chip Synthesis (ACS). Enough margins are usually added to the derived block budgets to cover inaccuracies in early-stage design and inter-block interconnect timing estimations. For a mostly top-down flow, Design Compiler using ACS can be used to help generate block-level constraints from a set of chip-level constraints. For a simplified example of this process, consider two lower-level blocks and one timing-critical signal that passes through both of them. Say that the tool shows a 5-ns path delay through block A (from input register to output register) and the same path delay through block B, with 1 ns of interconnect delay between the blocks. If these blocks use a clock that has a 10-ns period, the 11-ns total for the path will violate timing. With this information, the designer can go back to the block design and over-constrain the timing-critical path in synthesis (by 10 to 20 percent) to meet timing. Be careful to avoid placing unreasonable timing constraints on the design. Such constraints cause the synthesis tool to waste time applying a number of strategies iteratively before it gives up. As a general rule: Keep constraints simple. The more constraints that are applied, the more time the tool takes for optimization and analysis. Often, constraints are passed from an RTL designer to someone who actually runs the synthesis tool. When the RTL designer changes part of the design and forgets to remove an associated constraint, un-used and un-applicable constraints can accumulate. For this and other reasons, it is a good idea to periodically read the constraints and evaluate what they do. Sometimes by cleaning up constraints, an all-day synthesis run can be shortened to just a few hours. To achieve timing closure, it is essential to have good correlation between the placement optimization timing and post-layout timing. It is a good practice to conduct a placement vs. post-layout wire RC and timing correlation study based on the results of a pipe-cleaning timing closure commonly performed in the early stage of a design to test the flow, library, environment, etc. Then, the correlation study results are used for purposes such as tuning the wire-routing model that Physical Compiler uses in placement optimization. Design experience shows that long wires often cause poor placement and post-layout timing correlation, especially when weak cells drive these wires. Such wires are often seen when placement includes library cells that are modeled with large maximum capacitance (max cap). This issue can be resolved by ranking the library cells according to their impact on post-layout timing and then scaling down the max-cap values the cells can drive. Experience with the library is needed here to know how much to reduce the max-cap values. Another option is to set slightly pessimistic max_transition time and max_fanout on the design in the placement optimization. These conservative design rule constraints prevent long nets in the layout and thus minimize crosstalk problems. Designs that have multiple operating modes or a special test mode present special challenges to design optimization, because placement optimization tools do not optimize the design simultaneously in multiple modes. The constraints used in optimizing the design in one mode may mask the timing constraints in paths that are not part of that mode.

2004 Synopsys, Inc.

This issue can be resolved by removing the constraints that mask timing paths in other modes to let the tool optimize as many paths as possible. When two modes share a path that runs at different clock speeds, let the tool optimize the path with the worst-case constraints. In some cases, these worst-case constraints may over-constrain the paths, causing reports of false timing violations that cannot be fixed in the optimization. To handle these cases, local constraints can be defined to isolate the problematic paths from the mode in which the design is optimized.

Overcoming Hierarchical Design Limitations

Though hierarchical methods make timing closure more predictable, the conventional fully hierarchical methodology can sometimes fail to close timing. Difficulties can occur because the blocks are modeled as black boxes when they are integrated into a top-level design, so they act as routing obstructions. Nets that interconnect the blocks have to be routed through channels between blocks. These routes tend to be long and can cause timing and signal integrity problems. Signal repeaters and net splitters can be inserted in the channels to fix problematic routes but may not succeed. Figure 2 shows a simplified view of a fully hierarchical design that leads to long signal routing. The channelized floorplan may also cause routing congestion in core-limited layouts, particularly in a design that has many cross-chip connections. As a result, conventional hierarchical timing closure methods usually require more chip area than flat methods. Moreover, the timing of block I/O paths cannot be changed during top-level design optimization, so blocks must be optimized with a good I/O budget. However, it is often difficult to set a good I/O budget for every block because the budget quality depends on accurate predictions of top-level global path timing and inter-block routing, and these values are not available before a chip is laid out.

Hybrid Hierarchical Methodology

A hybrid hierarchical design methodology can avoid the limitations of the conventional hierarchical flow. The hybrid methodology introduces the concept of a pseudo-block to model those parts of the design that will cause timing violations and routing congestion if they are modeled as black boxes. The pseudo-blocks are optimized as a flat design separately and in parallel, similar to that of the blocks. However, the pseudo-blocks are not black-boxed during top-level design optimization. Instead, the pseudo-blocks optimized netlist and cell placement are integrated into a top-level design. The pseudo-block placement and routing resources are thus visible in top-level design optimization. Cross-chip nets can be routed through the pseudo-blocks (Figure 2), and pseudo-block I/O path logic can be optimized at the top level where accurate timing of global paths traversing through the pseudo-block I/O paths is available. Even though the netlist of a pseudo-block is present in the top-level design, top-level design optimization is still quite efficient because the pseudo-blocks are optimized and verified before integrating them into the top-level design.
Figure 2. One of the limitations of hierarchical design is that it sometimes creates blockages to top-level routing that are difficult to resolve. By treating some blocks as pseudo-blocks that are part of the top-level design rather than seperate low-level hierarchical blocks, the hybrid hierarchical methodology enables easier routing for critical top-level signals.

2004 Synopsys, Inc.

Implementing the Hybrid Hierarchical Methodology

The first step in which the hybrid methodology differs from the conventional methodology is in partitioning the design into three types of subdesigns: blocks, pseudo-blocks and glue logic-blocks (Figure 3).

Figure 3. The hybrid hierarchical design flow includes three types of blocks: regular hierarchical blocks, pseudo-blocks and glue logic-blocks.

2004 Synopsys, Inc.

The qualifications for each type of subdesign are: A block can be modeled as a black box in top-level optimization without causing major problems. As in the conventional hierarchical methodology, timing closure of every block is done separately and in parallel. An I/O buffer ring is inserted in the block and placed close to the block I/O pins to ensure good block timing quality and to prevent possible antenna rule violations when the block is integrated into a top-level design. A pseudo-block is a timing-critical subdesign that is not suitable for modeling as a black box because it has to be placed in an area where many global nets will be routed. The pseudo-block may also be a subdesign which does not have a good-quality I/O budget available. A glue-logic block is a subdesign that functions as a global signal relay with many cross-chip nets. It is difficult to optimize this type of subdesign locally without causing congestion and global-net design rule violations. The glue logic-blocks are thus optimized in the top-level design optimization, accounting for global signal paths and routing congestion. After the blocks and pseudo-blocks achieve timing closure, they are integrated into a top-level design with the glue logic-blocks. In the integration, cell placement of the pseudo-blocks needs to be adjusted according to the pseudo-block positions in top-level floorplanning. Top-level timing constraints also need to be modified in reference to block models and pins instead of block internal logic. Then the integrated top-level design is optimized by the combined synthesis and placement optimization methods (as with Physical Compiler). In the hybrid method, I/O timing budgets can be derived using a combination of layout-based budget extraction and RTL budgeting methods. After a pipe-cleaning timing closure of the design, the budget can be extracted again and refined based on the post-layout timing. Because the I/O paths of the pseudo-blocks can be optimized in top-level optimization, their I/O budgets are not as critical as that of the blocks. Additionally, pseudo-block pin assignments do not have to be optimal so long as the pins are placed on the correct side.

Hybrid Hierarchical Design Example

The hybrid hierarchical methodology has been successfully applied to a 1.5M-gate, high-performance, low-power DSP core that has been embedded in a number of wireless application chips. To minimize operation latency, a tight timing budget was applied to the DSPs operation pipeline. As a result, the design contained long logic paths that made timing closure difficult. Combined logic and physical flat design optimization suffered from capacity limitations and excessively long run times. Moreover, traditional block-based hierarchical optimization methods failed to close timing on the design. The hybrid methodology succeeded quite well. Before applying the hybrid methodology to the design, the team placed the design using Jupiter. Analysis showed that the timing and design rule violations were large and numerous. The design was then partitioned into 24 blocks, 7 pseudo-blocks and 11 glue logic-blocks. Team members handled the timing closure of the blocks and pseudo-blocks separately and in parallel. After timing closure was achieved separately, the blocks and pseudo-blocks were integrated into the top-level design according to the integration methods described earlier. The integrated design was pushed through a sign-off layout flow, and post-layout timing was checked by a sign-off STA flow using PrimeTime. The results were far superior to the initial placement results. The worst setup-time violation dropped from -14.8 to -0.58 ns, and the worst capacitance violation decreased from -3516 to -200 standard capacitance units.

2004 Synopsys, Inc.

Figure 4. Comparision of results between traditional and Hybrid hierarchical design flows for a 1.5M-gate design.

At this point, the worst setup-time violation was -0.4 ns, and the total setup time violation was -1.7 ns. (These violations occurred mainly in two cross-chip clock-gating paths that were difficult to fix due to a large clock skew between the leaf clock and the gated clocks at the top level of the clock tree.) The optimization also fixed design rule violations well. Total capacitance violations dropped from -173343 to -627 standard capacitance units. These remaining minor timing and design rule violations were fixed by post-layout ECO along with functional ECO fixes. For more details on the hybrid hierarchical design methodology, please consult the paper Hybrid Hierarchical Timing Closure Methodology for a High Performance and Low Power DSP (http://www.synopsys.com/sps/techpapers.html).

Static Timing Analysis

One of the most important differences between flat and hierarchical design is the way STA is applied. Especially important for a hierarchical flow is the ability to generate static timing models automatically from gate-level netlists because these models are compact and accurate representations of a blocks timing characteristics. Instantiating these models instead of gate-level netlists for blocks improve chip-level STA runtimes dramatically, yet avoid compromising verification accuracy. PrimeTime can abstract timing information into two types of models: Extracted timing models (ETMs) represent the timing characteristics of a gate-level netlist through timing arcs between internal and external pins on a library cell (Figure 5).

Figure 5. Extracted Timing Models (ETMs) replace a gate-level netlist with timing arcs between I/Os.

2004 Synopsys, Inc.

Interface logic models (ILMs) model the original gate-level netlist of a block with another gate-level netlist that contains the blocks interface logic (Figure 6).The interface logic includes all the circuitry leading from I/O ports to edge-triggered interface registers. ILMs preserve the clock tree leading to the interface registers, but ILMs exclude logic that is only in a blocks register-to-register paths. ILMs do not abstract; they simply discard what is not required for modeling boundary timing.

Figure 6. Interface Logic Models (ILMs) preserve a gate-level netlists interface logic.

ILMs provide an accurate and robust solution for hierarchical design flows. In post-layout flows, ILMs preserve the original block timing to within 10 ps for typical designs and technologies. Timing differences between an ILM and the original netlist are easy to debug because the interface logic is maintained. Additionally, PrimeTime can generate ILMs quickly. ILMs do have some limitations. From an IP reuse standpoint, ILMs make visible a significant amount of information (partial netlists, constraints, back-annotations) from the original design. Another issue is that third-party place-and-route and simulation tools may not be capable of replacing a blocks original netlist with a partial netlist.

Using ILMs
After ILMs have been generated and verified against the original gate-level netlists, they can be used for full-chip analysis and in-context block analysis. For full-chip analysis, the ILMs replace the original gate-level netlists of all applicable blocks. STA can then identify inter-block timing violations quickly and accurately. For in-context block analysis, the full netlist for one block is instantiated at the chip level while surrounding blocks are modeled using ILMs. This approach quickly analyzes both the internal timing and external interface timing for a block. Analysis speed can be further improved by ignoring all ports on the surrounding blocks that are not connected to the block being analyzed.

2004 Synopsys, Inc.

10

These are the steps for instantiating an ILM at the chip level: 1. Load the ILM netlist. 2. Load and link the chip-level design. 3. Apply chip-level constraints. 4. Apply chip-level back-annotation. 5. Read ILM back-annotation information. 6. Source the ILM script. 7. Perform the analysis.

ILMs in Signal Integrity Checks

ILMs can be useful for speeding-up signal integrity analysis for hierarchical designs, even though the nets that are removed to make the ILMs are no longer part of the analysis. PrimeTime, for example, has the ability to generate ILMs that preserve internal nets and they are cross coupled with ILM boundary nets. For this reason, it is ultimately necessary to run full-design signal integrity analysis with non-ILM blocks. However, the use of ILMs can significantly reduce the duration of the initial phase of timing closure by identifying many of the gross block-to-block timing issues. Note that enhancements to ILMs are making them more useful for signal integrity analysis. Since the 2003.03 PrimeTime release, for example, the tool has the ability to generate ILMs that preserve internal nets that are cross-coupled with ILM boundary nets. It is also possible to generate ILMs in which cross-coupling exists between the internal sub-block nets and top-level nets. The flows that enable ILM use in signal integrity analysis are constantly being improved. As when using ILMs for conventional STA, it is crucial to validate the ILM timing against the interface timing of the original block. For any ILM that does not meet the validation criteria, the corresponding block should not be replaced in the signal integrity analysis. For blocks that do meet the validation criteria, bear in mind that the ILM timing compared to full design timing can differ by the tolerance used in the validation.

Design for Test

Hierarchical design affects design for test (DFT) because it can be difficult to balance scan chains at the designs top level. In contrast, it is easy to tell DFT Compiler to generate five chains in a flat design and get balanced chains. Balancing chains across multiple blocks in a hierarchical design may require a bit more work. In hierarchical design practice, designers usually extract all necessary DFT information from the sub-chips. This information includes the number of scan chains, the length of each chain, preferred chain connection orders, and boundary-scan chain information where applicable. For third-party hard IP, the vendors usually provide such information. Once the DFT designers have the information, they can control the hook-up of top-level scan chains, considering the chain max-length limit, chain length balance and connection orders. Designers can either manually define top-level scan chain segmentation and insertion or use DFT Compiler. In the latter approach, designers specify the scan chain ports and scan chain attributes, such as the maximum number of scan chains and the maximum length of the scan chains, etc. Most designs are more complex than an array of multiple flops. They usually have multiple clocks, IP blocks, etc. DFT Compiler allows the designer to work with the complex nature of the designs by allowing the insertion of latches at the end of each scan chain or mixing clocks, even clock edges, etc. In the case of larger designs, a hierarchical test insertion methodology is recommended.

11

2004 Synopsys, Inc.

One method to achieve balanced scan chains at the top-level is to limit the length of the scan chains at the block level, thereby creating a larger number of shorter scan chains at the block level. Thus, test insertion must be completed at the hierarchical-block level before top-level test insertion can be set up. The main issue in hierarchical test insertion is how best to create the block test methodology so as to best assemble balanced scan chains at the top level. When inserting test structures at the block level, the blocks size and design-specific attributes (clock scheme, gate count, test control logic, etc.) drive the number and length of the scan chains. However, the scan chains created at the block level may not be optimum for the top level. One method to achieve balanced scan chains at the top level is to limit the length of the scan chains at the block level, thereby creating a larger number of shorter scan chains at the block level. These smaller segments of scan chains allow the chains to be stitched together more easily at the top level. Consider, for example, a hierarchical design of three blocks (A, B and C) with gate counts of 500, 300 and 200, respectively, for a total of 1000 flops. Assume a tester length of 250 flops and that the maximum number of scan chains required at the top level is five. Dividing 1000 flops among five chains clearly gives an optimal scan chain length at the top level of 200 flops. However, inserting balanced scan chains with a maximum chain length of 250 results in the following arrangement: block A has two 250-gate scan chains, block B has two 150-gate chains, and block C has one 200-gate chain. These scan chains are not balanced at the top-level. This imbalance can be avoided by limiting the maximum scan chain length at the block level to 100 flops. Block A thus has five 100-gate scan chains, block B has three 100-gate chains, and block C has two 100-gate chains. The necessary five scan chains can then be created at the top level by stitching the scan chains from across the blocks. Of the many permutable combinations, one possible solution is the following arrangement: Scan Chain #1: scan chains block A #1 + block A #2 Scan Chain #2: scan chains block A #3 + block A #4 Scan Chain #3: scan chains block A #5 + block B #1 Scan Chain #4: scan chains block B #2 + block B #3 Scan Chain #5: scan chains block C #1 + block C #2 This example assumes that the clocks in the design can be mixed and that the design is test-DRC clean. The example also assumes that lock-up latches are at the end of each scan chain to enable mixing the scan chains. In addition to the solution given above, other creative methods can be applied to specific designs. In general, test coverage can be analyzed at the block level and at the top level. The block-level target coverage should be higher than the top-level target coverage. Note that ILMs can simplify DFT procedures in a hierarchical design flow because it is possible to create ILMs that contain test information. Physical Compiler can read these test models and detect the scan chain information. This capability allows for test insertion at the top level without reading the entire block designs into the tool.

The Outlook for Hierarchical Design

As chip fabrication process feature sizes scale down and gate counts rise accordingly, the difficulty of designing a chip increases exponentially. This nonlinear increase in difficulty is the reason why more sophisticated methods of applying EDA technology are needed. Hierarchical methodologies offer workable solutions. The return on investment for initiating and managing a hierarchical flow in a large and growing number of cases can be significant.

2004 Synopsys, Inc.

12

700 East Middlefield Road, Mountain View, CA 94043 T 650 584 5000 www.synopsys.com For product related training, call 1-800-793-3448 or visit the Web at www.synopsys.com/services

Synopsys, the Synopsys logo, Design Compiler, Physical Compiler and PrimeTime are registered trademarks Jupiter and DFT Compiler are trademarks of Synopsys, Inc. All other products or service names mentioned herein are trademarks of their respective holders and should be treated as such. All rights reserved. Printed in the U.S.A. 2004 Synopsys, Inc. 11/03.KF. 03-11830.WO