0% found this document useful (0 votes)
170 views4 pages

Synthesis Commands Guide

sdasdasd

Uploaded by

ojas.images.23
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
170 views4 pages

Synthesis Commands Guide

sdasdasd

Uploaded by

ojas.images.23
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd

# Synthesis Command Flow (from the PDF)

This flow is typically placed in a Tcl script (e.g., `[Link]`) and executed
in `dc_shell`.

## 1. Setup and Design Loading

This phase involves setting up the environment, specifying the technology


libraries, and loading your HDL design files.

* **`set_host_options -max_cores <number>`**: (Optional but recommended) Sets the


number of CPU cores to use for parallel processing to speed up compilation.
* **`set search_path { ... }`**: Defines the directories where Design Compiler
should look for library files and your source files.
* **`set target_library { <target_library>.db }`**: Specifies the main technology
library file. This library contains the standard cells (AND, OR, Flip-Flops, etc.)
that the synthesizer will use to build the circuit.
* **`set link_library { * <target_library>.db }`**: Specifies the libraries to be
used for resolving references in the design. The `*` symbol refers to all designs
in memory.
* **`read_verilog { <your_file_1>.v <your_file_2>.v }`** or **`read_vhd
{ <your_file>.vhd }`**: Reads your Verilog or VHDL source files into memory.
* **`current_design <top_level_module_name>`**: Sets the top-level module of your
design. This is the module you intend to synthesize.
* **`link`**: Links the design, resolving all hierarchical references and
connecting it to the specified libraries.

## 2. Applying Constraints

This is the most critical phase for determining the quality of your synthesized
design. You are telling the tool about the environment in which the chip will
operate.

* **`create_clock -period <value> [get_ports <clock_port_name>]`**: Defines a


clock signal, specifying its period (in ns) and the port it comes in on. This is
the primary timing constraint.
* **`set_input_delay <value> -clock <clock_name> [all_inputs()]`**: Specifies how
long it takes for signals to arrive at the inputs of your design, relative to the
clock edge.
* **`set_output_delay <value> -clock <clock_name> [all_outputs()]`**: Specifies
the time required by the external components connected to your design's outputs,
relative to the clock edge.
* **`set_load <value> [all_outputs()]`**: Defines the capacitive load that the
output ports of your design must drive.

## 3. Synthesis (Compilation)

This is the step where the HDL code is transformed into a gate-level netlist based
on the libraries and constraints provided.

* **`compile_ultra`**: This is the recommended, powerful synthesis command. It


performs advanced optimizations for timing, area, and power simultaneously.
* *Alternatives:* The PDF also mentions `compile` for basic synthesis or
`compile -map_effort medium/high` for more effort. However, `compile_ultra` is
generally preferred.

## 4. Post-Synthesis: Reporting and Saving the Results


After compilation, you must check the results to see if the design meets its goals
and then save the final netlist.

* **`report_timing`**: Generates a detailed timing report, showing the critical


path and any timing violations (setup/hold). This is essential for verifying
performance.
* **`report_area`**: Reports the total area of the synthesized design, often
broken down by cell type and hierarchy.
* **`report_power`**: Reports the estimated power consumption of the design.
* **`write -format verilog -hierarchy -output <output_netlist_file>.v`**: Writes
the synthesized gate-level netlist to a Verilog file. This file is what you will
use for the next steps in the ASIC flow (e.g., place and route).
* **`write_sdc <output_constraints_file>.sdc`**: Saves the constraints you
defined (clocks, delays, etc.) into a Synopsys Design Constraints (`.sdc`) file.
This file will be used by the place-and-route tool.

---
---

# Variations in the `compile` Command

Based on the provided PDF and general Synopsys Design Compiler (DC) knowledge, here
is a detailed breakdown of the variations in the `compile` command. Understanding
these variations is key to controlling the trade-off between synthesis runtime and
the quality of the final netlist.

## The Goal of Compilation

First, remember the goal: the `compile` command's job is to translate your abstract
HDL (Verilog/VHDL) into a concrete, gate-level netlist using the standard cells
from your technology library (the `.db` file). The "variations" of the command
determine *how hard* the tool tries to optimize this netlist for timing, area, and
power.

---

## 1. The Classic: `compile`

This is the original, fundamental synthesis command.

* **Purpose/When to Use:**
* For a quick, initial synthesis to check for basic design errors.
* For simpler designs where timing is not a major challenge.
* In older synthesis scripts that follow a "two-pass" methodology.

