Skip to content

Vishakha7501/Sky-130-RTL-Design-and-Synthesis-Workshop-using-Verilog

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

90 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

RTL Design and Synthesis in Verilog using Sky130 Technology

VSD_Workshop_Detail

Table of Contents

Introduction

The report is based on 5-day RTL Design and Synthesis in Verilog using the SKY130 Technolog workshop facilitated by VSD on using open source tools involving iVerilog, GTKWave, Yosys with Sky130 technology.
This workshop introduces to the digital logic design using Verilog HDL. Validating the functionality of the design using Functional Simulation. Writing Test Benches to validate the functionality of the RTL design .Logic synthesis of the Functional RTL Code. Gate Level Simulation of the Synthesized Netlist.

SKY130 is the hardware industry's first open-source process design kit (PDK) released by SkyWater Technology Foundry in collaboration with Google giving all hardware design experts and aficionados, a worldwide access to their IP functions and open source ASICs.


1. Day 1 - Introduction to Verilog RTL design and Synthesis

1.1. Introduction to open source simulator iverilog

In the digital circuit design, register-transfer level (RTL) is a design abstraction which models a synchronous digital circuit in terms of the data flow between hardware register, and the logical operations performed on those signals. RTL abstraction is used in HDL to create high-level representations of a circuit, from which lower-level representations and ultimately actual wiring can be derived.

Simulator: It is a tool which is used for checking the design. In this workshop we are using iverilog tool.Simulation is the process of creating models that mimic the behavior of the device you are designing (simulation models) and creating models to exercise the device (test benches). RTL Design: It consists of an actual verilog code / a set of verilog codes that have the functionality to meet the required design specifications of the circuit.

Test Bench: It is the setup to apply stimulus(test vectors) to design to checks its functionality.

HOW SIMULATOR WORKS

Simulator looks for changes on input signals and based on that output is evaluated.

test bench

Design may have 1 or more primary inputs and primary outputs but TB doesn't have.)

SIMULATION FLOW

iverilog based

Simulator continuously checks for changes in the input. If there is an input change, the output is evaluated; else the simulator will never evaluate the output.

1.2. Labs using iverilog & gtkwave

ENVIRONMENT SETUP

//create a directory
$ mkdir VLSI 
//Git Clone vsdflow. 
$ git clone https://github.com/kunalg123/vsdflow.git
//Git Clone sky130RTLDesignAndSynthesisWorkshop. 
$ git clone https://github.com/kunalg123/sky130RTLDesignAndSynthesisWorkshop.git

Screenshot (130)

sky130RTLDesignAndSynthesisWorkshop Directory has: My_Lib - which contains all the necessary library files; where lib has the standard cell libraries to be used in synthesis and verilog_model with all standard cell verilog models for the standard cells present in the lib. Ther verilog_files folder contains all the experiments for lab sessions including both verilog code and test bench codes.

We are given a default set of files and libraries shown below to work on using the practical lab instance.

Screenshot (134)

Simulation using iverilog simulator - 2:1 multiplexer rtl design

VERILOG FILE OF A SIMPLE 2:1 MUX

Screenshot (135)

GTKWAVE Analysis

Access Module Files

$ gvim tb_good_mux.v -o good_mux.v 

Screen Shot 2021-09-02 at 12 23 28 AM

1.3. Introduction to Yosys & Logic Synthesis

Synthesizer is a tool for converting the RTL to Netlist and here we are using the Yosys Synthesizer.

Yosys SETUP

Yosys

verify the synthesis

Logic Synthesis

RTL Design - behavioral representation in HDL form for the required specification.

Synthesis - RTL to Gate level translation. The design is converted int gates and connections are made. This given outas a file called netlist.

.lib file is a collection of logical modules which includes all basic logic gates. It may also contain different flavors of the same gate (2 input AND, 3 input AND – slow, medium and fast version).

Faster cells and Slower Cells

