ASIC DESIGN

The term Asic stands for Application Specific Integrated Circuit. Is an integrated circuit (IC) customized for a particular use, rather than intended for general-purpose
use. Generally an ASIC design ill !e underta"en for a product that ill ha#e a large production run, and the ASIC may contain a #ery large part of the electronics needed
on a single integrated circuit. As feature sizes ha#e shrun" and design tools impro#ed o#er the years, the comple$ity in an ASIC has gron from %,&&& o#er '&& million gates

Mrd
A (ar"eting )e*uirements +ocument (()+) outlines the re*uirements a ne product. ,ngineers use an ()+ to create the product. (ar"eting re*uirement document co#ers
mar"et needs, the customer #alue proposition, and product functionality. It is de#eloped !y the (ar"eting team and upper management.
Architecture Specification
The architect !ased on the ()+ specification, de#elops the o#erall architecture of the chip. This is a #ery high le#el plan. Architecture Specification includes functional
descriptions of each module, -roperties and eights.
Design Specification
The designers and architects sit together to come up ith detailed design documents. +esign strategies, design partitions, type of memories to use, etc.
Verification Plan
A .erification specification is called a .erification/test plan. The #erification engineer goes through all the a!o#e documents and prepares #erification plan to #erify the
design.
Rtl Design
)T0 stands for )egister Transfer 0e#el. The designer starts implementing the )T0 design in 1+0 li"e #erilog or .1+0.
Functional Verification
The #erification engineers starts de#eloping Test2ench and #erifies hether the +3T or"s according to specification or not.
Synthesis
Synthesis is the process of ta"ing a design ritten in a hardare description language, compiling it into a net list of interconnected gates hich are selected from a user-
pro#ided li!rary of #arious gates. The design after synthesis is a gate-le#el design.
Physical Design
-hysical design process includes logic partitioning, floor planning, glo!al routing, detailed routing, compaction, and performance-dri#en layout. -+ team transforms net list
representation of a system into layout representation.
Timing Analysis
Static timing analysis is an important step in analyzing the performance of a design. In the Timing analysis Setup time, hold time ,reco#ery time ,remo#al time , Cloc"
latency, cloc" s"e, cloc" uncertainty etc chec"s are done.
Tapeout
This is the final stage of the design cycle of integrated circuits. 4nce all the chec"s are done, the design is ready to !e sent to 5oundry.
BOTTLE NECK IN ASIC FLOW
6hat is 2ottle nec" in the asic design flo7
.erification consumes %&8 to 9&8 of the effort of design cycle and is on the critical path in the design flo of multimillion gate ASICs, so #erification !ecame the main
!ottlenec" in the design process. The functional #erification !ottlenec" is an effect of rising the design a!straction le#el. (a:ority of ASICs re*uire at least one re-spin ith
9'8 of re-spins are due to functional !ugs.
FUNCTIONAL VERIFICATION NEED
6hy e need functional #erification7
To !uild confidence and stay in !usiness.
A primary purpose for functional #erification is to detect failures so that !ugs can !e identified and corrected !efore it gets shipped to costumer. If )T0 designer ma"es a
mista"e in designing or coding, this results as a !ug in the Chip. If this !ug is e$ecuted, in certain situations the system ill produce rong results, causing a failure. ;ot all
mista"es ill necessarily result in failures. The !ug in the dead code ill ne#er result in failure. A single mista"e may result in a ide range of failure symptoms. ;ot all
!ugs are caused !y coding errors. There are possi!ilities that error may in the specification itself. Sometimes miscommunications !eteen teams may lead to rong
design.
,$ample of coding error<

' reg ='<&> state?
@
A parameter zeroB&, oneB', toB@, threeBA?
C
% always D(state)
E begin
9 case (State)
F zero<
G out B CH!&&&&?
'& one<
'' out B CH!&&&'?
'@ to<
'A out B CH!&&'&?
'C three<
'% out B CH!&'&&?
'E default<
'9 out B CH!&&&&?
'F endcase
'G end


There is a coding error in the preceding e$ample. +esigner declared IstateI in the line-'. 0ater in the code it is reference in the line-%. In the line-9 also, the designer
intention is to refer IstateI. 2ut mista"enly he typed IStateI. .erilog is a case-sensiti#e language, and #aria!le IStateI and IstateI are different and this ill produce rong
results.
TESTBENCH
6hat is Test2ench7
Test2ench mimic the en#ironment in hich the design ill reside. It chec"s hether the )T0 Implementation meets the design spec or not. This ,n#ironment creates
in#alid and une$pected as ell as #alid and e$pected conditions to test the design.
LINEAR TESTBENCH
0inear Test2ench is the simplest, fastest and easiest ay of riting test!enchs. This !ecame no#ice #erification engineer choice. It is also sloest ay to e$ecute stimulus.
Typically, linear test!enchs are ritten in the .1+0 or .erilog. In this Test2ench, simple linear se*uence of test #ectors is mentioned. Stimulus code li"e this is easy to
generate translating a #ector file ith a -erl script, for e$ample. Small models li"e simple state machine or adder can !e #erified ith this approach. The folloing code
snippet shos linear Test2ench. The code snippet shos some input com!ination only. This is also !ad for simulator performance as the simulator must e#aluate and
schedule a #ery large num!er of e#ents. This reduces simulation performance in proportion to the size of the stimulus process.
Typically, linear test!enchs perform the folloing tas"s<
Instantiate the design under test (+3T)
Stimulate the +3T !y applying test #ectors.
4utput results a#eform indo or to a terminal for #isual inspection manually.
,$ample< 0inear Test2ench
module adder(a,!,c)? //+3T code start
input ='%<&> a?
input ='%<&> !?
output ='E<&> c?

assign c B a J !?

endmodule //+3T code end

module top()? //Test2ench code start
reg ='%<&> a?
reg ='%<&> !?
wire ='E<&> c?

adder +3T(a,!,c)? //+3T Instantiation

