TEST PLAN DOCUMENTATION

Version <1.0>
<03/29/2019>
 2

VERSION HISTORY

Ver Implemented Revision Approved Approval Reason

sio By Date By Date
n
#
1.0 Ananthan P 03/29/2019 <mm/dd/yy> Initial Documentation
draft
 3

TABLE OF CONTENTS
1 INTRODUCTION 4

1.1 Objective of The verification PLAN Document 4

1.2 Designer Simulation 4

1.3 Unit Simulation 4

1.4 Chip SIMULATION 4

1.5 Functionl GATE LEVEL EVENT SIMULATION 4

1.6 Verification TOOLS 4

2 VERIFICATION STRATEGY 4

2.1 Assumptions / Constraints / Standards 5

3 TESTBENCH ARCHITECTURE 5

3.1 BLOCK Diagram 5

3.2 sequence 6

3.3 TESTBENCH STRUCTURE 6

3.4 APB SLAVE DEVICE 6

3.5 AGENT 7

3.6 scoreboard 7

4 COVERAGE ANALYSIS 8

4.1 Functional coverage 8

4.2 Code coverage 9

5 ASSERTIONS 9

TESTCASE SCENARIOS 10
Appendix A: References 11
Appendix B: Key Terms 12
 4

1 INTRODUCTION

1.1 OBJECTIVE OF THE VERIFICATION PLAN DOCUMENT

The objective of the verification strategy described here in is to verify the functionality of
the APB BUS MASTER Device. The main verification concerns for this unit are
functional completeness and correctness, data integrity, data coherency and performance.
Testing will be structured to check that all functions are using the right resources at the
right time while many complex scenarios are in progress. Numerous verification methods
such as unit level simulation, chip level simulation , designer simulation and gate level
simulation can be used.
No Formal Verification is planned for this unit
No System Simulation is planned for this unit
No Chip level Simulation planned for this unit
1.2 DESIGNER SIMULATION
1.3 UNIT SIMULATION
Unit level verification of these will be completed by the core team. Verilog simulation
environments described below will be used for the simulation.
The primary simulation environment for the APB Slave device will be the UVM based
functional verification and simulation methodology. This environment is being developed
from UVM methodology based testing environment to ensure high verification coverage
and first-pass chip quality. The scope of the testing in this environment is all mainline data
flows, error detection, error recovery

1.4 CHIP SIMULATION

1.5 FUNCTIONAL GATE LEVEL EVENT SIMULATION
Functional Gate Level event simulation will confirm correct chip integration of clock
control logic , reset and Asynchronous domain crossing. We can do it with and without
timing

1.6 VERIFICATION TOOL:

SYNOPSYS VCS - FOR SIMULATION , CODE COVERAGE AND FUNCTIONAL COVERAGE.

2 VERIFICATION STRATEGY
 5

2.1 ASSUMPTIONS / CONSTRAINTS / STANDARDS

• On reset, all the registers and signals will take initial or default condition .
• Assuming slave device as the DUT.
• The devices connected to bridge is assumed to be 2.So PSELwill be constrained
to 2
• The address range can be assumed to be h0,h1,h2,...etc for device1 and
h11,h12,h13...etc for device 2
• Linted code will be passed on to the verification

3 TESTBENCH ARCHITECTURE

3.1 BLOCK DIAGRAM

apb_top

apb_test
apb_env
apb_sequence
apb_scb
DUT
apb_seq apb_driver APB SLAVE

apb_agent_act
apb_mon_act

apb_agent_pas

apb_mon_pas
 6

3.2 SEQUENCE:
apb write wait sequence : To check the data written correctly to the selected address
of the selected slave device with a wait time.
apb write no wait sequence : To check the data written correctly to the selected
address of the selected slave device with no wait time.
apb read wait sequence : To check the data read correctly from the selected address
of the selected slave device with a wait time.
apb read no wait sequence : To check the data read correctly from the selected
address of the selected slave device without wait time.
apb error sequence:To check the error signal is given from the slave device

3.3 TESTBENCH STRUCTURE

