asic design flow

Tutorial on CMCs Digital IC Design FlowInstructions for Taking a Sample Design through the Digital Flow(0.35-micron and 0.18-micron CMOS Technologies with Black-Box Libraries)

Document ICI-096, Part of Tutorial Release V1.3 Developed by Canadian Microelectronics Corporation

May 7, 2001

Copyright 2001 Canadian Microelectronics Corporation This document may be copied by eligible universities for use by licensed individuals. This tutorial involves the use of documentation, software and technology database files. Ensure you understand the conditions governing the use of all licensed material.

LICENSEYou must be licensed to use the materials in this tutorial. Your acceptance or use of the licensed material shall constitute your acceptance of the terms of the licensing. Read the LICENSE file for more information. Note that use of this tutorial can require use of licensed software such as that from Cadence and Synopsys. Similarly, the fabrication technology is proprietary to the manufacturer. Make sure you understand the licensing conditions governing the use of the tools and technology. In general, all of the materials in this tutorial and the CAD tools are governed by non-commercial use conditions. By prior arrangement, commercial use may be possible. Contact CMC about the possibility of such an arrangement.

TRADEMARKSSynopsys and the Synopsys logo are registered trademarks of Synopsys, Inc.; Design Analyzer, dont_touch, and dont_use are trademarks of Synopsys, Inc.Cadence, the Cadence logo, Design Framework II, Diva, GDSII, Pearl, SKILL, Spectre, Verilog-XL, Virtuoso, and Verilog are registered trademarks of Cadence Design Systems, Inc.; Envisia Physical Design Planner and Silicon Ensemble are trademarks of Cadence Design Systems, Inc. FrameMaker is a trademark of Adobe Systems Incorporated. Star-Hspice is a trademark of Avant! Corporation. UNIX is a registered trademark of The Open Group in the United States and other countries

Tutorial on CMCs Digital IC Design Flow V1.3 Page 2 Canadian Microelectronics Corporation/Socit canadienne de micro-lectronique

TABLE OF CONTENTS

TABLE OF CONTENTSTABLE OF CONTENTS ............................................................................................................................ iii LIST OF FIGURES .............................................................................................................................. vi INTRODUCTION ................................................................................................................................ 1 A TUTORIAL PURPOSE ...................................................................................................... 1 B CHECKLIST ...................................................................................................................... 3 C SETTING UP YOUR ENVIRONMENT ........................................................................... 4 D THE DESIGN EXAMPLE ............................................................................................... 11 E UP-FRONT ISSUES ........................................................................................................ 12 F REGISTERING YOUR TUTORIAL DESIGN WITH CMC .......................................... 17 MODULE 1: 1.1 1.2 1.3 1.4 MODULE 2: 2.1 2.2 2.3 MODULE 3: 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 MODULE 4: 4.1 4.2 MODULE 5: 5.1 5.2 5.3 5.4 SIMULATING THE RTL CODE .................................................................................... 18 Become familiar with the mult16chip design and test bench ........................................... 18 Simulate the RTL code with Verilog-XL ......................................................................... 19 View the simulator results ................................................................................................ 20 Save the waveform configuration ..................................................................................... 21 IMPORTING THE RTL CODE INTO SYNOPSYS ....................................................... 22 Start Synopsys Design Analyzer ...................................................................................... 22 Analyze and elaborate the RTL code ............................................................................... 23 Explore the Synopsys environment .................................................................................. 24 CONSTRAINING THE DESIGN .................................................................................... 26 Specify the I/O pads ......................................................................................................... 26 Define the scan style ......................................................................................................... 27 Define the output load ...................................................................................................... 28 Set maximum net transition (net slew) ............................................................................. 29 Define the clock................................................................................................................ 29 Set general compile directives .......................................................................................... 30 Propagate top-level constraints down to mult16bist module for synthesis ...................... 30 Save the constrained design .............................................................................................. 30 COMPILING THE DESIGN ........................................................................................... 32 Perform the initial compile ............................................................................................... 32 Perform an incremental compile ...................................................................................... 34 INSERTING SCAN ......................................................................................................... 37 Perform pre-insertion checks and check testability design rules ...................................... 38 Estimate fault coverage .................................................................................................... 38 Insert scan circuitry .......................................................................................................... 39 Perform final check and save the design as a gate-level Verilog netlist .......................... 39

Tutorial on CMCs Digital IC Design Flow V1.3 Page iii Canadian Microelectronics Corporation/Socit canadienne de micro-lectronique

TABLE OF CONTENTS

5.5 5.6 MODULE 6: 6.1 6.2 6.3 6.4 MODULE 7: 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 MODULE 8: 8.1 8.2 8.3 MODULE 9: 9.1 9.2 9.3 9.4 9.5 MODULE 10: 10.1 10.2 10.3 10.4 MODULE 11: 11.1 11.2 11.3 11.4 11.5 11.9

Write timing constraints 40 Create the physical test vectors ........................................................................................ 41 GATE-LEVEL SIMULATION ........................................................................................ 42 Modify or get your gate-level testbench ........................................................................... 42 Prepare the Verilog files ................................................................................................... 43 Run the simulations .......................................................................................................... 44 Insert and detect a fault ..................................................................................................... 45 FLOORPLANNNING ...................................................................................................... 47 Import the gate-level list ................................................................................................... 47 Add power pads to the design .......................................................................................... 48 Initialize the floorplan ...................................................................................................... 50 Create the ring of I/O cells ............................................................................................... 51 Define and place groups ................................................................................................... 54 Create placement sites ...................................................................................................... 56 Define special nets............................................................................................................ 57 Add power stripes (power planning) ................................................................................ 58 TIMING-DRIVEN PLACEMENT OF STANDARD CELLS ........................................ 60 Use the QPlace sequencer ................................................................................................ 60 View placement congestion .............................................................................................. 62 Perform timing analysis based on initial placement ......................................................... 62 CREATING A CLOCK TREE ........................................................................................ 65 Define the clock tree ......................................................................................................... 65 View the clock tree ........................................................................................................... 67 Write out the "golden netlist" ........................................................................................... 68 Add a power ring around the core .................................................................................... 69 Export the placed design .................................................................................................. 70 IMPORTING THE PLACED DESIGN ........................................................................... 72 Simulate the golden Verilog netlist .................................................................................. 72 Start Silicon Ensemble ..................................................................................................... 73 Import the results from Design Planner (PDP) into Silicon Ensemble ............................ 73 Import design-specific constraints .................................................................................... 74 ROUTING ........................................................................................................................ 76 Route power ...................................................................................................................... 76 Route the clock nets .......................................................................................................... 77 Perform timing-driven routing ......................................................................................... 78 Verify timing .................................................................................................................... 80 Export the routed design ................................................................................................... 81 Fix crosstalk problems identified in crosstalk error file ................................................... 87

Tutorial on CMCs Digital IC Design Flow V1.3 Page iv Canadian Microelectronics Corporation/Socit canadienne de micro-lectronique

TABLE OF CONTENTS

MODULE 12: 12.1 12.2 12.3 12.4 MODULE 13: 13.1 13.2 13.3 MODULE 14: 14.1 14.2 14.3 MODULE 15: 15.1 15.2 15.3 MODULE 16: 16.1 16.2 16.3 16.4 MODULE 17: 17.1 17.2 17.3