initial
begin
a B 'EHhC%? //apply the stimulus
! B 'EHh'@?
K'& Ldisplay(I aB8&d,!B8&d,cB8&dI,a,!,c)?
//send the output to terminal for #isual inspection
end
endmodule //Test2ench code end
To test all possi!le scenarios hich are "non to us, it is not an easy tas". +e#elopment time increases e$ponentially as the num!er of scenarios increases and maintain
them is nightmare. Instead of listing out all the possi!le scenarios, pic"up some randomly and chec" the +3T.
;4T, T4 ;4 .4IC, ,;GI;,,)S<
Generally tendency of any no#ice engineer is to see the outputs in the a#eform #ieer. 6a#eform #ieers are for de!ugging designs, not for test!ench. (ost of the
operation in Test2ench e$ecutes in zero time, here a#eform #ieer ill not !e helpful. All the e$amples in the !oo" outputs messages to terminal for analyzing its
!eha#ior.
LINEAR RANDOM TESTBENCH
)andom Test2ench donHt use 1ardcoded #alues li"e linear test!enchs. Input stimulus is generated using random #alues. In .erilog, system function Lrandom pro#ides a
mechanism for generating random num!ers. The function returns a ne A@-!it random num!er each time it is called. These test cases are not easily reada!le and are also
not reusa!le. ;e tests ha#e to !e created hen the specification or design changes, to accommodate the changes. The main disad#antage of this testing is that e ne#er
"no hat random #alues are generated and it may aste simulation cycles !y generating same #alues again and again.
EAMP!E" !inear Random Test#ench
module adder(a,!,c)? //+3T code start
input ='%<&> a,!?
output ='E<&> c?
assign c B a J !?
endmodule //+3T code end

module top()? //Test2ench code start
reg ='%<&> a?
reg ='%<&> !?
wire ='E<&> c?

adder +3T(a,!,c)? //+3T Instantiation

initial
repeat('&&) begin
a B Lrandom? //apply random stimulus
! B Lrandom?
K'& Ldisplay(I aB8&d,!B8&d,cB8&dI,a,!,c)?
end
endmodule //Test2ench code end
HOW TO CHECK THE RESULTS
1o does a .erification engineer chec" hether the results o!tained from the simulation match the original specification of the design7 5or simple test!enchs li"e the
a!o#e, output is displayed in a#eform indo or messages are sent to terminal for #isual chec"ing. .isually chec"ing is the oldest and most la!or intensi#e techni*ue.
The *uality of the #erification depends on the determination and dedication of the indi#idual ho is doing the chec"ing. It is not practical to #erify a comple$ model merely
!y e$amining the a#eform or te$t file. 6hene#er a change is made to the +3T to add a ne feature or to fi$ a !ug, same amount of effort needs to !e deployed to chec"
the simulation results.
SELF CHECKING TESTBENCHS
A self-chec"ing Test2ench chec"s e$pected results against actual results o!tained from the simulation. Although Self-chec"ing test!enchs re*uire considera!ly more effort
during the initial test !ench creation phase, this techni*ue can dramatically )educe the amount of effort needed to re-chec" a design after a change has !een made to the
+3T. +e!ugging time is significantly shortened !y useful error-trac"ing information that can !e !uilt into the Test2ench to sho here a design fails.
A self-chec"ing Test2ench has to ma:or parts, the input !loc"s and output !loc"s.
Input !loc" consist of stimulus and dri#er to dri#e the stimulus to +3T. The output !loc" consists of monitor to collect the +3T outputs and #erify them.
All the a!o#e approaches re*uire the test riter to create an e$plicit test for each feature of the design. .erification approach in hich each feature is ritten in a
separate test case file is called directed #erification.
EAMP!E" adder e$ample
module adder(a,!,c)? //+3T code start
input ='%<&> a,!?
output ='E<&> c?
assign c B a J !?
endmodule //+3T code end

module top()? //Test2ench code start
reg ='%<&> a?
reg ='%<&> !?
wire ='E<&> c?

adder +3T(a,!,c)? //+3T Instantiation

initial
repeat('&&) begin
a B Lrandom? //apply random stimulus
! B Lrandom?
K'&
Ldisplay(I aB8&d,!B8&d,cB8&dI,a,!,c)?
if( a J ! MB c) // monitor logic.
Ldisplay(I N,))4)N I)?
end
endmodule //Test2ench code end
HOW TO GET SCENARIOS WHICH WE NEVER THOUGHT
In +irected #erification, the .erification ,n#ironment has mechanism to send the Stimulus to +3T and collect the responses and chec" the responses. The Stimulus is
generated in Tests case. +irected test!enchs may also use a limited amount of randomization, often !y creating random data #alues rather than simply filling in each data
element ith a predetermined #alue. ,ach test case #erifies specific feature of the design. This !ecomes tedious hen the design comple$ity increases. As circuit
comple$ity increases, it !ecomes more difficult to create patterns that fully e$ercise the design. Test case maintenance !ecome harder and time consuming.

