LSI Development Flow (Review)

device
process design
requirements

device design Platform

LSI development (flow)

development Total
circuit design (flow) LSI design
(flow)
LSI
specifications LSI design LSI design (flow)

fabrication
*characterization
wafer level test
*qualification Production (flow)
packaging
*quality assurance
chip level test
LSI products

Page 4
Total LSI Design Flow (Review)

To design LSIs using design environment established by platform development

F Quality of the platform determines quality of all products

LSI Design Flow

Platform Development Flow System spec

Technology rule
Device spec Device parameters System design
(process spec) Device design Layout design rule
Layout verif. rule
Logic design
Circuit spec Circuit design
Cell library Test design
Logic model
Library spec Library design Timing model Layout design
Circuit model
Layout model

Mask making

Page 5
LSI Design Flow (1/2)
System spec

System design Define spec. and LSI structure Ø Design input &
output
Logic design Finalize logic description
Ø Design review
Verify timing
Ø Documentation
Test design Design for testing at fab. line

Layout design Finalize mask patterns

Assure timing

Prevent side effect

Minimize
Mask making Design Errors

Page 6
LSI Design Flow (2/2)
System spec

System design C based/System C s/w – h/w system verification (Co-Sim)

Logic design Logic synthesis (RTL -> Gate) Logic verification

Rough P&R Preliminary timing verification (Gate)

Test design ckt/program generation Fault coverage verification

Layout design Gate level P&R (timing driven) Layout verification

Power line routing Timing verification (Gate)

Data generation for packaging Verification of Signal Integrity

Mask making Mask data generation (dummy pattern, OPC) Mask data verification

Page 7
System Design
Systems & Components
Systems Transportation
Audio system
TV Application
Specific IPs Plant
DVD Circuits control
USB1/2
ADC AND
1394
DTV / OR
DAC DDRI/II Electronic
Device FF /
(Tr, C, R) Latch
money
Mobile
phone MPEG2/4 Memory LVDS
PC
DSP CPU
PDA
Computer
LAN system

Communication Automotive
switchboard
electronics

Page 9
System Integration
SoC (System-on-Chip): System implementation in single LSI
SiP(System-in-Package): System implementation in 1 package

Small footprint
Low power
consumption
High performance
CPU
CPU
Single LSI
(SoC)
ASIC
Memory
74 series
Memory CPU Multiple
periphery Memory chip LSIs in
chip ASIC
System board 2 Chip Single
System board 1 PKG (SiP)
Buildup of small-
scale peripherals

Page 10
System Design Flow
System design
Investigation of spec To propose external spec and features

Architecture To select CPU core, and define internal

Definition organization, and then determine job
sharing of h/w and s/w

Evaluation To estimate performance and cost

SW Design
HW Design
CPU/DSP execution
RTL design

Memory usage
Logic synthesis
Power dissipation

Page 11
Requirements for System Design
Ø To optimize LSI specifications by watching market trend and hearing customers’
needs, such as:
performance, features, power dissipation, reliability,
price (target die size, package selection, process).

Ø To remove over-spec and spec bugs.

Ø To avoid specification changes during HW design phase because HW design

becomes critical:
• Demand for time-to-market is increasing.
• Complexity is increasing.
• Need for performance is increasing.
• Fabrication cost is increasing (more than $1M for one mask set).

Page 12
Early Prototype
Functional description (algorithm) in ANSI C is converted to form FPGA-based early prototype
F Platform for software development, and system verification prior to initiation of RTL design.

software hardware
section section

I/F
section
ANSI C description

YXI Co.
C program eXCite TM

RTL l Application
I/F synthesis High-level synthesis
(VHDL/Verilog) - High-speed simulation
Software development
environment
driver/
glue logic

Interlock

LogicBench/VirtualTurbo

Page 13
Logic Design Flow
System Design

RTL Design RTL description [VerilogHDL/VHDL]

To check RTL code
assign sum = a ^ b ^ ci;
Logic Design assign co = (a&b)| …

To verify RTL description is compliant with functional

RTL verification
spec [NC-Verilog/VCS/Xcelium Single Core/ModelSim]

To synthesize gate level description from RTL

Logic synthesis
[Design Compiler, Genus Synthesis]
To verify operation speed of gate level
pre.Timing verification description using pre-layout load conditions
[PrimeTime]

Test Design co
a
b sum
ci

Page 15
Design and Modeling (1/3)
Idea
Natural language
UML

Huge gap
(Unified Modeling Language)
Modeling language
Specification C language (Software)
etc.
Design Process

HDL (Hardware Description Language)

Verilog
VHDL
Netlist language
Net list Show connectivity
GDS file
Mask
pattern There is no tool available to map
specification into netlist automatically.

Page 16
Design and Modeling (2/3)
In general, the flow goes from high abstraction level to low abstraction level as shown below. Currently
each model must be mapped into the next level manually. Some steps may be skipped, for example it is
not always necessary to create UML or/and C models.

