Design Compiler Tutorial

• Introduction
• Initialization
  • Linux
  • Solaris
• Project Setup
  • Directory Structure
  • Setup File .synopsys_dc.setup
    • Example Setup File
• Synthesis Flow
  • Synthesis Overview
    • Reading in the Design
    • Constraining the Design
    • Defining Design Environment
    • Optimizing the Design
      • Architectural Optimizations
      • Logic-Level Optimizations
      • Gate-Level Optimizations
  • Reporting and Analyzing the Design
  • Save Design
• Examples
  • Modular Ripple Carry Adder
    • RCA Design Structure
    • Reading in the Design
    • Saving the Elaborated Design
    • Setting the Constraints
    • Optimizing the Design
    • Design Analysis and Reporting
      • Timing Analysis
      • Structure Analysis
    • Saving the Design
  • Optimizations: Grouping and Ungrouping
  • An Adder Design
    • Reading in the Design
• Summary

Introduction

RTL synthesis is an automated design task in which high-level design descriptions written in Hardware Description Languages (such as Vhdl, verilog, or SystemVerilog) are transformed into gate-level netlists. Gate-level netlist is basically a circuit implementation of the design made of library components (both combinational and sequential cells) available in the technology library and their interconnections. The netlist is generated by the synthesis tool according to the constraints set by the designer. Figure 1 below shows an overview of the synthesis.

Design Compiler is RTL Synthesis tool by Synopsys. It supports UNIX platforms and is installed on Institute's computer systems (see here for available versions on each platform.: mustatikli/ linux). Design Compiler is not supported on Windows platform.

This tutorial is intended for users with no previous experience with Design Compiler. It introduces you how to set up the synthesis tool and the basic tasks of logic synthesis with Design Compiler: analyzing and elaborating the design, setting constraints, optimizing the design, analyzing the results, and saving generated netlists. Specifically, this tutorial considers only synchronous systems and basic synthesis tasks. Subjects as asynchronous systems or advanced synthesis techniques will not be discussed. In addition to Design Compiler, this tutorial introduces the basics of the Design Compiler GUI (called Design Vision).

This tutorial includes several examples written in VHDL but, excluding a few commands using VHDL specific command options, all information shown here can also be applied with designs written in Verilog or SystemVerilog. This tutorial was made by using Design Compiler version 2007.03 SP2 on Linux.

Note: the Y Foundation (i.e. versions starting from version 2007.03) introduced some important changes in Synopsys Desing Compiler tool:

• The tool supports only XG mode. Support for DB mode has been removed from the tool.
• The tool supports only DCTCL command language. Support for DCSH command language has been removed from the tool.

Therefore, this tutorial and its examples consider only Design Compiler running in XG mode using DCTCL command language even though older tools are still available and installed on Institute's computer systems.

Initialization

In order to use Design Compiler, you must set up your environment correctly. This includes setting up a few variables, files, and licensing information and can be done by sourcing the scripts shown below.

Linux

First, check this link to find out the available versions of synthesis tools currently installed on Linux machines. Then, initialize the tool by running the respective source script. You should always select the latest version available unless you have a reason to use an older version.

$ source /share/tktprog/synopsys/syn-2007.03-SP2/syn.sh

Solaris

First, check this link (mustatikli) to find out the available versions of synthesis tools currently installed on Solaris machine. Then, initialize the tool by running the respective source script. On Solaris platform. you may use either 32-bit or 64-bit binaries. You should always select the latest version available unless you have a reason to use an older version.

$ source /opt/synopsys/syn-2007.03-SP2/syn32.sh

After sourcing the given script. you should see a message similar to the one below (the actual message may differ depending on the tool version and platform) indicating that the source script. was read and your environment set up correctly:

########################################################################
                       SYNOPSYS Synthesis Tools
               version 2007.03-SP2 (32 bit binaries)
 -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