In +irected .erification, test riter has to list out each feature. Test riter canHt thin" of all possi!le potential !ug scenarios and there are chances that 2ugs ill
escape. 6ith these approaches, the !ugs lur"ing in these corners hide until late in the de#elopment cycle, or arenHt found at all until product is taped out.
Solution to the a!o#e pro!lems is Constraint random #erification. 3sing constraint random #erification, the stimulus re*uired to #erify test features are generated
automatically. Test riter specifies set of specification, and the Test2ench automatically creates solution space and pic"s up scenarios from the solution space.
Constraint random #erification also reduces manual effort and code for indi#idual tests. As the scenarios are generated automatically !y the Test2ench, the num!er of test
case files gets reduced. In +irected #erification, some of the tests share similar logic, if the engineer has to change the logic hich is common to certain group of tests,
then he has to edit all the test case files and it is time consuming. 2ut in Constraint random #erification, the num!er of tests case files ill !e #ery less, so changes ill !e
mostly in en#ironment and minimal.
+irected #erification ith a fairly simple Test2ench, #erification engineers can start finding !ugs in simulation almost immediately e#en !efore the Test2ench is fully
completed. 6ith a constrained-random #erification en#ironment, there is an up-front cost that must !e in#ested !efore the first test can !e run. Constraint-!ased
generators can !e easily con#erted into chec"ers if re*uired.
Generating fully randomly is meaningless as it may generate in#alid scenarios and it may also regenerate the same scenario again and again asting potential simulation
time. A 3ser must define data structures, hich represent stimulus applied to the +3T input. ;e$t, constraints must !e defined to guide the random generator. 3sing
constraint, the solution space is defined, and randomization pic"s up scenarios randomly from the solution space. Constraints act as "no!s in the Test2ench hich control
the generatorHs randomness.
The main disad#antage of constraint random #erification is e ne#er "no ho ell the +3T is #erified. If #erification engineer can get the information a!out the logic in
+3T hich is not #erified, he can further constraint the randomization or rite directed testcases to e$ercise the un#erified logic.
HOW TO CHECK WHETHER THE TESTBENCH HAS SATISFACTORILY EXERCISED THE DESIGN
Code co#erage is used to measure the efficiency of #erification implementation. It pro#ides a *uantitati#e measurement of the testing space. It descri!es the degree to
hich the source code of a +3T has !een tested. It is also referred as structural co#erage.
Code co#erage ansers the *uestions li"e
1a#e all the !ranches in I Case I, IifI ha#e !een entered7
1a#e all the conditions in IifI,IcaseI statement is simulated7
1a#e all the #aria!les ha#e !een toggles7
1a#e all the statements of the )T0 code ha#e !een e$ercised7
1a#e all the states in the 5S( has !een entered and all the legal transitions e$ercised7
1a#e all the paths ithin a !loc" ha#e !een e$ercised7
2y applying code co#erage analysis techni*ues to hardare description languages, #erification efficiency as impro#ed !y ena!ling a #erification engineer to isolate areas
of un-tested 1+0 code. The #erification engineer e$amine a co#erage report, see"s out the lo #alues and understands hy that particular code hasnHt !een tested fully
and rites more tests or directs randomness to co#er the untested areas here there may !e a possi!ility of !ug hiding.
;o additional coding is re*uired to get '&& percent code co#erage , the tool ould automatically sho the item as co#ered if the re*uired test scenario(s)/com!ination(s)
is(are) e$ercised.
In unit le#el #erification, a module !y module is #erified in its on test en#ironment to pro#e that the logic, control, and data paths are functionally correct. The goal of
module le#el #erification is to ensure that the component/unit !eing tested conforms to its specifications and is ready to !e integrated ith other su!components of the
product. Code co#erage !ecomes a criterion for finishing unit le#el testing as it needs to #erify e#ery feature of component/unit. In su!-system le#el /system le#el, the
goal is to ensure that the interfaces among the units are correct and the units or" together to e$ecute the functionality correctly. In su! system le#el /system le#el
testing, code co#erage may not !e useful as the #erification is not targeted at all the features of the unit.
TYPES OF CODE COVERAGE
There are a num!er of co#erage criteria, they are<
Statement co#erage /line co#erage
2loc"/segment co#erage
Conditional co#erage
2ranch co#erage
Toggle co#erage
-ath co#erage
5sm co#erage
The folloing e$ample is considered hile e$plaining code co#erage types in further sections.
EAMP!E
'
@ module dut()?
A reg a,!,c,d,e,f?
C
% initial
E begin
9 K% a B &?
F K% a B '?
G end
'&
'' always D(posedge a)
'@ begin
'A c B ! OO a?
'C if(c OO f)
'% ! B e?
'E else
'9 e B !?
'F
'G case(c)
@& '<f B '?
@' &<f B &?
@@ default < f B &?
@A endcase
@C
@% end
@E endmodule
STATEMENT COVERAGE
Statement co#erage, also "non as line co#erage is the easiest understanda!le type of co#erage. This is re*uired to !e '&&8 for e#ery pro:ect. 5rom ; lines of code and
according to the applied stimulus ho many statements (lines) are co#ered in the simulation is measured !y statement co#erage. If a +3T is '& lines long and F lines of
them ere e$ercised in a test run, then the +3T has line co#erage of F&8. 0ine co#erage includes continuous assignment statements, Indi#idual procedural statements,
-rocedural statement !loc"s, -rocedural statement !loc" types, Conditional statement and 2ranches for conditional statements. It considers only it the e$ecuta!le
statements and statements hich are not e$ecuta!le li"e module, endmodule, comments, timescale etc are not co#ered.
Statement co#erage report of the a!o#e e$ample<

There are total '@ statements at lines %,9,F,'','A,'C,'%,'9,'G,@&,@',@@

Co#ered G statements. They are at lines
%,9,F,'','A,'C,'9,'G,@@

3nco#ered A statements. They are at line
'%,@&,@'

Co#erage percentage< 9%.&& (G/'@)
BLOCK COVERAGE
The nature of the statement and !loc" co#erage loo"s somehat same. The difference is that !loc" co#erage considers !ranched !loc"s of if/else, case !ranches, ait,
hile, for etc. Analysis of !loc" co#erage re#eals the dead code in )T0.
2loc" co#erage report of the a!o#e e$ample<
There are total G !loc"s at lines
%,9,F,'','%,'9,@&,@',@@

Co#ered E !loc"s. They are at lines
%,9,F,'','9,@@

3nco#ered A !loc"s. They are at line
'%,@&,@'

