[go: up one dir, main page]

0% found this document useful (0 votes)
61 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)
61 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
You are on page 1/ 4

# Synthesis Command Flow (from the PDF)

This flow is typically placed in a Tcl script (e.g., `synthesis.tcl`) 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 compile.flow.spg -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