Design Article

IMG1

Streamlining the SoC Design Flow

Claudia Relyea

11/20/2002 12:00 AM EST

New Challenges Require Smart Solutions
New process technologies enable IC devices of extremely small sizes and very high complexity. System-on-a-chip (SoC) designs incorporate whole systems on a single chip, containing processors, embedded memory, peripherals, and other system blocks. Yet as complexity increases, the time to get these devices to market continues to shrink. Producing these highly complex designs requires hierarchical-design teams employing a hierarchical-design flow. These are some of the challenges modular design teams are facing today:

  • Various design styles on a single chip (analog, mixed-signal, cell-based, full-custom)
  • New device technologies
  • Smaller process geometries with new design rules
  • Lithography and manufacturing corrections
  • Effects of long interconnects (antenna effects, analysis)
  • Overall verification and analysis time.

Physical verification ensures that the physical design matches the design intent. New process and device technologies require more complex design rules. The demand for reduced iterations and decreased time-to-market results in the need to uncover and fix potential manufacturing problems, such as antenna effects and lithography aberrations, earlier during the physical-design cycle. Combining SoC modules with various design styles on a chip (including mixed-signal and full-custom) dramatically increases design size. A physical-verification and analysis flow needs to provide accurate solutions for these challenges, reduce the number of iterations involved in chip verification, and provide the fastest possible performance.

Accurate Block-Level Verification vs. Capacity Needs of Large Designs
Designers rely on the accuracy and interactive abilities of block-level verification and analysis tools. In SoC design, different design methodologies converge at the component level—SoCs contain analog cells, mixed-signal blocks, processors, memories, peripherals, embedded modules, and more. With good block-level tools, the designer can extract and check any device and its properties, be that device part of a standard library or a handcrafted component. But now that advanced functionality is put into a design, block sizes are increasing. Traditionally, there have been a number of different verification and analysis tools used for various design styles, each having a particular strength or integration into a particular design environment. But many of these tools are unable to cope with today's large designs and process requirements. Furthermore, it is costly to support a multiple verification-tool environment: multiple support requires duplication of maintenance, training and support; lengthens the design schedule; and diminishes the design-team effort as whole to become expert at the tools used in the flow.

A Traditional Bottleneck: Full-Chip Verification and Debug
After top-level chip assembly is completed, final verification follows. To ensure the overall correctness of a chip, the entire design has to be verified down to the device level; in other words, everything checked at the cell and block levels must be checked at full-chip. Capacity, performance and accuracy are key factors for full-chip verification and debug. To accurately verify an SoC at the full-chip level, the physical-verification tool needs to handle all modular components, mixed-signal and full custom, and their interactions.

Today's large databases bog down traditional layout, debugging, and viewing tools. Opening a file may take hours and subsequent steps such as zooming, panning, and saving can be agonizingly slow. This is especially true if you are using tools that do not integrate adequately with the design environment. An inadequate tool may not only hamper the designer's efforts to produce a "clean" design, but may also cause a significant delay to the tape-out schedule. In addition, if multiple verification tools are used at the cell/block level, those tools will differ on the translation of clean data, which, in turn, could create integration problems at full-chip assembly.

Manufacturability checking is also typically done during the full-chip verification phase. The design has to be checked for metal density, and fill patterns are added in sparse areas of the chip. This added data might explode output-file sizes, which, in turn, can create a bottleneck at the mask-writer formatting stage.

Full-Chip Extraction Accuracy Historically Meant Sacrificing Performance
In today's designs, the parasitic effects of interconnect can dominate circuit behavior. Designers rely on parasitic-extraction tools to uncover and eliminate design problems due to parasitic effects that could cause chip-performance problems, and to avoid over-designing. Accurate extraction of parasitic devices results in very large netlists. Accurately extracting every parasitic element may result in very slow performance. Post-layout simulation tools struggle to simulate full-chip parasitic netlists, often resulting in weeks of simulation or non-convergence.

To minimize output file sizes, it is critical to employ different extraction modes to the various components on a SoC. Analog modules must be extracted with the highest levels of accuracy, down to the transistor level. For digital macros, a gate-level extraction might suffice. Handling interconnect parasitics for the interfaces of the different modules is yet another consideration in SoC design. The challenge lies in determining and executing the level of extraction detail resulting in the highest accuracy, while enabling several extraction runs per day. Many extraction tools require the user to re-extract for each analysis output; that is, capacitance only, resistance plus lumped capacitance, and R-coupled-C. Multiple extraction runs for the various analysis modes take up valuable time.