Co#erage percentage< EE.E9 (E/G)
CONDITIONAL COVERAGE
Conditional co#erage also called as e$pression co#erage, ill re#eals ho the #aria!les or su!-e$pressions in conditional statements are e#aluated. ,$pressions ith logical
operators are only considered.. The donside is that the conditional co#erage measure doesnHt ta"e into consideration ho the 2oolean #alue as gotten from the
conditions. Conditional co#erage is the ratio of no. of cases chec"ed to the total no. of cases present. Suppose one e$pression ha#ing 2oolean e$pression li"e A;+ or 4), so
entries hich is gi#en to that e$pression to the total possi!ilities is called e$pression co#erage.
Conditional co#erage report of the pre#ious e$ample<
At 0I;, 'A
Com!inations of STAT,(,;T c B (! OO a)
2 B & and a B & is Co#ered
2 B & and a B ' is Co#ered
2 B ' and a B & is ;ot Co#ered
! B ' and a B ' is ;ot Co#ered

At 0I;, 'C com!inations of STAT,(,;T if ((c OO f))
C B & and f B & is Co#ered
C B & and f B ' is ;ot Co#ered
C B ' and f B & is ;ot Co#ered
C B ' and f B ' is ;ot Co#ered

Total possi!le com!inations< F
Total com!inations e$ecuted< A
BRANCH COVERAGE
2ranch co#erage hich is also called as +ecision co#erage report s the true or false of the conditions li"e if-else, case and the ternary operator (7 <) statements. 5or an IifI
statement, decision co#erage ill report hether the IifI statement is e#aluated in !oth true and false cases, e#en if IelseI statement doesnHt e$ist.
2ranch co#erage report of the e$ample<

At line '% !ranch ! B e? not co#ered
At line '9 !ranch e B !? co#ered
At line @& !ranch '< f B '? not co#ered
At line @' !ranch &< f B &? co#ered
At line @@ !ranch default< f B &? not co#ered

Co#erage percentage< C&.&& (@/%)
PATH COVERAGE
-ath co#erage represents yet another interesting measure. +ue to conditional statements li"e if-else, case in the design different path is created hich di#erts the flo of
stimulus to the specific path.
-ath co#erage is considered to !e more complete than !ranch co#erage !ecause it can detect the errors related to the se*uence of operations. As mentioned in the a!o#e
figure path ill !e decided according to the if-else statement According to the applied stimulus the condition hich is satisfied only under those e$pressions ill e$ecute,
the path ill !e di#erted according to that. -ath co#erage is possi!le in alays and function !loc"s . -ath created !y more than one !loc" is not co#ered. Analysis of path
co#erage report is not so easy tas".
-ath co#erage report of the e$ample<

-ath ' < '%,@& ;ot Co#ered
-ath @ < '%,@' ;ot Co#ered
-ath A< '%,@@ ;ot Co#ered
-ath C< '9,@& ;ot Co#ered
-ath % < '9,@' Co#ered
-ath E < '9,@@ ;ot Co#ered

Total possi!le paths < E
Total co#ered path < '
-ath co#erage -ercentage < 'E.E9 ('/E)
TOGGLE COVERAGE
It ma"es assures that ho many times #aria!les and nets toggled7 Toggle co#erage could !e as simple as the ratio of nodes toggled to the total num!er of nodes.
P or Q --R ' or 1
P or Q --R & or 0
' or 1 --R P or Q
& or 0 --R P or Q
A!o#e e$ample shos the signal changes from one le#el to another. All types of transitions mentioned a!o#e are not interested. 4nly '-R& and &-R' are important. Toggle
co#erage ill sho hich signal did not change the state. Toggle co#erage ill not consider zero-delay glitches. This is #ery useful in gate le#el simulation.
Toggle co#erage report of the e$ample<
;ame Toggled '-R& &-R'
a ;o ;o Ses
! ;o ;o ;o
c ;o ;o ;o
d ;o ;o ;o
e ;o ;o ;o
f ;o ;o ;o
FSM COVERAGE
It is the most comple$ type of code co#erage, !ecause it or"s on the !eha#ior of the design. 3sing 5inite state machine co#erage, all !ugs related to finite state machine
design can !e found. In this co#erage e loo" for ho many times states are #isited, transited and ho many se*uence are co#ered in a 5inite state machine.
State %o&erage"
It gi#es the co#erage of no. of states #isited o#er the total no. of states. Suppose you ha#e ; num!er of states and state machines transecting is in !eteen only ;-@ states
then co#erage ill gi#e alert that some states are unco#ered. It is ad#ised that all the states must !e co#ered.
Transition %o&erage"
It ill count the no. of transition from one state to another and it ill compare it ith other total no. of transition. Total no. of transition is nothing !ut all possi!le no. of
transition hich is present in the finite state machine. -ossi!le transition B no. of states N no. of inputs.
EAMP!E of FSM"
module fsm (cl", reset, in)?
input cl", reset, in?
reg ='<&> state?

parameter s' B @H!&&? parameter s@ B @H!&'?
parameter sA B @H!'&? parameter sC B @H!''?

always D(posedge cl" or posedge reset)
begin
if (reset) state TB s'?
else case (state)
s'<if (in BB 'H!') state TB s@?
else state TB sA?
s@< state TB sC?
sA< state TB sC?
sC< state TB s'?
endcase
end
endmodule

module test!ench()?
reg cl",reset,in?

fsm dut(cl",reset,in)?

initial
fore&er K% cl" B Ucl"?

initial
begin
cl" B&?in B &?
K@ reset B &?K@ reset B '?
K@' reset B &?KG in B &?
KG in B '?K'& Lfinish?
end

endmodule
5S( co#erage report for the a!o#e e$ample<

// state co#erage results
s' V Co#ered
s@ V ;ot Co#ered
sA V Co#ered
sC V Co#ered
// state transition co#erage results
s'-Rs@ V ;ot Co#ered
s'-RsA V Co#ered
s@-Rs' V ;ot Co#ered
s@-RsC V ;ot Co#ered
sA-Rs' V ;ot Co#ered
sA-RsC V Co#ered
sC-Rs' V Co#ered
MAKE YOUR GOAL 100 PERCENT CODE COVERAGE NOTHING LESS
;e#er set your goal to anything less than '&&8 code co#erage. Anything less than '&&8 is a slippery slope. If you set your goal to GF8 , may !e the most important feature
li"e reset of the system may !e in the untested part of@8. If the #erification engineer sets the code co#erage goal to G%8 to facilitate the %8 the unused untesta!le legacy
code, there are chances that the unused legacy code gets e$ecuted and the %8 holes may !e in the important code. '&&8 code co#erage pro#ides ad#antages not only in
reducing the !ug count !ut also in ma"ing it easier to ma"e significant changes to e$isting code !ase to remo#e unco#er a!le areas li"e the unused legacy !loc"s in )T0
code.
Dont #e Fooled #y The %ode %o&erage Report
1ighly co#ered code isnHt necessarily free of defects, although itHs certainly less li"ely to contain them. 2y definition, code co#erage is limited to the design code. It doesnHt
"no anything a!out hat design supposed to do. ,#en If a feature is not implemented in design, code co#erage can report '&&8 co#erage. It is also impossi!le to
determine hether e tested all possi!le #alues of a feature using code co#erage. 5or e$ample, randomization may not generate pac"ets ith all possi!le lengths, this
cannot !e reported !y code co#erage.. Code co#erage is una!le to tell much a!out ho ell you ha#e co#ered your logic -- only hether youH#e e$ecuted each line/!loc"
etc at least once. Code co#erage does not pro#ide information a!out your test !ench randomization *uality and it does not report hat caused the line e$ecution/state
transition etc. Analysis of code co#erage re*uire "noledge of design to find hich features are not #erified hich is time consuming and out of scope of #erification
engineer. If the analysis is done at higher le#el of a!straction, it ould !e easier for the test riter to identify the missed serious hich is not possi!le !y code
co#erage. So if the code co#erage is less than '&&8, it means there is more or" to do, if it is '&&8, it doesnHt mean that the #erification is complete.
'hen To Stop Testing(
ItHs getting harder to figure out hen to stop testing as the comple$ity of the protocol is increasing. In directed test en#ironment, for each point mentioned in test plan,
there ill !e a separate test case file. So if there are '&& points in test plan, then the engineer has to rite '&& test case files. After riting and e$ecuting the '&& test
case files, e can say that Iall the points in test plan are #erifiedI and e can stop testing.
FUNCTIONAL COVERAGE
In C)., the each point in test plan is generated automatically. As there points are generated automatically, e need a mechanism hich tells us that all the points in test
plan are not e$ercised. 6hen all the points in testplans are #erified and the code co#erage is '&&8 e can stop #erification.
6hat are the untested features7
In +irected #erification, there ill !e a separate testcase file for each feature to !e #erified. So to "no ho many features are #erified, count the testcases. .erification
is done hen all tests are coded and passing alone ith '&&8 code co#erage. In constraint random #erification all the features are generated randomly. .erification
engineer need a mechanism to "no the information a!out the #erified features of +3T.
System.erilog pro#ides a mechanism to "no the untested feature using functional co#erage. 5unctional Co#erage is IinstrumentationI that is manually added to the
Test2ench. This is a !etter approach then counting testcases. 5unctional co#erage is !etter than code co#erage here the code co#erage reports hat as e$ercised
rather that hat as tested.
5unctional co#erage ansers *uestions li"e
1a#e all the pac"ets length !eteen EC to '%'F are used7
+id the +3T got e$ercised ith alternate pac"ets ith good and !ad crc7
+id the monitor o!ser#e that the result comes ith C cloc" cycles after read operation7
+id the fifos are filled completely7
Summary of functional co#erage ad#antages<
5unctional co#erage helps determine ho much of your specification as co#ered.
5unctional co#erage *ualifies the test!enchs.
Considered as stopping criteria for unit le#el #erification.
Gi#es feed!ac" a!out the untested features.
Gi#es the information a!out the redundant tests hich consume #alua!le cycle.
Guides to reach the goals earlier !ased on grading.
)ntroduction To Functional %o&erage"
System.erilog pro#ides @ ays to mention co#erage. Co#er group hich is uses information from transactor, monitor and chec"er. Assertion co#erage hich is uses temporal
language hich can !e outside or inside )T0 code.
Co#ergroup<
There are three types of co#er group points<
'. item functional co#erage point
@. cross functional co#erage point
A. transitional functional co#erage point
)tem
IItemI is used to capture the information a!out the sclare #alue. A range of interested #alues can also !e o!ser#ed.
5or e$ample, consider a pac"et protocol. The pac"et has a address field ith possi!le #alues of A&,A' and data hich can !e C to '& !ytes. At the end of pac"et parity is
also attached for integrity chec"ing.
The folloing ta!le identifies these co#erage points for the a!o#e pac"et<
ItemW+0 +ata length C to '&
ItemWA++ Address A&,A'
ItemW-ar -arity Good and 2ad
Co#erage engine collects item #alues are during simulation and reports.
)eports consists ho many times
-ac"ets ith length C,%,E,9,F,G,'& are generated.
-ac"ets ith good parity, !ad parity are generated.
-ac"ets ith address A&, A' are generated.
%ross
IcrossI is used to e$amine the cross product of to or more item co#erage points.
,$ample< #erify +3T !y sending !oth good parity and !ad parity pac"ets ith all the address.
CrossW A++W-ar ItemWA++,ItemW-ar
Co#erage report consists ho many times
-ac"ets ith Address A& ith good parity are generated
-ac"ets ith Address A& ith !ad parity are generated
-ac"ets ith Address A' ith good parity are generated
-ac"ets ith Address A' ith !ad parity are generated
Transitional
Transitional functional point is used to e$amine the legal transitions of a #alue.
,$ample<
.erify the +3T ith incremental pac"et length from C to '&.
TransWlength ( C BR % BR E BR 9 BR F BRG BR'&)
Co#erage engine reports hether this se*uence is e$ercised or not.
Assertion %o&erage"
Assertion co#erage loo"s for the desired !eha#ior in )T0. It uses assertion language hich is in temporal nature. It has direct access to design #aria!les and designer can
add many points in )T0 hich he ants the #erification engineer to co#er.
,$ample< .erify !y sending !ac"-to-!ac" pac"ets.
5unctional co#erage ill !e discussed in more detail in later chapters.
.erification using functional co#erage and randomization is called co#erage dri#en constraint random #erification.
COVERAGE DRIVEN CONSTRAINT RANDOM VERIFICATION ARCHITECTURE
2asic functionality of C+). ,n#ironment<
Input side of +3T <
-- Generating traffic streams
-- +ri#ing traffic into the design (stimuli)
4utput side of +3T<
-- Chec"ing these data streams
-- Chec"ing protocols and timing
Collecting !oth the functional co#erage and code co#erage information.
6riting deterministic tests and random tests to achie#e '&&8 co#erage.