PERFORMING LVS VERIFICATION .......................................................................... 91 Start DFII with the appropriate technology ...................................................................... 91 Open your schematic ........................................................................................................ 94 Import the DEF view from Silicon Ensemble ................................................................. 96 Run LVS ........................................................................................................................... 97 FIXING MINOR DRC PROBLEMS .............................................................................. 99 Perform initial DRC ......................................................................................................... 99 Clean up the layout ......................................................................................................... 100 Fix "metal maxSize is 35.0um x 35.0um" errors ............................................................ 101 ADDING A LOGO ........................................................................................................ 110 Add a logo ...................................................................................................................... 110 Remove the PR boundary ............................................................................................... 111 Ensure edits have not introduced new errors .................................................................. 112 INITIAL SUBMISSION TO CMCS DRC SERVICE .................................................. 113 Create a copy of your design with the new name ........................................................... 113 Convert your design into a GDSII (stream) format ........................................................ 114 Submit the design to CMC for DRC checking ............................................................... 115 FIXING ANTENNA RULE VIOLATIONS .................................................................. 118 Save antenna rule error messages ................................................................................... 118 Fix the nets associated with the flagged antenna rule violations .................................... 118 View the DRC results on your design ............................................................................ 119 Locate the DRC problem nets ........................................................................................ 120 PREPARING YOUR DESIGN FOR FABRICATION ................................................. 124 Add fill ............................................................................................................................ 124 Perform final LVS .......................................................................................................... 126 Perform final DRC ......................................................................................................... 127

Tutorial on CMCs Digital IC Design Flow V1.3 Page v Canadian Microelectronics Corporation/Socit canadienne de micro-lectronique

LIST OF FIGURES

LIST OF FIGURESFigure 1: Figure 2: Figure 4.1: Figure 7.1: Figure 13.1: Figure 13.2: Figure 13.3: Figure 13.4: Figure 13.5: Figure 13.6: Figure 16.1: Digital IC Design Flow ....................................................................................................... 1 cmc_digflow Directory Structure ....................................................................................... 6 Schematic view of mult16chip ......................................................................................... 35 Floorplanned design ......................................................................................................... 54 Via Array Instance Before Edits (error marker not shown) ........................................... 101 Flattened Via Array (result of step 13.3.3) ..................................................................... 103 Vias Selected for Deletion (step 13.3.7) ......................................................................... 105 Vias Deleted ................................................................................................................... 106 Area Selected to be Chopped (steps 13.3.11-13.3.13) ................................................... 108 Slots After Chopping (result of step 13.3.14) ................................................................. 109 Diode Placement ............................................................................................................. 121

Tutorial on CMCs Digital IC Design Flow V1.3 Page vi Canadian Microelectronics Corporation/Socit canadienne de micro-lectronique

INTRODUCTIONREADME.FIRST

INTRODUCTIONREADME.FIRST A TUTORIAL PURPOSERTL Simulation Synthesis

The purpose of this tutorial is to introduce designersprimarily graduate students and faculty at Canadian universitiesto the digital IC design flow supported by CMC, and to the syntax used by the Synopsys and Cadence tools. To help you focus on the flow and the design environment, the tutorial package includes a sample design (described in part D of this Introduction). Using this design example, the steps outlined in Modules 1 to 17 will take you through a design process, starting with a register transfer level (RTL) model of the design all the way through to physical verification including stream file creation (see Figure 1). When you have completed all the design and verification steps, you will have a stream file to describe the mask layer information for your circuit. In the last steps, you can submit this file to CMC for Design Rule Checking (DRC) and will then correct the DRC errors. This guided process will help reduce initial difficulties in learning how to use CAD tools for synthesis (Synopsys) and physical design (Cadence). However, if you are relatively new to the IC design process, please note that the tutorial assumes you have some knowledge of the concepts behind the steps. To make the best use of the tutorial, you should be supported by a supervised educational environment and in-depth study of digital design theory and practice. Although this tutorial has been written to describe the specific steps required to complete a sample design using the TSMC 0.35-micron CMOS technology (CMOSP35) available through CMC, the steps will be applicable in some cases to digital design targeting other technologies. Similarly, you can transfer the lessons you have learned working with the tutorial sample design to your own design. This tutorial will help you work with a design that is flattened and without buses so that when you do a hierarchical design with buses you can focus on problems related to those features. You should be aware that you will need to do many more iterations with your own design than in the flow you will follow in this tutorial.

Verilog Design Analyzer Design Analyzer Verilog Design Planner DP/Qplace DP/CTGen Silicon Ensemble DFII

Scan Insertion

Gate-Level Simulation

Floorplanning

Placement

Clock Tree Generation

Routing & Timing Verification

Physical Verification

Figure 1: Digital IC Design Flow



CMOSP18 Throughout the tutorial, you will find boxes like this that highlight specific changes and additional steps that are required to use the tutorial with the 0.18micron CMOS technology (CMOSP18). You must be registered with CMC and have signed a Confidential Disclosure Agreement to get access to the 0.18-micron CMOS technology, including the design kit required to complete this tutorial (the design kit includes the design example for the tutorial). You can get information and forms about registration and completing the CDA at: http://www.cmc.ca/Assistance/legal.html Completing the tutorial can take approximately three days, depending on your experience with the tools. To help you pace yourself, we have marked two types of break points:

The hourglass icon will tell you when you will have a pause of at least a couple of minutes for computing.

The coffee cup icon will tell you when you have finished a set of tasks and/or exited a tool, and can take a break if you wish.

If you need help, e-mail [email protected]



B

CHECKLIST

CHECKLISTITEM # 1 2 ACTIVITYYou should have good problem-solving skills and be willing to provide feedback to CMC You must be registered with CMC, and your university must be licensed to use the TSMC 0.35-micron CMOS (CMOSP35) or you individually must be licensed to use the TSMC 0.18-micron CMOS (CMOSP18) technology, and you must understand and accept the associated licensing stipulations. You should be familiar with: a) Unix commands. b) Synopsys synthesis tools: If you are not familiar with Synopsys, there are tutorials located in the Synopsy on-line documentation. d) Cadence tools for Verilog simulation, floorplanning, place and route, DRC, and layout editing: If necessary, please contact CMC to request information on Cadence training materials and courses. d) CMCs CMOSP35 or CMOSP18 design kit If you are not familiar with the material mentioned above, then you might have difficulty with this tutorial. Stop now, and review the relevant training materials for the software you are not familiar with. Page ii

SEE

CHECK OFF

3

CMC

4 5 6 7

Ensure that the cmc_digflow or cmc_digflow18 directory has been created in your account. Ensure that your account has been set up properly to run both Synopsys and Cadence. Ensure that the required software and kit versions have been installed on your system To complete the entire tutorial you will require approximately 700 MB of disk space to store your design files and approximately 512 MB of RAM; however, you only need about 150 MB of disk space for Modules 1-16 with Module 17 requiring the additional space for tasks such as metal filling. You should now be ready to proceed through the tutorial. CONVENTIONS: In this document, ASCII text is shown in Courier font and executable commands and utilities are in bold Courier font.Icons, cells, objects, menu picks etc. are shown in bold Times font. CMC provides support for this tutorial and for the Synopsys/Cadence tools. If you have difficulty with any of these, you may contact CMC Engineering Support Services, [email protected] or 613-530-4666.

C1 C2 C3 C4

7 NOTE #1 NOTE #2



C

SETTING UP YOUR ENVIRONMENT

Before starting the steps of this tutorial, you must ensure that both your sites configuration and your own account configuration are properly set up to use the current versions of CMC-supported tools and design kit material. Since the CMC-supported design environment is constantly changing, this printed document may already be out of date. To ensure you have the latest information on using the material in this tutorial, you should check the CMC digital flow support page at: http://www.cmc.ca/Support/cmc_digflow/ The material on the linked pages will be kept current to reflect changes in the environment, flow, common problem areas, and feedback from other users. That Web address should be your first resource to overcome any difficulties you encounter while working on this tutorial. C.1 Obtaining the tutorial In order to go through this tutorial, you will need an initial working directory, the design and test bench files, and some technology-specific set-up files. The directory structure and initial files are available in a Unix .tar file from CMCs training material Web page: http://www.cmc.ca/Training/training.html (Note: You must be registered with CMC to obtain this filesee section F.) In order to install and complete the tutorial you will require 700 megabytes of disk space. Assuming you have access to that amount of space, obtain the compressed .tar file from the Web page by following the instructions listed there. Once you have the cmc_digflow35.1.2.tar.Z file, follow the steps listed below to create a cmc_digflow directory where you will complete the tutorial steps. 1. Move the cmc_digflow35.1.2.tar.Z file into the parent directory where you would like the new cmc_digflow directory to be created. Note that expanding the .tar file will create and place files in a new directory called cmc_digflow. You should not have a directory by that name in your account before proceeding. Uncompress the file with the following Unix command: uncompress cmc_digflow35.1.2.tar.Z 3. Extract the directory structure: tar xvf cmc_digflow35.1.2.tar