• Test benches are written as UVM methodology

• Contains a DUT slave device designed in verilog which receive the signal from
verification plan
• Top architecture in UVM which contains the test architecture and DUT.
• Contains interface between testbench and DUT.
• Contains test as the next hierarchy level to Top. To select which test to
execute.This will instantiate next hierarchy level that is environment.
• Environment is the next level of hierarchy in which instantiates all other modules
scoreboard,agent.
• Scoreboard contains checkers and verifies the functionality of the design.
• Sequence are the transaction generators or stimuli generators.
• Sequencer allows sequence to communicate to driver.
• Agent contains monitor driver and sequencer(active).Only monitor in case of
Passive ones.
• Monitor captures signal activity from DUT and ref model.
• Driver drives the sequence or stimuli to DUT.

3.4 TOP.SV:
Accomodates DUT, Test,Interfaces between test and DUT,clock ,reset instantiation.
module apb_top;
import uvm_pkg::*;
 7

bit clk;
bit rst;
clock generation
always #5 clk = ~clk;
intrf apb_if(clk);
apb_top dut(.clk(clk),
.rst(rst),
.paddr(paddr),
.pdata(pdata),
.psel(psel),
.penable(penable),
.pready(pready),
.pslverr(pslverr)
);
3.5 APB_ENV:
Used to instantiate entire test components like agent ,scoreboard etc.

class apb_env extends uvm_env;

`uvm_component_utils(apb_env)
apb_agent apb_agent;
apb_scb apb_scb;
virtual intrf vif;
function new(string name, uvm_component parent);
super.new(name, parent);
endfunction: new

3.6 APB_TEST.SV
It comes after top in hierarchy and before environment. Here we are instantiating
environment and all test cases are given to the DUT through test. The objection raising to
inject test case into DUT is done here.
 8

class apb_test extends uvm_test;

`uvm_component_utils(apb_test)
apb_env apb_top_env;
apb_config apb_con;
virtual apb_if vif;

task run_phase(uvm_phase phase);

apb_seq seq;
seq=apb_seq::type_id::create("seq");
phase.raise_objection(this,"starting apb sequence");
$display("%t Starting sequence apb_seq run_phase",$time);
seq.start(env.agt.sqr);
#100ns;
phase.drop_objection( this , "Finished apb_seq in main phase" );
endtask: run_phase

3.7 APB SLAVE DEVICE.V(DUT)

An APB Slave device is any device such as a memory which can write a data into any
specific register inside it which is designated by a specific address and read the data back
from the specific address inside it .
following functionality:
apb_write_wait:write to the specified address register. Wait for writing to complete
transfer
apb_write_no wait:write to the specified address register. No wait for writing to complete
transfer
apb_read_wait:read from the specified address register. Wait for read to complete transfer
apb_read_no wait:read from the specified address register. No wait for read to complete
transfer
1. 
Sample code:
module apb_slave
#(
addrWidth = 32,
dataWidth = 32
)
(
input clk,
 9

input rst_n,
input [addrWidth-1:0] paddr,
input pwrite,
input psel,
input penable,
input [dataWidth-1:0] pwdata,
output logic [dataWidth-1:0] prdata
output logic pready
output logic prdata
);

