Contents Foreword Preface Acknowledgements About The Author CHAPTER 1: ASIC DESIGN METHODOLOGY. ‘Typical Design Flow 1 Specification and RTL Coding 2 Dynamic Simulation 3 Constraints, Synthesis and Scan Insertion 4 Formal Verification Ss Static Timing Analysis using PrimeTime 6 Placement, Routing and Verification 7 Engineering Change Order Chapter Summary avi oxxiif oy2.1 Example Design 2.2 Initial Setup 2.3 Pre-Layout Steps 23.1 Synthesis 23.2 Static Timing Analysis using PrimeTime 23.3. SDF Generation 234 Verification 2.4 — Floorplanning and Routing 2.5 Post-Layout Steps 25.1 Static Timing Analysis using PrimeTime 25.2 Post-Layout Optimization 2.6 Chapter Summary CHAPTER 3: BASIC CONCEPTS 3.1 Synopsys Products 3.2 Synthesis Environment 3.21 Startup Files 3.2.2 System Library Variables 3.3, Objects, Variables and Attributes 33.1 Design Objects 3.32 Variables 33.3 Attributes 34 Finding Design Objects 3.5. Synopsys Formats 3.6 Data Organization 3.7 Design Entry 3.8 Compiler Directives 3.8.1 HDL Compiler Directives 3.8.2 VEDL Compiler Directives 3.9 Chapter Summary CHAPTER 4; SYNOPSYS TECHNOLOGY LIBRARY 4.1 Library Basies 4.1.1 Library Group 4.1.2 Library Level Attributes 16 7 18 18 26 28 35 39 2 43 45. 45 47 48 48 49 31 52 33 34 35 56 37 60 2 63 64 64 64 Contents 4.13 Environment Description 63 4.14 Cell Description 0 42 Delay Calculation B 42.1 Delay Model B 422 Delay Calculation Problems 8 4.3. Whatis a Good Library? 16 44° Chapter Summary B CHAPTER 5; PARTITIONING AND CODING STYLES _78 5.1 Partitioning for Synthesis 30 3.2 Whatis RTL? 82 32.1 Software versus Hardware 82 33 General Guidelines 83 33.1 Technology Independence 83 53.2 Clock Logie 83 53.3 NoGlue Logie at the Top 84 5.34 Module Name Same as Fite Name 85 5.3.5 Pads Separate from Core Logic 85 53.6 Minimize Unnecessary Hierarchy 85 53.7 Register All Outputs 85 5.3.8 Guidelines for FSM Synthesis 36 S4 Logic Inference 86 54.1 Incomplete Sensitivity Lists 86 54.2 Memory Element Inference 87 34.3 Multiplexer Inference 2 S44 Three-State Inference 95 55 Order Dependency 96 5.5.1 Blocking versus Non-Blocking Assignments in Verilog 96 3.5.2. Signals versus Variables in VDL ” 5.6 Chapter Summary 8 CHAPTER 6: CONSTRAINING DESIGNS. 99 CHAPTER 6: CONSTRAINING DESIGNS ___99 6.1 Environment and Constraints 100 6.1.1 Design Environment 100 61.2 Design Constraints 105 6.2 Advanced Constraints 110 63 Clocking Issues 1363.1 PreLayout 6.3.2 Post-Layout 63.3 Generated Clocks 64 Putting it Together 65 Chapter Summary CHAPTER 7: OPTIMIZING DESIGNS. 7.1 Design Space Exploration 72 Total Negative Slack 7.3 Compilation Strategies 73.1 Top-Down Hierarchical Compile 732 Time-Budgeting Compile 7.3.3 Compile-Characterize-Write-Script-Recompile 74 — Resolving Multiple Instances 7.5 Optimization Techniques 75.1 Compiling the Design 75.2 Flattening and Structuring 753 Removing Hierarchy 75.4 Optimizing Clock Networks 753 Optimizing for Area 7.6 Chapter Summary CHAPTER 8: DESIGN FOR TEST. 8.1 Types of DFT 8.1.1” Memory BIST 8.1.2 Boundary Scan DFT 8.2 Scan Insertion 82.1 Making Design Scannable 8.2.2 Test Pattern Generation 83 DFT Guidelines 83.1 ‘Tri-State Bus Contention 832 Latches 83.3 Gated Reset or Preset 83.4 Gated or Generated Clocks 8.3.5 Use Single Edge of the Clock 83.6 Multiple Clock Domains 83.7 Order Scan-Chains to Minimize Clock Skew 14 us 116 uy 119 121 121 125, 126 Ra 128 130 134 BS 136 137 141 142 145 145 147 147 148 148 149 149 152 152 152 153 153 153 134 155 155 OS 83.8 Logic Un-Scannable due to Memory Element 3.4 Chapter Summary CHAPTER 9: LINKS TO LAYOUT & POST-LAYOUT OPT. 9.1 Generating Netlist for Layout 9.1.1 Uniquify 9.12 Tailoring the Netlist for Layout 9.13 Remove Uncomnected Ports 9.14 Visible Port Names 9.18 Verilog Specific Statements 9.16 Unintentional Clock or Reset Gating 9.7 Unresolved References 92 Layout 92.1 Floorplanning 9.22 Clock Tree Insertion 92.3 Transfer of Clock Tree to Design Compiler 92.4 — Routing 92.5 Extraction 9.3 Post-Layout Optimization 93.1 Back Annotation and Custorn Wire Loads 93.2 In-Place Optimization 93.3 Location Based Optimization 93.4 Fixing Hold-Time Violations 9.4 Future Directions 9.5 Chapter Summary CHAPTER 10: SDF GENERATIC 10.1 SDF File 10.2 SDF File Generation 10.2.1 Generating Pre-Layout SDF File 10.2.2 Generating Post-Layout SDF File 10.2.3 Issues Related to Timing Checks 10.24 False Delay Calculation Problem. 10.25 Putting it Together 10.3 Chapter Summary 156 158 159 160 161 163 164 164 165 166 167 167 167 172 176 178 178 183, 184 186 187 189 193, 194 195 196 198, 198, 201 202 203 205 207CHAPTER 11; PRIMETIME BASICS ILL Introduction ILLI Invoking PT 11.2 PrimeTime Environment 11.1.3. Automatic Command Conversion 112 Tel Basies 11.2.1 Command Substitution 312.2 Lists 11.2.3 Flow Control and Loops 113 PrimeTime Commands 113.1 Design Entry 113.2 Clock Specification 113.3 Timing Analysis Commands 113.4 Other Miscellaneous Commands 114 — Chapter Summary CHAPTER 12: STATIC TIMING ANALYSIS 12.1 Why Static Timing Analysis? 12.1.1 What to Analyze? 12.2. Timing Exceptions 12.2.1 Multicycle Paths 122.2 False Paths 12.3. Disabling Timing Ares 123.1 Disabling Timing Ares Individually 123.2 Case Analysis 12.4 Environment and Constraints 12.4.1 Operating Conditions ~ A Dilemma 125 Pre-Layout 12.5.1 Pre-Layout Clock Specification 1252 Timing Analysis 12.6 Post-Layout 12.6.1 What to Back Annotate? 12.6.2 Post-Layout Clock Specification 1263 Timing Analysis, 12.7 Analyzing Reports 12.7.1 Pre-Layout Setup-Time Analysis Report 12.7.2 Pre-Layout Hold-Time Analysis Report 209 210 210 210 2 212 213 213 215 215 215 216 221 227 230 231 231 232, 233 233 237 239 240 241 242 242 243 244 245 247 248 249 249 254 254 256 12.7.3 1274 128 12.8.1 12.8.2 1283 12.84 12.9 Post-Layout Setup-Time Analysis Report Post-Layout Hold-Time Analysis Report ‘Advanced Analysis Detailed Timing Report Cell Swapping Bottleneck Analysis. Clock Gating Checks ‘Chapter Summary 258 260) 262 262 265 266 269 mm 275 APPENDIX, 277 INDEXForeword ur semiconductor industry is increasingly characterized by accelerated product obsolescence. As a result, business success is increasingly dependent ‘upon the ability of development teams to deliver a shortest “time-to-market” product that meets customer requirements. Early product introduction means higher profit margins, lasting only until slower-to-market competitors enter and erode prives. This intense cycle of market price erosion has been particularly evident in the personal computer industry over the last few years. Consumers are continually demanding quality products at lower cost but with increasing features, Semiconductor suppliers are, in tum, driven to develop system-on- achip (SoC) products utilizing VDSM (Very-Deep-Sub-Micron) technologies, just to remain competitive. Several high performance tools and techniques have been developed over the past few years to mitigate somewhat this “time-to-market” pressure and to ‘enable rapid design updates to meet evolving customer specifications. These changes have resulted in a redefinition of standard ASIC design flow methodologies. High level design languages, like VHDL and Verilog, have displaced schematic capture, thus promoting design reuse. Dynamic simulation has given way to formal verification and static timing analysis. Inaddition, synthesis engines have become more sophisticated, targeting complex designs containing millions of gates and large IP cores. It is now estimated that the mumber of gates in a complex ASIC will approach 10 million early in the next decade. Successfully achieving these levels of integration in a time-to-market focused development environment will require an intimate knowledge of ASIC design tlow in the VDSM realm and a complex integration of products offered by multiple BDA tool vendors. This book, written by Himanshu. Bhatnagar, provides a comprehensive overview of the ASIC design flow targeted for VDSM technologies using the Synopsys suite of tools. It emphasizes the practical issues faced by the semiconductor design engineer in terms of synthesis and the integration of frontend and back-end tools. Traditional design methodologies are challenged and unique solutions are offered to help define the next- generation of ASIC design flows. The author provides numerous practical examples derived from real-world situations that will prove valuable to practicing ASIC design engineers as well as to students of advanced VLSI courses in ASIC design. Dr. Dwight W. Decker Chairman and CEO, Conexant Systems, Inc. (Formerly, Rackwell Semiconductor Systems) Newport Beach, California, USA Preface ‘This book describes the advanced concepts and techniques used toward ASIC chip synthesis, formal verification and static timing analysis, using the Synopsys suite of tools. In addition, the entire ASIC design flow methodology targeted for VDSM (Very-Deep-Sub-Micron) technologies is covered in detail. hasis of this book is on real-time application of Synopsys tools, used to cat ‘aous problems seen at VDSM geometries. Readers will be exposed to an effective design methodology for handling complex, sub- rnicion ASIC designs. Significance is placed on HDL coding, syle, synthesis and optimization, dynamic simulation, formal verification, sean insertion, links to Teyout, and state timing analysis. At each step problems related to each phase of the design flow are idea _ wi solutions and workarounds deseribed ia detail. In addition, enc istes related to layout, which inchides clock tee synthesis and back-end imegration (links fo layout are also discussed at length, Furthermore, book contains in-depth discussions on the basics of Synopsys technology libraties and HDL coding styles, targeted towards optimal synthesis solutien. i ers and Target audiences for this book are practicing ASIC design engineers an sradiate level students vaderaking advanced VLSI courses on ASIC chip design and DFT techniques.This book is not intended as a substitute or a replacement for the Synopsys reference manual, but is meant for anyone who is involved in the ASIC design flow. Also, it is useful for those designers (and companies) who do not have layout capability, or their own technology libraries, but rely on outside vendors for back-end integration and final fabrication of the device. ‘The book provides altcmatives to traditional method of netlist hand-off to outside vendors because of various issues related to VDSM technologies. It also addresses solutions to common problems faced by designers when interfacing various tools from different EDA tool vendors. Overview of the Chapters Chapter 1 presents an overview to various stages involved in the ASIC design flow using Synopsys tools. The entire design flow is briefly described, staring from concept to chip tape-out. This chapter is useful for designers ‘who have not delved in the full process of chip design and integration, but ‘would like to learn the full process of ASIC design flow. Chapter 2, outlines the practical aspects of the ASIC design flow as described in Chapter I. Beginners may use this chapter as a tutorial. Advanced users of Synopsys tools may benefit by using this chapter as a ceference. Users with no prior experience in synthesis using Synopsys tools should skip this chapter and return to it later after reading the remaining book. The basic concepts related to synthesis are described in detail in Chapter 3. These concepts introduce the reader (o synthesis terminology used throughout the later chapters. Readers will find the information provided here useful by gaining a basic understanding of these tools and their environment. In addition to describing the purpose of each tool and their setup, this chapter also focuses on defining objects, variables, attributes and compiler directives used by the Design Compiler. Chapter 4 describes the basics of the Synopsys technology library. Designers usually do not concem themselves with the full details of the technology library, as long as the library contains a variety of cells with different drive strengths. However, a sich library usually determines the quality of synthesis. Therefore, the intent of this chapter is to describe the Synopsys technology library from the designer's perspective. Focus is provided on delay calculation method and other techniques that designers may use in order 10 alter the behavior of the technology library, hence the quality of the synthesized design. Proper partitioning and good coding style is essential in obtaining quality results. Chapter § provides guidelines to various techniques that may be used 0 correctly partition the design in order to achieve the optimal solution. In addition, the HDL coding styles is covered in this chapter that illustrates numerous examples and provides recommendations to designers on how to code the design in order to produce faster logic and minimum area. ‘The Design Compiler commands used for synthesis and optimization are described in Chapter 6. This chapter contains information that is useful for the novice and the advanced users of Synopsys tools, The chapter focuses on real-world applications by taking into account deviations from the ideal simation ie, “Not all designs or designers, follow Synopsys recommendations”. The chapter illustrates numerous examples that help guide the user in real-time application of the commands. Chapter 7 discusses optimization techniques in order to meet timing and area requirements. Comparison between older version of Design Compiler and the new version is highlighted. Emphasis is provided on the new optimization technique employed by Design Compiler called “TNS”. Also, detailed analysis on various methods used for optimizing logic is presented. In addition, different compilation strategies, each with advantages and disadvantages are discussed in detail. DET techniques are increasingly gaining momentum among ASIC design ‘engineers. Chapter 8 provides a brief overview of the different types of DFT techniques that are in use today, followed by detailed description on how devices can be made scannable using Synopsys’s Test Compiler. It describes ‘commands used for inserting scan through Design Compiler. A multitude of guidelines is presented in order to alleviate the problems related to DFT scan insertion on a design. Chapter 9 discusses the Tinks to layout feature of Design Compiler. It describes the interface between the front-end and back-end tools. Also, this chapter provides different strategies used for post-layout optimization ofdesigns. This includes in-place and location based optimization techniques. Furthermore, a section is devoted to clock tree insertion and issues related to clock tree transfer to Design Compiler. Various solutions to this common problem are described. This chapter is extremely valuable for designers (and companies) who do not posses their own layout tool, but would like to learn the place and route process along with full chip integration techniques. Chapter 10, titled “SDF Generation: for Dynamic Timing Simulation” describes the process of generating the SDF file from Design Compiler or PrimeTime. A section is devoted to the syntax of SDF format, followed by detailed discussion on the process of SDF generation, both for pre and post layout phases of the design. In addition, few innovative ideas and suggestions are provided to facilitate designers in performing successful simulation. This, chapter is useful for those designers who prefer dynamic simulation method to formal verification techniques, in order to verify the functionality of the design Chapter 11 introduces to the reader, the basics of static timing analysis, using PrimeTime. This includes a brief section devoted to Tel language that is utilized by PrimeTime. Also described in this chapter are selected PrimeTime commands that are used to perform static timing analysis, and also facilitate the designer in debugging the design for possible timing violations. The key to working silicon usually lies in successful completion of static timing analysis performed on a particular design. This capability makes static timing analysis one of the most important steps in the entice design flow and is used by many designers as a sign-off eriterion to the ASIC vendor. Chapter 12 is devoted to several basic and advanced topics on static timing analysis, using PrimeTime. It effectively illustrates the usage of PrimeTime, botls for ‘the pre and the post-layout phases of the ASIC design flow process. In addition, numerous examples on analyzing reports and suggestions on various scenarios are provided. This chapter is useful to those who would like to migrate from traditional methods of dynamic simulation to the method of analyzing designs statically. It is also helpful for those readers who would like to perform in-depth analysis of the design through PrimeTime. Conventions Used in the Book All Synopsys commands are typed in “Ariel” font. This includes all examples that contain synthesis and timing analysis seripts. The command line prompt is typed in “Courier New" font, For exampie: dc_she11> and, pt_shell> Option values for some of the commands are enclosed in < and >. In general, these values need to be replaced before the command can be used. For example: > to set_false_path -from create_clock period 33 —waveform {0 16.5} tok dc_she11> set_clock_skew —delay 2.0 tck dc_shel1> set_clock_transition 0.2 tok ‘The following script uses the above commands and may be used to generate the pre-layout SDF for the fap_controller design. This SDF file is targeted for simulating the design dynamically with timing. In addition, the script also ‘generates the timing constraints file. Though this file is also in SDF format, it is solely used for forward annotating the timing information to the layout tool in order to perform timing driven layout. DC script for pre-layout SDF generation active_design = tap_controller read active_design + ".db" current_design active_design link. set_wire_load LARGE -mode top set_operating_conditions WORST create_clock ~period 33 waveform {0 16.5} tck set_clock_skew —delay 2.0 —minus_uncertainty 3.0 tck set_clock_transition 0.2 tckset_driving_cell cell BUFF 1X —pin Z all_inputs() set_drive 0 {tck trst} set_load 50 all_outputs() set_input_delay 20.0 -clock tck—max all_inputs() set_output_delay 10.0 -clock tck -max all_outputs() write_timing format sdf-v2.1\ output active_design + *.sdf" write_constraints ~format sdf -cover_design \ output constraints. sdf 23.4 Verification The final step before layout is to verify the structural netlist for functionality. ‘There are two methods that perform this step: a) Dynamic timing simul: b) Formal verification, using the SDF file. 2.3.4.1 Gate-Level Simulation with Pre-Layout SDF This topic needs no clarification, as everyone in the ASIC world is well versed to the process of dynamic simulation, Simulating the structural netlist involves exercising combinations of input signals, while observing the outputs. This is generally performed by means of a test-bench coded in Verilog or VHDL, which emulates the whole system. In other words, it incorporates/envelops the tap_controller design. Dynamic simulation of the gate-level is the traditional approach and is still regarded by many as the best way to debug the design, and to check for functionality at the same time. However, this approach has some shortfalls. Primarily that certain paths of the logic in the design may never be active EEO a (get sensitized), for the specified combination of input signals. This means that these paths will not be checked for correct functionality and timing. ‘Another problem with the dynamic simulation method is the run-time for large designs containing millions of gates. The run-time for these designs can be enormous. It may even become impractical to run gate-level simulatiens con such designs. The concept of formal verification was introduced to overcome these issues, which are discussed in the next section, Let us assume that the tap_controller design is passing all the functional vectors with no setup or hold-time violations, using the pre-layout SDF generated previously. 2.3.4.2 Formal Verification Synopsys recently introduced a tool that is capable of performing formal verification, called Formality. Formality uses mathematical algorithms in order to check the logic equivalency of a design. Since this technique is static Gc. it does not use input test vectors), the verification run-times are reduced dramatically as compared to the dynamic simulation method. Furthermore, it also provides a powerful means to verify large designs in a comparatively short duration. However, the most significant advantage of using Formality is that complete verification of the design is achieved without omitting any logic paths (as is possible by dynamic simulation techniques). ‘This section (and the book) briefly outlines the purpose and importance of using formal verification techniques and where they can be applied. However, the syntax and usage of the commands used by Formality will not be described. Formality may be used to verify RTL against RTL, RTL against synthesized gate-level netlist, or gate-level against gate-level netlist. At this point, Formality should be used to verify the RTL against synthesized netlist to check for the functional validity of the gate-level netlist. Compared to gate~ level simulation using the pre-layout SDF, Formality takes a fraction of time to completely verify the design.eetlee teen 2.4 Floorplanning and Routing The floorplanning step involves physical placement of cells and clock tree synthesis. Both these steps are performed within the layout tool. The placement step may include timing driven placement of the cells, which is performed by annotating the constraints.sdf file (generated by DC) to the layout tool. This file consists of path delays that include the cell-to-cell timing information. This information is used by the layout tool to place cells with timing as the main criterion ie., the layout tool will place timing critical cells closer to each other in order to minimize the path delay. Let’s assume that the design has been floorplanned. Also, the clock tree has been inserted in the design by the layout tool. The clock tree insertion modifies the existing structure of the design. In other words, the netlist in the layout tool is different from the original netlist present in DC. This is because of the fact that the design present in the layout tool contains the clock tree, whereas the original design in DC does not contain this information, Therefore, the clock tree information should somehow be transferred to the design residing in DC or PT. The new netlist (containing the clock tree information) should be formally verified against the original netlist to ensure that the transfer of clock tree did not break the functionality of the original logic. Various methods of transferring the clock tree information to the design are explored in detail in Chapter 9. For the sake of simplicity, let us assume that the clock tree information is present in the tap_controller design. ‘The design is now ready for routing, In a broad sense, routing is performed in ‘two phases ~ global route and detailed route. During global route, the router divides the layout surface into separate regions and performs a point-to-point “Joose” routing without actually placing the geometric wires. The final routing is performed by the detailed router, which physically places the ‘geometric wires and routes within the regions. Full explanations of these types of routing are explained in Chapter 9. Lets assume that the design has been global routed. ‘The next step involves extracting the estimated parasitic capacitances, and RC delays from the global routed design. This step reduces the synthesis- layout iteration time, especially since cell placement and global routing may take much less time than detailed routing the entire chip. However, if the cells are placed optimally with minimal congestion, detailed routing is also very fast. In any case, extraction of delays after the global route phase (albeit estimates) provides a faster method of getting closer to the real delay values that are extracted from the layout database after the detailed routing phase. Back annotate the estimates to the design in PT for setup and hold-time static, timing analysis, using the following scripts. PT script for setup-time analysis, using estimated delays feeennecssennnasssseeeeesonenneesannoonenaeetees # Define top-level design name set active_design tap_controller pe neeaaeeneneananenaaaaaeaaaaan # Design entry in db format, netlist only — no constraints read_db -netlist_only Sactive_design.db current_design Sactive_design BAA AAMnan en eennnnnnnnatssssseees: # Design environment ‘set_operating_conditions WORST set_load 50.0 [all_outputs] set_driving_cell cell BUFF1X -pin Z [all_inputs] perneeeneasnnatennntennnneneeseessenencenensenses +# Back annotation of estimated data from floorplan source capacitance.pt_# estimated parasitic capacitances read_sdf rc_delays.sdf # estimated RC delays poteenenneseeenes # Clock specification and design constraints create_clock -period 33 -waveform [0 16.5] tck ‘set_propagated_clock [get_clocks tck] set_clock_uncertainty 0.5 -setup [get_clocks tck]Oe set_input_delay 20.0 ~clock tck fall_inputs} set_output_delay 10.0—clock tck [all_outputs] YANN enesenenannnnnneneateeseeeeeseseeeee® # Timing analysis commands report_constraint —all_violators report_timing —to {all_registers —data_pins] report_timing —to [all_outputs] foteeseseeeeesersssesscesneneeeeeeenneneneennenee # Define design name set active_design tap_controller feteeeeeeneneneeeeeeeneenneneeseseseeseseseeeeres # Design entry in db format, netlist only — no constraints, read_db -netlist_only $active_design.db current_design Sactive_design _feneneeneneenneennnaennenneneenneesesasnonannens # Design environment set_operating_conditions BEST set_load 20.0 fall_outputs} ‘set_driving_cell —cell BUFF1X —pin Z [all_inputs] petteeciteseeenassssseeeaseseennaassonnnnasenten # Back annotation of estimated data from floorplan source capacitance.pt_# estimated parasitic capacitances read_sdf ro_delays.sdf # estimated RC delays BNI ODES eens Jeeeeneeceeeeeeennnnnneasasennnnnngeeneesseeontes # Clock specification and design constraints create_clock —period 33 —waveform [0 16.5] tck set_propagated_clock [get_clocks tck] set_clock_uncertainty 0.05 —hold (get_clocks tck] set_input_delay 0.0 -clock tek [all_inputs] set_output_delay 0.0 —clock tok fall_outputs} {PH ERE U MAHA HEHE +# Timing analysis commands report_constraint -all_violators report_timing -to [all_registers -data_pins]_\ —delay_type min report_timing -to [all_outputs] —delay_type min ‘The above script back annotates capacitance pt and re_delays.sdf file. The capacitance.pt file contains the capacitive loading per net of the design in setload format, while the rc_delays.sdf file contains point-to-point interconnect RC delays of individual nets. DC (and PT) performs the calculation of cell delay, based upon the output net loading and input slope of each cell in the design. The reason for using this approach is explained in detail in Chapter 9. If the design fails setup-time requirements, you may re-synthesize the design with adjusted constraints or re-floorplan the design. If the design is failing hold-time requirements, then depending on the degree of violation you may decide to proceed to the final step of detailed routing the design, or re- optimize the design with adjusted constraints. If re-synthesis is desired then the floorplan (placement) information consisting of the physical clusters and cell locations, should be back annotated to DC. This step is desired because up till now, DC did not know the physical placement information of cells. By annotating the placement information to DC, the post-layout optimization of the design within DC isNO vastly improved. The layout tool generates the physical information in PDEF format that can be read by DC, using the following command: read_clusters ‘The script to perform this is similar to the initial synthesis script, with the exception of the annotated data and incremental optimization of the design, as illustrated below: Script for incremental synthesis of the design active_design = tap_controller read active_design + “.db" current_design active_design link include capacitance.dc_/* estimated parasitic capacitances */ read_timing -f sdf rc_delays.sdf_ /* estimated RC delays */ read_clusters clusters.pdef /* physical information */ r /* create custom wire-load models for next i create_wire_load -hierarchy =percentile 80 output cwim.txt veneweewenunannennsannessesstene] tion of synthesis */ create_clock -period 33 -waveform {0 16.5} tck set_clock_skew -propagated ~minus_uncertainty 3.0 tek set_dont_fouch_network {tck trst} set_driving_cell ~cell BUFF 1X -pin Z all_inputs() set_drive 0 {Ick trst} set_input_delay 20.0 -clock tck-max all_inputs() set_output_delay 10.0 -clock tck-max all_outputs() set_max_area 0 set_fix_multiple_port_nets —all -buffer_constants revenwasanannsunscennnnnnsssenecannnnsantnt /* Re-optimize the design to control the amount of modifications */ reoptimize_design -in_place write hierarchy ~output active_design + *.db" write -format verilog -hierarchy \ output active_design + "sv" ‘The create_wire_load command used in the above script creates a custom wire-load model for the fap_controiler design. The initial synthesis run used the wire-load models present the in the technology library that are not design specific. Therefore, in order to achieve better accuracy for the next synthesis iteration, the custom wire-load models specific to the design should be used. ‘The following command may be used to update the technology library present in DC’s memory to reflect the new custom wire-load models. For example: dc_shel1> update_lib ex25_worst.db cwlm.txt Let's assume that the design has been re-analyzed and is now passing both setup and hold-time requirements. The next step is to detail route the design. This is a layout dependent feature, therefore will not be discussed here. 25 Post-Layout Steps The post-layout steps involve, verifying the design for timing with actual delays back annotated; functional simulation of the design; and lastly, performing LVS and DRC. Let us presume that the design has been fully routed with minimal congestion and area. The finished layout surface must then be extracted to get the actual Parasitic capacitances and interconnect RC delays. Depending upon thelayout tool and the type of extraction, the extracted values are generally written out in the SDF format for the interconnect RC delays, while the parasitic information is generated as a string of set_load commands for each net in the design. In addition, if a hierarchical place and route has been performed, the physical placement location of cells in the PDEF format should also be generated. 2.5.1 Static Timing Analysis using PrimeTime ‘The first step after layout is to perform static timing on the design, using the actual delays. Similar to post-placement, the post-route timing analysis uses ‘the same commands, except that this time the actual delays are back annotated to the design. Predominantly, the timing of the design is dependent upon clock latency and skew. It is therefore prudent to perform the clock skew analysis before attempting to analyze the whole design. A useful Tel script is provided by Synopsys through their on-line support on the web, called SolvNET. You may download this script and run the analysis before proceeding. Let us assume that the clock latency and skew is within limits. The next step is to perform the static timing analysis on the design, to check the setup and hold~ time violations (iff any) using the following scripts: PT script for setup-time analysis, using actual delays JA eS oO sene tase eRRNAEE EE # Define top-level design name set active_design tap_controller _eteeenenaaasseneaaanennneensannnnaconensenessees # Design entry in db format, netlist only — no constraints read_db~netlist_only Sactive_design.db current_design Sactive_design pesteeesenessennnaaeenssennessnnaaennnsenscennnes # Design environment sel_operating_conditions WORST set_load 50.0 [all_outputs] set_driving_cell -cell BUFF1X -pin Z [all_inputs] PeRReeeeeeeeeseeeenenateseeneneeeenaseeeetene +# Back annotation of real data from the routed design source capacitance.pt # actual parasitic capacitances read_sdf ro_delays.sdf # actual RC delays read_parasitics clock_info_wrst.spf # for clocks ete. fARenaaeennanaaaennnnnnaaennnnnnasannenaaseseneee # Clock specification and design constraints create_clock -period 33 -waveform [0 16.5] tck set_propagated_clock (get_clocks tck] set_clock_uncertainty 0.5 —setup [get_clocks tck] set_input_delay 20.0 -clock tok [all_inputs] set_output_delay 10.0-clock (ck [all_outputs] |OeeeeeeReRRRRRERRRERRREEEEE EEE E SEERA EAA AHHH AHHH # Timing analysis commands report_constraint —all_violators report_timing —to [all_registers —data_pins] report_timing —to [all_outputs] PF script for hold-time analysis, using actual delays PEE aiiieeeeeeniet # Define top-level design name set active_design tap_controllerHAAAAAAAN ANE e ee aamecccenennannseeeeeETTT He tte # Design entry in db format, netlist only — no constraints read_db -netlist_only Sactive_design.db current_design $active_design HAMMAAAAAN ESRD eee eneeeeeeeeeeeeneteeeTETEHEHHHe® # Design environment set_operating_conditions BEST AAAs eanteecesesenneneeaeeaesaaaens # Back annotation of real data from the routed design source capacitance.pt # actual parasitic capacitances read_sdfrc_delays.sdf # actual RC delays read_parasitics clock_info_best.spf # for clocks ete. set_load 50.0 [all_outputs] set_driving_cell -cell BUFF1X -pin Z [all_inputs] AeteAt eee tonReeenenemnnnennneetnneeennenenesnees # Clock specification and design constraints create_clock ~period 33 -waveform [0 16.5] tck set_propagated_clock [get_clocks tck] set_clock_uncertainty 0.05 —hold [get_clocks tck} set_input_delay 0.0 -olock tck [all_inputs) set_output_delay 0.0 -clock tek [all_outputs} Ps erreseemeseIE En nneneteseiee # Timing analysis commands report_constraint ~all_violators report_timing -to [all_registers -data_pins] \ ~delay_type min report_timing -to [all_outputs] —delay_type min 25.2 Post-Layout Optimization The post-layout optimization or PLO may be performed on the design to improve or fix the timing requirements. DC provides several methods of fixing timing violations, through the in-place optimization (or IPO) feature. As before, DC also makes use of the physical placement information to perform location based optimization (LBO). In this example, we will use the cell resizing and buffer insertion feature of the IPO to fix the hold-time violations. 2.5.2.1 Fixing Hold-Time Violations The design was synthesized for maximum setup-time requirements. Timing was verified at each step (after synthesis and then, after the global route phase), therefore in all probability the routed design will pass the setup-time requirements. However, some parts of the design may fail hold-time requirements at various endpoints. If the design fails the hold-time requirements then you should fix the violations by adding buffers to delay the arrival time of the failing signals, with respect to the clock. Let’s assume that the design is failing hold-time requirements at multiple endpoints. There are various approaches to fix the hold-time violations. Such methods are discussed in detail in Chapter 9. In this example, we will utilize the dc_shell commands to fix the hold time violations, as illustrated below: DC Seript to fix the hold-time ns active_design = tap_controller read active_design + “.db" current_design active_design linkinclude capacitance.de_/*actual parasitic capacitances */ read_timing -f sdf rc_delays.sdf — /*actual RC delays */ read_clusters clusters.pdef _/*physical hierarchy info */ create_clock —period 33 -waveform {0 16.5} tek set_clock_skew -propagated —plus_uncertainty 0.05 tck set_dont_touch_network {tck trst} set_driving_cell -cell BUFF1X -pin Z all_inputs() set_drive 0 {tck trst} set_input_delay min 0.0 -clock tok -max all_inputs() set_output_delay —min 0.0 -clock tek -max all_outputs() set_fix_hold tck /* fix hold-time violations w.r.t. tek */ reoptimize_design -in_place write ~hierarchy output active_design + "db" write format verilog -hierarchy \ ~output active_design + *.sv" In the above script, the set_fix_hold command instructs DC to fix hold-time violations with respect to the clock fok. The ~in_place argument of the reoptimize_design command is the IPO command, which is regulated by various variables that are described in Chapter 9. Making use of these variables, DC inserts or resizes the gates to fix the hold time violations. The LBO variables are helpful in inserting the buffers at the correct location, so as to minimize its impact on some other logic path, leading off from the violating path. After IPO, the design should again be analyzed through PT to ensure that the Violations have been fixed using the post-layout PT script illustrated before. SS care Once the design passes all timing requirements, the post-layout SDF may be generated (from PT or DC) for simulation purposes, if needed. We will use DC to generate the worst-case post-layout SDF using the script provided below. A similar script may be used to generate the best-case SDF. Obviously, you need to back annotate the best-case extracted numbers from the layout tool to generate the best-case SDF from DC. This solely depends on the layout tool and the methodology being used, DC script for worst-case post-layout SDF generation active_design = tap_controller read active_design + *.db" current_design active_design tink. set_operating_conditions WORST include capacitance.de /* actual parasitic capacitances */ read_timing rc_delays.sdf /* actual RC delays */ create_clock ~period 33 ~waveform {0 16.5} tck set_clock_skew ~propagated -minus_uncertainty 0.5. Ick set_driving_cell -cell BUFF1X -pin Z all_inputs() set_drive 0 {tck trst} set_load 50 all_outputs() set_input_delay 20.0 -clock tck-max all_inputs() set_output_delay 10.0-clock tck-max all_outputs() write_timing format sdf-v2.1_\ output active_design + *.sdf”SE It is recommended that formal verification be performed again between the source RTL and the final netlist, to check for any errors that may have been unintentionally introduced during the whole process. This is the final step; the design is now ready for LVS and DRC checks, before tape-out. 2.6 Chapter Summary ‘This chapter highlighted the practical side of the ASIC design methodology in the form of a tutorial. An example design was used to guide the reader from start to finish. At each stage, brief explanation and relevant scripts were provided ‘The chapter started with basics of setting up the Synopsys environment and technical specification of the example design. Further sections were divided into pre-layout, floorplanning and routing, and finally the post-layout steps. ‘The pre-layout steps included initial synthesis and scan insertion of the design, along with static timing analysis, and SDF generation for dynamic simulation, In order to. minimize the synthesis-layout iterations, the floorplanning and routing section stressed upon the placement of cells, with emphasis on back annotating to DC, the estimated delays extracted after global routing the design. The final section used post-layout optimization techniques to fix the hold-time violations, and to generate the final SDF for simulation. Finally, the application of formal verification method using Synopsys Formality was also included. This section did not contain any scripts, but the reader was made aware of the usefulness of formal techniques and where they are applied. BASIC CONCEPTS This chapter covers the basic concepts related to synthesis, using Synopsys suite of tools. These concepts introduce the reader to synthesis terminology used throughout the later chapters. These terms provide the necessary framework for Synopsys synthesis and static timing analysis. Although this chapter is a good reference, advanced users of Synopsys tools, already familiar with Synopsys terminology, may skip this chapter. 3.1 Synopsys Products This section briefly describes all relevant Synopsys products related to this book. ) Library Compiler b) Design Compiler and Design Analyzer ©) PrimeTime 4) Test Compiler ©) FormalityLibrary Compiler The core of any ASIC design is the technology library containing a set of logic cells. The library may contain functional description, timing, area and other pertinent information of each cell. Library Compiler (LC) parses this textual information for completeness and correctness, before converting it to a format, used globally by all Synopsys applications. Library Compiler is invoked by typing Ic_shell in a UNIX shell. All the capabilities of the LC can also be utilized within de_shell Design Compiler and Design Analyzer ‘The Synopsys Design Compiler (DC) and Design Analyzer (DA) comprise a powerful suite of logic synthesis products, designed to provide an optimal gate-level synthesized netlist based on the design specifications, and timing constraints. In addition to high-level synthesis capabilities, it also incorporates a static timing analysis engine, along with solutions for FPGA synthesis and links-to-layout (LTTL). Design Compiler is the command line interface of Synopsys synthesis tool and is invoked by typing de_shell in a UNIX shell. The Design Analyzer is the graphical front-end version of DC and is launched by typing design_analyzer. Design Analyzer also supports schematic generation, with critical path analysis through point-to-point highlighting, Although, beginners may initially prefer using DA, they quickly migrate to using DC, as they become more familiar with Synopsys commands. PrimeTime PrimeTime (PT) is the Synopsys sign-off quality, full chip, gate-level static timing analysis tool. In addition, it also allows for comprehensive modeling capabilities, often required by large designs. PT is faster compared to DC’s intemal static timing analysis engine. It also provides enhanced analysis capabilities, both textually and graphically. In contrast to the rest of Synopsys tools, this tool is Tel language based, therefore providing powerful features of that language to promote the analysis and debugging of the design. PT is a stand-alone tool and can be invoked as a command line interface or ‘graphically. To use the command line interface, type pt_shell in the UNIX window, or type primetime for the graphical version, Test Compiler The Test Compiler (TC) is the Synopsys test insertion tool that is incorporated within the DC suite of tools. The TC is used to inset DFT features like scan insertion and boundary scan, to the design. All TC commands are directly invoked from do_shell. Formality Formality is the Synopsys formal verification tool. This tool was introduced recently by Synopsys. It is fully compatible with all Synopsys formats. The tool features enhanced graphical debugging capabilities that include schematic representation of logic under verification, and visual suggestions annotated to the schematic as pointers of possible incorrect logic. It also provides suggestions for possible fixes to the design. 3.2. Synthesis Environment As with most EDA products, Synopsys tools require a setup file that specifies the technology library location and other parameters used for synthesis. Synopsys also defines its own format for storing and processing the information. This section highlights such details. 3.2.1 Startup Files There is a common startup file called “.synopsys_de.setup” for all tools of the DC family. A separate startup file is required for PT which is named “synopsys_pt.setup”. This file is in Tel format, and contains path information to the technology libraries and parameters required by PT. ‘The default startup files for both DC and PT reside in the Syropsys installation directory, and are automatically loaded upon invocation of these tools. These default files do not contain the design dependent data. Their function is to load the Synopsys technology independent libraries and otherparameters. The user in the startup files specifies the design dependent data, During startup, DC or PT reads these files in the following order: 1. Synopsys installation directory. 2. Users home directory. 3. Project working directory. The settings specified in the startup files, residing in the project working directory, override the ones specified in the home directory and so forth, ie. the configuration specified in the project working directory takes precedence over all other settings. It is up to the discretion of the user to keep these files wherever it is convenient. However, it is recommended that the design dependent startup files be kept in the working directory. ‘The minimum information required by Design Compiler, is the search_path, target_library, link library and the symbol _library. PT requires the Search_path and link_path information only. Typical startup files are shown in Example 3.1. Note the change in format between the DC and PT setup files. Example 3.1 Synopsys Setup Files DC .synopsys_de.setup file company = “Lucknow Technologies"; designer = “Clemson”; technology = “0.25 micron”; search_path = search_path+{ *." “/usr/goldendlibrary/std_cells" \ “Lusr/goldenslibrary/pads’} target_library {std_cells_tib.db} link_tibrary “", std_cells_lib.db, pad_lib.db} symbol_library = {std_cells_lib.sdb, pad_lib.sdb} PBR ADL S _ PT .synopsys_pt.setup file set search_path [list . /usr/goldendlibrary/std_cells\ Jusrigoldenvlibraryipads) set link path [list {"} std_cells_lib.db pad_lib.db] 3.2.2. System Library Variables [At this time, it is worth explaining the difference between the target_ibrary and the link_library system variables. The target library specifies the name of the technology library that corresponds to the library whose cells the designers want DC to infer and finally map to. The link_library defines the name of the library that refers to the library of cells used solely for reference, ice, cells in the link_library are not inferred by DC. For example, you may specify a standard cell technology library as the target_library, while specifying the pad technology library name and all other macros (RAMS, ROMS etc.) in the link_library list. This means that the user would synthesize the design that targets the cells present in the standard cell library, while linking to the pads and macros that are instantiated in the design. If the pad library is included in the target_library list, then DC may use the pads to synthesize the core logic. ‘The target library name should also be included in the link_library list, as shown in Example 3.1. This is important while reading the gate-level netlist, in DC. DC will not be able to link to the mapped cells in the netlist, if the target library name is not included in the link library list. For this case, DC generates a warning stating that it was unable to resolve reference for the cells present in the netlist. ‘The target_library and link_library system variables allow the designer to better control the mapping of cells. These variables also provide a useful ‘means to re-map a gate-level netlist from one technology to the other. In this case, the link_library may contain the old technology library name, while the target_library may contain the new technology library. Re-mapping can be performed by using the translate command in de_shell.ee The symbol_library system variable holds the name of the library, containing graphical representation of the cells in the technology library. It is used, to represent the gates schematically, while using the graphical front- end tool, DA. The symbol libraries are identified with a “sdb” extension. If this variable is omitted from the setup file, DA will use a generic symbol library called “generic.sdb” to create schematics. Generally, all technology libraries provided by the library vendor include a corresponding symbol library. It is imperative that there be a exact match of the cell names and the pin names, between the technology and the symbol library. Any mismatch in a cell will cause DA to reject the cell from the symbol library, and use the cell from the generic library. {It must be noted that DC uses the link_fibrary variable, whereas PT calls it the link_path. Apart from the difference in name and the format, the application of both these variables is identical. Since PT is a gate-level static timing analyzer, it only works on the structural gate-level netlists. Thus, PT. does not utilize the target_library variable. 33 Objects, Variables and Attributes Synopsys supports a number of objects, variables and attributes in order to streamline the synthesis process. Using these, designers can write powerful de_shell scripts to automate the synthesis process. It is therefore essential for designers to familiarize themselves with these terms 3.3.1 Design Objects ‘There are eight different types of design objects categorized by DC. These are: ~ Design: It corresponds to the circuit description that performs some logical function. The design may be stand-alone or may include other sub-designs. Although, sub-designs may be part of the design, itis treated as another design by Synopsys. — Cell: It is the instantiated name of the sub-design in the design. In Synopsys terminology, there is no differentiation between the cell and instance; both are treated as cell. — Reference: This is the definition of the original design to which the cell or thane refers Fr ., a leaf cell in the netlist must be referenced from the link library, which contains the functional description of the cell. Similarly, an instantiated sub-design (called cell by Synopsys) must be referenced in the design, which contains functional description of the instantiated sub-design. — Port: These are the primary inputs, outputs or 1O"s of the design. — Pin: It corresponds to the inputs, outputs or 10"s of the cells in the design (Note the difference between port and pin) — Net: These are the signal names, ie., the wires that hook up the design together by connecting ports to pins and/or pins to each other. = Clock: The port or pin that is identified as a clock source, The identification may be intemal to the library or it may be done using de_shell commands. = Library: Corresponds to the collection of technology specific cells that the design is targeting for synthesis; or linking for reference. 33.2 Variables Variables are placeholders used by DC for the purpose of storing information. The information may relate to instructions for tailoring the final netlist, or it may contain user-defined value to be used for automating the synthesis process. Some variables are pre-defined by DC and may be used by the designer to obtain the current value stored in the variable. For eg., the variable called “de_shell_status” has a special meaning to DC, while “captain_picard” has no meaning to DC. The latter may be used to hold any user-defined value for scripting purposes.All variables are global and last only during the session. They are not saved along with the design database. Upon completion of the dc_shell session, the value of the variables is lost. Most de_shell variables have a default value associated with them, which they inkerit at the start of the session. For instance, the following variable uses IEEE.std logic 1164 as its default value and you need to specify additional values (packages in this case) for DC to write out the “USE” clause with the specified name in the synthesized VHDL netlist. For example: dc_she11> vhdlout_use_packages = { library IEEE.std_logic_1164: \ library STD_LIB; } Users may use variables to gather useful information about the design. Example 3.2 provides a de_shell script, aliased as reg_count, which may be used to find the number of flops per clock domain. To use the following script, the clock name in the design should first be assigned to the variable named CLK. Example 3.2 alias reg_count “list CLK > /devinull; \ if(dc_shell_status \ {echo “Set the CLK variable for a chosen clock”;}_\ else {create_clock CLK ~name CLK ~period 100; \ remove_variable count > /dev/null; \ 0 > /devinull \ foreach(reg, all_registers (-clock CLK)){ —\ count = count + 1; \ ‘ \ echo “Number of flops for the chosen clock is: “count; \ y A list of all DC variables may be obtained by using the following de_shell ‘command: list -variables all Variables may be removed from DC by using the following dc_shell ‘command: remove_variable ‘The variables used by PT differ from those of DC, in syntax and application. PT uses the Tel based syntax, while DC uses its own. The applications of the PT variables are based on Tel constructs. Usage of PT variables through Tel is described in detail in Chapter 11. 3.3.3 Attributes Attributes are similar in nature to variables. Both store information. However, attributes store information on a particular design object such as nets, cells or clocks, Generally, attributes are pre-defined and have special meaning to DC, though designers may set their own attributes if desired, For e.g, the set_dont_touch is a pre-defined attribute, used to set a dont_touch on a design, thereby disabling DC optimization on that design, Attributes are set on and retrieved from the design object by usirg the following commands: set_attribute