SESSION#1

  1. To record a pattern
    • GVIM escape mode
    • q : starts recording
      any charaterct in to which we want to record
      qa (recording starts in a)
      :map 3 @a
      53 enter => function will repeat 5 times(ehaterver pattern we recorded, it will happen 5 times now)
      203 enter => function will repeat 20 times(ehaterver pattern we recorded, it will happen 20 times now)
    • full stop : does only one pattern repetition
    • function : does multiple pattern repetitions
  2. CTAGs
    o big projects has lot of files spread across various directories in various paths.
    o Debug
    o many times we need to search for task and function definition and some keyword definitions.
    o CTAGS
    o tool which we can run and create tags
    o write_reg is a function
    o once CTAGS is run, this function will be mapped to all the files this function gets used or defined in.
    o We can map CTAGS to GVIM editor
    o using some shortcuts(5 varieties), we can search quickly where all above write_reg function is present
    o we can directly open that files
    o without using grep or find or locate
  3. to User GVIM CTRL+P, be in Insert mode
    o where we want a want which is already present in the file, go there, insert mode, CTRL+P, desired word selected, Escape
  4. Literals in SV
    o rules that needs to be followed in assigning values to the variables. real r;
    r = 2,3; //Wrong
    r = 2.3; //right : number.number time t;
    t = 10 timeunit = 10ns; integer intA[3:0] = 1,2,3,4; //Wrong
    integer intA[3:0] = {1,2,3,4}; //correct
  5. int is 2state, integer is 4 state
    default value of int variable is 0
    int a =x;
    a will be 0.
    default value of integer variable is x
  6. bit and byte
    bit [7:0] a;
    byte b;
    a = -20; //a = 255-20 = 235
    b = -20; //b will be stored as -20 only
  7. time stores time in integer fromat
    realtime stores time in realtime format timescale
  8. what is the default timescale used
    `timescale 1ns/1ns
  9. Generate a clock of 30MHz frequency
    Issue#1: Integer division
    Issue#2: time precision

rt = $realtime; //give current simulation time in real number format
realtime rt;

$time : integer time format
  1. integer division
    integer a = 100, b = 3;
    real c;
    c = a/b; //integer division: 33, output won’t 33.333
    c = a/3; //integer division: 33, output won’t 33.333
    c = a/3.0; //real division: 33.33
  2. bit [5:1] a; //both are same size
    bit [-1:-5] b;
    a = b;
    a[1] = b[-5];
    a[2] = b[-4];
    a[3] = b[-3];
    a[4] = b[-2];
    a[5] = b[-1];
  3. both are different size
    Left side is bigger than right side
    bit [7:1] a; //both are same size
    bit [-1:-5] b;
    a = b;
    a[1] = b[-5];
    a[2] = b[-4];
    a[3] = b[-3];
    a[4] = b[-2];
    a[5] = b[-1];
    a[6] = 0;
    a[7] = 0;
    //Right side vector don’t have those bit position, hence they will be taken 0

Left side is smaller than right side
bit [3:1] a; //both are same size
bit [-1:-5] b;
a = b;
a[1] = b[-5];
a[2] = b[-4];
a[3] = b[-3];
b[-1] and b[-2] will not be copied at all

  1. packed array operations
    o every possible SV operation can be done with packed array
    o packed array represent a signle variable stored in single address
  2. unpacked array operations
    o very few operations can be performed
    o unpacked array represent multiple variables stored in multiple addresses int intA[3:0], intB[3:0], intC[3:0];
    intA = intB + intC; //not possible
    intA[0] = intB[1] + intC[0]; //possible
  3. int intA[3:0];
    int intB[5:0];
    intA = intB;

for array to array copying
o data types should be amtching or similar variables
o array size also should match

  1. vsim work.top -sv_seed 478493 +num=10
    for reading +num argument:
    $value$plusargs(“num=%d”,num);
    tools automatically reads sv_seed argument
    o -nvopt
    o -sv_seed
  2. prime numebr printing
    o for i from 2 to the number
    o for j from 2 to i/2 (anyway i/2 above numbers won’t be able to divide)
    o if i is not divisible by any of the j numbers, then ‘i’ is a prime number
  3. queue is non-blocking, mailbox is blocking
    queue: every method is a function. Functions can’t help acheive blocking nature.
    mailbox: task: put, get, function: try_put, try_get, peek
    tasks can make the simulation wait, hence they can bring in blocking nature. how to get blocking nature with Queue:
    forever begin
    wait (gen2bfm_Q.size() > 0); //blocking nature
    tx = gen2bfm_Q.pop_front();
    drive_tx(tx);
    end
  4. fixed array: already memory is allcoated, all the elements there as soon array is declared
    int intQ[$:9]; //it maximum possible index:9, but right now there are no elements in it.
    since Queue is empty initially, we can’t use foreach.

SESSION#2

  1. How to make the code reusable and modular
  2. use cases of multi dimensional arrays
    o memory: array of vectors
    o Scoreboarding
    o complex design with configurable number of master interfaces and configurable number of slave interfaces
    o we need to get txs from multiple master monitors and multiple slave monitors
    o we can keep one multi dimensional array(array of Queues) to hold txs from all these monitors
    o Ethernet packet or USB frames
    o packed multi dimensional arrays
  3. We can use streaming operator for converting integer array to byte array. Like wise we can do reverse also. This would be useful when u are having two bus interface with different bus width and u wanted to do the comparison Or conversation
    o this concept can be used in reference model
  4. Verilog: event usage style makes it non-persistant triggred
    o it is not active fro complete timestep
    @(e); //Verilog style
    system Verilog: event usage style makes it persistant triggred
    o it is active fro complete timestep
    o even if event is being waited for after the event is triggred, it will still be caught, which will not be the case with Verilog style.
    wait(e.triggered()); //SV style
  5. Design which has 8 chip select
    o we can connect one slave per chip select
    o each slave has specific unique address range
    o when we develop testcases, our test is supposed to generate random write/read transactions to these chip selects.
    o We want verification engineer to have complete control on which chip selects to target in a given testcase
    test_cs1_cs2_target : vsim work.top +cs_target=8’b0000_0110
    test_cs4_cs7_target : vsim work.top +cs_target=8’b1001_0000
    test_all_cs_target : vsim work.top +cs_target=8’b1111_1111 tx.addr will be generated targeting those chip selects only.

SESSION#3

  1. as a verificaiton engineer, we should have control whcih all chip selects I want to target in current test
    8 Chip selects
    A given transaction can only be targeted to one of the chip selects vsim work.top +cs_target=8’b1100_0000
    o current testcase run should only target, CS7, CS6
    without proper constraints:
    tx.randomize() with {tx.addr inside {[CS6_START:CS6_END], [CS7_START:CS7_END]}}; vsim work.top +cs_target=8’b0000_1111
    o current testcase run should only target, CS0, CS1, CS2 and CS3
    without proper constraints:
    tx.randomize() with {tx.addr inside {[CS0_START:CS0_END], [CS1_START:CS1_END], CS2 and CS3}};
  1. alternatively target selected slaves in round robin manner
  2. USB2.0 core constriant writing example
    o Endpoints
    EP0 to EP15
    each EP can be eitehr Bulk, Control(EP0), Isochronous, Interrupt type
    each EP can be eitehr IN or OUT EP
    o how to write testcases
    vsim work.top +testname=test_bulk_in
    TB should be setup in such a way that, it should automatically figure out which all EP meet this criteria(Bulk, IN)
    USB UTMI host(Driver, Sequencer) should generate Token packets with this EP number
    o For every transfer targeted to any USB device, USB host first generates a token packet
    o in token packet, it generated EP number to which Host wants to send the transaction.
    o token packet randomization should happen in such a way that token_pkt.endp should be inside {bulk_and_in_type_ep_only} for current testcase
  3. Encapsulation, Polymorphism
    o USB2.0 veirifcation is good example of how Polymorphism can be used
    o

o How SV & UVM based TB architecture will llok
top
…
…
sub_env
agent
…

  1. USB2.0 core has
    o 2 master interfaces
    o UTMI interface
    o suspend, resume
    o speed negotiation
    o enumeration
    o USB frame generation (USB data transfer between USB Host and USB device)
    o Function controller interface implemented using Wishbone protocol
    o Programming the registers
    o DMA request handling
    o Interrupt handling
    o 1 slave interface
    o buffering of packet data coming in from UTMi and going to UTMI
  2. Creating the transaction class or sequence_item is one of the imporatn aspects
  3. In CS example, constraints made the whole scenarion generation lot easier
    o without constraints also it is possible to implement the testcases, but it would be more effort, effort in every testcase
    o implement teh sequeirnce_item, tx class with proper constraints, it will make scenarion generation lot easier
  4. what does this mean for USB2.0
    o we have 2 master agents
    o WB_Agent
    o UTMI_Agent
    o we need to create wb_tx and utmi_tx/pkt with proper set of constraints, which will give us complete flecxibility in impelemntign the testcases
  5. polymorphism, inheritance, enapsulation and constraints
  6. UTMI
    USB Frame:
    SOF, n number of {TOKEN_PKT, DATA_PKT, HANDSHAKE_PKT}
  7. concept of base class is importnat in veriifcaiton enviornemtn
    o used in multuple contects
    o test:
    base test
    o fields that are common to all the functional tests
    o methods common to all the functional tests
    functional test (inherited from base test)
    o sequence:
    base sequence
    functional sequence (inherited from base sequence)
    o Tx item or packets
    base_pkt
    o fields that are common to all the actual packets
    pid
    o methods common to all the actual packets
    virtual function void calc_crc5
    virtual function void calc_crc16
    actual pkt (inherited from base pkt)
  8. taking complex protocol USB2.0, trying to understand how to generate the testcase, items, constraints by reading the speciciaton
  9. I have read that mentor don’t suggest raising and dropping objection from sequence, it should be done from test only, what can be problems if we raise objection from sequence?

test is mapped to seqeunce, eitehr in
o build_phase
uvm_config_db#(uvm_object_wrapper)::set(this, “env.agent.sqr.run_phase”, “default_sequence”, utmi_bulk_out_seq::get_type());
if we map test here, there is no way to raise and drop objection here, since we are in a function(build_phase)
o run_phase

14.
utmi_bulk_out_seq
o this should only generate packets which are targeting EP of bulk type and OUT type
utmi_bulk_in_seq
o this should only generate packets which are targeting EP of bulk type and IN type
utmi_iso_out_seq
o this should only generate packets which are targeting EP of ISO type and OUT type
utmi_iso_in_seq
utmi_intr_out_seq
utmi_intr_in_seq


  1. APB, AXI and AHB based transaction items
    o they don’t pose many complex requiremnets
    o simple cosntraints, simple data varaibles

USB, PCIe
o transaction definition gets more complex
o various types of packets
o each having different fields
o variable number of packets
o USB2.0
o UTMI, Function controller
o UTMI
o

  1. WHy randomoztion was failing?
    o we were not populating the bulk_out_epQ and bulk_in_epQ
    o we were putting constraint to ep in this list, which is empty
    o tool was not able to solve => hence failing
    o why we were seeting values?
  2. Testcase development is as simple
    `uvm_do_with(req, {req.type == BULK; req.dir==IN;})
  3. Driver will get enitre frame from seq_item_port
    o get_sof => drive the SOF
    o get_token => drive the token

