9 Synthesizing the Design

Following application of the synthesis constraints, we are ready to synthesize the VHDL code into
a physical netlist. All commands I discuss will work with Design Compiler.

REFERENCE much of this material was created using the Synopsys Chip Synthesis Workshop
Student Guide training notes as a guide.

9.1 Checking Constraints

Before you synthesize the VHDL code {literally execute the design compiler {DC}
compile command), it is good practice to check your design constraints. The following DC
commands are useful for doing this.

report_port -verbose to check values specified for: set_load, set_drive, set_input_

delay, set_output_delay.
report_design to check wire loads and operating conditions.
report_constraint to check design rules and optimization goals.
report_clock to verify that the clocks have been defined.
report_attribute -design to list all attributes set on a design.
check_timing to report unconstrained paths.

Once all design constraints have been applied, the VHDL code is ready to be synthesized.
To synthesize the VHDL code, use the compile command as below.
compile map_effort medium

Although we could have specified a low or high map_effort, the first run of synthesis
should always be performed with medium map_effort. Most of the time, this will yield
good results and it is worth the trade off of what could easily be a very long CPU exercise
if map_effort high were specified on the first run.

Also, note, that there are many parameters that may be specified with the compile
command. We will discuss some of the more important ones following. Invoking compile -
help will list all possible parameters.

The result of executing this command will be a structural gate level netlist. We will be
doing this in the labs.

ENGI 9868 ASIC Design

Notes 8: Synthesizing the Design 1 Instructor: Cheng Li
 9.2 Generating Reports
Once the VHDL code has been synthesized, we need to verify that the resulting netlist
satisfies the applied design constraints. We start by focusing on the timing results of the
resulting netlist by generating timing reports using the Synopsys engine DesignTime.

Timing reports have 4 sections:

a) path information section
Provides information about the operating conditions used, the wire load model used,
the start and end points of the timing path, the path group and path type.
b) path delay section
Provides incremental gate/wire delays along the path, clock tree delay (if
applicable), any delay of external logic specified, and the actual data arrival time at
the end point of the path.
c) path required section
Provides clock uncertainty (skew) constraint information, any library related timing
for the standard cell at the end point of the path, and the required data arrival time at
the end point of the path.
d) summary section
The difference between the actual data arrival time and the required data arrival
time i.e. indication whether or not timing has been met, and if so, how much slack
is on the path.

To generate a timing report using Synopsys DesignTime, invoke the following command
(shown with some of the more useful parameters, but not all).
report_timing [-to pin-list] [-from pin-list] [-delay min|max] [-max_paths
max_path_count] [-path short | full | only | end]

The command is commonly used as below.

report_timing -delay max -path end

If the design has no timing constraints, the report_timing command defaults to reporting
timing for the longest path to an output port. If the design does have timing constraints, the
report_timing command defaults to reporting timing for the worst slack in each path
group (i.e. timing domain).

The next page shows an example of executing the command report_timing -delay max -
path end on my implementation of the design project.

ENGI 9868 ASIC Design

Notes 8: Synthesizing the Design 2 Instructor: Cheng Li
****************************************
Report: timing
-path end
-delay max
Design: wclk-domain
Version: 1999.05-4
Date: Fri Sep 27 15:40:11 2002
****************************************
* Some/all delay information is back-annotated.
Operating Conditions: WCCOM Library: cb18os120
Wire Load Model Mode: top

Endpoint Path Delay Path Required Slack