Verification %omponents Re*uired For %dcr&"
Stimulus
Stimulus generator
Transactor
+ri#er
(onitor
Assertion monitor
Chec"er
Score!oard
Co#erage
3tilities
Tests

Stimulus"
6hen !uilding a #erification en#ironment, the #erification engineer often starts !y modeling the de#ice input stimulus. In .erilog, the #erification engineer is limited in ho
to model this stimulus !ecause of the lac" of high-le#el data structures. Typically, the #erification engineer ill create a array/memory to store the stimuli. System.erilog
pro#ides high-le#el data structures and the notion of dynamic data types for modeling stimulus. 3sing System.erilog randomization, stimulus is generated
automatically. Stimulus is also processed in other #erification components. System.erilog high-le#el data structures helps in storing and processing of stimulus in an
efficient ay.
Stimulus +enerator
The generator component generates stimulus hich are sent to +3T !y dri#er. Stimulus generation is modeled to generate the stimulus !ased on the specification. 5or
simple memory stimulus generator generates read, rite operations, address and data to !e stored in the address if its rite operation. Scenarios li"e generate alternate
read/rite operations are specified in scenario generator. System.erilog pro#ided construct to control the random generation distri!ution and order. Constraints defined in
stimulus are com!inatioural in nature here as constraints defined in stimulus generators are se*uential in nature.
Stimulus generation can !e directed or directed random or automatic and user should ha#e proper controlla!ility from test case. It should also consider the generation of
stimulus hich depends on the state of the +3T for e$ample, Generating read cycle as soon as interrupt is seen. ,rror in:ection is a mechanism in hich the +3T is #erified
!y sending error input stimulus. Generally it is also ta"en care in this module.
Generally generator should !e a!le to generate e#ery possi!le scenario and the user should !e a!le to control the generation from directed and directed random testcases.
Transactor
Transactor does the high le#el operations li"e !urst-operations into indi#idual commands, su!-layer protocol in layered protocol li"e -ci,$press Transaction layer o#er
-ci,$press +ata 0in" 0ayer, TC-/I- o#er ,thernet etc. It also handles the +3T configuration operations. This layer also pro#ides necessary information to co#erage model
a!out the stimulus generated. Stimulus generated in generator is high le#el li"e -ac"et is ith good crc, length is % and da is FTG@Rh&. This high le#el stimulus is con#erted
into lo le#el data using pac"ing. This lo le#el data is :ust a array of !its or !ytes. -ac"ing is an operation in hich the high le#el stimulus #alues scalars, strings, array
elements and struct are concatenated in the specified manner.
Dri&er
The dri#ers translate the operations produced !y the generator into the actual inputs for the design under #erification. Generators create inputs at a high le#el of
a!straction namely, as transactions li"e read rite operation. The dri#ers con#ert this input into actual design inputs, as defined in the specification of the designs
interface. If the generator generates read operation, then read tas" is called, in that, the +3T input pin IreadWriteI is asserted.
Monitor
(onitor reports the protocol #iolation and identifies all the transactions. (onitors are to types, -assi#e and acti#e. -assi#e monitors do not dri#e any signals. Acti#e
monitors can dri#e the +3T signals. Sometimes this is also refered as recei#er. (onitor con#erts the state of the design and its outputs to a transaction a!straction le#el so
it can !e stored in a Hscore-!oardsH data!ase to !e chec"ed later on. (onitor con#erts the pin le#el acti#ities in to high le#el.
Assertion #ased Monitor
Assertions are used to chec" time !ased protocols, also "non as temporal chec"s.
Assertions are a necessary compliment to transaction !ased testing as they descri!e the pin le#el, cycle !y cycle, protocols of the design. Assertions are also used for
functional co#erage.
Data %hec,er
The monitor only monitors the interface protocol. It doesnHt chec" the hether the data is same as e$pected data or not, as interface has nothing to do ith the date.
Chec"er con#erts the lo le#el data to high le#el data and #alidated the data. This operation of con#erting lo le#el data to high le#el data is called 3npac"ing hich is
re#erse of pac"ing operation. 5or e$ample, if data is collected from all the commands of the !urst operation and then the data is con#erted in to ra data , and all the su!
fields information are e$tracted from the data and compared against the e$pected #alues. The comparison state is sent to score!oard.
Scoreboard
Score!oard is sometimes referred as trac"er. Score!oard stores the e$pected +3T output. Score!oard in .erilog tends to !e cum!ersome, rigid, and may use up much
memory due to the lac" of dynamic data types and memory allocation. +ynamic data types and +ynamic memory allocation ma"es it much easier to rite a score!oard in
System.erilog. The stimulus generator generated the random #ectors and is sent to the +3T using dri#ers. These stimuli are stored in score!oard until the output comes
out of the +3T. 6hen a rite operation is done on a memory ith address '&' and data @&@, after some cycles, if a read is done at address '&', hat should !e the
data7.The score !oard recorded the address and data hen rite operation is done. Get the data stored at address of '&' in score!oard and compare ith the output of the
+3T in chec"er module. Score!oard also has e$pected logic if needed. Ta"e a @ inputs and gate. The e$pect logic does the Iand I operation on the to inputs and stores the
outputI.
%o&erage
This component has all the co#erage related to the functional co#erage groups.
-tilities
3tilities are set of glo!al tas"s hich are not related to any protocol. So this module can !e reused across pro:ects ithout any modification to code. Tas"s such as glo!al
timeout, printing messages control, seeding control, test pass/fail conditions, error counters etc. The tas"s defined in utilities are used !y all other components of the
Test2ench.
En&ironment"
,n#ironment contains the instances of all the #erification component and Component connecti#ity is also done. Steps re*uired for e$ecution of each component is done in
this.
Tests
Tests contain the code to control the Test2ench features. Tests can communicate ith all the Test2ench components. 4nce the Test2ench is in place, the #erification
engineer no needs to focus on riting tests to #erify that the de#ice !eha#es according to specification.
PHASES OF VERIFICATION

Verification Plan
In test plan, e prepare a road map for ho do achie#e the goal, it is a li#ing document. Test plan includes, introduction, assumptions, list of test cases, list of features to
!e tested, approach, deli#era!les, resources, ris"s and scheduling, entry and e$it criteria. Test plan helps #erification engineer to understand ho the #erification should
!e done. A test plan could come in many forms, such as a spreadsheet, a document or a simple te$t file. Sometimes, test plan simply reside in the engineerHs head hich is
dangerous in hich the process cannot !e properly measured and controlled. Test plan also contains the descriptions of Test2ench architecture and description of each
component and its functionality.
#uilding Testbench
In this phase, the #erification en#ironment is de#eloped. ,ach #erification component can !e de#eloped one !y one or if more than one engineer is or"ing it can !e
de#eloped parallel. 6riting the co#erage module can !e done at any time. It is preffered to rite don the co#erage module first as it gi#es some idea of the #erification
progress.
'riting Tests
After the Test2ench is !uilt and integrated to +3T, itHs time for #alidating the +3T. Initially in C+., the test are ran randomly till some 9& 8 of co#erage is reached or no
impro#ement in the co#erage for ' day simulation. 2y analyzing the co#erage reports, ne tests are ritten to co#er the holes. In these tests, randomization is directed to
co#er the holes. Then finally, the hard to reach scenarios, called as corner cases ha#e to !e ritten in directed #erification fashion. 4f course, de!ugging is done in
parallel and +3T fi$es are done.
)ntegrating %ode %o&erage
4nce you ha#e achie#ed certain le#el of functional co#erage, integrate the code co#erage. 5or doing code co#erage, the code co#erage tools ha#e option to sitch it on.
And then do the simulation, the tool ill pro#ide the report.
Analy.e %o&erage
5inally analyze !oth functional co#erage and code co#erage reports and ta"e necessary steps to achie#e co#erage goals. )un simulation again ith a different seed, all the
hile collecting functional co#erage information.
ONES COUNTER EXAMPLE
5olloing e$ample is Test2ench for ones counter. It has some #erification components hich are re*uired, !ut not all the #erification components discussed earlier. All the
components implementation can !e seen in further chapters ith another protocol. +escription of the language construct is discussed in further chapters, so donHt pay
attention to them. The intention of shoing this e$ample is to ma"e you familiar ith some steps re*uired hile !uilding #erification en#ironment and to help you to
understand the flo discussed a!o#e.
Specification"
4nes Counter is a Counter hich counts the num!er of oneHs coming in serial stream. The (inimum #alue of the count is I&I and count starts !y incriminating one till
I'%I. After I'%I the counter rolls !ac" to I&I. )eset is also pro#ided to reset the counter #alue to I&I. )eset signal is acti#e negedge. Input is ' !it port for hich the serial
stream enters. 4ut !it is C !it port from here the count #alues can !e ta"en. )eset and cloc" pins also pro#ided.

The folloing is the )T0 code of onescounter ith !ugs.
module dff(cl",reset,din,dout)?
input cl",reset,din?
output dout?
logic dout?

alwaysD(posedge cl",negedge reset)
if(Mreset)
dout TB &?
else
dout TB din?
endmodule

module onesWcounter(cl",reset,data,count)?
input cl",reset,data?
output =&<A> count?

dff d'(cl",reset,data,count=&>)?
dff d@(count=&>,reset,Ucount='>,count='>)?
dff dA(count='>,reset,Ucount=@>,count=@>)?
dff dC(count=@>,reset,Ucount=A>,count=A>)?

endmodule

Test Plan"
This is a simple testplan. 5eatures to !e #erified are
') Count should increment from I&I to I'%I.( Co#erage item)
@) Count should roolo#er to I&I after I'%I.(Co#erage transition)
A) )eset should ma"e the output count to I&I, hen the count #alues is non I&I. ( Assertion co#erage)
#loc, Diagram"
Verification En&ironment /ierarchy
T4-
V-- Cloc" generator
V-- +ut Instance
V-- Interface
V-- Assertion !loc" instance ( assertion co#erage)
V-- Testcase instance
V-- ,n#ironment
V-- +ri#er
V V-- Stimulus
V V-- Co#ergroup
V-- (onitor
V-- Score!oard

Testbench %omponents"
Stimulus
Stimulus is a single !it #alue.
class stimulus?
rand bit #alue?
constraint distri!ution X#alue dist X & <B ' , ' <B ' Y? Y
endclass
Dri&er
This dri#er consists of reset and dri#e method. )eset method resets the +3T and dri#e method generates the stimulus and sends it to +3T. +ri#er also calculates the
e$pected +3T output and stores in score!oard. Co#erage is also sampled in this component. 5eature ' and @ hich are mentioned in Testplan are co#ered in this co#er
group.

class dri#er?
stimulus sti?
Score!oard s!?

co&ergroup co#?
5eatureW'< co&erpoint s!.store ?
5eatureW@ < co&erpoint s!.store X bins trans B ( '% BR &) ?Y
endgroup

&irtual intfWcnt intf?

function ne(&irtual intfWcnt intf,score!oard s!)?
this.intf B intf?
this.s! B s!?
co# B ne()?
endfunction

tas, reset()? // )eset method
intf.data B &?
D (negedge intf.cl")?
intf.reset B '?
D (negedge intf.cl")?
intf.reset B &?
D (negedge intf.cl")?
intf.reset B '?
endtas,

tas, dri#e(input integer iteration)?
repeat(iteration)
begin
sti B ne()?
D (negedge intf.cl")?
if(sti.randomize()) // Generate stimulus
intf.data B sti.#alue? // +ri#e to +3T
s!.store B s!.store J sti.#alue?// Cal e$p #alue and store in Score!oard
if(sti.#alue)
co#.sample()?
end
endtas,
endclass
Monitor
The monitor collects the +3T output and then gets the e$pected #alue from the score !oard and compares them.
class monitor?
score!oard s!?
&irtual intfWcnt intf?

function ne(&irtual intfWcnt intf,score!oard s!)?
this.intf B intf?
this.s! B s!?
endfunction

tas, chec"()?
fore&er
D (negedge intf.cl")
if(s!.store MB intf.count) // Get e$pected #alue from score!oard and compare ith +3T output
Ldisplay(I N ,))4) N +3T count is 8! << S2 count is 8! I, intf.count,s!.store)?
else
Ldisplay(I +3T count is 8! << S2 count is 8! I, intf.count,s!.store )?
endtas,
endclass
Assertion %o&erage
This !loc" contains the assertion co#erage related to A rd feature mentioned in testplan.
module assertionWco#(intfWcnt intf)?
5eatureWA < co&er property (D(posedge intf.cl") (intf.count MB&) V-R intf.resetBB & )?
endmodule
Scoreboard
This score!oard is a simple one hich stores one e$pected #alue.
class score!oard?
bit =&<A> store?
endclass
En&ironment"
,n#ironment contains instances of dri#er, monitor and score!oard.
class en#ironment?
dri#er dr#r?
score!oard s!?
monitor mntr?
&irtual intfWcnt intf?

function ne(&irtual intfWcnt intf)?
this.intf B intf?
s! B ne()?
dr#r B ne(intf,s!)?
mntr B ne(intf,s!)?
for,
mntr.chec"()?
0oin1none
endfunction

endclass

Top"
The interface is declared and the test !ench and +3T instances are ta"en. Test!ench and +3T are connected using interfaces. Cloc" is also generated and connects it to
+3T and test!ench.
interface intfWcnt(input cl")?
wire cl"?
wire reset?
wire data?
wire =&<A> count?
endinterface


module top()?
reg cl" B &?
initial // cloc" generator
fore&er K% cl" B Ucl"?

// +3T/assertion monitor/testcase instances
intfWcnt intf(cl")?
onesWcounter +3T(cl",intf.reset,intf.data,intf.count)?
testcase test(intf)?
assertionWco# aco#(intf)?
endmodule
Tests"
This is a simple test case. It does reset and then send '& input #alues.
program testcase(intfWcnt intf)?
en#ironment en# B ne(intf)?

initial
begin
en#.dr#r.reset()?
en#.dr#r.dri#e('&)?
end
endprogram
After simulating ith this testcase, the co#erage report I got
Total %o&erage Summary
SC4), ASS,)T G)43-
G.AF &.&& 'F.9%
%o&er group report
.A)IA20, ,P-,CT,+ 3;C4.,),+ C4.,),+ -,)C,;T G4A0 6,IG1T
5eatureW' 'E '& E A9.%& '&& '
5eatureW@ ' ' & &.&& '&& '
Assertion co&erage report"
C4.,) -)4-,)TI,S CAT,G4)S S,.,)ITS ATT,(-TS (ATC1,S I;C4(-0,T,
5eatureWA & & 'A & &
This co#erage report ill !e different if you simulate in your tool.
To impro#e the co#erage, than the 'st testcase , I rote @nd testcase ith more input #alues and also logic related to A feature in the testplan.
program testcase(intfWcnt intf)?
en#ironment en# B ne(intf)?

initial
begin
en#.dr#r.reset()?
en#.dr#r.dri#e('&&)?
en#.dr#r.reset()?
en#.dr#r.dri#e('&&)?
end
endprogram
Download the phase 2 files"
onesWcounter.tar
2rose the code in onesWcounter.tar
Run the simulation"
yourWtoolWcommand -f filelist testW'.s#
yourWtoolWcommand -f filelist testW@.s#
Simulation !og Report"
+3T count is &$$$ << S2 count is &&&&
+3T count is &$$$ << S2 count is &&&&
+3T count is &&&& << S2 count is &&&&
+3T count is &&&& << S2 count is &&&&
N ,))4) N +3T count is '''' << S2 count is &&&'
N ,))4) N +3T count is &''' << S2 count is &&&'
N ,))4) N +3T count is &''' << S2 count is &&&'
N ,))4) N +3T count is &''' << S2 count is &&&'
N ,))4) N +3T count is '&'' << S2 count is &&'&
N ,))4) N +3T count is '&'' << S2 count is &&''
+3T count is &&'' << S2 count is &&''
+3T count is &&'' << S2 count is &&''
N ,))4) N +3T count is ''&' << S2 count is &'&&
VERIFICATION PLAN
The .erification -lan is the focal point for defining e$actly hat needs to !e tested, and dri#es the co#erage criteria. Success of a #erification pro:ect relies hea#ily on the
completeness and accurate implementation of a #erification plan. A good plan contains detailed goals using measura!le metrics, along ith optimal resource usage and
realistic schedule estimates. .erification plan gi#es an opportunity to present and re#ie the strategy for functional #erification !efore the #erification engineer ha#e gone
into detail to implement it. It also esta!lishes proper communication. Zust imagine ho it ould !e or"ing ith a multisite pro:ect and you ha#e a *uery for hich you
ha#e to ait till the ne$t day to see the anser in email and they :ust call you hile you are in sleep. It also gi#es an idea a!out the areas that are going to !e difficult to
#erify for ta"ing necessary steps. It is used to determine the progress and completion of the #erification phase of #erification. .erification -lanning should start early ith
system/architecture e#aluation phase. 4nce the functional spec is gi#en to the #erification team, they ill start its de#elopment.
A #erification plan could come in many forms, such as a spreadsheet, a document or a simple te$t file. Templates are good if continually used in your company as it ma"es
common interface for information, re#ieer "no here to loo" for certain information e#en in a huge document that he ants to "no at this moment, !ecause different
re#ieers ant different infomation in different moments.
Generally .erification plan de#elopment is di#ided in to steps< 6hat to #erify and 1o to #erify7
Step one< 6hat to .erify7
list of clearly defined features-to-#erify. This is called feature e$traction phase.
Step to< 1o to .erify7
After defining hat e$actly need to !e #erified, define ho to #erify them.
Verification Plan %ontains The Following"
4#er#ie
)esources, 2udget and Schedule
.erification ,n#ironment
System .erilog .erification 5lo
5eature ,$traction
Stimulus Generation -lan
Chec"er -lan
Co#erage -lan
+etails of reusa!le components