19.
what is benifit of doing phase drain time in sequence pre_body?
How it will affect the simulation

Drain time: time for which simulation should continue to run even after all objections are dropped
why drain time is required?
o sequence consists of sequence_items

  1. Setup complete UTMI envinroentmn from your side
    o No design
  2. Testcase development is about creating a very effective sequence_item, with lot of controls(Knobs)
    o Using this knobs we can inline cosntraints and acheive the different testcases in one or two lines.

SESSION#4

questions:

  1. revision
  2. USB2.0 core as a DUT
    o 2 master interfaces
    o UTMI, WB
    o 1 slave interface
    o SRAM
  3. impelmented the TB environment for UTMI
    o suspend, resume, enumeration, speed negotation, normal data transfers
  4. concept of Knobs in testcase implementaiton
    o every transaction item or packet should have knobs.
    o knobs :
    o field declared inside the transaction or packet, it will be used as part of inline cosntraints or implication constraints.
    o these fields mostly will not be driven on interface. These are only used for making scenario generation easier.
    o ex: knobs in UTMI_frame.sv
    sequence::body
    `uvm_do_with(req, {req.knob1==SOME_VALUE, req.knob2== ; req.knobs==value3; so on}) o when we think of testcases or scenario, we first need to think of knobs in transaction item or packet.
  5. Concept
    o what part of scenario should go in to sequence
    o suspend: we were only generating a variable which would indicate suspend operation
    o what part of scenario should go in to driver
    o suspend signaling has to be implemnted in driver only, sequencer or sequence can’t take care of it.
  6. polymorphism concept
    o whatever methods we want to define in derived classes(sof, token, data, handshake_pkt), make them virtual empty task/function inside the base_pkt.
    o wheenver we work with USB2.0, USB3, PCIe, etc, this ceoncpt needs to be impelemtned
  7. static variables in class
  1. how static variables make TB development easier?
    Generator and BFM connection
    – mailbox
    class ctrl_common;
    static mailbox gen2bfm = new();
    endclass class ctrl_bfm;
    task run();
    ctrl_common::gen2bfm.get(tx);
    endtask
    endclass class ctrl_gen;
    task run(); //test specific
    ctrl_common::gen2bfm.put(tx);
    endtask
    endclass
  2. all variables in class are atuomatic(non-static) by default
    all variables in module are static by default

10.
function static
static function

function static bit [7:0] fact(input [2:0] var_t); //output =1
– function output is static type, hence all the function returns happens to same memory location, so whatever return comes in the last call of the function will override the already existing values.
– fact(1) : last call
o output of this is ‘1’ => this overide the existing value
function bit [7:0] fact(input [2:0] var_t); //output is correct numebr
– function output is automatci type, hence all the function returns happens to different memory locations, so whatever return comes in the last call of the function will not override the already existing values.
– hence we get correct output

  1. rand and randc
  1. randc loses the bheavior if new is done on object

repeat(32) begin
tx = new()
tx.randomize(); //randc won’t work
end

  1. pre_randomize, post_randomize

function void pre_randomize();
if (eth_config::testname == “test_sof_not_random”) begin
sof_c.constraint_mode(0); //disabling sof_c constraint
sof.rand_mode(0); //disable the randomization of sof
end
else if (eth_config::testname == “test_len_dataQ_no_random”) begin
dataQ_c.constraint_mode(0);
dataQ_len_c.constraint_mode(0);
dataQ.rand_mode(0);
len.rand_mode(0);
end
else if (eth_config::testname == “test_len_20”) begin
len.rand_mode(0);
len = 20;
end
else if (eth_config::testname == “test_preamble_not_rand”) begin
preamble.rand_mode(0);
end
endfunction

  1. shallow copy and deep copy
  1. copy by handle and shallow copy
    copy by handle: both objects are pointing to same memory
    o any change we do in one object, relfects in other object
    pkt1 = pkt2;
    shallow copy: both objects are pointing to different memory
    o any change we do in one object, will not impact in other object
    pkt1 = new pkt2;
  2. inheritance
    o Tb classes can be looked at in a layered manner
    layer#1: (used in all the other layer)
    o what should be class name
    o what should be fields
    o what should be methods
    layer#2: (used in all the layer#3 and above)
    o what should be class name
    o what should be fields
    o what should be methods
    layer#3:
    o what should be class name
    o what should be fields
    o what should be methods
    layer#4:
    o what should be class name
    o what should be fields
    o what should be methods
    o complex design verification requires this kind of class hiearchy
    o where we use inheriarcne effectily
    o how layering is helping?
    o it reduces the overall coding effort, since you are inheriting things(properties and methods) from the base class
  3. polymorphism

class base_pkt;
virtual function void print();
endfunction
virtual function void copy();
endfunction
virtual function void calc_crc5();
endfunction
endclass

  1. parameterized classes

18.
class stack_param_name #(type DT=int, int DEPTH=10, string NAME=”stack_param_name”) extends stack#(.DT(DT), .DEPTH(DEPTH));

19.
scope resolution operator
o accessing static methods and static properties inside a class
o accessing data type inside data type

20.
eth_pkt::my_pkt::sample::pkt_type = GOOD; //WRONG
eth_pkt::my_pkt::sample::pkt_type = eth_pkt::my_pkt::sample::GOOD; //correcvt

  1. $root, $unit
  1. Homework o USB2.0 core has 3 interfaces o UTMI o Wishbone (~APB or AHB) o Memory o Develop UTMI interface agent o Master agent o Driver, Sequencer, Monitor, functional coverage, UTMI frame(sequence item), UTMI_INTF o UTMI frame o Learn the cocneot of knobs o how to use Knobs in implication cosntraints => which make testcase development easier o Suspend o Resume o Enumeration o Speed Negotiation o Normal USB frame generation o UTMI interface gneerates frames which consists o SOF, n'{TOKEN_PKT, DATA_PKT, Handshake_PKT} o Define UTMI Frame o Define testcases for various types of scnearios o test_suspend_resume o test_bulk_in_transfer o test_bulk_out_transfer .. 10 testcases o check teh simulation log and see whether we are able to generate the UTMI frame for various requirements o user provided number of packets o user specified type of transfer and direction o get the frame from sequencer(sequence) o get each packet from the frame o pack the frame in ByteQ o drive the byte by byte to UTMI interface o valid, ready, data_i o ran simulation and checked the waveform knob:
    • field declared in sequence item, but that item will not be driven on to the interface
    • it is only used for control over scneario generation
      3 knobs in USB2.0 frame:
      o utmi_operation, ep_type, ep_dir

SESSION#5

revision:

  1. OOP
  2. parameterized class
  3. static properties, methods
  4. nested classes
  5. Scope
    o global scope
    o module/class scope
    o task/function/label scope
  6. Different type of copy
    o copy by handle
    o shallow copy
    o Deep copy

Notes:

  1. chandle
    • C Handle
    • useful while interfacing SV with C language using DPI
    • DPI
      o import and export of functions
      import: whatever function implemented in C language, can be called in SV TB environment
      export: whatever task/function implemented in SV TB, can be called in C code
      o During this import, at times we need to get C pointer in to SV TB
      o SV don’t have equivalnet data type => Chandle (C Handle => pointed we are getting from C in to SV TB)
  2. Inter process synchronization
    o IPS
    o event, semaphore, mailbox
    o Interface
    o clocking block, modport
    o program
    o assertions
    o Coverage
    o coverage report analysis
    o setting up a configurable TB
  3. Memory : DUT
    o Testbench which os configurable for user defined number of agents(env)
  4. What are the difference between Interface and BFM?
    BFM: Bus funcitonal model
    o it models the bus behavior
    o AXI BFM => Component
    o WIll model the behavior fo the componetn that is connected on AXI interface
    o AXI interface => Complex data type with all ports defined
    o Bundling of the all AXI signals in to one unit and giving names as ‘axi_itnf’
  5. SV LRM
    o there is no mention of Driver, BFM
  6. If the program block initial completes, TB simulation ends, even though we are not calling $finish

7.
for (int i = 0; i < mem_common::num_agents; i++) begin
fork
agentDA[i].run(i); //all 3 happens in 0 time due to fork join_none
join_none
end

  1. clockng block
    o output skew
    o how much time after the active edge of the clock(the one mentioned in clocking bclock), the signal should be driven
    @(vif.bfm_cb);
    vif.addr = tx.addr; //this signal is not getting driven at same time as edge of clock, it gets driven output SKEW time after the edge of the clock.
    o this signal driving is scheduled for later timestep.
    o whenever we need to scheudle an assignemtn for later time, we must use non-blocking statements, so that it does not block the following statements

9.
Property valid_ready;
@(posedge clk) valid ##2 ready; //WRONG: no implication operator
Endproperty

//next answer
sequence vld_rdy_hndshk;
valid |->##[1:2] READY; //implication operator can’t be used in sequences, can only be used in property
endsequence

property vld_rdy_hndshk_prop;
@(posedge clk) vld_rdy_hndshk;
endproperty

//next answer
property valid_ready_handshake;
@(posedge clk) $rose(valid) |-> ##[1:2] $rose(ready); //$rose(valid) is wrong
endproperty

10.
=> ##1 is same as -> ##2;

Since valid is input to design, we cannot guarantee that without waiting for one extra cycle for rdata we can capture it ???

11.
we have already declared clocking block so what is the need of modport in interface?

SESSION#6

  1. why we are not creating coverpoints for handshaking signals?
  1. can we exclude the error group using exclusion file?
    o it can be done.
  2. can we write coverage in interface ?
  1. process for coverage report generation
    o code coverage report
    o functional coverage report
    o assertion coverage report Questasim : UCDB
    o Unified Coverage Data Base
    o to generate UCDB?
    o
  2. code coverage
    o we are only interested in dut coverage (RTL)
    o functional coverage
    o all covergroups need to be analyzed
  3. Coverage analysis
    • how to update the run commands for coverage report generation
    • how to merge UCDB’s
    • how to load UCDB in to the tool
    • how to generate coverage report from UCDB
    • how to do the exclusions from the tool
  4. Scoreboarding
    o algorithm
    o monitor provides both write and read trasnactions to scoreboard
    o during writes, update the write data in to memory implemented using associative array
    o during reads, compare the read data with associative array data
  5. What are the best methods to write the scoreboard?
    o come up with algorithm, implement it
  6. why program block can be avoided?
    o program block is used since its initial block runs in reactive region
    o module block initial block runs in active region
    o

10.
int intDA[];
intDA each element can be either 2,4,8,16
intDA each element must be bigger than 2*i (i is index of teh element in the array)

  1. transistion coverage in funcitonal coverage?
  1. explain the code coverage vs function covergae, Advantage, and Significant of those in verification
  1. Functional and code coveraeg
    o Code coverage
    o 6 types of coverages => which adds up to code coverage
  2. How statement coverage is differ from branch coverage and how to get both correct & effectively?
    always @(posedge clk) begin
    if (sel == 2’b00) begin
    y =a + b *c – d;
    end
    else if (sel == 2’b01) begin
    y = a * b;
    end
    else if (sel == 2’b10) begin
    y = a – b;
    end
    else begin
    y = a / b;
    end
    end
  3. DMA controller
    o Every SOC compolsorily has DMA controller
    o Mobile SOC can have up to 10 DMA’s inside it
    o most of the data transfer testcases involve DMA in one or other manner
    o most of DMA controller irrespective of which company we work in has lot of common concepts
    o command
    o command lists
    o scatter and gatther
    o channels
    o core
    o different possible transfers
    memory to memory
    memory to peripheral
    peripheral to peripheral

16
what information do you want to get from Design specification?
Features
Architecture
Interfaces : type of interface
Input and output ports
Sub blocks, how they interface with each other
how many clock domains are there?
how many registers are there
Their detailed description
how Verilog code is organized
How many files are there, what is top most module
what is the design reset sequence?
If the design is complex, it will require a power up sequence
timing diagrams for interface transactions
how design implements various features(Very important)
how many interrupts, their requirements

WORD document with all above things captured from the spec.

  1. develop complete memory TB for configurable number of agents
    develop complete design document

SESSION#7

agenda:

  1. UVM
    APB protocol
    APB master UVC
    APB slave UVC
  2. Memory TB
    o port SV TB to UVM TB
    SV TB: top_module -> program -> env -> sub_env, reference model, checker -> BFM, generator, Monitor, functional coverage
    UVM TB: top_module -> top(uvm_root instance) -> uvm_test_top(test being run) -> env -> sub_env, reference model, checker -> agents -> Driver, Sequencer, Monitor, functional coverage
  3. Differences between SV & UVM TB
    o SV
    o testcase is a task/function, mostly refers to the scenario being driven
    o TB structure remains same as we run different tests
    o program block is the starting point of TB
    o All environemnts are refered as either env or sub_env
    o User needs to call all the TB phases manually
    o User needs to implement logic for deciding when to end the simulation
    o all the component and object instantiaitons happen based on SV file definition of the component or object
    o pkt or tx referred as txs.
    o mailbox used for component connections
    o SV does not provide any utility clases(factory, config/resoruce db) to register the component/object definitions
    o messages displayed using $display
    o UVM
    o testcase is a component, that gets mapped to a sequence or group of sequences
    o Every testcase run, testbench structure gets created as defined in part of testcase build_phase
    o uvm_root(top) is the starting point of TB
    o interface specific components are grouped, are called as ‘agent’
    o All the phases gets called automatically
    o objections automatically take care of when to end the simulation
    o most of the component and object instantiaitons happen based on factory registered definition
    o pkt or tx referred as sequence items.
    o TLM1.0 or TLM2.0 used for component connections
    o UVM provides utility clases(factory, config/resoruce db) to register the component/object definitions
    o messages displayed using `uvm_info/warning/error/fatal
  4. WHole TB development is all about, having a common control
    o one place we keep all the parameters, just by updating these parameters we should acehive the kind of the testbench we want.
    o these parameters can be used to indicate the number of transactions
    o these parameters can be used to indicate the type of agents, number of agents
    o these parameters can be used to indicate whether to generate any error scnearions
    o UVM is meant fo setting those kind of testbenches.
    o it uses concept of uvm_factory, config, resoruce_db to achieve this.
  5. factory?
    every component/object has 2 definitions
    o SV file definition
    o Factory register definition
    uvm_config_db#(bit)::set(this, “env.agent”, “active_passive_f”, ACTIVE);
    what definition is getting updated through above line?
    o Factory definition is getting updated
    agent = ahb_agent::type_id::create(“agent”, this); => since factory definition is updated, this will behave like an active agent
  6. any component or object registered with factory, to create that component/object instiance, we use create method. Which will in turn call new constructor.
    o create will work as per the factory registered definition
  7. any component or object not registered with factory, to create that component/object instiance, we use new method. Create method comes in to picture only when the definition is registered with factory.
    o new will be create object/component isntnace as per SV file definition, not factory(becuase we didn’t register itself)
  8. how to decide when to use new or create?
    uvm_blocking_put_port put_port;
    put_port = new(“put_port”, this); //why create is not used?
    o uvm_blocking_put_port is not registered to factory
    o UVM developers(Mentor, Cadence, Synopsys) felt that, there will never be requirement for updating uvm_blocking_put_port definition. There will not be any testbench which will require different behavior for uvm_blocking_put_port. Since its definition need not be changed, it need not be registered with factory.
  9. what is the siginifnace of run_test in UVM?
    o run_test is a task defined in global scope of UVM package. (uvm_pkg.sv)
    o it creates the instance of uvm_root as ‘top’
    o in turn call top.run_test (uvm_root::run_test is called)
    o run_test defined in uvm_root, starts all the phases of UVM testbench execution
    o read all the command line arguments
    o uvm-root knows which is the test being run
    o it creates a phase variable (uvm_phase phase)
    o phase will be passed to all the components in the testbench heiarchy
    o using above phase variables, uvm_root keeps track of objections raised and dropped.
    o based on objections, uvm_root decides when to end the simulation
    o based on UVM_TESTNAME vairbale read, it create uvm_test_top
    o it star off all the UVM testbench phases starting from build_phase till report_phase
    o uvm_root doesn’t print topoloty
    o TB topoloty gets pritned when user does this.sprint(); Structure print
  10. objections
    o drain time?
    o the additional time for which duration simulation should continue to run even after all objections are dropped
    o why drain time is required?
    o objections are used only in two places: testcase::run_phase, sequence::body task
    o drop objection happens as soon as sequence provides the last item to the driver
    o now if we end the simulation immediately, design and rest of the testbench will not get time to process this last transaction
    o we measure the clock cycle that will be required by the design to process this one last transaction, this time is implemented as drain time
    o drain time is not a fixed number, it is design specific, it is measured in clock cycles, later conveted to ns.
    o use set_drain_time to set this time. task body(); starting_phase.raise_objection(this); repeat(10) `uvm_do(req) //10 items will be generated starting_phase.drop_objection(this); //if htere is no drain time(default is 0) endtask
  11. why don’t we raise and drop objections in monitor , driver, scoreboard, and coverage?
    o all these components have forever running behavior in run_phase, hence objectons will never get dropped. Hence we don’t use objectons
  12. how do we raise and drop objections in sequence?
    • to raise and drop objections we need phase variable
    • phase is not there in sequence since it is based on uvm_object
      o how it gets handled?
      o it will use the scheduled_phase of uvm_sequencer for phase, that variable is called as ‘starting_phase’
      uvm_config_db#(uvm_object_wrapper)::set(this, “env.agent.sqr.run_phase”, “default_sequence”, ahb_10_tx_seq::get_type());
      o run_phase of the sequencer becomes the starting_phase
      o starting_phase.raise_objection(); //called as part of pre_body task
      o starting_phase.drop_objection(); //called as part of post_body task
  13. uvm_config_db#(uvm_object_wrapper)::set(this, “env.magentA[0].sqr.run_phase”, “default_sequence”, ahb_mult_wr_rd_wrap16_seq::get_type());
    • run ahb_mult_wr_rd_wrap16_seq in env.magentA[0].sqr run_phase
      o we are setting above sequence as ‘default_sequence’
      o even though objection is raised from sequence, but who is essentially raising objection? env.magentA[0].sqr
      o in which phase it gets mapped to? run_phase of the env.magentA[0].sqr
  14. UVM_OBJECTION_TRACE?
    o command line arguemtn, used for tracing the raise and drop objections.
    o it makes debug easier, since we get to know which objections are dropped and which are not dropped.
    o effectively, we quickly know where the simulation is hung
  15. +UVM_VERBOSITY=UVM_LOW +uvm_set_verbosity=uvm_test_top.env0.agent1.*,ALL,UVM_FULL,time,800
    o WHole TB will run with reference versboity of UVM_LOW
    o only the components in env0.agent1.driver/sequencer/monitor/cov will run with reference verbosity of UVM_FULL
    o lot of messaging from agent1 children, minimal messaging from other components.

15Q. can we use time variable to set different verbosity for one component ??

  1. setting virutal interface
    uvm_config_db#(virtual mem_intf)::set(null,”*”,”mpif”,mpif);
    o wrong: null => uvm_root::get()
  2. Is it possible to use only one monitor as we did in SV TB?

18Q>
How we are making sure that only one monitor should sample the interface signal at a time as there is only one interface and multiple monitors.
o this feature is not yet implemented

19Q.
What if we change agent count then how to manage imp port in scoreboard?
o we need to manuuallt do it.

SESSION#8

Agenda:

  1. Questions from previous session
  2. Any topics to cover
  3. Memory TB development

Notes:

  1. please cover pseqeuncer and virtual sequencer concept?
    with example means what is use cases and how we can use with example can you explain?
  2. overriding
  3. callback
  4. config_db, set and get from object and component, bottem in the hairarchy, top in the hairachy.
  5. resource_db
  6. user defined phases
  7. uvm_event
  8. uvm_heartbeat
  9. TLM1, TLM2
    o main difference between tlm1 and tlm2
  10. cross coverage
    o Main project
    o ADDR_X_WR_RD_CP : cross ADDR_CP, WR_RD_CP;
  11. RAL
    https://www.embeddedguru.in/online-courses/uvm-ral-training.php
  12. use only one monitor in tb

Notes:

  1. virtual sequencer
    task body();
    uvm_do_on(seq1, p_sequencer.main_sqr1) uvm_do_on(seq2, p_sequencer.main_sqr2)
    fork
    uvm_do_on(seq3, p_sequencer.main_sqr3) uvm_do_on(seq4, p_sequencer.main_sqr4)
    join
    endtask
  1. virtual sequencer code
    class top_sqr extends uvm_sequencer; //this is virtual sequencer since we did not parameterize it
    apb_sqr apb_sqr_i;
    ahb_sqr ahb_sqr_i;
    `uvm_component_utils(top_sqr)
    function new(string name=“”, uvm_component parent=null);
    super.new(name, parent);
    endfunction
    //we are not creating apb_sqr_i and ahb_sqr_i handles
    //rather we will map these to agent sequencer handles in the base test.
    endclass
  2. `uvm_declare_p_sequencer(top_sqr) //top_sqr becomes p_sequencer
    we know the top_sqr is coded as virtual sequeencer, why explictly declaring? Qualcomm:
    o it can have 10 program managers
    o we won’t assign one project to all 10 program manager
    o we need to tell current mobile soc, who will be the program amanger who will handle it.
  3. Questions to be asked in any project
    what is the name of virtual sequencer?
    where is it integrated? What is the hierarchy path?
    where is the virtual sequence library?
    how to create tests using virtual sequencer
    How to create tests using virtual sequences.
  4. overriding
  1. overriding by callback,
  1. config_db, set and get from object and component, bottem in the hairarchy, top in the hairachy.
    o how to set config_db from top hiearchy and get in the bottom hierarchy
    o how to set config_db from bottom hiearchy and get in the top hierarchy ==> This is never a usecase
  2. user defined phases?
  3. uvm_heartbeat
    o no update required in testcase

10Q. At specified time duration we are triggering event in agent so where we are waiting for the event
o event is only trigged to tell heartbeat that check if all objections have happened in heartbeat window, hence no sample of event is required

  1. TLM1, TLM2
    o main difference between tlm1 and tlm2
    o SystemC: TLM2.0
    o UVM wants to at minimum match whatever is tehre in SystemC, hence it is introduced.
    o TLM2.0 concept is rarely used in actual TB development.
    o all the UVM base classes(driver, sequencer, subscriber) are based on TLM1.0
  2. use only one monitor in tb
    o moved mon and cov from agent to env
    o did ref model updates for one imp connection
  3. monitor is specific to interface
    o we only have one physical interface, hence there is no need of keeping 3 monitors
    o keeping 3 monitors, signle tx is monitored and collected 3 times
  4. Memory TB coding
    DMA controller verification plan

SESSION#9

questions:
Agenda:

  1. UVM topics
    o phase jumping
    o uvm barrier
    o uvm packer
    o cmd line processor
  2. Memory TB review
  3. DMA controller project overview

What is the significance of multiple agent case for a DUT with single interface, running different sequences on each agent can be replaced with multiple sequences on same seqr and seqr will handle the arbitration on it’s own right ??

Mmeory TB review:
comments
Prabhu:

  1. TB was developed, it wasn’t run
  2. Do not create invidual folder for each component

Shraddha:

  1. Scoreboard needs to be updated to collect transactions from multiple agents
    o `uvm_analysis_imp_decl need to be used
    o write method needs to be updated
    o local memory needs to be declated as an asscoaitive array
  2. Enviornemtn (mem_env.sv)
    o connect phase is missing
    o establish TLM connections between individual agent monitor and scoreboard imp_ports
  3. mem_item.sv
    o remove handshaking signals
  4. mem_mon.sv
    o don’t collect handshaking signals