natural model L1
language
We usually make several levels of
documents written in natural
UML language, such as,
model L2
requirements specification,
model L3 functional/interface specification,
C
internal design specification, and
etc.
Verilog RTL
model L4

Page 17
Design and Modeling (3/3)
Abstraction level Description Difficulty to write the code

Highest Focusing on functionality only. Easy

Timing and hardware resource Just focus on functionality only.
needed can be ignored. (Short development time, less
bugs)
Order of events such as signal
change is taken into account.
(Sequence accurate)
Processing time of signal change is
taken into account. (Elapsed time
accurate)
Precise timing is taken into account.
(Cycle time accurate) Many aspects must be
considered at the same time.
Not only functionality and timing, but (Long development time, more
also hardware resources needed are bugs)
Lowest Difficult
described.

Page 18
Modeling Level Example
Description level

Simulation
Synthesis
Timing Explicit Description
Example language
Machine hardware
Sequence Elapsed cycle resource
time
transaction level C, C++
No *1 modeling
*1: If a model has no No No No Yes System C
untimed
concurrency and accurate
untimed, several Yes timed System C
behavioral synthesis
tools are available, *2
Cycle System C
but not well Yes No No Yes
accurate accurate accurate Verilog
developed yet. simulation VHDL
model

*2: Several Verilog

accurate accurate Yes Yes Yes Yes RTL model VHDL
behavioral synthesis
tools are available,
but not well Yes Gate level Verilog-
accurate accurate Yes Yes
developed yet model netlist

Page 19
Design Process Using Models
Used as the
reference
Specification C model whenever any
Architecture
ambiguity arise.
design C model
Golden model
Simulation
result of
Code and debug golden model

Sometimes
C model is Compare
not created. RTL code the results
Simulation

Code and debug If OK, go to further

testing/debugging.

Page 20
Objective of Logic Design
Get photo masks equivalent to the
Objective of logic design = specifications, for fabrication purpose.

Function coding synthesis layout Mask

description Logic Logic gate pattern
(Specifications) description connection (photo mask)

Simulation
result for Verilog RTL Verilog netlist GDS
verification for layout
fabrication

RTL code must be RTL code must be LSI chips

“simulatable”. “synthesizable”. to sell

We have to write RTL code so that an EDA We have to write RTL code so that an EDA
tool can simulate the code for verification. tool can create a netlist from the code.

Page 22
Design Models
Abstraction Applicable
Feature Comment
level language
We must select a
suitable abstraction
Currently, C code is not

untimed
level depending on high
synthesizable.

not synthesizable
the purpose of C
modeling the target
logic. RTL code using
features of Verilog
which are not

simulatable
synthesizable is
not synthesizable.

synthesizable
Cycle accurate
RTL code using only
Verilog RTL synthesizable
features of Verilog is
low synthesizable.
Verilog RTL

Page 23
 Verilog RTL Design (1/2)
There are several levels of description in Verilog language. For front end design, we generally use Register
Transfer Level (RTL Level), which can
describe how signals go into registers, registers (typically FFs) registers (typically FFs)
memory elements, as shown beside.
logic FF logic FF logic
Renesas mainly uses Verilog as a
high level hardware description
language Verilog RTL code for the truth table on the left

Truth table
casez ( a[3:0] )
a[3] a[2] a[1] a[0] y 4’b1??? : y = q1 ;
1 x x x q1 4’b01?? : y = q2 ;
0 1 x x q2 4’b00?0 : y = q3 ;
0 0 x 0 q3
0 4’b0001: y = q4 ;
0 0 1 q4
0 0 1 1 q5 4’b0011: y = q5 ;
default : y = 4’bxxxx ;
endcase

Page 24
Verilog RTL Design (2/2)
When writing RTL code, frontend designers do not have to concern on:

how to combine what kind of gates, and the

circuits of the gates which are necessary to realize the logic in the code.

Therefore, frontend designers can be free from the physical design and focus on the logic itself.

The mapping between RTL code and the circuit on the silicon is done by
backend designers with a help of design automation tools.

Silicon wafer
Circuit pattern
RTL code
on silicon
DA tools

Page 25
RTL Programming Summary (1/18)
Follow the following steps to write Verilog RTL source program of a module.

Step 1. Write a header for a file you are going to create to help others
understand what are written, and help yourself to remind what are
written, in the file.
// +HC -------------------------------------------------
// File: snake_game_top.v
// Module: snake_game_top File and module name
// Function: Top module of snake game Functions
// ------------------------------------------------------
// keywords: snake, game, lamp_field, Key words for the file
// ------------------------------------------------------
// Remarks: Comments for reusers
// ------------------------------------------------------
// History: Version, Date, Author, Description
// v1.0, 07.May.2011, Viet Viet, new release
// v1.1, 12.Aug.2012, Minh Minh, Update history
// game over signal timing corrected
// ------------------------------------------------------
// (C) Copyright 2011 Renesas Electronics Corp. All rights reserved. Copyright
// -HC -------------------------------------------------- notice

