Synopsys Tutorial: Using the Design Compiler | ECE 126, Lab Reports of Electrical and Electronics Engineering

Material Type: Lab; Professor: Farmer; Class: Laboratory; Subject: Electrical & Computer Engring; University: George Washington University; Term: Spring 2009;

Typology: Lab Reports

Pre 2010

Uploaded on 08/16/2009

koofers-user-zln
koofers-user-zln 🇺🇸

5

(2)

9 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
ECE 126 – Synopsys Tutorial: Using the Design Compiler
Created at GWU by Thomas Farmer
Objectives:
Synthesize a “structural” 1-bit full adder using the Synopsys Design Compiler
Synthesize a “behavioral” 1-bit full adder using the Synopsys Design Compiler
Synthesize both full adders using the AMI .5 library using the OSU Standardized Cells
Assumptions:
Student has completed lab 1 and has a working structural 1-bit full adder
Introduction:
The ASIC design flow is as follows:
Specification
RTL Coding and Simulation
Logic Synthesis
Optimization
Gate Level Simulation
Static Timing Analysis
Place and Route
Static Timing Analysis
Preliminary Netlist Handoff
In this tutorial, we will be working in “Logic Synthesis” portion of the ASIC flow. In this course, we will use the
Synopsys Product Family. IN particular, we will concentrate on the Synopsys Tool called the “Design Compiler.”
The Design Compiler is the core synthesis engine of Synopsys synthesis product family.
It has 2 user interfaces :-
1) Design Vision- a GUI (Graphical User Interface)
2) dc_shell - a command line interface
In this tutorial we will take the verilog code you have written in lab 1 for a full adder and “synthesize” it into actual
logic gates using the design compiler tool. We will use the GUI first, and after you become more familiar with the
commands, you can migrate to dc_shell.
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Synopsys Tutorial: Using the Design Compiler | ECE 126 and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!

ECE 126 – Synopsys Tutorial: Using the Design Compiler Created at GWU by Thomas Farmer Objectives:

  • Synthesize a “structural” 1-bit full adder using the Synopsys Design Compiler
  • Synthesize a “behavioral” 1-bit full adder using the Synopsys Design Compiler
  • Synthesize both full adders using the AMI .5 library using the OSU Standardized Cells Assumptions :
  • Student has completed lab 1 and has a working structural 1-bit full adder Introduction: The ASIC design flow is as follows: Specification ▼ RTL Coding and Simulation ▼ Logic Synthesis ▼ Optimization ▼ Gate Level Simulation ▼ Static Timing Analysis ▼ Place and Route ▼ Static Timing Analysis ▼ Preliminary Netlist Handoff In this tutorial, we will be working in “Logic Synthesis” portion of the ASIC flow. In this course, we will use the Synopsys Product Family. IN particular, we will concentrate on the Synopsys Tool called the “Design Compiler.” The Design Compiler is the core synthesis engine of Synopsys synthesis product family. It has 2 user interfaces :-
  1. Design Vision- a GUI (Graphical User Interface)
  2. dc_shell - a command line interface In this tutorial we will take the verilog code you have written in lab 1 for a full adder and “synthesize” it into actual logic gates using the design compiler tool. We will use the GUI first, and after you become more familiar with the commands, you can migrate to dc_shell.