wr-done (out) 2.61 r 2.65 0.04
iready (out) 9.82 r 10.00 0.18
wport-meb (out) 2.07 r 2.65 0.58
wport-web (out) 1.27 r 2.65 1.38
wpointer-addr(l) (out) 1.22 r 2.65 1.43
wpointer-addr(4) (out) 1.19 r 2.65 1.46
wport-data(0) (out) 1.10 r 2.65 1.55
wport-data(8) (out) 1.10 r 2.65 1.55
idata-pipe-inst/idata-s1-reg(0)/D (sdcrq1)
7.35 f 9.28 1.93
idata-pipe-inst/idata-s1-reg(7)/D (sdcrq1}
7.35 f 9.28 1.93
write-sm-inst/ieop-s-reg/D (sdcrq1)
7.35 f 9.28 1.93
write-sm-inst/isop-s-reg/D (sdcrq1)
7.35 f 9.28 1.93
write-sm-inst/ivalid-s-reg/D (sdcrq1)
7.35 f 9.28 1.93
wpointer-inst/count-i-reg(4)/D (sdcrb1)
1.81 f 9.25 7.43
write-sm-inst/state-reg(2)/D (sdcrq1)
1.70 f 9.27 7.57
idatayipe-inst/wport-data-reg(4)/D (sdcrql)
0.99 f 9.13 8.15

ENGI 9868 ASIC Design

Notes 8: Synthesizing the Design 3 Instructor: Cheng Li
write-sm-inst/wpointer-enable-i-reg/D (sdcrb1)
0.84 f 9.26 8.42
write-sm-inst/ieop-s2-reg/D (sdcrq1)
0.51 f 9.25 8.74
idatayipe-inst/idata-s2-reg(0)/D (sdcrq1)
0.44 f 9.28 8.83
idata-pipe-inst/idata-s2-reg(7)/D (sdcrq1)
0.44 f 9.28 8.83
idata-pipe-inst/wport-data-reg(O)/D (sdcrq1)
0.44 f 9.28 8.83
idatayipe-inst/wport-data-reg(7)/D (sdcrq1)
0.44 f 9.28 8.83
write-sm-inst/ieop-s3-reg/D (sdcrq1)
0.44 f 9.28 8.83

9.3 Fixing Hold Time Violations

Once we have synthesized the design VHDL code using worst case operating conditions
and all design rules and optimization constraints are satisfied we need to perform one
additional optimization prior to writing out the netlist.

We need to fix hold time violations. Because hold time violations are usually a result of
logic being too "fast", we switch to best case operating conditions to perform this step.
Further, we perform an "incremental" optimization on the gate level netlist, and only
permit the synthesizer to fix hold time violations without any further logic level
optimizations. To perform fixing of hold time violations, use the commands below.
set_fix_hold find( clock, clock_name)
compile map_effort high prioritize_min_paths only_design_rule -incremental

The prioritize-min-paths parameter treats min-delay and fix-hold as design rule violations,
thereby giving them higher priority.

The only-design-rule parameter takes less time then a regular compile and only design-
rule-fixing gate-level optimization is done.

Alternately, hold time fixing could be done using worst case operating conditions but the
clock uncertainty (skew) would need to be increased by the time delta between best case
and worst case operating conditions.

ENGI 9868 ASIC Design

Notes 8: Synthesizing the Design 4 Instructor: Cheng Li
 Having said that, ALL TIMING (both min and max delays) MUST be verified using
both best case and worst case operating conditions.

I suggest using the latter method for hold time fixing (that being using worst case operating
conditions and increasing the clock uncertainty by an appropriate amount), primarily
because:
a) switching between best case and worst case operating conditions is not as easy as
simply invoking a single command the operating conditions are specified in
the .synopsys_dc.setup file. And although vendors have tried to combine best case
and worst case operating conditions into a single environment to simplify hold time
fixing, it hasn't worked well in practice.

b) Based on my experience, I have found that switching to best case operating

conditions to perform hold time fixing does not yield significantly better results
than performing the hold time fixing using worst case operating conditions with a
higher clock uncertainty. In fact, when fixing hold time violations using best case
operating conditions, further timing checks using worst case operating conditions
yield failures in setup times. Yet fixing hold time violations using worst case
operating conditions, and then performing best case hold time checking, succeeds.