Another issue is back-annotation of parasitic-extraction results. For parasitic netlists to be usable in the designer's simulation testbench, the extracted-layout netlist, including parasitic devices, needs to be back annotated to the schematic netlist. For transistor-level extraction, an LVS (logic vs. schematic) run is done to match layout devices and nets to the corresponding schematic. The parasitic-extraction tool has to be able to access the LVS data in order to produce the back-annotated netlist; therefore, a seamless interface between LVS and extraction is critical.

Foundry Incompatibility Can Hamper Market Opportunity
If the physical-verification tool and rule files used in the design do not represent the foundry standard, an additional verification phase must be added to the design flow. All designs must conform to the chosen foundry's internal standard and the GDSII industry standard. Although some foundries offer second-tier tools and rule files, they are not supported or updated at the same level as the internal standard.

Stand-alone design groups using differing methodologies most often create individual components of a SoC. At a time when as much as seventy-five percent of a designer's efforts can be spent on verification issues, additional verification steps created as the result of not using the foundry standard can determine whether or not a product meets the time-to-market schedule or first-working silicon opportunity.

High-performance, Easily Integrated Tools Streamline The Design Flow
A streamlined design flow can contribute significantly to the success of a product and whether it meets its projected time-to-market schedule. Choosing tools that are design-style independent and that operate in the common language of the industry, GDSII, ensure integration ease. Design-independent tools will function the same whether the designer works in analog, digital, memory, or mixed-signal designs—built-in intelligence enables these tools to analyze the differences internally. User intervention is not required and because GDSII is the format in which all designs must be represented at the manufacturing stage, using a tool that already operates in GDSII eliminates the time and effort needed to stream in and out of proprietary formats. The key to streamlining the SoC flow is to choose tools capable of a high degree of performance, capacity, and accuracy, and which minimize iteration time, data volume, and expensive resources.

Adopting A Hierarchical, Single-Flow Physical-Verification Tool
Selecting a single hierarchical physical-verification tool that is design-style independent and encompasses a high-level of accuracy, capacity, and performance for both cell/block and full-chip design will quickly streamline the design flow (Figure 1). Being able to use a single tool for full-chip and cell-level verification ensures that there are no missed errors at the cell-level that emerge during final verification, and no time wasted on debugging false errors that a multiple-tool flow can create. In addition, by eliminating multiple tools, designers also erase the duplicated efforts of tool maintenance, support, training, documentation, and rule-file support.


Figure 1:  A single-tool physical-verification flow achieves cycle-time reduction in SoC designs

A physical-verification system that is well integrated into a custom-layout environment may greatly boost productivity at the modular level. Integration involves automation of common tasks such as stream-out, netlisting, and graphical debugging, along with a cross-probing environment where errors can be viewed and fixed in the actual layout. To save further iteration time, only corrected areas of the design need to be re-verified. During verification, the layout environment is not "locked," and the designer can use the layout tool for different tasks.

An intuitive graphical user-interface (GUI) is at the center of an efficient verification environment. Such an interface provides access to cell/block level verification as well as full-chip verification. A single rule-file for both cell/block verification and full-chip verification ensures that all components of a design, as well as their interactions, are accurately verified, with no chance for missed errors. Locating top-level signal shorts with traditional tools, or manually, can possibly delay a tape-out for weeks. Using a production-proven verification environment, you can locate and fix shorts in a matter of minutes.

The verification interface is also the center of integration for all other backend verification functions. Within such an interface, the designer can launch parasitic extraction and back-annotate parasitic values to the actual design environment. Shared algorithms and shared rule-files between tools, such as LVS and parasitic extraction, save significant steps and time in the verification flow. All parts of the flow, from DRC through extraction, can use multi-threaded processing to maximize performance. The look and feel of the various applications is the same, so the time to adopt, integrate, and master the tools is greatly reduced.