Part I: Basic Overview of Synthesis: In sythensizing a design in Synopys' design compiler, there are 4 basic steps:

  1. Analyze & Elaborate
  2. Apply Constraints
  3. Optimization & Compilation
  4. Inspection of Results Part II: Preparation Any time you wish to “synthesize” some verilog code, create a directory in your ece128 folder to house all of the files that will be created during the synthesise process. For this example, prepare the following directory structure:
  1. Login to a workstation, open up a terminal window and type: cd ece mkdir lab cd lab mkdir work mkdir src mkdir db Always create the “work” “src” and “db” directories in whatever directory you decide to work under. In our case, our 'working' directory will be 'lab3' Copy the AMI 0.5 “standard cell library's” verilog code into your “src” directory: cp /apps/design_kits/osu_stdcells_v2p7/cadence/lib/ami05/lib/osu05_stdcells.v ~/ece128/lab3/src
  2. Copy the verilog code you wish to synthesize into the “src” subdirectory: In this lab, we want to use the fulladder & halfadder you created in lab1: You may need to change the first part of the directory location to where your fulladder code is: cp ~/ece128/lab1/fulladder.v ~/ece128/lab3/src cp ~/ece128/lab1/halfadder.v ~/ece128/lab3/src cp ~/ece128/lab1/fulladder_tb.v ~/ece128/lab3/src The above three lines copy the “fulladder” “halfadder” and the test bench you created in lab1 into 'src' directory underneath the lab3 directory you created in step1.
  3. Create a file called: .synopsys_dc.setup in your home directory (this only needs to be done one time, you will not need to do it again for ece 128) gedit ~/.synopsys_dc.setup Copy and paste the following lines: set search_path [list. ${search_path} /apps/design_kits/osu_stdcells_v2p7/synopsys/lib/ami05 "./src" "./db"] set target_library osu05_stdcells.db set link_library { * osu05_stdcells.db } set acs_work_dir "./work" This file should be only 4 lines long (the first line has “wrapped” in this tutorial_
  1. Click on File->Setup to verify that the parameters you setup in your “synopsys_dc.setup” file have taken effect (look through both tabs to see all the variables and parameters you've setup)
  2. Load all your verilog code (and its dependent files) by going to: File-> Analyze Click on the “add” button and click on the “src” sub-directory Add “fulladder.v” and “halfadder.v” Note : The analyze command will do syntax checking and create intermediate .syn files which will be stored in the directory work, the defined design library. The elaborate command goes to the work directory to pick up the .syn files and builds the design up to the Design Compiler memory.
  3. Inspect the messages in the LOG window at the bottom, correct any syntax errors in your verilog files and do the analyze again, otherwise, proceed.
  4. Once you've succesfully analyzed the code, Select File-> Elaborate Elaboration brings all the associated lower level blocks into the Design Compiler automatically (by following the dependency of the instantiations within the HDL code) Instead of doing Analyze & Elaborate, you can also do just Read for a verilog design, the difference is that you have a choice of design library to place the analyzed design when you do Analyze, whereas with Read only the default library WORK is used. Your design is now translated to a technology independent RTL model. Part IV: Viewing the schematic You should notice your full adder and the half adder that it depends on is now loaded into the design compiler. The logical heirarchy shows
  5. Click on Design → New Design Schematic View and the following schematic should appear
  6. You can click on the “ha1” or “ha2” components to drill down further into the elaborated design. As you drill down, various 'tabs' will open up. You can also use the icon on top of the menu bar to go back “up” in the design heirarchy Notice the basic gates, the OR gates, have the label “GTECH” this stands for 'generic' technology, meaning the OR gates have no timing, power, or other realistic information contained within them. They are merely symbols.

Part V: Applying Contraints to your design Adding constraints to your design is a process to make your design a bit more realistic than just simple gates. As an example, the wires that connect your gates are ideal, no R,L, or C. You can apply what is known as a 'wire model' to make the wires take on realistic RLC characteristics as they would in an extracted layout. Or another example would be to apply a 'fanout' or 'fanin' to the inputs and outputs of your design as to simulate a realistic level of input or output driving.

  1. The first step is to “LINK” your design, click File → Link Design The link command checks to make sure all parts in the current design are available in Design_Analyzer's memory.
  2. In the “Heirachy” window, click on the fulladder (the top most portion of your design). Then from the file menu click on File → Uniquify → Heriarchy Choose the top most level of your design (in this case “halfadder”) in cell reference from the drop down list menu that comes up. Do not adjust any other defaults, and press “OK” to allow the uniqufying process to begin. The command uniquify is used to make unique the instances of the same reference design during synthesis. why uniquify your design? when 2 instances of the same reference design/cell are present in the design (like how the “halfadder” module is used twice in our fulladder” design, then different constraints will have to be applied to the design; thus to resolve the multiple instances issue we use uniquify command. If you were to now look at your schematic view, you'd notice that ha1 and ha2 have different internal names. They now have the names: ha_1 and ha_0. Before they both had the same name: ha...this step allows each half adder to be its own 'unique' module. We can now apply different 'constraints' to each half adder, without affecting the other isntance of it in the design.
  3. Setting up the clock a) If your design DOESN'T have a clock, follow this step. If your design DOES have a clock skip this step, go to the next step If you're design doesn't have a clock at all, then it is purely 'combinational' logic. We need to create what is known as a 'virtual' clock. The virtual clock would be analagous to a system clock that all of the signals in your design would be 'measured' against. To create a virtual clock named “clk” type the command below into the design_vision field: create_clock -period 40 -waveform {0 20} -name clk This creates a virtual clock with a 40 ns period, 50% duty cycle = 25MHz clock
  1. To set the overall set of constrains on all of your input and output ports, type the following command: report_port
  • This command will display each input and output port and show the constraints you have set on them. Check to ensure that each port has the constraints that you have set in the last 4 steps.
  1. AREA vs. SPEED
  • When the design_compiler synthesizes your design, it can attempt to minimize the 'area' of your design, and sacrifice speed. Or it can attempt to maximize the speed of your design by sacrificing area.
  • To ask the design_compiler to synthesize for area, from the menu choose: Attributes->Optimization Constraints->Design Constraints Set the 'maximum area' to 0. This will force the synthesizer to optimize for the smallest possible area:
  • If you wish the design compiler to optimize for speed, clear the max area field and press OK
  1. Once you are finished specifying all of the design constraings, from the menu choose: Design → Check Design, press OK
  • This step will check your design's netlist description for problems like connectivity, shorts, opens, multiple instantiations. If your design passes this step, in the “LOG” window, you should see no errors.
  1. You are now ready to have the design_compiler synthesize your design using the AMI 0.5 standard cell library.
  • From the menu choose: Design → Compile Design. You can ask the synthesizer to use 'low' 'medium' or 'high' effort to achieve the constraints you have set. The higher the effort, the longer the synthesize will take. If you design is large, this could mean several hours to days if you choose a 'high' effort.
  • For this exercise, 'medium' effort will be sufficient, that should be the default, press OK to being synthesis

Part VI: Inspecting your Results

  1. Once the synthesis is complete, you can view your 'synthesized' schematic. From the menu choose: Schematic → New Design Schematic View
  • Your design will now be implemented using the AMI 0.5 standard cell library.
  • You may double click on the 'half adders' to see what is inside each of them. You should see that they have been implemented using GATES from the standard cell library.
  • If you see components that don't map to a standardized cell, you may have done something in verilog that cannot be synthesized. You must investigate the cell and your verilog code to see what you have done incorrectly in verilog.
  1. To view the critical path in your design, while in the schematic view, from the menu choose: Select → Paths From/Through/to set the: delay type: max
  • The critical path will then be highlighted on the schematic window using a white line.
  1. Checking if your constraints have been met.
  • If you have setup a clock that is FAR to fast for your design, the design_compiler will synthesize something, but it won't have met the constraint you have setup. Or if you set a fanin/fanout load that is unreasonable, the same will occur. You need to check the results of the synthesis by checking the synthesis reports.
  • Checking the Timing
    • From the menu, choose: Timing → Report Timing Path
    • If you wish, you can have the design_compiler write this 'report' to a file, as well as the the screen. From the bottom of the dialog box, press: “To file:”
    • Then press OK
      • A 'report' will be generated and printed the screen. It will show the timing for each cell in the design as well as the entire design itself. If you have a clock in the system, it will show you if your design has 'met' the clock constraint, or 'failed' the clock constraint.
      • This is a crucial report to check. If you have violated the timing requirements, you may need to change the period of your clock, and then re-compile the design.