There is no /tmp/synopsys_cache directory... creating a new one.
NOTE: By default, Design Compiler is now starting in XG mode. If you
      want to revert back to DB mode, please use:
      dc_shell-t -db_mode OR dc_shell -tcl_mode -db_mode
RTFM: synopsys_help &
      read man pages: man <command_name>
      eg. man set_clock_uncertainty
Ensure that your .synopsys_dc.setup etc. is valid for this version.
########################################################################

Project Setup

Instructions for setting up a project directory and Design Compiler setup file for your project.

Directory Structure

In order to keep your project data well-organized and safe, it is recommended to store files in each project into a separate project directory. The following example proposes one possible directory structure for small projects.

The example below includes an optional simulation directory (SIM/) for ModelSim which is not needed in these exercises but is shown as an example of what sort of subdirectories might be needed in real projects.

<PROJECT>/  -- project directory
   .synopsys_dc.setup  -- Synopsys Design Compiler initialization file
   modelsim.ini        -- ModelSim initialization file
   SRC/  -- HDL source files
   SYN/  -- synthesis subdirectory
      DDC/      -- Design Compiler database
      NETLIST/  -- mapped Verilog/VHDL netlists
      RPT/      -- reports
      SCR/      -- synthesis scripts
      WORK/     -- intermediate files from synthesis tool
   SIM/  -- simulation subdirectory (not needed in these examples)
      SCR/      -- simulation scripts
      WORK/     -- ModelSim work directory

You may copy the directory structure shown above and use it as such, modify it as you like, or create your own directory structure according to your needs for your own projects. Whichever way you choose do, keep in mind that consistent and simple directory structure helps you to reuse your code from different projects and to automate some tasks in the design flow.

Note that unless otherwise stated, the examples in this tutorial assume that the directory structure described above is used.

Setup file .synopsys_dc.setup

The .synopsys_dc.setup file is the setup file for Synopsys' Design Compiler. Setup file is used for initializing design parameters and variables, declare design libraries, and so on. Shortly, the setup file defines the behavior. of the tool and is required for setting the tool up correctly. The commands in this file are executed when Design Compiler is invoked. There are three different locations from where this file is searched for:

1. The Synopsys root directory (<SYNOPSYS>/admin/setup/) for system-wide settings
2. Your home directory ($HOME/) for user-defined settings
3. The current working directory ($PWD/) for design-specific settings

The files are read in the order shown above. Settings in user-specific setup file override the settings from system-wide setup file and settings in design-specific setup file overrides settings from both system-wide and user-specific setup file. You should have at least design-specific setup file for each of your projects.

Example setup file

The following shows an example of a minimal setup file using dctcl syntax. The example setup file has also been adapted to use the directory structure described above:

# Minimal .synopsys_dc.setup file

# Define the UMC L180 GII library
set UMC /share/tktprog/IC/umc
set L180_GII ${UMC}/L180_GII/core/UMCL18G212D3_1.0/design_compiler

# Define the libraries and search path
set search_path [concat $search_path ./SRC ./SYN/SCR ${L180_GII}]
set target_library ${L180_GII}/umcl18g212t3_tc_180V_25C.db
set synthetic_library dw_foundation.sldb
set link_library [concat "*" $target_library $synthetic_library]
set symbol_library ${L180_GII}/umcl18g212t3.sdb

define_design_lib WORK -path ./SYN/WORK

The example file does the following:

Sets the search_path

If a file is referenced just by its name (directory path not specified) then Design Compiler searches the file from the directories specified by the search_path variable. For example, in this case the search order is: the current directory (.), Synopsys installation directories <SYNOPSYS>/libraries/syn, <SYNOPSYS>/dw/syn_ver, and <SYNOPSYS>/dw/sim_ver, and finally the directories./SRC and ./SYN/SCR in the project directory and the UMC technology library directory.

Sets the target_library

The target library variable defines the technology library that Design Compiler uses to build the circuit. That is, during technology mapping phase Design Compiler selects components from the library specified with the target library variable to build the gate-level netlist. In this example, we are using the UMC L180 GII library which can be found from the ${L180_GII} directory.

