An Introduction to Synthesis and Timing Analysis

A Note on Directory Structures

In your specific IT environment, we will assume your root working directory is called “/home”. /home is a
placeholder – replace it with the complete path to your root working directory. Underneath this, we will
have the following directory structure:
/home/tech: all standard cell libraries will be stored here
/home/design: all design files (netlists, etc.) will be stored here. Also, all runs will be fired from
subdirectories in /home/design.

In synthesis, we generate a logic circuit from a behavioral description. The behavioral description is in
the form of Verilog code. The logic circuit is generated using logic gates from a specified standard cell
library. This logic circuit, also called a gate-level netlist, is also in Verilog format.

In this learning module:

1. You will understand the difference between behavioral code and gate-level netlist
2. You will manually create a gate level netlist from behavioral code
3. You will synthesize the behavioral code and compare the generated circuit to the circuit you
manually created.
4. You will learn to use the Genus synthesis tool
5. You will use the Tempus static timing analysis tool to explore the timing characteristics of the
generated circuit.

Let us start by designing and analyzing an ultrasimple piece of logic. A plain English behavioral
description of the logic is as follows:
1. The circuit (we’ll call is “sel_sense”) has one output, B, and two inputs, A and S
2. The output B is equal to the input A if S = 0 or is equal to the inverse of input A if S = 1.

Behavioral Verilog code for this logic is quite simple:

module sel_sense (A, S, B);

input A, S;
output B;
assign B = S ? A : ~A
endmodule;

An alternative behavioral model for the same logic is:

module sel_sense (A, S, B);

input A, S;
output B;
reg B;
always @(*) begin
case(S)
1'b0 : B = A;
1'b1 : B = ~A;
endcase
 end
endmodule

Submissions:
(i) Draw a schematic of a circuit that implements sel_sense. Your schematic must involve gates
like NAND2, NOR2, MUX, INVERTER, XOR, NAND, etc. Choose whichever gates you like to
implement the logic. Do not make a truth-table; draw a schematic based only on your
understanding of the logic.
(ii) Now write a truth table for the circuit. Based on your truth-table, if you would like to make
an alternative schematic for the circuit, please do so.

Synthesis

Now let’s synthesize the circuit with Genus.

First, set the mode to “common_ui”:

genus> set_db common_ui false

(A) Read the behavioral code

genus> read_hdl -v2001 /home/anandb/ultralite/design/example/sel_sense.v

(B) Read the standard cell library

genus> set_attribute library <path to dotlib>
For synthesis, always use the “slow” library, i.e. the dotlib with the highest delays. This
ensures that the synthesis tool produces logic that can meet the target clock frequencies or
maximum delays. Once the library is read, you can use the “check_library” command to get
information on important features of the library:
genus> check_library

(C) Elaboration
The first step in synthesis is called “elaboration”. In this step, the synthesis tool (Genus) converts
the behavioral code into a logic circuit using in-built logic components, not standard cells. For
elaboration, a standard cell library is not required. The in-built logic components are simple logic
gates like two-input NAND and NOR gates, muxes, D flip-flops, etc. You can see the results of
elaborate by writing out the resulting netlist using the “write_hdl” command (the netlist is in
Verilog format). For the elaborate command, you need to tell Genus which module to elaborate.
Since our design is not hierarchical and we have only a single module in the behavioral code
(“sel_sense”), you will ask Genus to elaborate “sel_sense”:
genus> elaborate sel_sense
genus> write_hdl
You should see the following netlist being written out:
// Generated by Cadence Genus(TM) Synthesis Solution 18.11-s009_1
// Generated on: May 29 2020 16:51:09 IST (May 29 2020 11:21:09 UTC)
// Verification Directory fv/sel_sense

module bmux(ctl, in_0, in_1, z);

 input ctl, in_0, in_1;
output z;
wire ctl, in_0, in_1;
wire z;
CDN_bmux2 g1(.sel0 (ctl), .data0 (in_0), .data1 (in_1), .z (z));
endmodule

module sel_sense(A, S, B);

input A, S;
output B;
wire A, S;
wire B;
wire n_3;
bmux mux_5_17(.ctl (S), .in_0 (n_3), .in_1 (A), .z (B));
not g1 (n_3, A);
endmodule
In this netlist, two gates are instantiated: CDN_bmux2 and not (marked in red). These are internal gates
that are coded in the Genus software – they are not actual gates in the standard cell library. To
implement the logic with its built-in gates, Genus has used a two-input mux and has inverted the A input
before it goes to the mux.

(D) Synthesis
In this step, synthesis is accomplished with the use of “generic” logic cells, also called “g-cells”.
These cells are part of the synthesis software tool. They are not cells from the standard cell
library.
genus> syn_gen
genus> write_hdl
module sel_sense(A, S, B);
input A, S;
output B;
wire A, S;
wire B;
wire n_5, n_6;
nand g4 (n_5, A, S);
or g5 (n_6, A, S);
nand g6 (B, n_5, n_6);
endmodule