2.



4.

Remove the original.tar file (you can obtain a copy from CMC if you need this again at a later time). rm cmc_digflow35.1.2.tar

5.

To meet your licensing requirements and protect your design environment, use the following Unix command to change the file access mode on your design environment so only you have read access to the files. chmod -R go-rwx cmc_digflow

The cmc_digflow directory should now be created with the appropriate files and links required to complete the tutorial. CMOSP18 - Obtaining the directory structure that is compatible with CMOSP18 The directory structure for the CMOSP18 design example is called cmc_digflow18 (in place of cmc_digflow) and is created by obtaining cmc_digflow18.1.0.tar.Z from the Web and installing that file in your account with the following commands: uncompress cmc_digflow18.1.0.tar.Z tar xf cmc_digflow18.1.0.tar rm cmc_digflow18.1.0.tar Design Name You should use the same design name as with CMOSP35, except change the technology code from CD to CF. For example if your assigned design name was TCDICABC, you would use the name TCFICABC for the CMOSP18 design created using this tutorial. The basic directory structure used in this tutorial is shown below. Note that, in most cases, directories are tool-dependent. This same directory structure can be used for your own designs, once you are familiar with the design flow procedure. Throughout the tutorial documentation, an effort has been made to specify where particular files come from, and whether they are design-specific or general to most designs using this technology. This should help you adapt this training material for your own design.



dfII

dp

HDLs

samples

se

Synopsys

run

tech

design

dbs

Work

Figure 2: cmc_digflow Directory Structure

The use of each directory should become more apparent through the tutorial, but a brief description of each directory and its major contents and function is provided here. dfII - Cadence Design Framework II directory. This is used for the final design verification steps, once your layout is complete. dp - Cadence Design Planner (also called Physical Design Planner or PDP). Most of the physical design (layout) is done with this tool from within its run directory. The design directory is used to store intermediate design databases, and the tech directory is a link to CMOSP35-specific technology files within the CMOSP35 design kit. Design Planner is used to floorplan your I/O and core, as well as run a constraint-driven placement engine (Q-Place) and a clock tree generation tool (CT-Gen). HDLs - This is a design-specific directory that contains the Hardware Description Language (HDL) description of your design, and of the design test bench. This is also where functional simulation of the design takes place to ensure both the original designer-created Register Transfer Level (RTL) code, and the computer-generated gate-level netlists meet your functional specifications. samples - Some files are stored here that a designer would typically create for use in the design process. These files are included as examples, and also to reduce the time required to complete the tutorial and to ensure consistent results during this training exercise. se - Silicon Ensemble directory. Silicon Ensemble is a powerful set of tools, many of which can also be called from the Design Planner tool. For the purpose of this flow, the Silicon Ensemble tool is used for constraint-based routing of your design, and for running the Pearl static timing analyzer to ensure your routed design meets your timing constraints.



Synopsys - This directory is used for synthesis to convert your design from RTL code into gatelevel code, generate timing constraints to be met by the placement and routing tools, and to create scan-based test and test vectors. It contains a .synopsys_dc.setup file which points to technology-specific standard cell libraries (the black-box libraries) and a Work sub-directory that contains working views of your design. C.2 Ensuring your account is set up to use the environment Next you should ensure your account is set up to properly use the CMC-supported tools and flow. Since each university is different, CMC cannot document the exact steps required to set up your account. The following are some general pointers: 1. 2. You should read the LICENSE file included in this release and follow its conditions. Your account should be set up to use the CMC-supported versions of Cadence and Synopsys CAD tools. Sample C-shell script files which may be used to set up your account are listed on the CMC Support page: http://www.cmc.ca/Support If you are not sure if your account is properly set up, or if you run into problems later on, the best source of knowledge is usually another person at your university who has already completed the tutorial. Your sites Unix system administrator and lab instructors are also usually a good place to turn for help in setting up your environment. Although CMC suggests your account should be set up to configure the Cadence and Synopsys tools from your .cshrc file, some sites have configuration scripts that the user calls from a shell before running the CAD tool. These scripts can cause trouble if the tool spawns a new Unix shell itself since that new auto-generated shell has not been properly configured. Fortunately, system administrators who create the setup scripts are usually knowledgeable enough to debug other effects. 3. In addition to the variables set in the provided tool setup scripts, it is assumed that your account already sets other required variables such as a valid LD_LIBRARY_PATH variable, and that you do not get warnings or errors such as "Ridiculously long path truncated" when you source your .cshrc. It is well worth your time to debug any .cshrc file problems before attempting to complete the tutorial steps. 4. You will require approximately 700 megabytes of disk space to store your design files. However, it only requires about 150 megabytes to complete Modules 1-16. The tasks in the final Module 17 require much more disk space because they involve adding the metal fill and saving the file in GDSII format (the uncompressed version of the final GDSII (stream)



file for example is over 100 megabytes alone). 5. You will require access to a computer with sufficient RAM, SWAP and CPU to use the tools. CMC recommends 512 Mbytes RAM, but this also depends on other loads, etc.

You may need to consult your faculty supervisor or system administrator if you do not have sufficient computing resources to complete this tutorial. C.3 Ensuring your site is properly configured In order to successfully complete the training material, you will need to ensure the CAD tools and design kits you are using are the proper versions. The current set is listed below, and an updated set of required tools and kits can be found on the Web at: http://www.cmc.ca/Support/ If you find your site is not properly configured for this tutorial, you will need help from your faculty supervisor and/or system administrator. 1. Design kit. This training material uses the TSMC 0.35-micron CMOS technology (called CMOSP35 by CMC). You should be using V4.2 or higher of that design kit. To see which version is installed at your site, in a Unix shell issue the command: more /CMC/kits/cmosp35/README The top of the file you get should list the version as being 4.2 or higher. For documentation on this design kit, check out the HTML pages included in the kit by entering the following in a Web browser: file:/CMC/kits/cmosp35/doc/cmosp35_docs.html. The page that comes up should also list the kit version as being 4.2 or higher. This page contains documentation on various aspects of the CMOSP35 design kit including data sheets on the standard cell library being used, and general instructions on using the digital design flow. CMOSP18 - Design Kit Version This training material uses the TSMC 0.18-micron CMOS technology (called CMOSP18 by CMC). You should be using V3.0 or higher of that design kit. To see which version is installed at your site, in a Unix shell issue the command: more /CMC/kits/cmosp18/README The top of the file you get should list the version as being 3.0 or higher. For documentation on this design kit, check out the HTML pages included in the kit by entering the following in a Web browser: file:/CMC/kits/cmosp18/cmosp18_docs.html.



2.