Sets the synthetic_library

The synthetic library variable specifies the synthetic or DesignWare libraries. These synthetic libraries are technology-independent, microarchitecture-level design libraries providing implementations for various IP blocks.

• Note that these libraries are tighly integrated into the Synopsys synthesis environment (i.e. they cannot be used with non-Synopsys synthesis tools).

The standard.sldb synthetic library which is automatically included contains basic implementations for the built-in HDL operators (adders, subtractors, comparators etc). The dw_foundationlibrary which is shown in the example includes DesignWare Building Block IP Libraries DW01, DW02, DW03, DW04, DW05, DW06, and DW07. These libraries provide more advanced implementations for the built-in operators to improve performance. They also include implementations for more complex arithmetic operators such as MAC, SOP, and vector adders. Other DesignWare libraries include e.g. building blocks for dsp (FIR and IIR filters), memories, advanced math functions, microcontrollers and so on. If additional synthetic libraries are defined with thesynthetic_library variable, they must also be included in the link_library variable.

Sets the link_library

The link library variable is used to resolve design references. That is, Design Compiler must connect all the library components and designs it references. This step is called linking the design or resolving references.

• Note that in most cases the link library is the same as the target library.
• The asterisk (*) in the link library variable tells that Design Compiler should first search the reference from the memory.

Sets the symbol_library

Symbol library defines the schematic symbols for components in technology library. These symbols are needed for drawing design schematics.

Sets the path to work library

This command maps a design library to a directory. Design Compiler uses this directory to store intermediate represenstations of the design it generates during synthesis.

Note that since the search path variable defines directories ${L180_GII} and <SYNOPSYS>/libraries/syn, we can reference the UMC technology library and dw_foundation library just by their name.

Synthesis Flow

Synthesis is a complex task consisting of many phases and requires various inputs in order to produce a functionally correct netlist. The following chapter presents the basic synthesis flow with Synopsys Design Compiler. It assumes that you have a synthesizable and functionally correct HDL description available.

Synthesis Overview

Synthesis with Design Compiler include the following main tasks: reading in the design, setting constraints, optimizing the design, analyzing the results and saving the design database. These tasks are described below:

Reading in the design

The first task in synthesis is to read the design into Design Compiler memory. Reading in an HDL design description consist of two tasks: analyzing and elaborating the description. The analysis command (analyze) performs the following tasks:

• Reads the HDL source and checks it for syntactical errors
• Creates HDL library objects in an HDL-independent intermediate format and saves these intermediate files in a specified location (./SYN/WORK/ in this tutorial).

If the analysis reports errors, they must be fixed, and the design reanalyzed before continuing.

The elaboration command (elaborate) does e.g. the following:

• Translates the design into a technology-independent design (GTECH) from the intermediate files produced during analysis
• Allows changing of parameter values (generics) defined in the source code
• Replaces the HDL arithmetic operators in the code with DesignWare components
• Automatically executes the link command, which resolves design references

Note: check the elaboration reports carefully to see the number and the type of memory elements Design Compiler thinks it should infer and whether you agree with it or not. Badly modeled hardware description may result as excessive or wrong type of memory elements inferred.

At this point, if the elaboration completed successfully, the design is represented in GTECH format, which is an internal, equation-based, technology-independent design format.

Constraining the design

The next task is to set the design constraints. Constraints are the instructions that the designer gives to Design Compiler. They define what the synthesis tool can or cannot do with the design or how the tool behaves. Usually this information can be derived from the various design specifications (e.g. from timing specification).

There are basically two types of design constraints:

Design Rule Constraints

Design rules constraints are implicit constraints which means that they are defined by the ASIC vendor in technology library. By specifying the technology library that Design Compiler should use, you also specify all design rules in that library. You cannot discard or override these rules.

Optimization Constraints

Optimization constraints are explicit constraints (set by the designer). They describe the design goals (area, timing, and so on) the designer has set for the design and work as instructions for the Design Compiler how to perform. synthesis.