Sayantani Bala:

  1. Not running sequences on all agents
  2. Update interface for modport and clocking blocks
  3. implement modport and clocking block in driver and monitor
  4. mem_item.sv
    wdata, rdata both not required, since we can only do write or read at any time(not both)
    data is sufficienct
  5. scorebaord.sv
    o needs update
    o move teh comparison logic to write function
    o implement for multiple agents

Hemant:

  1. driver
    drive_txn : needs to be updated
    o do not code too many things in to signal task
    o always use sub task
  2. test pass/fail criteria

Saloni:

  1. needs to submit again
  2. UVM topics
    o phase jumping
    o uvm barrier
    o uvm packer
    o cmd line processor

Notes:

  1. phase jumping
  1. forward jumping
    o main_phase
    o some speicifc type of error happens, where we feel, there is no need to apply furhter scenario, but still we want to end the simulation gracefully(run all remaining phases after the run_phase);
    domain.jump(uvm_extract_phase::get); //all the components in this domain will jump to extract_phase
  2. any phase jumping is done only using domain.jump
  3. when we setup a TB, we need to decide which componetns needs to separated and grouped as one domain
    o importnat part of phase jumping
  4. uvm barrier
  5. uvm packer
    o family of UVM base clases called as ‘policy classes’
    o what is packing? why is it required in TB?
    o protocols are 2 types
    o on-chip
    o there are dedicated ports for each signal
    axi_tx: axi_tx.awaddr will be driven on axi_intf.awaddr, so on
    o peripherals
    o complete packet information needs to be driven on limited number of ports in serial manner
    o ex: USB frame, whole frame needs to be driven on D+/D- (single line only)
    o this is where concept of packing is required
    byteQ = {>>byte{pkt.preamble, pkt.sof, pkt.sa, pkt.sa, pkt.len, pkt.data, pkt.crc}};
    bitQ = {>>bit{pkt.preamble, pkt.sof, pkt.sa, pkt.sa, pkt.len, pkt.data, pkt.crc}};
    o UVM provides with a provision to pack various things in various manners
    o UVM_packer can pack objects in to byteQ, bitQ, etc
    o UVM_packer can pack integer in to byteQ, bitQ, etc
    o UVM_packer can pack real in to byteQ, bitQ, etc
    o How uvm_packer works
    o takes all the data converts in to one concatenated vector: m_bits
    o based on user requirement(i.e the funciton called), m_bits is converted to required output format
  6. cmd line processor
    o UVM provided base class
    o it has predefined set of UVM arguemnts which it reads by default
    o it is autoamtically called as part of run_test user call
    o it is called inside uvm_root
    o when it is called, it autoamtically parses all the vsim arguemnts
    vsim work.top +UVM_TESTNAME=ahb_10_wr_test +UVM_VERBOSITY=UVM_LOW +uvm_set_verbosity=0,800,uvm_test_top.env.agent.drv,UVM_FULL +UVM_OBJECTION_TRACE +count=10 (user manuallt use $value$plusargs to parse count)
    o let complete TB run with minimal versbority(UVM_LOW), only driver let it run with UVM_FULL verbosity
    o I want lot of messaging from driver, very minimal from other TB compoentns
    o two types of arguments
    o arguments with all Capital letters(upper case)
    o arguments that apply to complete testbench
    o arguments with all lower case letters
    o arguments that apply only to speciifc hierarchy of the testbench
    o cmd line agruemnts are elaboration arugemtns, not compile arugments
    vlog top.sv //don’t pass here
    vsim work.top +UVM_TESTNAME… irun +UVM_TESTNAME=…
  7. when to use scheduled phases?
    o usage is to map specific sequences to run in specific phases, hence the term scheduled phases.
    o what we are scheduling: we are scheduling a speciifc sequence to run in speicifc phase
    o UVM does not suggest user to implement scheudled phases in any of testbench components, UVM only suggests to schedule specific sequences to run in speciifc scheudled phases