(E) Map design to the library: in this step, Genus creates a first-cut netlist using actual logic gates
from the standard cell library. Run the mapping command (“syn_map”) and then write out the
Verilog gate-level netlist (“write_hdl”) to see what type of netlist Genus has generated:
genus> syn_map
genus> write_hdl
module sel_sense(A, S, B);
input A, S;
output B;
wire A, S;
 wire B;
wire n_0, n_1;
XNOR2XL g17__8780 (.A (n_1), .B (n_0), .Y (B));
INVXL g18 (.A (S), .Y (n_1));
INVXL g19(.A (A), .Y (n_0));
endmodule

(F) Finally, we optimize the netlist:

genus> syn_opt

Use the write_hdl command again, and copy the resulting netlist in your submission sheet
(submission iii).
genus> write_hdl
module sel_sense(A, S, B);
input A, S;
output B;
wire A, S;
wire B;
XNOR2X4 g2(.A (S), .B (A), .Y (B));
endmodule

The optimization step will try to minimize area while meeting any delay or timing targets. If no delay or
timing target is specified, Genus will simply minimize area when generating a netlist.

The optimized netlist produced above has an XNOR2X4 cell. The standard cell library has XNOR2X1,
XNOR2X2 and XNOR2X4 cells, but Genus selected XNOR2X4. When we look at the dotlib, we find that
the area for all the standard cells is set to 0:

* Design : XNOR2X4 *
* ---------------- */
cell (XNOR2X4) {
area : 0.0;

Since the area for all cells is zero, and there are no target delays specified during the synthesis, Genus
may have simply chosen the cell with the least delays in the dotlib. Generate a report using the tag
“noArea” in a directory called REPORTS and you will see zero area being reported in the file
“noArea_gates.rpt”:

genus> generate_report -outdir REPORTS -tag noArea

Since the area of cells is not specified in the dotlib, we need to provide this information to Genus in
some other way. We do this by having Genus read the standard cell LEF file. The LEF data includes area.
Rerun Genus, and immediately after setting the “library” attribute (step B above), specify the LEF file to
be read:

genus> set_attr lef_library ~/ultralite/tech/Cadence_RAKs/RAK_18.1_blockImplementation/LIBS/lef/gsclib045.fixed2.lef

Now complete the remaining steps as above and check the final netlist. What difference do you see?
Generate a report in the REPORTS directory with the tag “withArea” and indicate what area is reported.

Questions:

(i) Does the dotlib of the Nangate standard cell library contain cell area?
(ii) If the dotlib contains the cell area, synthesize sel_sense with this library without reading the
LEF file, and report the drive strength of the cell in the synthesized netlist. Is it the lowest,
highest or intermediate drive strength?
(iii) Generate reports with the tag “Nangate” and report the cell area the tool indicates in the
report.

Circuit Optimization for Timing

A synthesis tool optimizes the final netlist for both area and timing. It meets timing requirements with
minimum standard cell area. In Genus, the optimization happens when we run “syn_opt”.

So far, we have not specified any timing requirements, so Genus has selected the XOR gate with
minimum area. Let’s see how things change when we specify some timing requirements.

We will specify a maximum delay from input A to output B as a timing requirement. We expect Genus to
use the XOR gate with the minimum area that meets this requirement. Read the behavioral code and
library, including the LEF file, and synthesize the netlist all the way through syn_opt. Then specify a
maximum delay requirement of 7 ns using the “set_max_delay” constraint:
genus> set_max_delay -from A -to B 7

Genus needs to calculate the delay of the XOR cell to select the cell with the minimum area that meets
the above timing specification. But cell delay depends on input transition time and output load
capacitance. These will need to be specified:
genus> set_input_transition 0.04 [get_ports A]
genus> set_load 0.08 [get_ports B]

After this report the timing from A to B:

genus> report_timing -from A -to B

Checking Circuit Timing

The netlist we have created for sel_sense contains only one instance: an XOR gate. The primary inputs (A
and S) and the primary output (B) are directly connected to this instance. Let’s check the timing of this
very simple circuit. To do this, you need to read this circuit into Tempus.
Run the following commands sequentially in Tempus and record the cell delay and output transition
times in the table below.

(A) Read the dotlib of the standard cell library:

tempus> read_lib /home/anandb/ultralite/tech/Cadence_RAKs/RAK_18.1_blockImplementation/LIBS/lib/max/slow.lib

tempus> set_global timing_apply_default_primary_input_assertion false

(B) Read the Verilog netlist and define the top level module:
tempus> read_verilog /home/anandb/ultralite/design/example/OUTPUTS_ALT/sel_sense_FINAL.v
tempus>set_top_module sel_sense

(C) Next we constrain the circuit by specifying a maximum delay from the A input to the B output. To
do this, we use the “set_max_delay” command:

tempus> set_max_delay 0.5 -from A -to B

What we have done with the set_max_delay command is to indicate that the maximum delay from A to
B should be no more than 0.5 ns. Such a stipulation is called a “timing constraint”. In timing analysis,
individual delays in a circuit are added up, and the sum checked against the relevant timing constraint. If
the constraint is a “max” constraint (like “max delay” in our case), the sum should be less than the
constraint value. If the constraint is a “min” constraint, the sum should be more that the constraint
value.

Now, the delay from A to B through the XOR gate depends on the following factors:
(i) Capacitive load driven by the XOR gate
(ii) Transition time at the input A
(iii) Logic value (0 or 1) at S (delay from an input of the XOR gate to its output could depend on
the whether the other input is 0 or 1).

tempus> set_load 0.08 [get_ports B]

tempus> set_input_transition 0.04 [get_ports A]
tempus> set_case_analysis 0 S
tempus> set_global report_precision 6
tempus> report_timing -format {instance arc delay arrival slew load} -from A -fall_to B
tempus> report_timing -format {instance arc delay arrival slew load} -from A -rise_to B
tempus> set_case_analysis 1 S
tempus> report_timing -format {instance arc delay arrival slew load} -from A -rise_to B
tempus> report_timing -format {instance arc delay arrival slew load} -from A -fall_to B
Case Transitio Capaciti Rise Delay (A Rise Fall Delay (A Fall Transition Slac
Valu n time ve load to B) Transition to B) Time k
e at at A at B time
S (rise or
fall) In Temp In Temp In Temp In Tempu
dotli us dotli us dotli us dotli s
b b b b

0 0.04 0.08

0.15

1 0.04 0.08

0.15

Synthesizing a Sequential Circuit: MCRB

Next we will synthesize a sequential circuit, “mcrb”. The RTL file is “mcrb.v”. Peruse this RTL file and
answer the following questions:

(i) How many inputs and how many outputs does this circuit have?
(ii) Which is the clock input?
(iii) How many D-flipflops do you expect to see in the netlist?

When synthesizing a sequential circuit, in addition to the RTL, you need to specify the clocks. This is
done using a standard format call “SDC”. SDC stands for “Synopsys Design Constraints”. It’s a format
created by the electronic design automation (EDA) company Synopsys, but is now widely adopted for
many EDA tools.

mcrb has only one clock, and the clock input is the port “mc_rb_ef1_sclk_i”. The clock is specified using
the “create_clock” command. With this command, you specify the source of the clock (the
“mc_rb_ef1_sclk_i” input pin in the case of mcrb) and the clock period. Other clock attributes can also
be specified, but these two are the bare minimum. The clock can be given a name of your choice. We
will call the clock “sclk”. The following is the complete clock specification:

create_clock -period 5 [get_port mc_rb_ef1_sclk_i] -name sclk

Among the other clock attributes that may be specified is the “duty cycle” (see Fig. xx). If the duty cycle
is not specified, then the default value is 50%. The duty cycle is important if there are timing paths
between rising-edge flip-flops and falling-edge flip-flops, or vice versa.
When a clock is properly defined, the paths between flip-flops are constrained. However, for paths from
inputs to flip-flops, or from flip-flops to outputs, timing has to be differently specified. You need to
specify when valid data will be available at the input, and when valid data is expected at the output.
These timing attributes are specified with the set_input_delay and set_output_delay commands
respectively.

Suppose the inputs arrive no later than 0.5 ns before the clock edge. To specify this, we create a
collection of all inputs except the clock input, and specify an “input_delay” of 0.5 ns w.r.t the clock “sclk”
(which happens to be the only clock in mcrb):

set_input_delay 0.5 -clock [get_clock sclk] [remove_from_collection [all_inputs] [get_port

mc_rb_ef1_sclk_i]]

The sdc file for mcrb is “mcrb.sdc”. It contains clock definition, input delay specifications and output
delay specifications. Let us use this SDC file to synthesize the logic described in mcrb.v. Go through the
same set of steps as you did when synthesizing sel_sense, except that before running syn_opt, read the
sdc with the following command:
genus>

Assignment: Alcazar

Debugging and fixing errors in design data is a critical skill you must develop. To debug effectively, you
must use unix utilities to quickly sort through and analyze large log files and error reports.

EDA tools usually list ERRORs and WARNINGs in log files. ERRORs cause the tool to abort the run;
WARNINGs are for issues the tool can ignore or bypass, but they may produce bad results. WARNINGs
must be reviewed and, if necessary, fixed. You should always review logfiles for warning messages. Since
log files may be long with lots of other content, grep for “error” and “warning” (use “-i” to make grep
case insensitive).

In this assignment, you are given a netlist, alcazar.v, which has errors that cause Tempus to abort and
exit. Fortunately for you, Tempus reports the errors in a log file. Your job is to find these errors in the log
file (use “grep”), debug the errors and fix the netlist. (Hint: you may need to look at the standard cell
library dotlib or LEF files to do this debug). Do not fix the netlist by editing line after incorrect line in a
text editor like vi. Instead, use a unix utility like command-line perl to do the substitution.

Note that alcazar uses standard cells from the Cadence RAK standard cell library. The SDC is alcazar.sdc.
Read the netlist and SDC in Tempus, then debug and fix the errors Tempus reports. Rerun Tempus and
generate a timing report for the error-free netlist.

Submit a report with the following:

(i) Summary of the errors causing Tempus to abort: explain the error
 (ii) How did you debug the error, and what was the fix you came up with? In your report,
reproduce any pipelined unix command that you used to implement the fix.
(iii) In a Tempus session with the fixed netlist, report:
a. Count of inputs and outputs
b. Total number of flip-flops
c. Count of flip-flops not receiving clock
d. Count of flip-flops with unconstrained timing to the D pin

Fixing alacazar.sdc

(a) Determine the cause(s) of paths to D pins of some flip-flops being unconstrained
(b) What other endpoints are unconstrained and why?
(c) Update the SDC to resolve these unconstrained. Use any reasonable value for any parameters
you need for your SDC update.

Assignment: CPU_SYS

(!) Generate a list of instance names and memory types of all memories in the netlist
Ans:
foreach_in_collection mem [remove_from_collection [all_registers] [all_registers -flops]] {
set memname [get_object_name $mem]
set llc [get_property [get_cells $memname] ref_name]
puts "$memname $llc"
}

(2) How many ports does the memory rf_2p_512d_76w_2m_4b have?

How many instances of this memory are present in the netlist?
How many words, and how many address bits, does this memory have?
How many bits are there in each word?
In each instance, how many bits of each word are actually used (written and read)? How did you know?
How would you change this memory to optimize the netlist, if the minimum width of a memory is 40
bits? Modify the netlist to make this change, and submit only the lines modified.

Ans:
2 ports
4 instances
512 words, 9 address bits
Only 68 bits of each word are used. The 8 most significant bits are not used, with DA[75:68] tied to
ground and QB{75:68] unconnected.
Change memory to rf_2p_512d_68w_4b.

(3) List all the startpoints (and their type) to the CENA pin of
“U_emep_top/i_pcie4_rxbuf/rx_buf_x16_x16_U_pcie_ip_rx_buf_0_”

Ans:
foreach_in_collection fa [all_fanin -startpoints_only -to
U_emep_top/i_pcie4_rxbuf/rx_buf_x16_x16_U_pcie_ip_rx_buf_0_/CENA] {
set sp [get_object_name $fa]
set llc [get_property [get_cells -of_objects $fa] ref_name]
puts "$sp $llc"
}

CLKA-to-CLKB (and CLKB-to-CLKA) Timing Checks in Two-Port Memories

Disabling The Timing Check:

genus> set_disable_timing [get_lib_cells rf_2p_*] -from CLKB -to CLKA

Inferred Clock Gating Check

Report timing from any Q pin of the memory instace

“U_emep_top/i_pcie4_rxbuf/rx_buf_x16_x16_U_pcie_ip_rx_buf_0_”:
genus> report_timing -from U_emep_top/i_pcie4_rxbuf/rx_buf_x16_x16_U_pcie_ip_rx_buf_0_/Q*

You will find the endpoint is a pin of a combinational cell, and a “clock gating” timing violation is
reported:

What this means is that one of the inputs of the NAND4X2 combinational cell is a clock, and Tempus is
checking that the output of the cell does not have a glitch. A glitch on the output can create an incorrect
clock edge at a flip-flop.

In general, such combinational cells on the clock path are not good design practice, and you must report
them to the logic designer. However, in our case, we find that the output of the combinational cell does
not go to any flip-flops, but only to output pins:
genus> all_fanout -endpoints_only -from U_cpu_sys_top/U114/Y

After sending a report to the logic designer, let us disable these inferred clock gating checks. Our
assumption is that the logic designer has ensured there will be no problems in the logic due to a clock
going through a combinational cell.
genus> set timing_disable_inferred_clock_gating_checks true

**** Interesting Info: line in switch_cell synthesis ******************************

Replacing a flip-flop with a logic constant 0. [GLO-12]
: The instance is 'rx_sl6_top/rx_interface_p0/swp_sram_ctrl_if_0/rddata_reg[23]