Design rule constraints comprise:

Maximum transition time

Longest time allowed for a driving pin of a net to change its logic value

Maximum fanout

Maximum fanout for a driving pin

Maximum (and minimum) capacitance

The maximum (and minimum) total capacitive load that an output pin can drive. The total capacitance comprises of load pin capacitance and interconnect capacitances.

Cell degradation

Some technology libraries contain cell degradation tables. The cell degradation tables list the maximum capacitance that can be driven by a cell as a function of the transition times at the inputs of the cell.

The optimization constraints comprise timing and maximum area constraints. The most common timing constraints include:

System clock definition and clock delays

Clock constraints are the most important constraints in your ASIC design. The clock signal is the synchronization signal that controls the operation of the system. The clock signal also defines the timing requirements for all paths in the design. Most of the other timing constraints are related to the clock signal.

Multicycle paths

A multicycle path is an exception to the default single cycle timing requirement of paths. That is, on a multicycle path the signal requires more than a single clock cycle to propagate from the path startpoint to the path endpoint.

Input and output delays

Input and output delays constrain external path delays at the boundaries of a design. Input delay is used to model the path delay from external inputs to the first registers in the design. Output delay constrain the path from the last register to the outputs of the design.

Minimum and maximum path delays

Minimum and maximum path delays allow constraining paths individually and setting specific timing constraints on those paths.

Input transition and output load capacitance

These constraints can be used to constrain the input slew rate and output capacitance on input and output pins.

False paths

A false path is a path that cannot propagate a signal. For example, a path that is not activated by any combination of inputs is a false path.

Note that Design Compiler tries to meet both design rule and optimization constraints but design rule constraints always have precedence over the optimization constraints. This means that Design Compiler can violate optimization constraints if necessary to avoid violating design rule constraints.

Examples that follow show how to set these constraints.

Defining Design Environment

You also need to describe the environment in which the design is supposed to operate. The design environment description includes:

Defining Operating Conditions

The operating conditions considers the variations in process, voltage, and temperature (PVT) ranges a design is expected to encounter. These variations are taken into consideration with operating condition specifications in the technology library. The cell and wire delays are scaled according to these conditions.

Modeling Wire Loads

Wire load models are used to estimate the effect of interconnect nets on capacitance, resistance, and area before real data is obtained from the actual layout. These models are statistical models and they estimate the wire length as a function of net's fanout.

Optimizing the Design

The following section presents the behavior. of Design Compiler optimization step. The optimization step translates the HDL description into gate-level netlist using the cells available in the technology library. The optimization is done in several phases. In each optimization phase different optimization techniques are applied according to the design constraints. The following is somewhat simplified description of optimizations performed during synthesis.

Design Compiler performs optimizations on three levels: architectural, logic-level, and gate-level.

Architectural Optimizations

Architectural optimizations are high-level optimizations which are performed on the HDL description level. These optimizations include tasks such as:

Arithmetic Optimizations

Arithmetic optimization uses the rules of algebra to improve the implementation of the design. That is, Design Compiler may rearrange the operations in arithmetic expressions according to the constraints to minimize the area or timing.

Resource Sharing

Resource sharing tries to reduce the amount of hardware by sharing hardware resources with multiple operators in your HDL description. For example, single adder component may be shared with multiple addition operators in the HDL code. Without resource sharing each operator in your code will result as a separate HW component in the final circuitry.

Selecting DesignWare Implementations

Selecting a DesignWare implementation means that the implementation selection of a particular resource is left to the Design Compiler. For example, the Basic IP Library contains two implementations (ripple and carry-lookahead) for the +-operator (the DesignWare Foundation Library provides more implementations for the '+' and other operators). When selecting DesignWare implementation, Design Compiler considers all available implementations and makes it selection according to your constraints.

At this point, the design is represented by GTECH library parts (i.e. generic, technology-independent netlist).

Logic-level Optimizations