class sample_test extends base_test;
uvm_component_utils(sample_test) function new(); function void build_phase(uvm_phase phase); uvm_config_db#(uvm_object_wrapper)::set(this, "env.rst_agent.sqr.reset_phase", "default_sequence", dma_ctrl_reset_sequence::get_type()) uvm_config_db#(uvm_object_wrapper)::set(this, "env.rst_agent.sqr.reset_phase", "default_sequence", dma_ctrl_reset_sequence_1::get_type()) //this will onyl run uvm_config_db#(uvm_object_wrapper)::set(this, "env.apb_agent.sqr.configure_phase", "default_sequence", apb_configure_sequence::get_type()) uvm_config_db#(uvm_object_wrapper)::set(this, "env.axi_agent.sqr.main_phase", "default_sequence", axi_10_tx_wr_sequence::get_type()) uvm_config_db#(uvm_object_wrapper)::set(this, "env.axi_agent.sqr.shutdown_phase", "default_sequence", axi_drain_sequence::get_type()) endfunction endclass o virutal sequences has more advantage compared to scheudling phasing of sequences o using virtual sequences on same sequencer we can run multiple sqeunces, uvm_do_on(dma_ctrl_reset_sequence_1, p_sequencer.rst_sqr)
`uvm_do_on(dma_ctrl_reset_sequence, p_sequencer.rst_sqr)

DO we implmeent axi_driver.sv with scheduled phases? we should not

  1. DMA controller
    o learn complex TB enviroenmtn development concepts
    o code coverage, funcitonal coverage closure
    o initial 1 week, learning DMA contorller

SESSION#10

questions:

  1. agenda:
  2. DMA controller

Notes:

  1. different modes of DMA controller
  2. Different features of DMA controller, how they get implemented

SESSION#11

revision:

  1. DMA controller
    o Specification
    o features
    o scenarios
    o testplan
    o funcitonal coverage points
    o TB architecture

questions:

  1. Operation mode
    o data buffer
    o FIFO
  2. Buffer size
    o total data that needs to be transferred
  3. FIFO size
    o channel depth
  4. How the control path works?
    o APB interface
    o configures teh channel and shared registers
    o this in turn triggers the AXI reads and writes
    o write and reads are issued based on operation mode.
  5. How the data path works?
    o DMA controller has 2 cores
    o AXI tx is targeted to one of these cores
    o DMA controller acts as an AXI master
    o user chooses one master and one specific channel
    o AXI master issues reads and writes as per the operation mode
  6. Peripheral transfers
    o COnfiguration flow
    o Program DMA registers
    o Periph_tx/rx_req is issued
    o same in case of memory transfer : ch_enable and ch_start
    o DMA controller will initiates AXI write/reads
  7. memory to memory transfer
    DMA controller issues reads, it stores data in temporary buffer
    Same data is written on AXI write txn
  8. Channel
    o temporary buffer (FIFO)
    o when read happens, data needs to stored
    o same data will be written
    o why multiple channels?
    o multiple concurrent transfers
    o this will avoid bottlenecks
    o what if temporary buffer is not there?
    o DMA has to work in cut through mode(as data comes, same data is given on write channel)
  9. Operation mode
    o there are 3 aspects involved in the overall transfer
    o Source
    o DMA controller
    o Destination
    o we can have different types of source and destination
    o fast responding soruce and destination => independent, otustanding channel
    o slow responding soruce and destination
    o Applicaiton which is using DMA controller for the transfers should keep DMA Controller core in one of teh modes
    o Independent mode
    o Outstanding channel mode
    o Joint mode

Agenda:

  1. TB Component coding based on SV & UVM
  2. TB Component integration
  3. Bring up sanity testcases
    o sanity testcases
    o register reset tests
    o register wr-rd tests
    o basic DMA access test
    o sanity testcase passing gives confidence that common control and data paths in the design are working fine.
    o we can go ahead with advanced testcases

Notes:

  1. DMA Controller TB architecture
    SV & UVM
  2. TB Component coding
    TB environemtn hierarchy:
    top
    test_lib.sv
    dma_env
    apb_agent(periph also), axi_agent, dma_sbd, dma_reg_model
    driver, sqr, mon, cov
  3. top.sv
    o test_lib.sv
    o DUT
    o interfaces
    o add interface to config_db
    o clk, rst
    o run_test
  4. TB Step#1
    o Directory structure
    o DMA_CTRL
    o design
    o verif
    o top
    o sim
    o sbd
    o apb
    o axi
    o periph
    o reg
  5. TB Step#2
    o Copy the RTL code in design folder
  6. TB Step#3
    o compile all RTL files without any TB
    why?
    o to check if we got all the required RTL files.
  7. TB Step#4
    o top.sv
    o instinatiate the dma_axi64
    o otehr aspects of top module
    o interface insitnation
    o clk, rst generation
    o DUT insitnation, connections
    o test_lib include
    o run_test
    o add pif to config_db
  8. TB Step#5
    o Develop axi_intf.sv, apb_intf.sv, periph_intf.sv
    o Develop test_lib.sv
    o develop dma_ctrl_common.sv
    o Keep NEW_COMP,NEW_OBJ macro definitions
  9. TBStep#6
    o Update run.do
    o include all TB directory paths
    o include uvm pkg
    o run the dma_ctrl_base_test
  10. TBStep#7
    o implement dma_reg_wr_rd test
    o map it to dma_reg_wr_rd_seq
    o do one register write and same register read
    o create wave.do
    o all interfaces grouped in to 3 different groups
    o drive all design inputs to reset values(not 0) when design reset is applied
  11. Run the register wr-rd test
    o check manually write data with read data
    o list down registers for which we are getting pslverr=1
    o 0x1034, 0x103c, 0x1044
    o 0x1034: CORE1_JOINT_MODE => Core1 is not there => hence this register is not implemneted => pslverr=1
    o 0x103C: CORE1_PRIORITY => Core1 is not there => hence this register is not implemneted => pslverr=1
    o 0x1044: CORE1_CLKDIV => Core1 is not there => hence this register is not implemneted => pslverr=1
    o IDENTIFY registers for which write data is not matching with read data
    o we need to debug those registers
    o if register write is not working as intended, then functional testcases also will have same problem where we write some data, that write doesn’t happen as intended. then it will result in wrong behavior.
  12. Debugging register mismatches in register wr-rd test (this needs to be done before developing any functional test)
    0x1C:
    wdata = 26a6afe4
    rdata = 0;
    o totally 13 register mismatches are happening
    o Pinpoint the issue at the RTL code level
  13. Notice
    o from now, whatever we do has no relation to SV or UVM
    o more to do with Design understanding
    SV and UVM: 2 -3 hours
    UVM : TB more user friendly

SESSION#12

revision

Questions:
1.Q How to copy the design files into vnc session
-> to copy design files in VNC session, ask root(admin) to do the copy in to server

SESSION#13

revision:

  1. DMA controller specification, feature, scenarion, testplan
  2. register write-read, register reset tests

agenda:

  1. Register model integration
  2. developing other testbench components
  3. developing functional testcases

questions:

  1. reset assertion
    o reset is applied from top module
    why?
    reset is input to all the components in environemtn
    o DUT
    o BFM
    o Monitor
    o BFM can’t apply a reset, since it is input it
    o Hence best place to apply reset is top module
  2. on the fly reset
    o even during the design functional operation, if reset is applied, it should take effect.

notes:

  1. register model integration
    what is need for register model in TB?
    o
  2. PERL script is used to generate UVM based register model
    o using that register model, we are performing register write-reads
  3. QUe: so we are expecting default value from read only register while doing comparison?
    o read only register, write is attempted, DUT register vlaue doesn’t get updated, TB register model is getting updated. When we read same register, DUT is giving ‘0’, TB register model is giving some non-0 value, hence mismatch is happening.
  4. Register model
    o it is easy to integrate register model in to Tb environemtn
    o it is easy to develop register access testcases usign register model
    o these testcases automatically handle RW/RO type of register accessn
  5. Regster reset test errors

UVM_ERROR ../apb/apb_seq_lib.sv(208) @ 45: uvm_test_top.env.apb_agent_i.sqr@@wr_rd_seq [REG_TEST_SEQ:] Reset read error for ch0_ch_enable_reg_i: Expected: 1 Actual: 0

UVM_ERROR ../apb/apb_seq_lib.sv(208) @ 105: uvm_test_top.env.apb_agent_i.sqr@@wr_rd_seq [REG_TEST_SEQ:] Reset read error for ch5_static_reg1_i: Expected: c4010000 Actual: 0

UVM_ERROR ../apb/apb_seq_lib.sv(208) @ 165: uvm_test_top.env.apb_agent_i.sqr@@wr_rd_seq [REG_TEST_SEQ:] Reset read error for ch2_static_reg0_i: Expected: 84010000 Actual: 0

UVM_ERROR ../apb/apb_seq_lib.sv(208) @ 465: uvm_test_top.env.apb_agent_i.sqr@@wr_rd_seq [REG_TEST_SEQ:] Reset read error for ch3_cmd_outs_reg_i: Expected: 3f3f Actual: 0

SESSION#14

questions:

  1. when DUT register is read using reg model read method
    o how register model gets updated?
    o there is a implicit predictor which does this update.
  2. use case of backdoor access
    o used for 2 purposes
    o majorly for reducing the access time
    o confirnatiom about register access
    o FD write, FD read to all the register
    o FD write, BD read to all the register
    o BD write, BD read to all the register
    o BD write, FD read to all the register

agenda:

  1. develop functional testcases
  2. testcases for any design verificaiton has 3 steps
    o reset sequence or power up sequence
    o DMA controller is a simple design, hence it doesn’t have power up seqeunce(is meant for complex designs)
    o reset seqeunce
    o apply reset, hold it, release it => already done in top module, hence no need to implement explicitly in our testcase.
    o register programming (design configuration)
    o for any design, this is compolsory, except for design which don’t have any registers(ex: APB2OCP brdige don’t need to have registers)
    o very critical part of every testcase
    o any small mistake(programming 1 regiser, 1field with wrong value), can make testcase fail
    o many times order of register pgroamming also matter
    CH0_CH_ENABLE
    CH0_CH_START
    o spec tells which one should be programmed first, then later which one.
    o traffic(stimulus) generation
    o using proper set of inline cosntraints to generate a scenarion as per current test requirements
    ex: we only want to target CS2 and CS6 => vsim work.top +cs_target=8’b0100_0100 +num_txs=50
  3. design team is supposed to provide verificaiton team with Hardware programmer guide (HPG)
    o this document details the sequences used is supposed to follow during the testcase development
  4. for DMA controller
    testcases step#1, step#2 are only important
    step#3 is not required.
    o DMA controller will automatically read a memory location and writes to anotehr memory location based on programming done to the registers. DMA controller testcase development is all about register programming only.

SESSION#15

revision:

  1. Command lists
    o first command was in CMD_REG0 to 3
    o rest of commands in memroy (axi slave)

what all tests can be added?

agenda:

  1. few more tests
    o different channels (CH1 to CH7) ==> DONE
    o different modes
    o peripheral transfer tests ====> Pending
  2. Implement regression script
  3. generate coverage report
    o analyze the report
  4. scorebaord and checker

Notes:

  1. debug for CH0 transfers
    rd_start_addr
    wr_start_addr
    x_size
    above 3 signals are proper in CH0 and CH1
  2. AXI Monitor issue
    o AXI_TX are printed empty
    o why is it empty?
    o UVM printed 0 hierarhcy: no
    o monitor is not collecting all txs properly
  3. AXI Monitor issue
    o read txs are not getting collected(not given to imp port)
    o issue: race condition at the edge of clock, signals are not sampled properly
    o Solution: use clocking block
    o temp solution: use negedge of clock
  4. Whether AXI monitor is collecting all txs properly
    expected:
    o rd_tx_count = 4 (10000, 10020, 10040, 10060)
    o wr_tx_count = 4 (20000, 20020, 20040, 20060)
  5. scoreboarding algorithm
    o keep questioning if all thnings are happening properly or not?
    o data check will be last thing o checks
    o ch_enabled
    o is the transfer happening on right channel?
    o is the source_address correct?
    o is the dest_address correct?
    o is the read data matching the write data?
    o are the required number of axi write and read txs are happening?
    o is interrupt getting generated?
    o is command list enabled? o algorithm
    o APB TX will be used to decide when the DMA transfer will start
    o enable and start
    o collect all the transaction parameter
    o from where do we get all these parameters?
    o configuration registers
    o src_addr
    o dest_addr
    o buffer_size
    o whether int should be generated
    o is the cmd_last = 1?
    o next_cmd_addr?
    o which channel transfer?
    o operation_mode?
    o rd_tokens
    o wr_tokens
    o rd_max_burst_size
    o wr_max_burst_size

SESSION#16

questions:

  1. If a reg RO, and if we perform a write , will the write happen and vice versa for WO?
    o it doesn’t happen
    o write will not happen, slave error can come
  2. Can you please add backdoor access code sample for any one register in DMA controller
    without hdl path added in reg model how does it take backdoor path?
  3. is there any advantage using uvm_analysis_imp_dec over uvm_analysis_fifo in the SB? if we useuvm_analysis_fifo also can get two transactions by using ge()
    o If the algorithm can be implemtned to connect monitor’s wkith uvm_analysis_fifo, then we can uvm_analysis_fifo
    o put and get
  4. Please explain the implicit predictor in RAL model. And how it works without connecting to monitor?
    o implicit predictor is a concept where RAL model automatically gets updated for desired, mirrored and value
    o reg_block.reg_name.write/read(status, value) o driver
    seq_item_port.item_done(rsp);
    o sequence doesn’t get this item
    item.rdata = data_from_dut;
    adapter:
    – bus2reg during the read
    – it will be using updated item.rdata variable
    – then implicit predictor comes in to picture, which updates desired, mirrored and value
  5. register coverage implementation in reg model
    reg_map.set_auto_predict(.on(1));
  6. Using this assertion module, where bind will nedded?
    o in this case, bind is not required, since we are connecitng to ports at the design interface level
    o bind is required when we connect inside the design internal signals

Agenda:

  1. assertions
    o create a module with all the ports of the design
    o all the ports are inputs
    o write the properties, assert properties
  2. scoreboard implementation
    o APB Tx happens
    o register are getting programmed
    o one channel or multiple channels
    o based on configuration sequence
    o different channels will iitiate the transfer
    o those transfers based on register pgoramming
    o what kinds of things are decided based on register programming?
    o rd_start_addr
    o wr_start_addr
    o is it the last command?
    o is there any interrupt generated?
    o what is the next command address?
    o after this register configuration, once we program, ch_enable and ch_start registers
    o transfers will start on AXI interface
    o AXI monitor collects these txs, gives it to the scoreboard
    o Scoreboard needs to use above variables and AXI tx informtion to check if the AXI write/reads are happening as per the register pgroamming(variables that are sampled from register programming)
  3. regression setup

Scoreboard futehr updates:
o implement for all the channels
o implement for all the modes
o implement for peripheral transfers

SESSION#17

questions:

  1. does the implemented axi slave supports outstanding reads?
    o it does support outstanding reads

revision:

  1. Implemented backdoor access testcases
    o update the hdl_path_slice (for individual registers)
    o update the hdl_path (for complete register block)
    o hdl_path + hdl_path_slice = absolute path of each register
  2. Coverage implementation for register model
  3. assertion module coding
  4. Scoreboard implementation
    o what all aspects needs to be checked?
    o how to we get all configuration parameters
    o used during the scoreboarding implementation
    o ran dma_basic_transfer_test
    o test passed for scoreboard checks

agenda:

  1. adding new testcases
  2. coverage analysis
  3. updating the scoreboard
  4. regression setup

notes:

  1. regression setup
  2. we did not run joint mode test because of the limitation of arbiter , so is that the reason for this ?
  3. adding new testcases
    • dma_peripheral_transfer_test
      o SOC projects
      o DMA transfers:
      o memory to memory
      o peripheral to memory
    • peripheral to memory
      o DMA controller configuration should be done
      o periph_tx_req = 1
      o which in turn starts the DMA controller transactions
  4. periph_wr
    periph_rd

periph_tx => periph_wr
periph_rx => periph_rd

  1. belwo code works only for uvm1.1 versions
    task post_body();
    uvm_info("POST_BODY", "Post_body", UVM_NONE) if(starting_phase != null) begin starting_phase.drop_objection(this); uvm_info(“POST_BODY”, “drop_objection”, UVM_NONE)
    end
Course Registration