3&er&iew
This section contains description of the pro:ect, hat specification is folloed, hat languages and methodology are used. Information related to the 16 !loc"s, S6
!loc"s and 16/S6 interaction is outlined.
Feature E$traction
This section contains list of all the features to !e #erified. Generally each feature is associated ith
'. 3ni*ue ;ame Id
@. +escription
A. ,$pected result
C. -ointer to the specification
%. priority.
The I3ni*ue name I+I should !e descripti#e in nature to understand the nature of the feature and should !e uni*ue. 5or e$ample, Tmodule nameRWTsu! moduleRWTfeature
num!erRWTfeature nameR
Some points on ho e$traction the features<
)ead the ()+, System Specification, (acro and (icro 1ardare Specification.
Go through the designer notes/presentations.
Annotate each line/paragraph specifying a functional item e.g., read/rite a register
Annotate each line/paragraph specifying a multiple-functional items e.g., steps re*uired to set and cause an interrupt .
Identify all )T0 configurations
Identify interfaces and related protocols across interface.
Identify standards compliance re*uirements, list corner cases.
Create a list of illegal scenarios to #erify.
Create a list of e$ceptions to #erify.
Create a list of operation se*uences to #erify e.g., interrupt folloed !y !rea"point etc.
Create a list of things to try and !rea" the machine.
Ta"e ad#antage of e$isting plans.
3se points from compliance chec"list for standard protocols.
Get information a!out the Common tests for all chips.
Get re#ie !y a num!er of people, usually #ery e$perienced engineers. 2etter if you get re#ieed !y Architects, micro Architects, 0eads, #erification engineers, )T0
+esigners, softare designers, mar"eting team and other team mem!ers.
Resources4 #udget And Schedule
This section contains details of man poer re*uired and schedule for each phase of the #erification. Information a!out the tools hich are used for simulation, de!ugger
and !ug trac"ing are listed.
Verification En&ironment
A detailed Test2ench architecture is essential for a ro!ust #erification en#ironment. In this section descri!e the topology, a!out each component of the Test2ench, special
techni*ues that are used, I-s, )eused !loc"s, ne !loc"s, and guidelines on ho to reuse the Test2ench components. 5or e$ample if you thin" upfront a!out error
in:ection, configuration, component communication, call!ac"s etc, you can pro#ide hoo"s to do those.
System Verilog Verification Flow
+etails a!out each le#el (!loc", su!-system, system) and phases ()T0, gate) of #erification are mentioned.
Stimulus +eneration Plan
The stimulus generation section contains information a!out different types of transactions, se*uences of transactions and #arious scenarios generated as per the
specification.

,ach point is associated ith
'. 3ni*ue name I+
@. Stimulus to !e generated for dri#ing into the +3T
A. Configuration/constraints Information
%hec,er Plan
This section ill e$plain the e$pected result chec"ingHs in the Test2ench. This can !e done in monitor/chec"er.
.arious fields associated ith each of the point are<
'. Chec"er 3ni*ue name
@. 3ni*ue 5eature I+(+efined in 5eature plan)
A. Chec"er +escription
%o&erage Plan
The co#erage section e$plains the functional co#erage of the features. A functional co#erage plan should !e !uilt to help implement co#erage points in the #erification
en#ironment. Genarally it ould !e !etter if the co#erage !loc" is !roc"en !ased on the design logical !loc"s. It ill list the #arious Co#erage groups and assertion.
.arious fields of the co#erage plan section are<
'. Co#erage Group
@. Co#erage +escription
A. Co#erage name
C. 3ni*ue name I+ (+efined in feature plan)
%. Co#er point (Items/cross/transition/assertion)
E. Co#erage goal
Details 3f Reusable %omponents
This section contains the details of reusa!le components and the description a!out their usage.