Logic-level optimizations are performed on GTECH netlist and consists of two processes: structuring and flattening.

Structuring

Structuring evaluates the design equations represented by the GTECH netlist and tries by using Boolean algebra to factor out common subexpressions in these equations. The subexpressions that have been identified and factored out can then be shared between the equations. For example,

Before Structuring	After Structuring
P = ax + ay + c	P = aI + c
Q = x + y + z	Q = I + z
	I = x + y

Structuring is usually recommended for designs with regular structured logic.

Flattening

Flattening tries to convert logic into two-level, Sum-of-Products representation. Flattening produces fast logic (by minimizing the levels of logic between the inputs and outputs) at the expense of the area increase. Flattening is recommended for designs containing unstructured or random logic.

Gate-level Optimizations

Gate-level optimizations work on the technology-independent netlist and maps it to the library cells to produce a technology-specific gate-level netlist. Gate-level optimizations include the following processes:

Mapping

This process maps the cells from technology-independent netlist (GTECH) to the cells in library specified by the target_library variable.

Delay Optimization

Delay optimization fixes the timing violations introduced by mapping phase.

Design Rule Fixing

Design rule fixing fixes the design rule violations in the design. Basically this means that Design Compiler inserts buffers or resizes existing cells. Note that design rule fixing phase is allowed to break timing constraints.

Area Optimization

Area optimization is the last step that Design Compiler performs on the design. During this phase, only those optimizations that don't break design rules or timing constraints are allowed.

Note: the optimizations Design Compiler performs (or does not perform) depend on the constraints you set. Therefore, setting realistic constraints is one of the most important synthesis tasks.

Reporting and Analyzing the Design

Once the synthesis has been completed, you need to analyze the results. Design Compiler provides together with its graphical user interface (Design Vision) various means to debug the synthesized design. These include both textual reports that can be generated for different design objects and graphical views that help inspecting and visualizing the design.

There are basically two types of analysis methods and tools:

Generating reports for design object properties

Reporting commands generate textual reports for various design objects: timing and area, cells, clocks, ports, buses, pins, nets, hierarchy, resources, constraints in the design, and so on.

Visualizing design objects (Design Vision)

Some design objects and their properties can be analyzed graphically. You may examine for example the design schematic and explore the design structure, visualize critical and other timing paths in the design, generate histograms for various metrics and so on.

These methods and tools are used to verify that the design meets the goals set by the designer and described with design constraints. If the design does not meet a design goal then the analysis methods can help determining the cause of the problem.

Save Design

The final task in synthesis with Design Compiler is to save the synthesized design. The design can be saved in many formats but you should save for example the gate-level netlist (usually in Verilog) and/or the design database. Remember that by default, Design Compiler does not save anything when exiting.

Examples

This section illustrates the synthesis flow and some of the tasks described above with a few examples.

Note that you may get different results from synthesis depending on the platform. and version used. These examples were made with the version Z-2007.03-SP2 running on Linux.

Modular Ripple Carry Adder

The first example is a simple Ripple Carry Adder (RCA). This example illustrates the basic synthesis flow: reading the design, setting constraints, optimizing the design, reporting and analyzing, and saving the design.

RCA Design Structure

This adder has modular structure as illustrated in pictures below. Figure 2 shows the gate-level structure of the Half Adder (HA) module, which is composed of two gates, AND and exclusive OR. This design is described in file ha.vhd.

The Full Adder (FA) module is composed of two instances of Half Adders and single OR gate as shown in Figure 3. This design is described in file fa.vhd.

The Ripple Carry Adder (RCA) design is generic instantiation of Full Adder Modules as shown in Figure 4. The RCA design is described in file rca.vhd.

The last part of the design instantiates the RCA design using bus width of 4 bits. The design also registers the output of the adder as shown in Figure 5. The carry in (CI) bit of the RCA is connected low (0) and the carry out (CI) bit is the most significant bit (MSB) of the output bus. This design is described in file adder.vhd.