3.8 DRIVER.SV
Drives the sequence signals coming from from sequencer to DUT. Sequences are exactly
the stimuli.
Reading data from slave and writing data into slave device are the task given to driver.
class apb_driver extends uvm_driver(#apb_seq_item);
`uvm_component_utils(apb_driver)

3.9 MONITOR.SV
Monitor checks the signal activity from DUT and reference model.
class apb_monitor_before extends uvm_monitor;
`uvm_component_utils (apb_monitor_before)
virtual intrf vif;
uvm_analysis_port #(apb_seq_item) mon_analysis_port_before;

3.10 SEQUENCER.SV
Sequencer will transfer sequences to driver to drive it to DUT.
class counter_sequencer extends uvm_sequencer#(counter_seq_item);
`uvm_object_utils(counter_sequencer)
//Constructor
function new(string name = "counter_sequencer");
super.new(name);
endfunction
 10

3.11 SEQUENCE.SV

It generates the stimuli for the testcases.

class counter_sequence extends uvm_sequence;

// [Recommended] Makes this sequence reusable. Note that we are calling

// `uvm_object_utils instead of `uvm_component_utils because sequence is a
uvm_transaction object
`uvm_object_utils (counter_sequence)

// This is standard code for all components

function new (string name = "counter_sequence");
super.new (name);
endfunction

repeat(20)

begin
start_item(req);
assert (req.randomize())
finish_item(req);

3.12 AGENT:
Implemented two agents. An active one and a passive one. The active one is
having a sequencer driver and monitor. Sequences from sequence is given to driver
through sequencer and is given to DUT. Same signal is given to monitor from driver.
In passive agent declare only monitor to check the output from DUT.
3.13 SCOREBOARD.SV
A Scoreboard is a functional block of testbench in UVM Methodology that does the
following:
Receives response data from the monitor block. Here the monitor is present in the passive
agent which takes the responses from DUT.
Fetches expected results from monitor in Active agent which has the expected output and
compares with the response data received from the monitor block in the passive agent
 11

Generates results and stores them for each test case. This aids in generating reports

Scoreboard

Monitor from passive agent Monitor from active agent

3.14

4 COVERAGE ANALYSIS

4.1 FUNCTIONAL COVERAGE

Apply reset to make sure that all the outputs
and internal signals are set to a known value
Apply reset to low after asserting high check
whether it is going to different values
Write to the SLAVE device with wait signal.
Check whether data written to selected device
and to selected address

Write to the SLAVE device with wait signal.

Check whether data written to selected device
and to selected address

Read from the slave device with wait signal.

Check whether data taken from selected device
using PSEL line and device address .

Read from the slave device with no wait signal.

Check whether data taken from selected device
using PSEL line and device address .

Try to read or write to a memory location

whose address is out of the coverage points
and check whether error signal is asserted
 12

without wait signal

Try to read or write to a memory location

whose address is out of the coverage points
and check whether error signal is asserted
with wait signal asserted

4.2 CODE COVERAGE

Expecting a code coverage of 100 percent for the verification to be complete.

5 ASSERTIONS
Reset is set to 1 and reasserted to 0 at power on state. At reset=1 all signal should be in
known or initial condition. At reset=0 only the device starts its normal operation.
 13

TESTCASE SCENARIOS

NO Name of the testcase Specification reference Design Functiona Status

documen l
t coverage
reference reference

1 Power on reset 1 Pass/fail

2. apb_write_with_wait Write to the SLAVE device with wait signal. Pass/Fail

Check whether data written to selected
device and to selected address

3. apb_write_with_no_wa Write to the SLAVE device with wait signal.

it Check whether data written to selected
device and to selected address

4. apb_read_with_wait Read from the slave device with wait signal. Pass/Fail
Check whether data taken from selected
device using PSEL line and device address .

5. apb_read_with_no_wai Read from the slave device with no wait Pass/Fail

t signal. Check whether data taken from
selected device using PSEL line and device
address .

6. apb_error_signal_with Try to read or write to a memory location Pass/Fail

wait whose address is out of the coverage points
and check whether error signal is asserted
without wait signal

7. apb_error_signal_no_w Try to read or write to a memory location Pass/Fail

ait signal whose address is out of the coverage points
and check whether error signal is asserted
with wait signal asserted
 14

Appendix A: References
[Insert the name, version number, description, and physical location of any
documents referenced in this document. Add rows to the table as necessary.]
The following table summarizes the documents referenced in this document.
Document Description Location
Name and
Version
<Document [Provide description of the <URL or Network path where
Name and document] document is located>
Version
Number>
 15

Appendix B: Key Terms

[Insert terms and definitions used in this document. Add rows to the table as
necessary.]
The following table provides definitions for terms relevant to this document.
Term Definition
[Insert Term] [Provide definition of the term used in this document.]

[Insert Term] [Provide definition of the term used in this document.]

[Insert Term] [Provide definition of the term used in this document.]