Thursday, January 28, 2016

Synthesis Introduction - A Practical Approach

This Article provides you an overview of synthesis process along with the ASIC design flow which is used in industry. ASIC design flow gives you an overview of various processes involved in development of a chip. After reading this article you would be in a position to answer the following questions: What is ASIC flow? What are the various flows invloved in designing a chip? What is synthesis? Why we need synthesis? What are the inputs used for synthesis? What is the industry flow used for synthesis ? so let's start with the very basic of synthesis. Before going forward lets's see a design process which is used across the industry and synthesis is one of them.

Let's start with a basic ASIC design flow. How a chip is designed. What processes we follow.
This following flow chart represents the ASIC/VLSI design flow.




As you can see from above flow chart that mainly ASIC flow includes Front end and Backend Processes as called in industry. Basically Frontend processes includes  RTL Architecture, Synthesis, Logical Equivalence check (LEC) whereas Backend process mainly comprise of Floor Planning, CTS (Clock Tree Synthesis), PnR (Placement and Routing), LVS (Layout versus Schematic) and generating GDS model which is sent to foundry for fabrication. This whole process is known as RTL2GDS flow.

Let's begin with the discussion of synthesis.

What is Synthesis?

Synthesis is a process in which a high level design description in the form of a software code like verilog or VHDL is converted in the form of an optimized netlist, which is also called as gate level representation of a design. To be precise, Basically this is a process which gives hardware interpretation of your software code. The output of synthesis is a netlist which includes nets, sequential/combinational cells and their connectivity. Synthesis is not a single step process as in turn it includes some sub processes which i will explain later in this section. 

Before you start synthesis, you should know the various inputs which are required for this process. So i will mention the following prerequisites which are required for synthesis.
  • First input is your RTL Code (in verilog/vhdl).
  • Technology Library (.lib)
  • Design Constraints
  • Design Environments 
 The following flow diagram represents a logical synthesis flow as described above.
 



The important part in synthesis is design constraints and design environments. Technology library is provided by the vendor which will be technology specific (specific to node like 28nm, 45nm etc) having information about the cells characterized separately. 

Design environments variables are comprised of the following things,
  • Process Parameters: technology library, operating conditions
  • I/O attributes: Drive strength of Input ports, capacitive loading of output ports
  • DRC (Design Rule Checks): max_cap, max_trans, max_fanout
  • Selection of Wireload models which will be part of technology file .lib (need not be)
Design constraints include the following, they are also called as optimization constraints which guides the tool for optimizations.
  • Clock Specification: Period, duty cycle, transition time, skew etc
  • Delay Specification: max/min delay (for feedthrus) 
  • Timing Exception: False path, multicycle paths (if any).
Now lets go in detail inside the sub sections of steps in synthesis,
For performing RTL synthesis we have different tool from EDA Vendors which are used by various product based companies. Mainly popular tools are RC (RTL Compiler) from Cadence and DC (Design Compiler) from synopsys. They basically differ in the commands and attributes settings. Basic concept is same in both the tools.
Generic Synthesis: After setting up of design constraints and design environments we can proceed for synthesis. First step in synthesis is performing the generic synthesis or sometimes we also call this GTECH synthesis. In this step basically we do the RTL optimizations by converting the code into generic cells. These generic cells are a part of tool default library, which are not related to any specific technology. so we can say that this step is technology independent. 
Mapped Synthesis: After generic synthesis, next step performed is mapped synthesis. In mapped synthesis, the generic cells in the design (after generic synthesis) are mapped to the technology specific cells defined in the technology library (.lib) and performs logic optimization. This step is technology dependent. Basically the following functions are performed in mapped synthesis,
  • Boolean optimization (technology independent)
  • Technology mapping.
  • Technology dependent gate optimization. 
Incremental Optimization: In this step there are various techniques which are applied to optimize the design in terms of area, timing, power and fix DRC violations. By default tools tries to fix the timing violations at the expense of DRC (if any) but this priority can be overridden. IOPT includes some techniques like incremental retiming, multi bit cell mapping, incremental clock gating etc. 
Some optimization settings include the following,
  • Grouping and Ungrouing
  • Partioning
  • Boundary optimization settings
  • Preserving instances or modules.
  • Deleting unused sequential instances.
  • Optimizing TNS (total negative slack) 
A simple script for synthesis is shown below (Please note that this script is based on the cadence tool RTL Compiler, RC)
set_attribute lib_search_path <path of technology lib>
set_attribite hdl_search_path <path of RTL>
set_attribute library <Name of technology library> / (note "/" represents attribute is applied to root)
read_hdl <hdl_files>
elaborate <top module name>
read_sdc <constraint.sdc>
synthesize -to_generic
synthesize -to_mapped
report timing
report area
write_hdl <netlist to be written>

Below is the flow for synopsys Design Compiler (DC)
set target_library <technology library>
set link_library <library used for linking purpose e.g RAM, Black box>
set search_path <hdl search path>
read_file <hdl file>
current_design <top_module>
analyze <analyzes and elaborates the design>
read_sdc <constraints.sdc>
compile
compile_ultra
check_design
report_constraint
report_area
report_timing
write_file <netlist>

Please note that in DC, the input files can be read in three different ways, the read_file command analyzes the design and translates it into a technology-independent (GTECH) design in single step.
The analyze command check the design and report errors then elaborate command translates the design into technology-independent design (GTECH) from the output of analyze command. read_verilog/vhdl command checks for for the syntax and build the design into GTECH netlist.

Hope this would have helped you in understanding the concepts related to synthesis and flow.

Quality Checks After Synthesis
 
Now the question arises that after synthesis is over, what one need to look into to make sure that the generated netlist is of good quality? The following section covers the basic sanity checks which one should do in order to ensure the quality of netlist.

There are some in-built design checks in the tools, which tool does and report those as errors/warnings/info depending on the severity. Some checks include "latch inference, multi-driven ports, error on black box, unloaded ports, signal is not in sensitivity list". One can always upgrade the severity of the messages. This will be caught during elaboration.

Once we have the netlist written out, we should first analyze the QoR report for timing figures like WNS/TNS, If you are seeing a big violations in nano seconds then you should look into the paths, analyze it and look whether the path is missing some constraints/exceptions (if any). You should also check for the area, how many sequential/combinational cells a design have. You should also use the linting check for checking the timing errors. Mostly this option is used with the report timing command. This option provides a list of possible timing problems due to over constraining the design or incomplete constraints, such as missing multicycle paths or false paths.

There are two important checks one should look into this includes no-clocks/multi-clocks and unconstrained end points (also know as modal coverage) in the design. This will help a lot in the design to constrain it properly and help in reducing the iterations with back-end team.
 

4 comments:

  1. Very nicely explained whole process of synthesis. Thanks for publishing it.

    ReplyDelete
  2. Is the same also for FPGA synthesis?

    ReplyDelete
  3. by defualt the tool gives maximum priority to DRC than timing. Please correct me if i am wrong.

    ReplyDelete