This example uses the directory structure described earlier in section Directory Structure. Create a directory structure as described and copy the following files (SRC/ha.vhd, SRC/fa.vhd, SRC/rca.vhd,SRC/adder.vhd) into the directory SRC/. Copy also the .synopsys_dc.setup file into your project root directory.

Initialize Design Compiler as shown in section Initialization and invoke the Design Compiler GUI:

$ design_vision

Note that there is no ampersand (&) at the end of the command. In a moment, you should see a screen similar to the one below:

The Hierarchy Browser displays information about the design in textual form. The Hierarchy Browser is divided into two panes: instance tree (left) and objects list (right). The instance tree displays the design's hierarchy and the objects list information about the objects in current instance.

The Console views display information between the designer and the synthesis tool (commands entered by the designer and messages resulting the commands). Commands can be entered in Console Command Line (or from menubar menus and toolbar buttons).

Note that only some of the most common commands can be entered by using the Design Compiler GUI menubars and buttons. All commands can always be executed by writing them into the console. Therefore, in this tutorial we will mostly write the commands into the console. At the end of the synthesis, we will create a synthesis script. file from commands that were executed during this example. This synthesis script. file can then be used in subsequent synthesis runs.

Before proceeding with the example you need check that the tool has been set up correctly (i.e. the .synopsys_dc.setup file was read at the start up and there wasn't any problems with that). Our setup file merely sets the libraries that are required for synthesis and defines a library for work files.

Check libraries by selecting File -> Setup... from the menubar. This will open an Application Setup dialog box. In Application Setup check the values for target_library, link_library,symbol_library, and synthetic_library. They should be the same as in the setup file. The search_path should contain ./SRC, ./SYN/SCR, and ${L180_GII} directories in addition to default search path directories.

If the values for libraries or search path is something else then there was a problem with the setup file. In particular, if the values for libraries are your_library.db, your setup file was not read at all. In that case, the most probable reason is that the Design Vision was invoked in a wrong directory (Design Compiler/Vision searches for the setup file from the same directory it is invoked).

Check also that the design library is mapped correctly by writing the following command to the Console Command Line:

get_design_lib_path WORK

This should print the full path to the ./SYN/WORK/ library.

Reading in the Design

The first thing to do is to load the design into the Design Compiler memory. This task consists of two operations: analyzing and elaborating the design as described earlier (see the section Reading in the Design).

There are two commands for reading in the design: analyze and read_file. The read_file command is used with designs that are already in .ddc format so you should use the analyze command:

analyze -library WORK -format vhdl {./SRC/ha.vhd ./SRC/fa.vhd ./SRC/rca.vhd ./SRC/adder.vhd}

The same command can be found from the menubar (File -> Analyze...):

Select Add... and browse in to SRC directory in the file browser dialog and select your VHDL files. Check that Format is VHDL and Work library is WORK and click OK.

If there are syntactical errors or any non-synthesizable descriptions in your files the analysis will fail (and you need to fix them until you may proceed). In this case there shouldn't be any problems.

The next step is to elaborate the design:

elaborate ADDER -architecture RTL -library WORK -parameters "N=4"

The same command can be found from the menubar (File -> Elaborate...):

Check that Library is WORK, Design is ADDER(RTL), and in Parameters box set N to 4 and click OK.

Setting the parameter N to 4 overrides the default generic value (8) set in the file adder.vhd and creates a 4-bit RCA.

Always check the messages that Design Compiler generates in the console for each command you enter. For example, the elaboration command printed the following messages about the elaboration process:

design_vision-xg-t> elaborate ADDER -architecture RTL -library WORK -parameters "N=4"
Running PRESTO HDLC

Inferred memory devices in process
        in routine adder_N4 line 85 in file
                '/usr/oma/pirttimj/WORK/dc_tut/rca/SRC/adder.vhd'.
===============================================================================
|    Register Name    |   Type    | Width | Bus | MB | AR | AS | SR | SS | ST |
===============================================================================
|        s_reg        | Flip-flop |   5   |  Y  | N  | Y  | N  | N  | N  | N  |
===============================================================================
Presto compilation completed successfully.
Elaborated 1 design.
Current design is now 'adder_N4'.
Information: Building the design 'rca' instantiated from design 'adder_N4' with
        the parameters "N=4". (HDL-193)
Presto compilation completed successfully.
Information: Building the design 'fa'. (HDL-193)
Presto compilation completed successfully.
Information: Building the design 'ha'. (HDL-193)
Presto compilation completed successfully.
design_vision-xg-t> 
Current design is 'adder_N4'.

You should always check from the elaboration report what kind of memory devices (Type) Design Compiler wants to infer and the number (Width) of those devices. In this example, Design Compiler has decided to infer 5 flip-flops and that these registers are inferred for the process outregs in file adder.vhd. The number of registers and the type matches with what was expected for this design.

Sometimes Design Compiler wishes to infer latches from your description (latch in colunm Type in elaboration report). Latches may be intentional or unintentional. Consider latches as design errors in your description unless you know that latches should be inferred.

You may now also check the design structure by using the Hierarchy Browser or by creating a desing schematic for your design.

The design schematic can be generated with the 'Create Design Schematic' button () in the toolbar. The schematic is generated for the instance currently selected in the instance tree (or top level design by default). The following four figures display the design's structure after elaboration. You may move up and down in the design hierarchy e.g. by double clicking the instance in the design schematic, by using the toolbar buttons, or by using the Hierarchy Browser (select an instance, right-click the mouse and select the Schematic View).

Note that the following figures represents the design structure as it was understood and extracted by Design Compiler from your HDL design description. You should verify that Design Compiler did actually understand correctly what you intended. This extracted design structure will be the starting point for the optimizations but it does not necessarily represent the final design structure. Also note that the design is currently represented in an intermediate form. using GTECH cells. These cells are used internally by Design Compiler and will be replaced with the actual library cells at the end of synthesis, during technology mapping phase, as explained here.

The design is now read into the Design Compiler memory. It was analyzed for the syntactical errors and non-synthesizable structures and prepared for synthesis by the analyze and elaborate commands. However, it is still possible that there are some problems with the design. To check the design consistency, we need to run the check_design command on the design:

check_design -multiple_designs

This will produce the following messages:

design_vision-xg-t> check_design -multiple_designs
Warning: In design 'adder_N4', a pin on submodule 'i_rca' is connected to logic 1 or logic 0. (LINT-32)
   Pin 'ci' is connected to logic 0. 
Information: Design 'fa' is instantiated 4 times. (LINT-45)
         Cell 'i_rca/i_fa_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_1' in design 'adder_N4' 
         Cell 'i_rca/i_fa_2' in design 'adder_N4' 
         Cell 'i_rca/i_fa_3' in design 'adder_N4' 
Information: Design 'ha' is instantiated 8 times. (LINT-45)
         Cell 'i_rca/i_fa_0/i_ha_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_0/i_ha_1' in design 'adder_N4' 
         Cell 'i_rca/i_fa_1/i_ha_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_1/i_ha_1' in design 'adder_N4' 
         Cell 'i_rca/i_fa_2/i_ha_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_2/i_ha_1' in design 'adder_N4' 
         Cell 'i_rca/i_fa_3/i_ha_0' in design 'adder_N4' 
         Cell 'i_rca/i_fa_3/i_ha_1' in design 'adder_N4' 
1

The check_design command checks the internal representation of the current design and issues error, warning, and informative messages about the design to indicate potential design problems. In this example, the check_design command indicates that the design instantiates design fa four times and the design ha eight times which is how the design is described. It also issues a warning that there is a pin that has been permanently connected to ground or supply voltage (the input pin ci of the module rca in file adder.vhd). The ci pin is the carry in bit for the adder and it was intentionally connected to thelogic 0 so we can ignore this warning.

Saving the Elaborated Design

It is recommended to save the design every now and then