* **Key Characteristics:**
* It performs the three core steps of synthesis:
1. **Architectural Synthesis:** Converts HDL into a generic, technology-
independent format (GTECH).
2. **Logic Optimization:** Optimizes the boolean logic of the GTECH
netlist.
3. **Technology Mapping:** Maps the optimized GTECH logic to the actual
standard cells in your target library.
* In legacy scripts, you might see it used like this:
1. `compile` (First pass to get an initial netlist)
2. Apply more specific constraints.
3. `compile -incremental` (Second pass to re-optimize only the parts of
the design affected by the new constraints).
* **Example Usage:**
```tcl
# Basic compile with default effort
compile
```

## 2. Controlling the Effort: `compile -map_effort [low | medium | high]`

This is the primary way to control the trade-off between runtime and quality for
the classic `compile` command.

* **Purpose/When to Use:**
* To explicitly tell the tool how much time it should spend searching for a
better implementation of your logic.

* **Key Characteristics:**
* **`-map_effort low`**: Fastest runtime. The tool performs basic
optimizations but doesn't try very hard. Good for a quick "sanity check" to see if
the design synthesizes at all.
* **`-map_effort medium`**: The default setting. Provides a good balance
between runtime and quality of results (QoR).
* **`-map_effort high`**: Longest runtime. The tool uses more advanced
algorithms and tries many different mapping strategies to meet timing and reduce
area. **Use this when your design is failing to meet timing constraints.**

* **Example Usage:**
```tcl
# Tell the compiler to try very hard to meet timing
compile -map_effort high
```

## 3. The Modern Powerhouse: `compile_ultra`

This is the modern, recommended, "one-pass" synthesis command. It essentially


combines the classic `compile` with many advanced optimization features enabled by
default.

* **Purpose/When to Use:**
* This should be your **default choice** for almost all modern designs.
* Especially critical for designs with challenging timing, power, or area
requirements.

* **Key Characteristics:**
* **High-Effort by Default:** It automatically uses high-effort mapping and
optimization strategies.
* **Integrated Optimizations:** It integrates many powerful features into a
single command:
* **Datapath Optimization:** Recognizes arithmetic structures (adders,
multipliers) and uses specialized datapath cells from the library.
* **Automatic Ungrouping:** Can dissolve hierarchies to optimize logic
across module boundaries.
* **Register Retiming:** Can move registers across combinational logic to
improve the clock speed of the critical path. This is a very powerful timing
optimization.
* **Boundary Optimization:** Optimizes logic at the boundaries between
modules.
* **License Requirement:** Requires the "DC Ultra" or "Design Compiler
Graphical" license.
* **Example Usage:**
```tcl
# The standard, powerful, one-shot compile command
compile_ultra

# A very common and powerful variation


compile_ultra -retime
```

## 4. The Physically-Aware Evolution: Topographical Mode (`-spg`)

For modern process nodes (45nm and smaller), the delay of the wires can be even
more significant than the delay of the gates. Traditional synthesis has a poor
estimate of wire delays, leading to inaccurate timing reports. Topographical mode
fixes this.

* **Purpose/When to Use:**
* Essential for designs in modern, small-geometry process nodes.
* When you need the timing results from synthesis to correlate closely with
the results after place-and-route.

* **Key Characteristics:**
* The `-spg` flag stands for **"Synthesis with Physical Guidance"**.
* It uses physical information (like a floorplan from the layout tool) to get
much more accurate estimations of wire lengths and delays *during* synthesis.
* This results in a netlist that is already "aware" of the physical layout,
leading to much better post-layout timing and fewer iterations between synthesis
and layout.

* **Example Usage:**
```tcl
# Must set this app option before reading the design
set_app_options -name [Link] -value true

# Then, during compilation:


compile_ultra -spg
```

## Summary Table

| Command | Primary Use Case | Key Feature(s) | Relative Runtime |


| :--- | :--- | :--- | :--- |
| **`compile`** | Quick checks, simple blocks, legacy scripts. | Basic 3-step
synthesis. | Fast |
| **`compile -map_effort high`** | When `compile` fails to meet timing. | More
exhaustive search for logic mappings. | Medium-Slow |
| **`compile_ultra`** | **Default for most modern designs.** | Integrates datapath,
retiming, boundary opt. | Slow (but effective) |
| **`compile_ultra -spg`** | **Essential for modern process nodes (<45nm).** |
Physically-aware synthesis, accurate wire delays. | Slowest |

You might also like