When fixing hold times, ALWAYS, ALWAYS, ALWAYS pay attention to any gate count
explosions. If the gate counts rockets, then chances are you were overly pessimistic in your
design constraints check them. The more buffers you insert into your circuit, the more
interconnect there is, and the greater the risk that there will a significant variance between
pre-layout timing results and post-layout timing results.

Final note. No hold time violation fixing should be done until AFTER scan logic is inserted.
Often, simply inserting scan logic (essentially replacing FFs with muxed FFs) fixes what
would have otherwise been hold time violations.

9.4 The Cost Function design rule constraints vs. optimization constraints

All design rule constraint and optimization constraint fixing has an associated cost cost in
terms of die area, synthesis time, etc.

We define two cost functions.

ENGI 9868 ASIC Design

Notes 8: Synthesizing the Design 5 Instructor: Cheng Li
 a) Design Rule Constraint (DRC) cost function
COSTDRC = COSTMAX-FANOUT + COSTMAX-TRANSITION+ COSTMAX-CAPACITANCE

b) Optimization Constraint cost function

COST OPTIMIZATION = COST MAX-DELAY+ COST MIN-DELAY+ COST MAX-AREA

Costs are computed on the basis of the difference between the actual and target constraints.

Design Compiler attempts to reduce both cost functions to zero. However, under no
circumstances will DRCs be violated, even if it means violating an optimization constraint.
The order of priority in which DC orders the cost functions and associated constraints
during synthesis is:
a) DRCs
b) MAX Delay
c) MIN Delay
d) MAX Area

Optimization stops when both cost functions reach zero, or when the DRC cost function is
zero and DC reaches a point of diminishing returns to further optimize.

9.5 Dealing with multiple instances of the same design block

When ever you have multiple instances of the same design, you must use one of the
following three methods to resolve the multiple instances. In relation to the design project,
an example of this would be instantiation of a generic 5-bit counter for both the write
pointer and the read pointer and some of you have done this and will need to resolve the
multiple instances of that same design.

a) UNIQUIFY
Makes unique copy of reference design for each instance.
Each cell is mapped to its own environment.
Likely, netlist for each referenced design component will be different.
DC will give each instance a unique instance name => likely, something like
instance-name-0, instance-name-l, etc.
b) SET-DONT-TOUCH
First, synthesize the design that will be instantiated multiple times.

ENGI 9868 ASIC Design

Notes 8: Synthesizing the Design 6 Instructor: Cheng Li
 Invoke the SET-DONT-TOUCH attribute on the design object (reference, design or
cell) this prevents DC from further optimizing the "don't touched" design object,
and each of the instantiated designs will have identical netlists.
To list all "don't touched" designs, use the command filter find(design "* -
hierarchy) "@dont_touch = true".
It is best to set_dont_touch on the design itself, not the instance name. This will
ensure that all instances of the design will be "don't touched".
c) Modify the Hierarchy
If you change the hierarchy to eliminate multiple instances of the same design, you
no longer have a resolution of multiple instances issue. To do this, use the
command:
group -design new_block_name {instance1 , instance2, etc}
ungroup {instance1, instance2, etc}
The resulting netlist may have a different hierarchy than the VHDL code, and this
may make debugging simulations or auditing the design more difficult.

Use set_dont_touch when the design environments are the same (this is usually the case, since
the designs will be fabricated in the same ASIC).

Use uniquify when the design environments vary significantly.

Uniquify takes more memory and CPU time than set_dont_touch. The ungroup command uses
more memory and CPU time than uniquify and set-dont-touch.

My recommendation is to use set-dont-touch when ever possible. While is OK to modify the

hierarchy, sometimes the resulting hierarchical differences between the netlist and VHDL code
aren't worth it. Try to avoid uniquify, as it will create two different netlists out of identical logic,
and sometimes this can bite you when one instance has timing problems and the other instance(s)
do not.

ENGI 9868 ASIC Design

Notes 8: Synthesizing the Design 7 Instructor: Cheng Li