A cell delay in the digital logic circuit depends on the load of the circuit which here is Capacitance.

Faster the charging / discharging of the capacitance --> Lesser is the Cell Delay

Inorder to charge/discharge the capacitance faster, we use wider transistors that can source more current. This will help us reduce the cell delay but at the same time, wider transistors consumer more power and area. Similarly, using narrower transistors help in reduced area and power but the circuit will have a higher cell delay. Hence, we have to compromise on area and power if we are to design a circuit with low cell delay.

Constraints

A Constraint is a guidance file given to a synthesizer inorder to enable an optimum implementation of the logic circuit by selecting the appropriate flavour of cells (fast or slow).

1.4. Labs using Yosys and Sky130 PDKs

Steps for Design Synthesis

Screen Shot 2021-09-02 at 12 16 52 AM

Inference from Synthesis and Execution of netlist generation

Screenshot (151)

Synthesis by using show command

Screenshot (153)

Writing Netlist

Screenshot (157)


2. Day 2 - Timing Libs, Hierarchial Vs Flat Synthesis and Efficient Flop Coding Styles

2.1. Introduction to timing labs

__Command to open the libary file
$ gvim ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
__To shut off the background colors/ syntax off:
: syn off
__To enable the line numbers
: se nu

Library file

Screenshot (150)

Contents

For a design to work, there are three important parameters that determines how the Silicon works: Process (Variations due to Fabrications), Voltage (Changes in the behavior of the circuit) and Temperature (Sensitivity of semiconductors). Libraries are characterized to model these variations.

Screenshot (162)

Various Flavours of AND Cell

Screenshot (163)

2.2. Hierarchial synthesis vs Flat synthesis

Hierarchial synthesis

_Opening the file used for this experiment
$ gvim multiple_modules.v
_Invoke Yosys
$ yosys
_Read library 
$ read_liberty -lib ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
_Read Design
$ read_verilog multiple_modules.v
_Synthesize Design
$ synth -top multiple_modules
_Generate Netlist
$ abc -liberty ../my_lib/lib/sky130_fd_sc_hd__t_025C_1v80.lib
_Realizing Graphical Version of Logic for multiple modules
$ show multiple_modules
_Writing the netlist in a crisp manner 
$ write_verilog -noattr multiple_modules_hier.v
$ !gvim multiple_modules_hier.v

Multiple Modules: - 2 SubModules Staistics of Multiple Modules

Screenshot (165)

Realization of the Logic

Screen Shot 2021-09-02 at 5 12 46 PM

Netlist file

Screenshot (168)

Flat synthesis

_To flatten the netlist
$ flatten
_Writing the netlist in a crisp manner and to view it
$ write_verilog -noattr multiple_modules_flat.v
$ !gvim multiple_modules_flat.v

Realization of the Logic

Screen Shot 2021-09-02 at 6 14 16 PM

Netlist file

Screenshot (169)

SUB MODULE LEVEL SYNTHESIS

Sub-module level synthesis is preferred when there are multiple instances of same module. Sythesizing the same module over several times may not be advantageous with respect to time. Instead, synthsis can be performed for one module, its netlist can be replicated and then stitched together in the top module. This is also used particulary in massive designs using divide and conquer method.

Statistics of Sub-module

Screen Shot 2021-09-02 at 9 11 28 PM

Graphical Realization of the Logic

Screen Shot 2021-09-02 at 9 12 18 PM

NetList File of Sub-module

Screen Shot 2021-09-02 at 9 13 33 PM

2.3. Various Flop coding styles and optimization

In a digital design, when an input signal changes state, the output changes after a propogation delay. All logic gates add some delay to singals. These delays cause expected and unwanted transitions in the output, called as Glitches where the output value is momentarily different from the expected value. An increased delay in one path can cause glitch when those signals are combined at the output gate. In short, more combinational circuits lead to more glitchy outputs that will not settle down with the output value.

Flip flop overview