Multi-Threading Power for Significant Performance Gain
Most physical verification tools distribute multiple checks to each CPU in multi-threaded mode. However, to realize a substantial performance gain, it is best to choose a tool that geometrically leverages multiprocessor workstations or servers by dividing verification into thousands of individual "threads." Each thread can be run on a separate processor, multiplying the speed at which results are returned. By checking the same rule on multiple pieces of data at the same time, the total memory required does not differ considerably from running a single CPU versus multiple CPUs. Furthermore, since multi-threading capabilities are enabled with a simple command-line option, you don't need auxiliary files or set-up constraints.

Choose an Extraction Tool that Combines Accuracy and Performance
In a SoC design environment, parasitic-extraction output needs to address many different analysis requirements. An efficient tool can extract all parasitic data for an entire design—lumped C, lumped or distributed Rs and Cs, coupling capacitors or parasitic inductors—in a single run, and store that data in a parasitic database. Depending on the type of analysis needed for a particular module or the full-chip, the netlist formatter can generate a file containing only the required parasitics, thus minimizing the amount of data analysis tools need. In addition, no repeated extraction runs are necessary (Figure 2).


Figure 2:  All parasitic data is stored and on-call in the extracted database. All data critical for downstream analyses can be stored in netlist formats as needed without having to rerun extraction

A hierarchical netlist can further streamline the post-layout analysis flow. Hierarchical netlists enable complete full-chip transistor-level simulations in hours with powerful full-chip SPICE simulation tools on the market. Parasitic extraction for SoCs needs to address the added data volume of fill patterns. Fill polygons of various metals are added to sparse areas of the chip before manufacturing in order to help in planarization of the wafer surface. Due to the vast data volume resulting from the flat metal-fill methodologies of other verification tools, parasitic extraction including metal-fill used to be a bottleneck. Yet, the inclusion of metal-fill patterns is critical for accurate parasitic extraction. In a streamlined SoC verification flow, metal-fill data can be added and arrayed hierarchically during the DRC stage, and automatically handled by the extractor as intrinsic or coupling capacitors. Therefore, the bottleneck is eliminated.

To provide meaningful input to analysis, the parasitic netlist has to fit seamlessly into the designer's simulation environment, which is typically in the schematic source environment. Therefore, you need an LVS comparison of the design, which stores a cross-reference database of devices and nets. The extractor then can access this data and merge it with the parasitic results. Simulation and analysis tools can now use the merged netlist, containing designed devices and nets as well as all parasitic information. This example illustrates the extreme importance of seamless tool interfacing.

Full-Chip Visualization is Best for Debug
An efficient GDS-based viewing/editing tool can handle today's extremely large files. Each step of opening and editing a database takes only seconds; therefore, error-debugging time is greatly reduced, as is final verification time when the clean data is delivered for chip fabrication. The database can then be archived in GDSII format; however, after the crucial verification phase is finished, the physical database can then be updated and archived in the original design environment.

Look to the Foundry for the "Golden" Standard
Getting a design delivered on time means relying on industry-standard solutions. Tools using GDSII as the standard input/output format has many important advantages over proprietary database formats. No time is wasted translating data in and out of a database, and no data is lost in the process. The designer can be sure that the data sent to fabrication is indeed that which the designer verified.

Selecting the foundry's internal, or "golden," physical-verification standard ensures command files are readily available, up to date, and fully supported. Without this reliable standardization, designers have to construct their own rule files, or "fix" the design according to the foundry's internal physical-verification standard, which exposes designs to a greater risk of costly and time-consuming error-correction cycles.

Putting It All Together
In SoC design, a streamlined verification and analysis flow can contribute significantly to the success of a product. With manufacturing yield and time-to-market schedules crucial, it is important to select physical-verification and analysis tools that offer the best possible performance, capacity, and accuracy while minimizing iteration time and data volume. Selecting a single-tool flow for physical verification that is not only the internal foundry standard but also operates in the GDSII industry standard saves the time, resources, and costs of duplicate maintenance, support, and training. Tools that offer design-style independence ensure that the verification and analysis solution looks, feels, and integrates the same even if the designer changes or updates the design environment.


About the Author
Claudia Relyea holds a B.S. in Electrical Engineering, and has an extensive background in analog design. For the past three years, she has worked in technical and product marketing focusing on physical verification and parasitic extraction. She joined Mentor Graphics in 2002 as technical marketing engineer for the Calibre parasitic-extraction product line.

print

email

rss

Bookmark and Share

Joinpost comment




Please sign in to post comment

Navigate to related information

Product Parts Search

Enter part number or keyword
PartsSearch

FeedbackForm