CMCs local environment for Cadence. This environment is used to bind the CMOSP35 design kit into the Design Framework II tools from Cadence. Your site should be at V1.10 or higher. Cadence tools. This tutorial is intended for use with a patched version of what CMC calls Cadence.2000a. If your site has that tool, you should have the IC stream IC.445.000508 with QSR (Quarterly Software Roll-up) 1. Check the following path appears: /CMC/tools/cadence.2000a/IC.445.qsr1 and the DSMSE stream should have been patched with the Pearl patch (pearl04.30s080sun4v). If you enter the command pearl -version, you should get the following: Pearl 4.3-s080 Also, you should be able to start the Pearl timing analysis tool from the Unix command line with the following command: pearl -gui If that command successfully spawns a user-interface, you can exit from that interface, and it is likely that the IC stream of your Cadence environment is properly set up. If you can not run pearl -gui, you should consult with your system administrator for suggested work arounds at your site. A second test of your Cadence install is to start the DFII environment with the command: startCds -t cmosp35 This should launch the Cadence Command Interpretor Window (CIW) where you can check your current version of the Cadence icfb tools and the version of design kit being used. You can use the command icfb -W from the Unix prompt to find your sub-version, or if you expand your CIW, near the top you should be able to find a line that lists the sub-version of the tool you are using. If your Cadence install has had a QSR applied, you should have a sub-version equal to or larger than: Sub version: sub-version 4.4.5.100.28 You should also be able to find a line similar to the following in your CIW which should give you confidence that Cadence is using the proper version of the CMOSP35 design kit: This is the CMC CMOSP35 Design Kit V4.2 for Synopsys and Cadence There are two other Cadence streams (DSMSE and DSMDP) that must be compatible for this tutorial. Your system administrator is responsible for that, but you can check the most recent instructions on CMCs Web Support page. Online documentation for most Cadence tools is found by entering "openbook" from your Unix command line. In order to access all the streams of Cadence online documentation, users should review the "Cadence Online Documentation" item linked from the http://

3.



www.cmc.ca/Support page. That page also gives some information on accessing documentation on Design Planner (another Cadence tool) from your Web browser. 4. Synopsys tools The exact version of the tool being used is less critical with Synopsys than with the other tools. To determine if Synopsys is working, and which tool you are using, at the Unix prompt issue the command: design_analyzer & A version message something like: Version 2000.05 -- Apr 10, 2000 Copyright (c) 2000 by Synopsys, Inc. ALL RIGHTS RESERVED should appear in your Unix window, and a Synopsys Design Analyzer window should appear. The Synopsys version should be 1998.02 or higher. You can exit from the Design Analyzer window by clicking on File -> Quit Online documentation for Synopsys depends on the version of Synopsys you are using. If youve used the CMC-provided setup script, documentation for version 1998.08 and newer is in PDF format, and can be started by entering "sold" (Synopsys On Line Documentation) or "synview" from the Unix command line. Versions of Synopsys prior to 1998.08 used the command "iview" from the Unix prompt. You are strongly encouraged to read as much as possible of the online documentation for the tools you are using. If you encounter problems using the tools, check the following sources of information: 1. 2. 3. 4. 5. 6. The http://www.cmc.ca/Support Web pages, including the Digital Flow page linked from there The tools on-line documentation Other users at your site Your sites system administrator Users at other sites (using the [email protected] mailing reflector) [email protected]

NOTE: Users must NOT contact the CAD tool providers (Synopsys or Cadence) directly.



D

THE DESIGN EXAMPLE

D.1 Understanding the design example The particular example selected for this training material is a basic 16-bit multiplier (16-bit x 16bit producing 32-bit output). BIST: In an attempt to illustrate good design technique, a Built-In Self-Test (BIST) feature is included. Although not documented in this tutorial, self-test (BIST) is a feature that allows a device to test itself for functional problems once manufactured. Self-test is growing in use as more complex designs are being created, and as block-based and system-on-chip design is becoming more common. Please note that this design includes only a basic attempt at BISTthe algorithm is flawed, and should NOT be used for your own design. There is a wide range of resource material on BIST design, including various BIST algorithms which can be used for your own designs. Scan: A second form of test included in this design example is scan-based Design For Testability (DFT). This scan-based DFT allows the chip to be easily tested after manufacture to ensure there were no manufacturing errors, or subsequent problems (bonding problems for example) with the chip. Scan-based DFT is intended to test the chip before it is placed in its final application, to ensure the part you are using is working. BIST is used once the chip is in its final application to ensure the part continues to operate as expected. Scan-based DFT is also not covered in this material, since there are books that can be found which cover the subject (the Synopsys On-line documentation also has some information on scan-based DFT). For the purpose of this design, DFT means building the design so all sequential elements (flip-flops) can be replaced with multiplexed equivalents, which are connected into a shift register. When in "scan mode" this long shift register (or scan chain) is used to pre-load and sample values of internal nodes of the circuit. When scan-based testing is not used, the multiplexed FFs are placed in non-scan mode, and the circuit operates normally. In order to use scan-based test, scan in, scan enable, scan clock, and scan out pins are required on your design. For this example, the scan clock is the same pin as the regular clock, and scan out is also used as the designs BIST out pin. Neither BIST nor scan-based DFT are designed to ensure the original design is functionally (or logically) correct. Nor do they ensure your design will meet your timing goals. To ensure your design is functionally and logically correct, you should use sound design practices while designing your chip, and make use of a complete set of test patterns to simulate your chip before synthesis and throughout the design process.



This design example has five separate Verilog modules: mult16chip is the top-level module, and is also called an "I/O wrapper", since it is port-compatible with the next lower mult16bist module, but includes instantiated I/O pads. It is common practice to have the wrapper module as a separate file. This module does not affect the logical function of the design, and is the only technology-specific portion of this design. To port this same design to another technology, only the wrapper module needs to be modified (to instantiate I/O from the new technology instead of from the CMOSP35 technology libraries). mult16bist has the same port list as the top-level mult16chip, and would have been used as the top-level of this design during development stages. mult16bist just contains calls to the three sub-modules. mult16 is the simplest in terms of RTL code, and simply has the form of: product = A x B. bist contains a crude BIST algorithm which you can look into, but which should NOT be used in your own designs. glue is logic which ties the other two sub-level modules together. It is critical that you understand all of the interfacing and functional aspects of your own design. However, for this tutorial example it is not important to fully understand the logic within the design itself, if you accept that the test bench properly exercises the design example.

E

UP-FRONT ISSUES

A designer must undertake a lot of evaluation up-front in order to create a chip. Although much of the up-front evaluation can be ignored when doing a training exercise (since this chip is not going to be fabricated anyway), you still should be aware of the up-front issues you MUST consider before attempting to fabricate your own chip. Architecture exploration: What function is meant to be accomplished, and what is the most efficient way of completing it? This is a very complex consideration, and will include your motivation/need for creating an IC. For this design example, a 16 by 16-bit multiplier, the designer should consider using an FPGA to create the design, or using an existing microprocessor or microcontroller to accomplish the task. In industry, factors such as per-unit cost, development cost, time to market, and performance requirements will often play a part in the decision. The academic world is often driven by quite different factors.