A D flip-flop is a sequential element that follows the input pin d at the clock's given edge. D flip-flop is a fundamental component in digital logic circuits. There are two types of D Flip-Flops being implemented: Rising-Edge D Flip Flop and Falling-Edge D Flip Flop.

fe verilog-d-flip-flop

Every flop element needs an initial state, else the combinational circuit will evaluate to a garbage value. In order to achieve this, there are control pins in the flop namely: Set and Reset which can either be Synchronous or Asynchronous.

Asynchronous Reset/Set:

Aset

Aset2

_ Here, always block gets evaluated when there is a change in the clock or change in the set/reset.The circuit is sensitive to positive edge of the clock. Upon the signal going low/high depending on reset or set control, singal q line goes changes respectively. Hence, it does not wait for the positive edge of the clock and happens irrespective of the clock_.

Synchronous Reset:

syn 1

Both Synchronous and Asynchronous Reset:

both

FLIP FLOP SIMULATION

#Steps Followed for analysing Asynchronous behavior:
//Load the design in iVerilog by giving the verilog and testbench file names
$ iverilog dff_asyncres.v tb_dff_asyncres.v 
//List so as to ensure that it has been added to the simulator
$ ls
//To dump the VCD file
$ ./a.out
//To load the VCD file in GTKwaveform
$ gtkwave tb_dff_asyncres.vcd

GTK WAVE OF ASYNCHRONOUS RESET

Screenshot (181)

FLIP FLOP SYNTHESIS

_Invoke Yosys
$ yosys
_Read library 
$ read_liberty -lib ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
_Read Design
$ read_verilog dff_asyncres.v
_Synthesize Design - this controls which module to synthesize
$ synth -top dff_asyncres
_There will be a separate flop library under a standard library
_But here we point back to the same library and tool looks only for DFF instead of all cells
$ dfflibmap -liberty ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
_Generate Netlist
$ abc -liberty ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
_Realizing Graphical Version of Logic for single modules
$ show 
_Writing the netlist in a crisp manner 
$ write_verilog -noattr dff_asyncres_ff.v
$ !gvim dff_asyncres_ff.v

Statistics of D FLipflop with Asynchronous Reset

Screenshot (185)

Realization of Logic

Screenshot (187)

Statistics of D FLipflop with Asynchronous set

Screenshot (188)

Realization of Logic

Screenshot (189)

Statistics of D FLipflop with Synchronous Reset

Screenshot (190)

Realization of Logic

Screenshot (191)

Interesting Optimizations

modules used are opened using the command
$ gvim mult_*.v -o
_Invoke Yosys
$ yosys
_Read library 
$ read_liberty -lib ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
_Read Design
$ read_verilog mult_2.v
_Synthesize Design - this controls which module to synthesize
$ synth -top mul2
_Generate Netlist
$ abc -liberty ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
_Realizing Graphical Version of Logic for single modules
$ show 
_Writing the netlist in a crisp manner 
$ write_verilog -noattr mult_2.v
$ !gvim mult_2.v

(i) mult_2.v

Expected Logic

Screenshot (195)

Statistics & abc command return due to absence of standard cell library

Screenshot (196)

No hardware requirements - No # of memories, memory bites, processes and cells. Number of cells inferred is 0.

NetList File of Sub-module

Screenshot (198)

Realization of Logic

Screenshot (197)

(ii) mult_8.v

Expected Logic

Screenshot (194)

Screen Shot 2021-09-04 at 4 19 20 AM

_Statistics _

Screenshot (199)

NetList File of Sub-module

Screenshot (202)

Realization of Logic

Screenshot (200)


3. Day 3 - Combinational and Sequential Optimizations

Logic Circuits Combinational circuits are defined as the time independent circuits which do not depends upon previous inputs to generate any output are termed as combinational circuits. Sequential circuits are those which are dependent on clock cycles and depends on present as well as past inputs to generate any output.

3.1. Introduction to Logic Optimizations

Combinational Logic Optimization