Page 26
RTL Programming Summary (2/18)
Step 2. Give a unique name to a module.

//////////////////////////////////
// header
//////////////////////////////////
module module_name ; Give a unique meaningful name,
Use 5 to 16 lowercase characters.
endmodule

Step 3. Find how many inputs and outputs are needed for the module.
And give them unique meaningful names, and then list them up
in a port list in the order of clock, reset, input and output signals.

//////////////////////////////////
// header
//////////////////////////////////
module module_name ( clk, rst, in_a, in_b,,,, out_c, out_d,,,, ) ;
Give a unique meaningful name
endmodule List up all the interface signals including for each signal, use 5 to 16
clock and reset in a module port list. lowercase characters.

Page 27
RTL Programming Summary (3/18)
Step 4. Declare parameters for constants, such as bit-width of signals used in
the module, initial values of FFs, etc. to improve readability and reusability of
the module.

//////////////////////////////////
// header
//////////////////////////////////
module module_name ( clk, rst, in_a, in_b,,,, out_c, out_d,,,, ) ;
// parameters
parameter BW_IN_B = 16 ; // Bit width of in_b,
// BW_IN_B can be either 4, 8, 16, 32, or 64
parameter BW_OUT_D = 8 ; // Bit width of out_d,
// BW_OUT_D can be either 2, 4, 8, 16, or 32
parameter ,,,,,,,

endmodule

Declare parameters and give comments for them.

Parameter ranges must also be declared.

Page 28
RTL Programming Summary (4/18)
Step 5. Declare port using input/output keywords for all the signals listed up
in a module port list. Use range specification for multi-bit signals.

//////////////////////////////////
// header
//////////////////////////////////
module module_name ( clk, rst, in_a, in_b,,,, out_c, out_d,,,, ) ;
parameter BW_IN_B = 16 ; // Bit width of in_b,
// BW_IN_B can be either 4, 8, 16, 32, or 64
parameter BW_OUT_D = 8 ; // Bit width of out_d,
// BW_OUT_D can be either 2, 4, 8, 16, or 32
parameter ,,,,,,,
// ports
input clk, rst ; // clock and reset signal Declare input and output
input in_a; // comment, ,,,,,,, for all the signals listed in
input [BW_IN_B -1 :0] in_b ; // ,,,, a module port list.
output out_c ; // ,,,,,,,,, Use range specification
output [BW_OUT_D -1 :0] out_d ; // ,,,,,, for multi-bit signals.

endmodule
Give comments to describe each port.

Page 29
RTL Programming Summary (5/18)
Step 6. Declare data type for input ports using wire keyword.
//////////////////////////////////
// header
//////////////////////////////////
module module_name ( clk, rst, in_a, in_b,,,, out_c, out_d,,,, ) ;
// parameters
parameter ,,,,
parameter ,,,,,,,
// ports
input clk, rst ;
,,,,,,
,,,
output [BW_OUT_D -1 :0] out_d ;
// input data type Declare data type of all inputs
wire ckl, rst ; by using wire keyword. Use
wire in_a ; the same range specification
wire [BW_IN_B -1:0] in_b ; for multi-bit signals.
endmodule

Page 30
 RTL Programming Summary (6/18)
Step 7-1. Find if output signals can be described by using continuous assign
statement or not. For those output signals which can be described
as “assign out_c = some_expression ;”, declare their data type by
using wire keyword.

//////////////////////////////////
// header
,,,,,,,,
,,,,,
// input data type
wire ckl, rst ;
wire in_a ;
wire [BW_IN_B -1:0] in_b ;
,,,,
// output data type Declare data type of outputs
wire out_c ; by using wire keyword if they
wire [BW_OUT_D -1:0] out_d ; appear on LHS of continuous
assign statements.
Use the same range
endmodule
specification for multi-bit
signals.

Page 31
 RTL Programming Summary (7/18)
Step 7-2. For those output signals which can not be defined by continuous assign statements
and have to be defined by procedural assign statements, declare their data type by
using reg keyword.
Use reg keyword if a signal appears on LHS of
procedural assign statements.

//////////////////////////////////
// header
,,,,,,,,
// output data type
,,,,,,
,, Give comments to describe output
wire [BW_OUT_D -1 :0] out_d ;
arguments. And also give note to make it
reg out_f ; // non-FF
clear that if they are to be mapped into FF
reg [BW_OUT_G -1 :0] out_g ; // FF
or not.
reg [BW_OUT_P -1 :0] out_p ; // non-FF
Use the same range specification for multi-
endmodule bit signals.

Page 32
RTL Programming Summary (8/18)

Step 8. Declare internal signals by using wire or reg keyword depending on if they appear on LHS of
continuous assign or procedural assign statements.