Interfaces and top-level floorplan: If you are creating a chip, to what and how will it interface? How many input/output and power pins will be required? What speed will it need to run at? Fabrication technology and cell library selection: When starting a design project, one of the factors a designer must consider is which design technologies are available, which are most appropriate, and what other issues are related to the selected technology. After studying this design example, a good case could be made to use an FPGA as the fabrication technology, rather than an ASIC (Application Specific Integrated Circuit). However, the whole purpose of this tutorial is to take the user through a Digital IC Design Flow (which is a form of an ASIC flow) and it was therefore decided to use the 0.35-micron CMOS (CMOSP35) IC fabrication technology that is available through CMC (more information on this technology is available on the Web at http://www.cmc.ca/Fabrication). Having selected a technology, the designer needs to select a standard cell library (set of basic gates such as AND, OR, INVERT, FFs, etc.). The CMOSP35 design kit provided by CMC includes two standard cell libraries. The library selected for this tutorial is from the technology foundry (TSMC or Taiwan Semiconductor Manufacturing Company) and the cells are often referred to as "Black Box", "BBox", "B-cells", or sometimes phantom cells. This is a fairly elaborate set of standard cells of professional quality, and in order to protect TSMCs intellectual property the layout information of these cells is not provided in the CMOSP35 design kit. Instead, the designer creates a design based on abstract (information reduced) views of the cells. The physical layout detail is only added to the design after it is submitted to CMC for design rule check (DRC) or fabrication services. Since this library does not have layout or extracted views, it is not possible to run "analog" simulations such as Spectre or Hspice on your design. This is not a problem in the case of this design, since it is a pure digital design, and logical Verilog simulations coupled with static timing analysis are sufficient to verify the design will work without conducting transistor level simulations of the circuit. Many aspects of the techology and standard cell selection will affect how the designer proceeds at various steps. For example, a technology with more layers of metal can usually have its standard cells compressed together more tightly. Also, the size of the standard cells will affect the spacing of rows and cells within the design, and the optimum metal routing pitch which can be used to route the design. Most of these items are not under the control of the designer since the designer is stuck with the choices made by the cell library developer, who was stuck with limits placed by the technology fabrication facility. It will take a while to learn what parameters you should or can modify as a designer, and which ones you should use as set out in this tutorial. It is hoped that completing this tutorial example will help you develop the design experience needed to make such choices. Packaging: Packaging is related to the top-level floorplan. Before you can design the chip, you need to determine what package (for example a 20-pin DIP) your chip will end up in. In order



to select a package, you will need to consider what packages are available, and if your chip can be bonded to them. What pin-count do you need, what are your speed requirements, what is your die area going to be, will bonding (attaching your IC die to the package) be a problem, etc.? All designers should review the CMC Web page on packaging page: http://www.cmc.ca/Packaging/ before proceeding with their own design, and contact [email protected] if you have any questions. Design size and power: Well before you create your design, you will need to have a good idea about its final size, shape and power requirements. Experience, both your own and that of other designers, is the best aid in up-front planning of your design. The following is a list of up-front issues that were considered for this design example. You MUST consider these and more when planning your own design. 1. Will this design be I/O bound, or core bound? That is, will there be any free space within the I/O ring? Designs that are I/O bound (have free space within the core) are wasting expensive design area, and would seldom be fabricated in industry. To get an initial estimate of the size of this design example, a very short Verilog RTL file was created which only contained the 16-bit multiplier. That module was similar to the mult16 module in the present design. That one module was synthesized without constraints using Synopsys. The area, timing, and power values are used as a starting point: In this case, the total area was reported as 143,000 square microns. A target clock speed (50 MHz) was applied and the critical path and a basic power estimate were generated: 33 mW and 26 ns critical path time were reported. It is anticipated that the multiply function will account for over one-half of the core area, almost all of the timing delay, and less than one-half of the power requirement (since the glue and BIST logic will add FFs and clock gating is not being used to reduce power consumed by those components). Given these data, it is estimated that the design will have a core area of 300,000 square microns if 100% core utilization was used, i.e. if all standard cells were packed together with no space between them. Power consumption should be well under 100 mW, and the 50 MHz (20 ns period) clock may be tight, but is not totally unreasonable. 2. I/O Pins. Next the number of required I/O pins is considered. The basic design has two 16bit input vectors, a 32-bit output, an input clock, reset, scan enable, scan input, and bist mode pins, as well as a combined scan/BIST output pin. This adds up to 70 I/O pins. In



addition VDD and VSS pins will be required to power the chip. Browsing the I/O datasheets for the TSMC library provided with the design kit shows three types of power cells are available. 1. Core power pads which provide power to the core of the chip. Core and ring power are often separate to reduce the off-chip noise associated with high-current drive from affecting the core power. (PVDD1 and PVSS1) 1. Ring power pads which are used to provide power to the other I/O cells, and drive signals off-chip. (PVDD2 and PVSS2) 3. Combination core/ring pads exist. These pads power both the ring and the core from the same pin. (PVDD3 and PVSS3) It is decided that this design will have 6 pairs of ring power pads based on a rule-of thumb of one pair for every 4-6 output pins (this is very dependent on output toggle rate! For a fabricated design, simulation and detailed calculation are strongly encouraged.) For core power, four pairs of pads will be used. This allows for distributed power connections to the core, and using the rule of thumb of 1 mA per micron of metal width and assuming 60-micron wide power connections are going to be made, this should allow for an average flow of 240 mA of current to the core, which at 3.3 Volts gives a margin of almost 8x the estimated maximum core requirement of 100 mW. If your design is power intensive, or has portions which may be, heating effects or "hot spots" might cause problems. Adding 20 power pads (6 pair for ring power, 4 pair for core) brings the design pin count up to 90. 3. Die Size. Before determining if a suitable packaging option exists, the total die size should be estimated. From viewing the layout of the I/O pads it is determined that the standard I/O size is 84 by 365 microns. The CMC Web page on fabrication issues suggests that the "easiest" bonding pitch is 150 microns. This implies that without having special bonding considerations, the I/O pads need to be spaced apart an extra 66 microns. To accomplish this, four 20-micron wide "feeder" cells are added between every I/O pad within the I/O ring. So in effect, each I/O connection takes up 84 + 80 = 164 microns of the I/O ring. In addition to this, four 365-by-365 micron corner cells need to be added. If the 90 I/O pads could be evenly spaced around the design there would be 22.5 per side (that is an impractical number, but since this is just a rough calculation, we will use it for this example). Each side would be 22.5 times 164 plus two 365 corner cell lengths, plus an extra set of 80 micron feeder cells per side (to space the corner cells out). This makes a total length of 4500 microns, or 4.5 mm. Assuming this is a square chip, the usable core area is this number minus the space taken up by the I/O ring (2 times 365) squared or 14,212,900 square microns. Or over 108 times the 100% core utilization area number!!



It is not practical to manufacture a chip with so much wasted area. Some steps which could be done to reduce the area requirement for this I/O ring are: 1. Reduce the pin count. This can be done by multiplexing signals, or transferring data in a serial fashion, instead of parallel busses. 2. If possible, reduce the I/O pitch. In the case of this design, the designer should contact [email protected] to discuss the possibility of bonding the chip if no I/O feeder cells are used. 3. Modify the aspect ratio. Assuming the chip perimeter is fixed based on the number of required I/O and power pads, the internal area is maximized as the shape becomes square. The internal (and total) area is minimized, as the aspect ratio is increased or decreased and the chip takes the form of a long or flat rectangle. Modifying the shape in this way can cause other problems such as bonding issues, and increased trace lengths within the die. Also, the shape/size of your die should be discussed with CMC before floorplanning the I/O to ensure your die will fit on the wafer along with designs from other designers. If your chip is core bound, the area used by your core (you will not be able to realize 100% utilization) is larger than the bound area of the chip. You will likely use a square shape to maximize internal area, and will need to add feeder cells around the I/O ring to ensure all I/Os are connected by abutment. A final note on the I/O ring is that in this flow the ring is connected by abutting I/O pads, feeder cells and corner cells to form a solid I/O ring. For this reason, the designer needs to consider and place every I/O and power pad on his/her design. This should be considered up front, along with external interfacing issues, and you need to be aware that core power routing is difficult if core power is placed in the corners of the die. In the example I/O floorplan used in this tutorial, the core power pairs are intentionally placed in the centre of each side of the die. Although this design example is severely I/O bound, since it is not going to be fabricated and is only used as a training example, we will continue with these numbers. The design will be given a flat aspect ratio which reduces the core area. If you plan on fabricating your own design, you must fully resolve packaging, bonding, test fixturing, and physical test issues BEFORE creating your design. All of these issues are interrelated, and affect decisions such as the number of I/O ports you can have on your design.



CMC has developed a digital design checklist which will help ensure the designer considers necessary aspects of the design before getting too far on in the design process. Check http://www.cmc.ca/Design_Flows/ for more details. When possible, designers should review their design plans with supervisors, or other experienced designers, to avoid potential problems later in the design/test cycle.

F

REGISTERING YOUR TUTORIAL DESIGN WITH CMC

Before beginning the tutorial, you should obtain a design name for use in the later steps of the tutorial. For you own designs, you typically pick a three letter code, and append it to the technology code, and your university code, as described on CMCs Web pages on Fabrication (www.cmc.ca/Fabrication). For this tutorial, CMC will assign a special "tutorial" code for use with the CMOSP35 technology. To obtain your design name, go to the Web page: http://www.cmc.ca/Training/Digital_Flow/cmc_digflow_getting_started.html


MODULE 1: SIMULATING THE RTL CODE

MODULE 1: SIMULATING THE RTL CODERTL Simulation


Objective 1: To verify the functionality of the Register Transfer Level (RTL) code describing the design exampleBackground: The back-end of the DSM flow uses Verilog to transfer the design from Synopsys to Cadence, but the design itself can be in either Verilog or VHDL. Using Verilog for the RTL code offers the advantage of needing only one test bench for the entire design cycle. If you wish to write your RTL code in VHDL, you will need a VHDL test bench for initial code verification, and then an equivalent Verilog test bench for final simulations. To avoid these problems, Verilog was selected for the RTL code.

Synthesis

Scan Insertion


Floorplanning

Placement


1.1

Become familiar with the mult16chip design and test bench

The design is a 16-by-16 integer multiplier with a built-in self test (BIST) feature. It is hoped that the design will operate with a 50 MHz clock, and have over 98% fault coverage using a multiplexed flip-flop scan-based test system. Power consumption should be less than 100 mW. For the final stages of this design exercise, you must have an assigned design name which you will use to submit the design example to the CMC Design Rule Check (DRC) service. In preparation for those stages, you should now register for an individual design name by going to the Web page: http://www.cmc.ca/Training/Digital_Flow/cmc_digflow_getting_started.html Updates on the digital design flow and environment can also be found at the same Web page.



CMOSP18 Remember the directory for your design files is: cmc_digflow18 1.1.1 To view the design files, from the Unix prompt: cd cmc_digflow/HDLs more mult16chip_rtl.v more mult16tb_rtl.v



Normally the designer would be quite familiar with the code and test bench. Take a while to look through the code. Understand the mult16chip design, and the test bench. Notice that the actual a x b = prod. multiplication is only a very small portion of the RTL code. Most of the code is dedicated to the BIST. It is not important to understand the BIST itself, as this is a very poor example of a BIST algorithm. Note that a simple design style was used. The design is fully synchronous off the rising edge of one clock signal. No latches or three-state devices were used. The reset input will place the entire design in a known state. These simple points will help make the design easier to test, and to ensure the synthesized results behave as expected. When writing the RTL code it is important to not only ensure the code will function properly, but the designer should also have a fairly good idea of the resources which will be created by the code. For example, how many flip-flops would be used by this design? The test bench provides the system clock and reset signals, and also initially invokes the circuits selftest, and monitors the output. Once two complete self-test cycles are finished, the chip is placed in its functional mode, and test vectors (with input values and expected results) are fed into the circuit. In this test bench, the functional vectors were generated by the included C program. Arbitrarily 1000 random vectors were generated, with expected results. Then some of the vectors were changed to exercise specific corner conditions (anticipated trouble areas for the multiplier circuit) and finally, one of the expected results was altered so the test bench would flag an error. The erroneous expected result serves two purposes. First, it reassures the designer that the test bench is working, and can tell when an error occurs, and secondly, because the vector with the error is near the end of the 1000 test vectors, it ensures that all of the vectors are being read in by the test bench.

1.2

Simulate the RTL code with Verilog-XL

The bbox_ver.setup file used in the Verilog simulation command contains technology library information used by Synopsys. This is needed since the RTL netlist does contain some gate-level I/O instances, so it is really a technology-dependent netlist. 1.2.1 At the Unix prompt, ensure you are in the HDLs directory: cd cmc_digflow/HDLs and issue the following command: verilog -f bbox_ver.setup mult16chip_rtl.v mult16tb_rtl.v This should cause Verilog to compile and simulate the specified files. Here is a sample output for a working design:



...Compiling source file mult16chip_rtl.v Compiling source file mult16tb_rtl.v Scanning library file /CMC/hits/cmosp35/models/verilog/nwb/bcells.v Highest level modules: tb Bist_out went low at time: 0 Bist_out went high at time: 170 Bist_out went low at time: 230 Bist_out went high at time: 2450 Bist_out went low at time: 2510 Functional test error: Vector 995, Actual product was: 177356088 L68 mult16tb_rtl.v: $finish at simulation time 2600000 0 simulation events (use +profile or +listcounts option to count) CPU time: 0.2 secs to compile + 0.0 secs to link + 0.7 secs in simulation End of VERILOG-XL 2.5.15 Oct 9, 1998 22:11:34

Note that the error at vector 995 was intentionally inserted in the mult16tb.stim file. For initial simulations, or times when the results are not as expected, the designer will likely want to view waveforms of internal signals.

1.3

View the simulator results

In the test bench file a number of signals were written to a database. These signals can now be viewed. The name of the database and the signals written to it are defined in the mult16tb_rtl.v file by the two commands: $shm_open(file_name); and $shm_probe(signals, to, be, saved); 1.3.1 To start the waveform viewer tool, enter the following at your Unix prompt: signalscan mult16tb_rtl.db Once the signalscan tool starts up, select: File -> Open Simulation File In the pop-up window, select: cmc_digflow/HDLs/mult16tb_rtl.db Click: OK 1.3.3 Click the Desbrows:1 button, then the DAI Signalscan Design Browse:1 window will pop up. In Instance in Current Context, select tb. It will display chip at once, and in Nodes/Variables in Current Context, all inputs and outputs of chip will display.

1.3.2



1.3.4 1.3.5

Select all of the signals by clicking the GetAllVars button. To add or remove a signal from the selected set: To add a signal, just click the signal in the Nodes/Variables in Current Context. To remove a signal, select the signal from the selected set and click on the Delete button.

1.3.6 1.3.7

To have these selected dignals added to the display window click on the AddtoWave button. You can ascend the hierarchy instances by clicking on an instance in Instance in Current Context. For example, with this design: Click on chip then mult16bist will display. All the input and output signals of mult16bist will display under Nodes/Variables in Current Context. Once you have all the desired signals displayed in the DAI Signalscan Waveform:1 window, you can adjust the order of the signals and the way they are displayed, zoom in, zoom out, etc. If you have the display you want, it is a good practice to save the setup, so that you don't need to go through this process every time you call up the Signalscan tool.

1.41.4.1 1.4.2 1.4.3

Save the waveform configurationTo save the setup, click on: File -> Save do-File In the pop-up window, put in the name of save do-file, and click OK. To show this set of waveforms next time, from the main Signalscan window select: File -> Execute do-File Select the do-File name in the pop-up window and click OK.

1.4.4

Once you are happy with the simulation results, close the Signalscan tool: File -> Exit


MODULE 2: IMPORTING THE RTL CODE INTO SYNOPSYS

MODULE 2: IMPORTING THE RTL CODE INTO SYNOPSYSRTL Simulation


Objective 2: To import the design example into a Synopsys database

Synthesis

2.12.1.1

Start Synopsys Design AnalyzerChange into the Synopsys directory: cd ../Synopsys Ensure you have an appropriate .synopsys_dc.setup file: more .synopsys_dc.setup

Scan Insertion


Floorplanning

2.1.2

Placement

The .synopsys_dc.setup file sets the environment for the Design Compiler family of Synopsys tools. This file sets the search path for all libraries which will be used, and tells Synopsys what the target technology will be. It sets some other default values (bus naming style, etc.), and in this case, includes some scripts of common functions. Note that the .synopsys_dc.setup file in this tutorial is similar to the one that is used in your sites design environment and is included in the /CMC/ kits/cmosp35/synopsys/dotfiles directory. One difference is the addition of the following line: define_design_lib work -path Work This line is needed to tell synopsys to use Work as the working directory. It is needed since a .synopsys_vss.setup file is not used (the .synopsys_vss.setup file often includes the path to a working directory). 2.1.3 Start up the Design Analyzer tool by entering at the Unix prompt: design_analyzer Design Analyzer is a graphical interface to Design Compiler. 2.1.4 Open the Command Window by selecting: Setup -> Command Window... The Command Window echoes text versions of all functions performed, and allows the designer to enter Design Compiler commands as if they were using dc_shell (the Design Compiler text-based interface).






A log of the Command Window is automatically created in the view_command.log file. This is useful to review previous steps/results, especially after a long compile. HDL code (Verilog or VHDL) should be read into Design Analyzer with the Analyze and Elaborate steps. This is especially important when reading a file in for the first time.

2.22.2.1 2.2.2

Analyze and elaborate the RTL codeIn the Synopsys Design Analyzer window, select: File -> Analyze... In the Analyze File window double left-click on: ../HDLs/mult16chip_rtl.v There should be no errors with this design, but this step is usually part of the code debug cycle. Just because you can simulate your code does not mean it can be synthesized!! Now elaborate the top-level design into the default library: File -> Elaborate... In the Elaborate Design form: Left-click on DEFAULT Left-click on mult16chip(verilog) which is the top-level module of this design. Click: OK

2.2.3 2.2.4

The results of elaboration will appear in both the Elaborate window, and the Command Window. This is a good place to look for problems with your design. Designs should have no warnings or errors at the elaborate stage. Also, instantiated sequential components (e.g. FFs) should be as expected. All modules in your design should now be present in the Synopsys Design Analyzer window (bist, glue, mult16, mult16bist and mult16chip in this case). You can Cancel the Elaborate window, or leave it there. Synopsys will use that window to report results from other steps. Note that the top-level designs are shown as a gate, where the other modules are shown as text code. This is because the mult16bist and mult16chip modules contain only "gate level" Verilog, where the other modules contain "RTL" code.



2.32.3.1

Explore the Synopsys environmentLeft-click on the top level of your design (mult16chip). Have Synopsys check your design for problems: Analysis -> Check Design... OK the Check Design form. This design should only have warnings about connection class differences on the I/O pads, and test_si and test_se signals not driving any nets. These are ports on the design but they have nothing connected to them. They will be used later for scan-based test.

Initially you have five boxes corresponding to the five Verilog modules in your design: mult16chip, mult16bist, bist, glue, and mult16. Each of these modules has various views in Design Analyzer. The current view is displayed on the bottom right had corner of the Design Analyzer window: Designs View. 2.3.2 If you single click on the mult16chip module, the following is displayed at the bottom of the window: Design: mult16chip (mult16chip.db) You can double-click on the mult16chip box, or click on the down-arrow on the left side of the window to descend into that design. You should now have the following displayed: Current Design: mult16chip You can change between hierarchy (button containing a block diagram), symbol (button containing a block with input and output pins), and schematic (button containing an and gate symbol) views. In schematic view you can see all of the I/O pad symbols, the mult16bist block, and how they are interconnected. If you click on an object or net, the window displays what you have selected. For example a blue box in the centre (you may need to zoom-in) of your design should be Instance: mult16bist (mult16bist). 2.3.3 If you double-click on that instance, Current Instance: mult16bist (mult16bist) should be displayed on your screen. You can explore the different views of the various modules. Note that all components displayed except the I/O pads are generic at this point. The mult16bist module shows the connection to the other three modules. Return to the top level of the design by clicking on the up-arrow a few times. 2.3.4 The design is currently in a Synopsys database. Save the design in this form as follows: Select the top-level module (mult16chip) and then: File -> Save As... OK the Save File form to save the design under the default name mult16chip.db The .db file is a Synopsys proprietary format which has the advantages of being quickly read/written by the tool, and it stores constraints placed on the design as well as the design information itself. This is not related to the .db directory created by Verilog in Module 1.



You can now proceed directly to Module 3, or exit from Synopsys: File -> Quit

THIS IS A NATURAL BREAK POINT


MODULE 3: CONSTRAINING THE DESIGN

MODULE 3: CONSTRAINING THE DESIGNRTL Simulation


Objective 3: To specify constraints on the design which are a way of ensuring the design meets the designers performance objectives

Synthesis

Scan Insertion

3.13.1.1

Specify the I/O padsGate-Level Simulation

For Module 3 you will need to start Design Analyzer from the Synopsys directory. cd Synopsys design_analyzer

Floorplanning

Placement


3.1.2 3.1.3

Bring up the Command Window: Setup -> Command Window... Read in the previously created design database: File -> Read... Double-click on mult16chip.db (or single-click on it, then click on OK). Note that Read is used to import .db files. The .db files preserve Synopsys environment settings as well as circuit structure.Routing & Timing Verification


I/O pads can be specified for your design in a number of places. Some of the common ways of adding I/O along with pro's and con's are discussed: They can be instantiated in the RTL code. This provides the advantage of being able to add all I/O pads (including for the scan circuitry which does not yet exist) up front. It also allows the instance names to be specified by the user so that top-level nets, including the clock and reset nets, can be easily identified later on. Also, adding the I/O up front allows Synopsys to synthesize the design knowing what drive/load is being applied to all the I/O nets. Finally, it allows the designer to specify which I/O is intended for use with this design, since this is a decision which should have been made up-front at the same time as the top-level pin-out. One disadvantage is that I/O pads are technology-specific, so including these in your RTL code makes it less generic. Adding I/O within Synopsys: The I/O pads can be added within Synopsys, but pads can only be added for existing nets, so scan chain-related pads need to be added after the scan chain has been inserted. Adding I/O after synthesis: I/O can be added to the gate-level Verilog netlist after Synthesis, either by a script or by manual editing. Or the I/O pads can be added in Design Planner or in Silicon Ensemble as an Engineering ChangeTutorial on CMCs Digital IC Design Flow V1.3 Page 26 Canadian Microelectronics Corporation/Socit canadienne de micro-lectronique


Order (ECO), the same time power pads or corner cells are added. One main disadvantage to this method is that the design has not been synthesized with those pads in place, so pad constraints may not be taken into account. In this flow, I/O pads have been added to the RTL code. Since the desired pads were added, a dont_touch flag should now be set on all I/O pads to prevent Synopsys from modifying those pads. One way to set dont_touch on the I/O cells is to select each I/O pad in the Design Analyzer window, and set the attribute. Since this design has been created with all I/O pads, and NO OTHER modules starting with the letter "p", the attribute can also easily be set from the design_analyzer command line. 3.1.4 In the Command Window: design_analyzer> set_dont_touch find(cell "p*") Check the log and ensure all (and only) I/O pads have dont_touch set. If this is your own design you may need to use. remove_attribute find (cell "name") dont_touch and set_dont_touch find (cell "name") to ensure the desired effect is achieved.

3.2

Define the scan style

NOTE: Since the top-level module of this design (mult16chip) is only an I/O wrapper module, and it contains no other logic, the DFT methodology and synthesis of this design is focused on the mult16bist module. One reason for this is to overcome an observed problem with Synopsys that adding a scan chain from the top-level of the design modifies the wrapper, and adds un-needed logic and pins to the mult16bist module. 3.2.1 3.2.2 3.2.3 Select the module (mult16bist) Select: Attributes -> Optimization Directives -> Design... In the Design Attributes form, change Test Scan Style to Multiplexed Flip Flop Click Apply then Cancel In the main window: Click the down arrow to descend into mult16bist Select the Symbol View if not already displayed.

3.2.4



3.2.5

The bist_out pin will also function as the scan chain output pin. Select the bist_out port and then: Attributes -> Optimization Directives -> Output Port... In the Output Port Attributes form change Signal Type to Scan Out Click Apply and Cancel

3.2.6

In the main window, if you double-click on the test_se port the Input Port Attributes form should come up. Select: Signal Type: Test -> Scan Enable Click Apply

3.2.7

Repeat for the test_si pin, changing its Signal Type to Test -> Scan In Always click Apply after changing a form. Design Compiler now knows which pins to use for scan-based test.

3.2.8

You can Cancel the open forms.

3.33.3.1

Define the output loadReturn to the top-level module of this design for the remainder of the constraints. To do this, click the Up-Arrow, and then double click on mult16chip. Click on the Symbol view button (from the left-side of the Synopsys Design Analyzer window) if you are not already viewing the symbol view of mult16chip.

3.3.2

To set the expected output load, select the bist_out and prod_out output ports (draw a box around them, or click on one, then hold shift while you click on the other) and select: Attributes -> Operating Environment -> Load... Enter a Capacitive load: of 20 The units for capacitance in this library are picofarads.

3.3.3

Click Apply then Cancel



3.4

Set maximum net transition (net slew)

CMOSP18 3.4 In the CMOSP18 design kit, maximum net transition is defined in the library, so it does not need to be defined here. Omit all of step 3.4. Synopsys calls net slew "transition time". The TLF file for the CMOSP35 black-box libraries have a maximum slew rate of 2.0 ns, although the cells have been characterized with slew rates up to 3.0 ns. In order to try and meet the TLF file's limit of 2.0, a maximum transition time is set within Synopsys. 3.4.1 To set this design constraint select: Attributes -> Optimization Constraints -> Design Constraints In the Design Constraints form select: Design Rules: Max Transition: 2.0 Test Constraints: Min Fault Coverage: 98% Click Apply

3.4.2

3.53.5.1 3.5.2 3.5.3

Define the clockIn the main window, click on the clk pin. Select: Attributes -> Clocks -> Specify... In the Specify Clock form change Period to 20 in nanoseconds Select Dont Touch Network Click Apply Click on Skew ...

3.5.4 3.5.5

In the Skew form, select Propagated Enter under Uncertainty: Min: 0.5 (note Max: is set the same) Click Apply Cancel any open forms. Note that the clk pin now has a red square wave shown on the symbol. This indicates it is a defined clock. Weve told Synopsys that there is an uncertainty of 0.5 ns on the clock signals, and not to touch the clock tree. The clock tree will be created later using CT-Gen.



3.63.6.1 3.6.2

Set general compile directivesClick on mult16chip Enter the following in the Command Window: design_analyzer> set_fix_multiple_port_nets -all This will prevent a number of port/net related problems during synthesis. All of the other default constraints should be adequate, and this design should be ready for synthesis.

3.7

Propagate top-level constraints down to mult16bist module for synthesis

Since the mult16bist module will synthesized later when the scan chain is added to the design, constraints and the clock definition which were added to the top-level of this design should now be propagated to the mult16bist level as well. 3.7.1 3.7.2 Select the mult16chip symbol In the Command Window enter: design_analyzer> characterize mult16bist If you view the symbol view of mult16bist you should now see that its clk pin also has the red square wave displayed, indicating that this pin has been defined as the clock pin for the module.

3.83.8.1 3.8.2 3.8.3

Save the constrained designEnsure the top-level mult16chip module is selected, then: Select: File -> Save As... In the Save File form, change File Name to mult16chip_constrained.db Click OK You may now exit Synopsys Design Analyzer by selecting: File -> Quit

3.8.4

You have now completed Module 3. Module 4 includes compute-intensive steps which take your constrained design to a compiled design which meets all of the applied design constraints.





MODULE 4: COMPILING THE DESIGN

MODULE 4: COMPILING THE DESIGNRTL Simulation


Objective 4: To synthesize the design into gates, meeting all pre-set constraints If you are not still in Design Analyzer, or have modified your design since Module 3, re-start Design Analyzer and Read mult16bist_constrained.db. Start up the Design Analyzer tool by entering at the Unix prompt:

Synthesis

Scan Insertion


Floorplanning

design_analyzer Open the Command Window: Setup -> Command Window... Read in mult16bist_constrained.db: File -> Read...Placement


4.1

Perform the initial compile


CMOSP18 4.1 In this and subsequent compiles, you may get a message of the form: Error: Could not find user specified selection group:WireAreaCon. (WL-40) This is not a critical problem and these messages can be ignored. Since the top-level wrapper (mult16chip) already only contains I/O cells and the sub-module mult16bist, it does not need to be synthesized. As a way of maintaining two levels of hierarchy (one containing the I/O cells, and the other containing only standard cells), the design will be synthesized with the ungroup_all flag from the mult16bist level. 4.1.1 4.1.2 In the Synopsys Design Analyzer window select mult16bist To compile your design enter the following in the Command Window: design_analyzer> compile -scan -ungroup_all




This first compile takes approximately 10 minutes on an UltraSparc 10.

The command needs to be entered in the Command Window, instead of using the steps Tools -> Design Optimization... so that the -scan option can be specified which tells Design Compiler to use timing values from the scan-equivalent cells. This should eliminate problems being caused by the insertion of the scan chain after the design has been optimized. It is normal for the compile to generate a number of warnings, but no errors should exist. During code development stages the design was not ungrouped during compile, i.e. some hierarchy was maintained. For the place and route steps, hierarchy within the design core is not desired. Save the results of the first compile from the main window: Select the top-level box (mult16chip): File -> Save As... 4.1.3 In the Save File form, change File Name to mult16chip_compile1.db Click OK Generate a report using the following from the main window: Analysis -> Report... In the Report form select: Area, Constraints and Timing Click Apply Check the design: Analysis -> Check design Click OK the Check design form. No new warnings/errors should be present. You can ignore warning messages related to "Connection class violations".

4.1.4

4.1.5

You can experiment by generating different reports. You will notice that some reports (such as power) take much longer to generate than others. Your design may or may not have violations (such as a minor timing problem) resulting from the first compile step.



4.2

Perform an incremental compile

CMOSP18 4.2 Since the constraints used for CMOSP18 are the same as were used for CMOSP35, it is very easy for Synopsys to meet the constraints on the first compile, and this second compile is not necessary. Even though it is not needed, users are encouraged to complete the incremental compile so design names will be consistent with the remainder of the tutorial. Since the design has no violations at this point the second compile is very quick. The mult16bist module now has been synthesized into CMOSP35-specific gates. Although the mult16, glue and bist modules still show up in the Designs View window, they are no longer bound to this design as they have been flattened into the mult16bist module. The mult16chip module should not have been changed by the compile. Figure 4.1 shows the schematic view of mult16chip. None of the synthesis steps in the design flow should modify this mult16chip module. As a designer you should have a much better idea now about your final design size, and if you will be able to meet your timing goal or not. Keep in mind that the timing values used are based on wireload files and may still be quite different from post-layout values. An incremental compile will be performed on this design. Now that the mult16bist module is flat, the incremental compile can be done from the top level.



Figure 4.1: Schematic view of mult16chip



4.2.1 4.2.2

Remove all designs: Setup -> Scripts -> Remove All Designs Re-load mult16chip_compile1.db Note that only two blocks (mult16bist and mult16chip) should be present, but both of the blocks contain logic. Click on the mult16chip Module Attempt an incremental compile with high effort as follows:design_analyzer> compile -scan -map_effort high -incremental_map

4.2.3

4.2.4 4.2.5

Save the design as: mult16chip_compile2.db. Repeat the Check Design and Report steps.

For the purpose of this tutorial, you can continue if you have no violations, or if your timing violation is less than 2 ns. For your own designs, experience will tell you how much of a violation can be overcome by the placement and routing tools. If timing is not close, the design structure or performance goals may need to be rethought. It is good practice to visually inspect the mult16 chip I/O wrapper module to ensure it still contains all the I/O pads and no other logic cells.



MODULE 5: INSERTING SCAN

MODULE 5: INSERTING SCANRTL Simulation


Objective 5: To make the design testable via standard scan-based Design For Testability (DFT) techniques

Synthesis

Scan Insertion

The Synopsys tool Test Compiler is part of the Design Analyzer tool. Test Compiler will substitute all sequential devices (FFs) with scan equivalents, and then connect them together to form a scan chain. Test Compiler will then be used to create a set of test vectors which can detect stuck at 1 and stuck at 0 faults in the chip. Other features such as vector compaction, and fault coverage estimation will also be performed. 1. If you previou

asic design flow

Documents

channel offset

clock tree

cmcs drc service

natural break

pulse width

performing

pearl console

congestion