Why do we need Combinational Logic Optimizations?

  • Primarily to squeeze the logic to get the most optimized design.
    • An optimized design results in comprehensive Area and Power saving.

Types of Combinational Optimizations

  • Constant Propagation
    • Direct Optimization technique
  • Boolean Logic Optimization.
    • Karnaugh map
    • Quine Mckluskey

CONSTANT PROPAGATION

In Constant propagation techniques, inputs that are no way related or affecting the changes in the output are ignored/optimized to simplify the combination logic thereby saving area and power usage by those input pins.

Y =((AB)+ C)'
If A = 0
Y =((0)+ C)' = C'

BOOLEAN LOGIC OPTIMIZATION

Boolean logic optimization is nothing simplifying a complex boolean expression into a simplified expression by utilizing the laws of boolean logic algebra.

assign y = a?(b?c:(c?a:0)):(!c)

above is simplified as

y = a'c' + a(bc + b'ca) 
y = a'c' + abc + ab'c 
y = a'c' + ac(b+b') 
y = a'c' + ac
y = a xor c

Sequential Logic Optimization

Types of Sequential Optimizations

  • Basic Technique
    • Sequential Constant Propagation
  • Advanced Technique
    • State Optimization
    • Retiming
    • Sequential Logic cloning(Floorplan aware synthesis)

COMBINATIONAL LOGIC OPTIMIZATION

//to view all optimization files
$ ls *opt_check*
//Invoke Yosys
$ yosys
//Read library 
$ read_liberty -lib ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
//Read Design
$ read_verilog opt_check.v
//Synthesize Design - this controls which module to synthesize
$ synth -top opt_check
//To perform constant propogation optimization
$ opt_clean -purge
//Generate Netlist
$ abc -liberty ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
//Realizing Graphical Version of Logic for single modules
$ show 

Screenshot (203)

(i)opt_check.v

Expected logic from verilog file

13

value of y depends on a, y = ab.

Command for constant propogation method

2

Realization of the Logic

Screenshot (206)

optimized graphical realization thus shows a 2-input AND gate being implemented.

(ii) opt_check2.v

Expected logic from verilog file

opt check 2 mo

value of y depends on a, y = a+b.

Realization of the Logic

Screenshot (208)

optimized graphical realization thus shows 2-input OR gate being implemented. Although OR gate can be realized using NOR, it can lead to having stacked PMOS configuration which is not a design recommendation. So the OR gate is realized using NAND and NOT gates (which has stacked NMOS configuration).

(iii) opt_check3.v

Expected logic from verilog file

opt check 3 mo

value of y depends on a, y = abc.

Realization of the Logic Screenshot (209)

optimized graphical realization thus shows 3-input AND gate being implemented.

(iv) opt_check4.v

Expected logic from verilog file

opt check 4 mo

The value of y depends on a, y = a'c + ac

Realization of the Logic

opt check 4

optimized graphical realization thus shows A XNOR C gate being implemented.

SEQUENTIAL LOGIC OPTIMIZATION

//To view all optimization files
$ ls *df*const*
//To open multiple files 
$ dff_const1.v -o dff_const2.v
//Performing Simulation
//Load the design in iVerilog by giving the verilog and testbench file names
$ iverilog dff_const1.v tb_dff_const1.v 
//To dump the VCD file
$ ./a.out
//To load the VCD file in GTKwaveform
$ gtkwave tb_dff_const1.vcd
//Performing Synthesis
//Invoke Yosys 
$ yosys
//Read library 
$ read_liberty -lib ../my_lib/lib/sky130_fd_sc_hd_-tt_025C_1v80.lib
//Read Design
$ read_verilog dff_const1.v
//Synthesize Design - this controls which module to synthesize
$ synth -top dff_const1
//There will be a separate flop library under a standard library
//so we need to tell the design where to specifically pick up the DFF
//But here we point back to the same library and tool looks only for DFF instead of all cells
$ dfflibmap -liberty ../my_lib/lib/sky130_fd_sc_hd_-tt_025C_1v80.lib
//Generate Netlist
$ abc -liberty ../my_lib/lib/sky130_fd_sc_hd_-tt_025C_1v80.lib
//Realizing Graphical Version of Logic for single modules
$ show 

(i)dff_const1.v

Expected logic from verilog file

dff_const1

GTK Wave

const1 gtkwave

Statistics showing a flop inferred

Screenshot (217)

Realization of Logic

Screenshot (216)

The optimized graphical realization thus shows the flop inferred. Also, the design code has active high reset and the standard cell library has active low reset - so, there is a presence of inverter for the reset.

(ii)dff_const2.v

Expected logic from verilog file

const2 mo

GTK Wave

const 2 gtk

Statistics showing a flop inferred

Screenshot (218)

Realization of Logic

Screenshot (219)

(iii)dff_const3.v

Expected logic from verilog file

const3 mo

GTK Wave

Screenshot (221)

Statistics showing a flop inferred

const 3 st

Realization of Logic

Screenshot (223)

(iv)dff_const4.v

Expected logic from verilog file

const 4 mo

GTK Wave

const 4 gtk

Statistics showing a flop inferred

const4 st

Realization of Logic

const4 re

(v)dff_const5.v

Expected logic from verilog file

const5 mo

GTK Wave

const 5 gtk

Statistics showing a flop inferred

const5 st

Realization of Logic

const 5 re

SEQUENTIAL UNUSED OUTPUT OPTIMIZATION

//Steps Followed for each of the unused output optimization problems:
//opening the file
$ gvim counter_opt.v
//Invoke Yosys
$ yosys
//Read library 
$ read_liberty -lib ../my_lib/lib/sky130_fd_sc_hd__tt_025C_1v80.lib
//Read Design
$ read_verilog opt_check.v
//Synthesize Design - this controls which module to synthesize
$ synth -top opt_check
//To perform constant propogation optimization
$ opt_clean -purge
//Generate Netlist
$ abc -liberty ../my_lib/lib/sky130_fd_sc_hd_-tt_025C_1v80.lib
//Realizing Graphical Version of Logic for single modules
$ show 

(i) counter_opt.v

Expected logic from verilog file

count opt mo

count opt fig

If there is a reset, the counter is intialised to 0, else it is incremented - performing like an upcounter. Since it is a 3 bit signal, the counter rolls back after 7. However, the final output q is sensing only the count [0], so the bit is toggling in every clock cycle (000, 001, 010 ...111). The other two outputs are unused and does not create any output dependency. Hence, these unused outpus need not be present in the design.

Statistics showing only one flop inferred instead of 3 flops sinces it is a 3 bit counter

Screenshot (228)

Realization of Logic

Screenshot (229)

optimized graphical realization output Q (count0) being fed to NOT gate so as to perform the toggle function. The other outputs which has no dependency on the primary out is optimized off.

(ii) counter_opt2.v

//Steps Followed:
//Copying the code to a new file
$ cp counter_opt.v counter_opt2.v
$ gvim counter_opt2.v
//Changes made in the verilog code, i for insert mode: 
- assign q = [count2:0] == 3'b100;

Expected logic from verilog file

co2 mo

In this case, all three bits of the counter is used and hence 3 flops are expected in the optimized netlist.

Statistics showing all three flops inferred

co 2 st

Realization of Logic

Screenshot (230)

All three flops can be seen. There is a need for incremental logic, so the logic other than flops represent the adder circuit. The expression at the output is q = counter2.counter1'.counter0'. Therefore, the outputs having no direct role on the primary output will only be optimized away.


4. Day 4 - Gate Level Simulation(GLS), Blocking vs Non-blocking and Synthesis-Simulation Mismatch

4.1.GLS, Synthesis-Simulation mismatch and Blocking/Non-blocking statements

What is Gate Level Simulation (GLS) ?

Running the testbench against the synthesized netlist ouput as a DUT is known as Gate Level Simulation (GLS). The Output netlist should logically be same as the RTL code so that the testbench will align itself when we simulate both the files to obtain the waveforms.

Advantages of GLS:

*To logically verify the correctness of the design after Synthesis. *During the RTL Simulation, timing was not accounted. But for practical applications, there is a need to ensure the timing of the design to be met.

Why GLS?

GLS is required to verify the logical correctness of the design post synthesis with the help of the netlist file. It ensures whether the timing of the design is met and for thi, the GLS used to run with delay annotations.

GLS

//consider a netlist
and uand (.a(a),.b(b))
or uor (.a(a),.b(b))
//There is a need to define the meaning of and and or
//Thus we need netlist, testbench and verilog models of the standard cells

Netlist consists of all standard cells instantiated and it's meaning is conveyed to the iVerilog using Gate Level Verilog Models. Gate Level Verilog Models can be functional or timing aware. If the gate level models are delay annotated, then GLS can be performed for timing validation also in addition to functional validation.

SYNTHESIS SIMULATION MISMATCH

If netlist is a true reciprocation of RTL, what is the need to validate the functionality of netlist? There may be synthesis and simulation mismatch due to the following reasons:

(I)Missing Sensitivity List (II)Blocking Vs Non Blocking Assignments (III)Non Standard Verilog Coding

(I)Missing Sensitivity List

module mux(
input i0,input i1
input sel,
output reg y
);
always @ (sel)
begin
   if (sel)
            y = i1;
   else 
            y = i0;          
end
endmodule

The output of Simulator changes only when the input changes. The output is not evaluated when there is no activity. In the above 2x1 mux code, when select is changing (when select is 1), the output is 1 when input is 1 else the output is 0. The always block evaluates only when there is a transition change in select pin, and is not sensitive (output does not reflect) to changes in the inputs 0 and 1.

Corrected code for missing sensitivity list:

module mux(
input i0,input i1
input sel,
output reg y
);
always @ (*)
begin
   if (sel)
            y = i1;
   else 
            y = i0;        
end
endmodule

mismatch is corrected by having always @ (*) where the always block is evaluated when any signal changes. So, any changes in inputs will also be seen in the output.

(II)Blocking Vs Non Blocking Assignments in Verilog

Blocking and Non-blocking statements are procedural assignment statements that can be implemented only inside an always block.

*Blocking Assignments --> = *Executes the statements in the order in which they are coded.

*Non-blocking Assignments --> <= *Executes the RHS of all such assignments when the always block is entered and assigned to LHS in a parallel evaluation.

Synthesis-Simulation mismatches due to incorrect ordering of the blocking assignments done inside an always block.

CAVEAT 1:-

module code (input clk,input reset,
input d,
output reg q);
always @ (posedge clk,posedge reset)
begin
if(reset)
begin
        q0 = 1'b0;
        q = 1'b0;
end
else
        q = q0;
        q0 = d;    
end
endmodule

cav1

The assignments inside the code represent the blocking statements. q0 and q are assigned to 1 bit 0s - so asynchronous reset connection happens. However, in the later parts, q0 is assigned to q and then d gets assigned to q0. If suppose, there is a change in the code.

module code (input clk,input reset,
input d,
output reg q);
always @ (posedge clk,posedge reset)
begin
if(reset)
begin
        q0 = 1'b0;
        q = 1'b0;
end
else
        q0 = d;
        q = q0;    
end
endmodule

In this case, d is assigned to q0 and then q0 is assigned to q. So, by the time the second statment gets executed, q0 has the value of d. This will lead to implementation of only one flop. Previously, q has the value of q0 and q0 has the value of d - which lead to implementation of 2 storage elements.

Always Use Non- Blocking Statements when writng the Sequential circuits code

CAVEAT 2:- Causing Synthesis Simulation Mismatch

module code (input a,b,c
output reg y);
reg q0;
always @ (*)
begin
        y = q0 & c;
        q0 = a|b ;    
end 
endmodule

The code is aimed to create a function of y = (A+B).C. In the above code, when the code enters always block, due to the presence of blocking statements, they get evaulated in order. So y gets evaluated first (q0.C), where the q0 results corresponds to the previous iteration's result. The q0 value gets updated only in the second statement.

When the order of the statements is changed: In this case, a OR b is evaluated first and the latest value is used for calculating y.

module code (input a,b,c
output reg y);
reg q0;
always @ (*)
begin
        q0 = a|b ;
        y = q0 & c;
end 
endmodule

> Therefore there is a paramount importance to run the GLS on the netlist and match the specifications, to ensure there is no simulation synthesis mismatch.

(i) ternary_operator.v

_Note: Mux function is written using a ternary operator. Ternary operator takes 3 operands with the format.

<Condition>?<True>:<False>

Verilog File

Screenshot (288)

GTK Wave

Screenshot (237)

Statistics

ter st

Realization of Logic

Screenshot (238)

NAND gate with i1 and sel, inverted io and Or to And invert gate, to which the inputs are sel and inverted i0. The output y is given by the expression = sel'.i0 + sel.i1

GLS OUTPUT

gls gtk

MISSING SENSITIVITY LIST

(ii): bad_mux.v showing mismatch due to missing sensitivity list

Verilog File

bad mo

during Simulation, the logic acts as a latch and during synthesis, it acts as a mux.

GTK Wave

bad gtk

Synthesis Statistics

bad st

GLS Output

bad gls

Realization of Logic

Screenshot (241)

Confirms the functionality of 2x1 mux after synthesis where when the select is low, activity of input 0 is reflected on y. Similarly, when the select is hight, activity of input 1 is reflected on y. Hence there is a synthesis simulation mismatch due to missing sensitivity list.

CAVEATS IN BLOCKING ASSIGNMENTS

(iii) blocking_caveat.v showing mismatch due to blocking assignments

Verilog File

cav mo

when the code enters always block, due to the presence of blocking statements, they get evaulated in order. So d gets evaluated first (x.c), where the x results corresponds to the previous iteration's result (a|b). The d value gets updated only in the second statement. The output expression is given as d = (a+b).c

Synthesis Statistics

cav st

GTK Wave

cav gtk

d = (a+b).c, if the inputs a,b = 0; then a+b = 0. The output d = 0. But, we observe the output d = 1 because it looks at the past value where a+b was 1.

GLS Output

cav gls

Realization of Logic

cav re

<value of output d is 0 after simulation and 1 after synthesis for the same set of input values. Hence there is a synthesis simulation mismatch due to blocking assignments.


5. Day 5 - Optimization in synthesis

5.1 If Case constructs

The if statement is a conditional statement which uses boolean conditions to determine which blocks of verilog code to execute. If always translates into Multiplexer. It is used for priority Logic and are always used inside always block.The variable should be assigned as a register.

Syntax for IF Statement

if<cond>
begin
.....
.....
end
else
begin
.....
.....
end

Syntax for IF- ELSE-IF Statement

if<cond1>
begin
.....
 executes cb1
.....
end
else if<cond2>
begin
.....
  executes cb2
.....
end
else if<cond3>
begin
.....
  executes cb3
.....
end
else
begin
.....
  executes cb4
.....
end

Hardware Implementation

hd imp

Cautions with using IF Statements Inferred latches can serve as a 'warning sign' that the logic design might not be implemented as intended. They represent a bad coding style, which happens because of incomplete if statements/crucial statements missing in the design. For ex: if a else statement is missing in the logic code, the hardware has not been informed on the decision, and hence it will latch and will tried retain the value. This type of design should be completely avoided unless intended to meet the design functionality (ex: Counter Design).

inf if

CASE Statements

The hardware implementation is a Multiplexer. Similar to IF Statements, Case statements are also used inside always block and the variable should be a register variable.

Case Statements

_reg y
always @ (*)
begin
	case(sel)
		2'b00:begin
		      ....
		      end
		2'b01:begin
		      ....
		      end
		      .
		      .
		      .
	endcase	
end

Caveats in CASE Statements

*Case statements are dangerous when there is an incomplete Case Statement Structure may lead to inferred latches. To avoid inferred latches, code Case with default conditions.

reg y
always @ (*)
begin
	case(sel)
		2'b00:begin
		      ....
		      end
		2'b01:begin
		      ....
		      end
		      .
		      .
	default:begin
         ....
		       end
	endcase	
end

*Partial Assignments in Case statements - not specifying the values. This will also create inferred latches. To avoid inferred latches, assign all the inputs in all the segments of the case statement.

5.2 INCOMPLETE IF STATEMENTS

* (Case 1) incomplete if statements

Verilog File

100

GTK Wave

Screenshot (250)

Else case is missing so there will be a D latch.

Synthesis Statistics
Screenshot (251)

Realization of Logic Screenshot (252)

synthesized design has a D Latch inferred due to incomplete if structure (missing else statement).

* (Case2) incomplete if statements

Verilog File

200

GTK Wave

Screenshot (254)

When i0 is high, the output follows i1. When i0 is low, the output latches to a constant value (when both i0 and i2 are 0). Presence of inferred latches due to incomplete if structure.

Synthesis Statistics

Screenshot (256)

Realization of Logic

Screenshot (257)

5.2 INCOMPLETE CASE STATEMENTS

CASE 1: incomplete case statements

Verilog File

33

GTK Wave Screenshot (258)

When select signal is 00, the output follows i0 and is i1 when the select value is 01. Since the output is undefined for 10 and 11 values, the ouput latches to the previously available value.

Synthesis Statistics

i st

Realization of Logic

Screenshot (259)

The synthesized design has a D Latch inferred due to incomplete case structure (missing output definition for 2 of the select statements).

CASE 2: incomplete case statements with default

Verilog File

comp case mo

Synthesis Statistics

comp st

GTK Wave

Screenshot (260)

When select signal is 00, the output follows i0 and is i1 when the select value is 01. Since the output is undefined for 10 and 11 values, the presence of default sets the output to i2 when the select line is 10 or 11. The ouput will not latch and be a proper combinational circuit. Realization of Logic

Screenshot (261)

CASE 3: partial case statement

Verilog File

p mo

Synthesis Statistics

p st

Realization of Logic

p re

5.3 STATEMENTS USING FOR

Understanding the Usage of For and Generate Statements:

FOR STATEMENTS GENERATE STATEMENTS
These statements are used inside the always block These statements are used outsde the always block
Used for evaluating expressions Used for instantiating/replicating Hardwares

CASE 1: using generate if statement

Verilog File

1 mo

GTK Wave

1 gtk

CASE 2: demux using case statement.v

Verilog File

2 mo

GTK Wave

2 gtk

Synthesis Statistics

2 stk

Realization of Logic

2 re

GLS Output

2 gls

CASE 3: demux using generate if statement.v

Verilog File

3 mo

GTK Wave

3 gtk

Synthesis Statistics

3 st

Realization of Logic

3 re

GLS Output

3 gls

5.3 STATEMENTS USING GENERATE

Experiment on Ripple Carry Adder

Instantiating the full adder in a loop to replicate the hardware Verilog File

1 mo

GTK Wave

1 gtk

Synthesis Statistics

1 st

Realization of Logic - rca

1 re

Realization of Logic- fa

1 re2

GLS Output

1 gls

The observed waveform in simulation and synthesis matches and conforms code functionality.

ACKNOWLEDGEMENTS

  • Kunal Ghosh, Co-Founder (VLSI SYSTEM DESIGN - VSD)
  • Shon Taware

References

Releases

No releases published

Packages

No packages published