/////////////////
// header Declare data type of internal signals.
,,,
,, Use wire keyword if they appear on LHS of
reg [BW_OUT_P -1:0] out_p ; // non-FF continuous assign statements,
// internal signals
wire intnl_sig_a; //,,,, use reg keyword if they appear on LHS of
wire [BW_SIG_B -1:0] intnl_sig_b ; // ,,, procedural assign statements.
reg intnl_sig_c ; // non-FF Use range specification for multi-bit signals.
reg [BW_SIG_D -1:0] intnl_sig_d ; // FF
Give comments for reg data type to make it
clear that they are to be mapped into FF or not.
All internal signals must be commented to
endmodule
describe what they are used for.

Page 33
RTL Programming Summary (9/18)
Step 9. Describe logic using continuous assign statements, procedures and module instanciation.

//////////////////////// assign sig_r = sig_s & sig_t ;

// header
/////////////////////// assign sig_u = ( sig_f )? sig_w : sig_v ;
module module_name ( clk, rst,
// parameters m_name m_name_01 ( ,,,,,, ) ;
parameter ,,,
,,,,,,
m_name m_name_02 ( ,,,,, ) ;
// ports
input clk, rst ; function func_name ;
,,,,,,,,, endfunction
// data type
wire ,,,, ,,
// internal signals always ,,,,, begin
wire intnl_sig_a; end
,,,,
,,
// start logic description initial begin
end

task task_name ;
endmodule endtask

Page 34
RTL Programming Summary (10/18)
The following set of code lines must be written near to each other if they are
related to the same logic block. Do not mix up unrelated code lines together.

assign sig_r = sig_s & sig_t ;

assign sig_u = ( sig_f )? sig_w : sig_v ;

m_name m_name_01 ( ,,,,,, ) ;

m_name m_name_02 ( ,,,,, ) ;

function func_name ;
endfunction
,,
always ,,,,, begin
end

task task_name ;
endtask

Page 35
 RTL Programming Summary (11/18)
Step 9-1. Define FFs by using always constructs with posedge clk in a sensitivity list.

//////////////////////// (1) LHS must be declared by reg keyword.

// header
,,,,
(2) Use nonblocking procedural assignment.
,, (3) Write change direction event of clock and
// start logic description reset ( for asynchronous reset ) in the sensitivity
list.
// always for FF
always @ ( posedge clk or negedge rst_n ) begin
if ( rst_n == 1’b0 ) begin
sig_ff <= INTL ;
end Write FFs using
else begin always constructs.
sig_ff <= next_sig_ff ;
end
end

endmodule Apply delay to avoid racing, if the project policy says so.

Page 36
 RTL Programming Summary (12/18)
Step 9-2. Describe logic using continuous assign statements.

////////////////////////
// header
,,,,
,,
// start logic description
// always for FF
always @ (posedge clk ,,,, )
,,,,
,,
// continuous assigns Write logic blocks
assign sig_w = sig_u & sig_y ; // comment using continuous
assign sig_h = ( sig_en )? sig_s : sig t ; // comment assign statements.
assign ,,,,,,

endmodule

(1) LHS must be declared by wire keyword.

(2) Do not use @ nor #.

Page 37
 RTL Programming Summary (13/18)
Step 9-3. Describe logic by instanciating lower level modules.

////////////////////////
// header
,,,, (1) Output port must
,, be connected to wire.
// start logic description (2) Input port can be
// always for FF
,,
connected to wire or
// continuous assigns reg.
assign sig_w = sig_u & sig_y ; // comment
assign sig_h = ( sig_en )? sig_s : sig t ; // comment
assign ,,,,,, Syntax
// module instanciation
m_name m_name_01 ( ,,,,,, ) ; module_name module_name_01
m_name m_name_02 ( ,,,,, ) ; ( .port1_name(connecting_signal_name),
.port2_name(connecting_signal_name),
,,,,,
endmodule );

Page 38
 RTL Programming Summary (14/18)
Step 9-4. Define combinational logic blocks by functions.

//////////////////////// Syntax
// header
,,,, function range_declaration function_name ;
,, input range_declaration input_name ;
assign ,,,,,,
input range_declaration input_name ;
// module instanciation
m_name m_name_01 ( ,,,,,, ) ; reg local_wk ;
,,,
// functions function_name = ,,,, ;
function [BW_FUNC -1:0] func; endfunction
input [BW_F_IN -1:0] f_in_a ;
,,,,
func = ,,,, ;
endfunction (1) Internal work must be declared by reg
keyword.
endmodule (2) Do not use @ nor #.
(3) Use blocking procedural assignment only.
(4) Declare range if func is multi-bit.

Page 39
 RTL Programming Summary (15/18)
Step 9-5. Define combinational logic blocks by always constructs.

////////////////////////
// header
,,,,
,,
assign ,,,,,,
// module instanciation
m_name m_name_01 ( ,,,,,, ) ;
,,
// functions
,,,
// always for combinational logic
always @ ( sig_a or sig_b ,,, ) begin
if ( ,,,,) ,,
,,,
sig_w = ,,, ;
end

endmodule

Page 40
 RTL Programming Summary (16/18)
Step 10. Review the code lines. If code lines related to the same logic block are distributed among other code
lines, move them into one part so that the logic part can be seen at a glance.
//////////////////////// assign ,,,,,,
// header // module instanciation
,,,, m_name m_name_01 ( ,,,,,, ) ;
,, ,,
assign ,,,,,, always @ ( ,,,
assign ,,, end
// module instanciation
m_name m_name_01 ( ,,,,,, ) ;
,,
// functions assign ,,,
// functions
function ff ;
,, function ff ;
endfunction ,,
function gg; always @ (,,,
,, end
endfunction
always @ ( ,,,
end
always @ (,,,
end

endmodule

Page 41
 RTL Programming Summary (17/18)
Step 11. Review the code lines. If code lines creating flags are placed far from the logic block where the
original signal is generated, move them near to the original signal generating block.

assign sig_a = ,,,,, ;

// module instanciation
m_name m_name_01 ( ,,,,,, ) ;
,,
// functions
function gg;
,,
endfunction Move this flag signal generating
always @ ( ,,, code line into the code block
end
// generating sig_a.
assign en_flag = | sig_a;
always @ (,,,
if ( en_flag ) begin
,,,
,,
end

endmodule

Page 42
 RTL Programming Summary (18/18)

Step 12. Review the code lines to check if readability is good and if they are easy to understand and to reuse.
Improve the understandability, readability, and reusability.

Page 43
RTL Verification – Where Bugs come from?
Misunderstanding. Poor imagination

Customer’s
expectation Specification

Implicit requirements Ambiguous and/or

Misunderstanding.
insufficient description
Poor imagination.
Example:
Interfaces and
For three events A, B and C, the logic internal logics
was designed for those events coming in
Ambiguous and/or
sequence of A-B-C, or B-A-C, or B-C-A Misunderstanding.
insufficient description
or C-A-B or C-B-A.
Insufficient/wrong
However a poor imaginative designer programming knowledge.
cannot think of the sequence A-C-B. And
RTL programs Careless miss
this sequence may result in failure of the
logic.
Incorrect coding,
tool dependent coding

Page 44
RTL Verification – Desktop Checking (1/3)
Checking a logic on a desk by “hand” (eyes) is still an effective way to
verify logics if it is done in a way that every assumption a designer made
is checked whether they are really true or not.

You must do desktop check to make sure that

you really understand the issues in your design.

Sometimes RTG (Random Test Generator) can checkout

bugs by providing test data which a designer may never
imagine. However, this does not mean RTG can replace
desktop checking.

Logics designed by an engineer with poor

imagination have a lot of bugs.

Page 45
RTL Verification – Desktop Checking (2/3)
There is little chance for bugs to
You will code the sequence you think of.
sneak into such sequences.

Sometimes, engineers cannot take specific

Signal A will come cases into consideration and there is a big
risk of bugs being implemented in such cases.
Then , take this action,,,,
When processing (2), the environment
Next, signal B will come, may vary from that of (1). However,
Then, .. .. . very often a designer tends to forget
(1)
about the possibility that his
Next, signal B will comes, Therefore,,. assumption becomes invalid.

Do this and that

Always check whether the
(2)
basic assumption you have
made is still true or not .
Page 46
RTL Verification – Desktop Checking (3/3)
Especially, following points must be checked all the time during the design activities.

What happens might not happen in the way you hope.

(The input which you expect may not come when you think it will come).

Events may happen in a different sequence to that you expected.

(Event A will come before Event B, when you assume B will come before A.
Or Event A and B happen at the same time, when you expect them to come in a sequence).

A presupposed condition may not realized.

Some blocks may have no power when you think all the blocks are powered up.
Some blocks may not be initialized, when you think all the blocks are initialized.
A clock signal is dead, when you think the clock is always alive.
Some voltage may be supplied, even after the power is off.

A value which must be fixed, may not be defined yet.

(Not initialized, Not given a predetermined value, Unstable, , , , )

Page 47
RTL Verification – RTL Checker (Style Check)

Checkout naming and coding style which are prohibited or not recommended.

RTL description Check results

.....
always @(i) begin .....
casez (i) Error
3'b??1: o = 1'b0; Case statement is missing
3'b?10: o = 1'b1; RTL cases and has no default
3'b100: o = 1'b0; Checker ("casez (i)")
endcase [SpyGlass] .....
end
.....

(case, 3‘b000 is missing)

- Rule creation is important
Checking rule
- Sometimes customization is needed

Page 48
RTL Verification – Static Functional Verification
Given a set of properties that describe the behavior of the design, static functional verification tools can
prove proper functionality of the design using formal verification techniques.

What are checked out?

Properties given by a designer hold true or not.
If not true, it gives a counterexample.

Available tools
Solidify (Averant), 0-In (Mentor)

Although static functional verification cannot handle large size logic, it is suitable for testing logics
which need huge combination of input patterns such as ECC, pattern matching logics, or FIFO, etc.

Static verification does not do logic simulation, therefore no test

input is needed. It checks if properties given are true or not.

Page 49
RTL Verification – Assertion Based Verification
Define properties of signals in target modules using a language such
as PSL (Property Specification Language)

Run simulation on a simulator supporting assertion, such as NC-Verilog

(LDV5.0 or later)

When violation detected, error report is given.

“Must” and “must not” can be declared.

Signal A must rise 5 clock cycles after signal B falls.
Signal A and B must not be 1 at the same time.

Especially useful for checking improper reuse of modules.

Expected to improve reusability or reduce troubles using IPs.

Page 50
RTL Verification – Functional Logic Simulation (1/4)

To check expected simulation output by applying functional test patterns to RTL

description

RTL description Functional Output waveform (visual confirmation)

(Verilog_HDL,VHDL) test patterns

Logic simulator

Page 51
RTL Verification – Functional Logic Simulation (2/4)

By using RTL simulator, we can see if the logic works as intended by checking
the outputs.

RTL simulation takes time. Therefore, to make it time efficient, test

data must be carefully prepared to test critical or corner cases.

There are several ways to help RTL simulation time short.

(a) To reduce test data preparation time: Random Test Generator (RTG)

(b) To reduce simulation time: Early prototyping with FPGA or emulator

Page 52
 RTL Verification – Functional Logic Simulation (3/4)
RTG creates so many data patterns, therefore it is not
feasible to see the result and check if it is OK or not by A model which is believed to be correct
hand. Therefore, usually we use a golden model as a and can be used as a reference for RTL
reference and compare the result as shown below. code is called the golden model.

C programming environment

C model Outputs of the

Test data
(Golden model) golden model

RTL
RTG provide Modules observe compare
inputs under test outputs.
Automatically check
This part can be if the modules under
Test bench test are OK or NG
implemented in a hardware.

Page 53
RTL Verification – Functional Logic Simulation (4/4)

C model Outputs of the

Test data
golden model
(Golden model)

Random test Modules observe compare

provide
pattern under test outputs.
inputs
generator
Automatically check
(RTG) if the modules under
Test bench test are OK or NG

Logic Bench
FPGA can reduce the simulation time by
Run on server/Workstation (FPGA base early several hundredth compared to a simulator
prototyping kit) on workstation.

Page 54
 RTL Verification – Test Bench vs Target Code
Target code Test bench

Good Wrong Good code may be rejected

Do not think
Wrong code may be accepted.
Wrong Wrong
Bugs may be overlooked “My code is
correct,
because the
Wrong Good Wrong code is rejected
simulation
result is good.”
Good Good Good code is accepted

Damage of wrong test bench Damage of wrong target code

Test bench is much more vital for our products to assure that our products are bug free.
Page 55
RTL Verification – Test Data
While programming RTL code, it is important to assume various data as input and make your code
prepared for such data. Your code will not work properly for data which you did not expect to come. This
means your imaginative power decides the quality of your program.
It is very important for an engineer to be able to select or determine proper data to test a module he/she
designed.

Test data shall be selected so that all the possible paths of your code are covered.

Typical cases Use data which will be applied

most usually.
Test data All possible state changes Use data which will cause state
transitions.
Corner cases Use data which are critical for
the logic.

Page 56
RTL Verification – Black Box vs White Box Test (1/2)
Black box test : Test without knowledge of internal structure and logic.

White box test : Test with knowledge of internal structure and logic.

Black box To test black box, we have

to apply all the possible
a 4 combinations of input data.
c
b 4
?? 4 White box

c=
a+b + >> 1 ??
2

Page 57
RTL Verification – Black Box vs White Box Test (2/2)

white box
To test white box, we do not have to apply
4 c all the possible combinations of input
a
b + >> 1 4 data. We can apply selective input data to
4 check specific part of the design.

a+b If the target is white box, we can create

c= selective input data to activate specific
2
part of the logic.
And once checked with some data, it may
not have to be checked by using all the
possible values. Typical and corner case
data may be enough to be applied.

Page 58
Logic Synthesis (1/3)
A synthesis tool uses a Verilog RTL source program as an input and generates a gate netlist which can be
directly mapped to circuits on a silicon wafer.

RTL Source code Gate netlist Photo mask pattern

Synthesis
assign a = b + c ;
tool

The tool will generate minimum set of logic gate blocks and will not generate
gates which are not specified, explicitly or implicitly, in the RTL source code.

This means that a designer has to write all the logic blocks necessary to
make them work properly themselves.

Silicon wafer
This is very much different from a case of software application program.

Page 60
Logic Synthesis (2/3)
Executable code

load b; Application system

C source code a=b+c; Compiler add c;
store a;

This add instruction can do add operation with a help of a CPU implemented Memory CPU
in an application system. Without a CPU, it cannot do anything.
Gate netlist Photo mask pattern

Synthesis
RTL Source code assign a = b + c ;
tool

These logic gates have to be able to

do add operation by themselves. We sell this chip to our customers. If it
needs additional CPUs to work properly,
no customer will buy this chip.
Silicon wafer

Page 61
Logic Synthesis (3/3)

Synthesis: RTL description is converted to gate-level description.

RTL description
(Verilog, VHDL)
Gate
Logic Synthesis netlist
Timing constraints
- Cock period
Tool
- Timing and drivability
at core boundary - Interpretation of RTL
- Operation conditions - Logic optimization
- Library mapping
Synthesis
Library information report
- Cell list
- Cell information
(function, delay, size)

Page 62
Logic Synthesis and Cell-Based Design (1/4)
We have to implement electric circuit on silicon to get a chip
RTL code which has the same functionality to RTL code we designed.
assign d = ~( a & b ) ;
Front-end design Circuit pattern
assign e = d | ( ~c ) ;
on silicon
(mask pattern)
Logic synthesis : mapping between
RTL and gates

Gate a d
e Back-end design
b
c
a d
RTL code can a e
e b
be mapped into b c
several c
possible
combinations
Select suitable gates from readily available gates,
of gates. Cell-based design
instead of creating circuit pattern on silicon for each gate.

Page 63
Logic Synthesis and Cell-Based Design (2/4)
Example. Verilog RTL code Synthesis process

assign d = a & b ; // <1> (1) Each assign statement is mapped to

assign f = d | c ; // <2> a gate logic block.

not01d1 INST1(.a1(E), .zn(D)) ;

Synthesis nand02d1 INST2(.a1(A), .a2(B), .zn(E)) ;
connection
a d not01d1 INST3(.a1(C), .zn(G)) ;
b not01d1 INST4(.a1(D), .zn(H)) ;
nand02d1 INST5(.a1(G), .a2(H), .zn(F)) ;

c f
(2) Optimize and determine which circuit
shall be used on a silicon.
Synthesis
(optimization) not01d1 INST1(.a1(C), .zn(G)) ;
a nand02d1 INST2(.a1(A), .a2(B), .zn(E)) ;
b f nand02d1 INST3(.a1(E), .a2(G), .zn(F)) ;
c
Cell name
Page 64
Logic Synthesis and Cell-Based Design (3/4)
a d
b f
c such as minimize area and/or power
NAND gate is much smaller and
efficient than AND and OR gates.
Layout
Cells are select from a standard cell
library depending on a design constraint
consumption, maximize speed, etc.
Example:
If f has to drive four gates, then
nand02d4 is used instead of
nand02d1 as shown below.

not01d1 INST1(.a1(C), .zn(G)) ;

a nand02d1 INST2(.a1(A), .a2(B), .zn(E)) ;
c nand02d4 INST3(.a1(E), .a2(G), .zn(F)) ;
b
f
The drivability of this cell is 4.

Verilog gate level programming

Page 65
Logic Synthesis and Cell-Based Design (4/4)
While synthesizing, procedures are mapped into a logic gate blocks procedure by procedure base.

Verilog RTL code Synthesis process

always @ ( a or b or c ) begin
if (a) begin f = b ; end
else begin f = c ; end (1) Each procedure is mapped to a logic
end gate block.

(2) Optimize and determine which circuit

synthesis shall be used on a silicon.

b
a
not01d1 INST1(.a1(B), .zn(D)) ;
f
nand02d1 INST2(.a1(A), .a2(B), .zn(E)) ;
nand02d1 INST3(.a1(D), .a2(C), .zn(G)) ;
c nand02d1 INST4(.a1(E), .a2(G), .zn(F)) ;

Page 66
Implement The Logic on Silicon (1/4)
1.The information connection between cells
EDA tools handle the following information 2.The feature information of the cell
for implementing the logic on to the silicon (Function, input/output, the drive power, etc.)
3.The information on the structure of the cell
a1 (Width, the height, the terminal position, etc.)
zn 4.The information on the inner structure of the cell
a2 Diffusion layer size/position, gate, inner wiring, etc.
5.Layout rules
(Minimum distance between cells, etc.)
The NAND gate with two inputs 6.Wiring rules
(Minimum pitch, multi-via, etc.)
Input Library information
a1
The frontend library
Information necessary to choose the cells
Input Information about delay and drivability
a2 The backend library
The information necessary for place and route
Output The layout library
zn The pattern information to make photo mask.

Page 68
Implement The Logic on Silicon (2/4)
The cell library
This part can be provided to the customers
The frontend library who synthesize logic by themselves.
Information necessary to choose the cells
Information about delay and drivability
This part may be provided to the customers
The backend library
who do layout jobs by themselves.
The information necessary for place
and route
The layout library This part is strictly confidential.
The pattern information to make photo
mask.

The cell library contains a lot of information which is highly dependent on particular process
generation and fabrication line.

In particular, macro cells and custom cells have no compatibility between fabrication lines,
therefore avoid using these cells whenever possible.

Page 69
Implement The Logic on Silicon (3/4)
1.The information connection between cells
2.The feature information of the cell
(Function, input/output, the drive power, etc.)
3.The information on the structure of the cell
(Width, the height, the terminal position, etc.)
4.The information on the inner structure of the cell
Diffusion layer size/position, gate, inner wiring, etc.
5.Layout rules
(Minimum distance between cells, etc.)
6.Layout rules
(wiring rule, etc.)

The design rule

Minimum spacing, wiring width, and other
conditions defined specific to a fabrication
line.

Page 70
Implement The Logic on Silicon (4/4)
1.The information connection between cells
2.The feature information of the cell
(Function, input/output, the drive power, etc.)
3.The information on the structure of the cell
(Width, the height, the terminal position, etc.)
4.The information on the inner structure of the cell
Diffusion layer size/position, gate, inner wiring, etc.
5.Layout rules
(Minimum distance between cells, etc.)
6.Layout rules
(wiring rule, etc.)
The Netlist
arbitrary unique name
F
not01d1 INST1(.a1(A), .zn(F)) ; A D
nand02d1 INST2(.a1(F), .a2(B), .zn(D)) ; B
nand02d1 INST3(.a1(C), .a2(B), .zn(E)) ; C E

Name of the Name of Name of the Connection

cell used the wire I/O of the cell
Page 71
Gate Level Design

not01d1 INST1(.a1(A), .zn(F)) ;

nand02d1 INST2(.a1(F), .a2(B), .zn(D)) ;
nand02d1 INST3(.a1(C), .a2(B), .zn(E)) ;

Generating a total logic or modifying a part of logic by selecting/connecting primitive gates as the above is
called “gate level design”.
This situation may happen in Design for Testability (DFT), Static Timing Analysis (STS), Layout design.
Gate level design has some disadvantages as below:
(1) Visibility of a code is very poor, hard to understand at a glance.
(2) Portability of a design in net list is very bad because of the cells used in the
design.
(3) There are few compatibilities among the process generations.
(4) It will be difficult to enjoy the benefit of the evolution of DA tools (such as
optimization)

Page 72
 Gate Level Verification – Functional Simulation
Gate level simulation (or logic simulation): event driven method by test patterns

1 1
0 0
Initial 0 Event 0
0 0 0
0 propa- 0
1 0 0->1 0
gation 2
1 0 0
0 0 propagation

Event diminishes
1 due to no output
0 0
Event change
0 0
occurred 0 1 0 1
Event 0 0->1
1->0 0
propa- 0
0 1 0
gation 3
occurrence 0
0
1 0 propagation
0
Event 0
0 0
propa- 0
gation 1 0 Simulation of event propagation consumes
0 1->0 CPU power, longer test patterns, longer TAT.
0
propagation

Page 73
Gate Level Verification – Equivalence Check
Ø Equivalence of two logic descriptions is mathematically verified by formality check： no
need for test patterns.
Ø Equivalence check is exhaustive and faster than functional simulation.

RTL description
(Verilog, VHDL) Equivalence check
tool
Gate-level x 100 faster
description Example of 1MG logic Check report
(Verilog netlist) - func. sim.: 200 hrs.
- equiv. check: 2 hrs.

Library info. [Conformal GXL/Formality]

- Cell list
- Cell function

Page 74
Floor Planning

For pre-layout timing verification

I-cache Integer
• Place functional blocks by considering signal Unit
flow Instruction
Unit
• Consider package specifications, minimize pin I/O Integer
Memory

PLL
Unit
count, and shorten wiring length Unit Register

• Bonding pad layout must be well considered Floating

D-cache1
Register

Floating
Unit D-cache2

Example for floor plan of

processor chip

Page 75
Timing Verification – Methods
Pre-layout timing verification
STA: Static Timing Analysis
• Structure of gate-level logic description is analyzed and then compared with timing constraints
• Test patterns are not required
• Synchronous paths can be 100% verified
• Asynchronous logic and other special circuit cannot be analyzed
• Special paths must be specified manually

DTA: Dynamic Timing Analysis

• Logic simulation handling delay timing is executed
• Verification of all paths is unrealistic because huge test patterns are required

Verify synchronous paths with STA, and use DTA for limited paths that cannot be
checked by STA. Always do synchronous design except for unavoidable case!

Page 76
Timing Verification – STA Basic Algorithm

A
LAT1 C LAT2 STA tool propagates LAT by selecting the maximum
B
of LATs and adding delay of ARC to the LAT.
LAT propagation
LAT: Latest Arrival Time

Sum : d1 + d2 Example
d1 d2 A
24
16
0 N2 N3 37
21 35 51
14
B N1 29 Y
0 14 41
Max : max (d1, d2) N4 88
32 43
C
d1
0
blue italic: gate delay
d2 red: LAT

Page 77
Timing Verification – Design Process

• If the timing doesn't meet the requirement, replace cells and re-route wiring for
better result.
• When it isn't possible to meet the timing requirement by just replacing and
re-routing, then we have to go back to RTL code and have to rewrite the code.

Page 78