sVM Training

sVM Training
Mar-04
ClubV US 2004 1

Agenda
1. Intro to sVM: focus + roadmap
2. sVM Architecture 45min
• Module eVC, unit to system
• Structural generation
3. Register and Memory package 45min
4. Summary
ClubV US 2004 2

1: sVM Introduction
1.a. Focus
ClubV US 2004 3

sVM Roadmap
• Short term focus
• Provide svm_lib with the basic features
• Architecture guidelines
• Golden eVCs demonstrating guidelines
ClubV US 2004 4

1: sVM Introduction
1.b. Example
ClubV US 2004 5

The DUT - RSoC
• The RSoC is our DUT:
a Point-Of-Sales station
(somewhat simplified)
RSoC_Full
RSoC_D
RSoC_HW
XCore
Enet
• Contains HW and SW
• The QSoC is a smaller
subset of the RSoC, but
with the same SW
ClubV US 2004 6

The RSoC - HW and SW
RSoC (HW + full SW)
SW Application
Legend
sVE
RSoC (HW + SW drivers)
RSoC (HW only)
SW Device Drivers
CPU
DMA
Memory
AHB
XBridge
XCore
XBus
Ethernet
XCore
XCore
USB
Ethernet
From keyboard
To screen
From barcode /
credit card reader
To / From
credit center
ClubV US 2004 7

Some Specifications
RSoC (HW + full SW)
SW Application
RSoC (HW + SW drivers)
RSoC (HW only)
SW Device Drivers
Scenario:
Check: If a bad credit card is swiped,
then it should not be accepted
CPU DMA
Bridge
XCore
XCore XCore USB
Memory
Ethernet
Enet
Scenario:
Check: If a corrupt packet is received,
then a retransmit request should be sent
From
keyboard
To
screen
From
barcode /
credit
card
reader
To /
From
credit
center
Scenario:
Check: If a corrupt packet is received, then
the CPU should be interrupted
ClubV US 2004 8

The QSoC – What does it do?
(5) SW calculates the
price
QSoC_D
Device Drivers
QSoC_HW
(4) Device driver reads code (6) Device driver writes item
and price information
XCore
XCore
XCore
(3) Xcore-0 receives item code
(7) Xcore-1 sends info to screen
(2) An items code is
typed on keyboard
From keyboard
To screen
(8) Item information
appears on the screen
(1) A person is purchasing items
ClubV US 2004 9

2: sVM Architecture
ClubV US 2004 10

sVM Architecture - Agenda
• DUT & SVE
• Module eVCs
• Module to system
• SW eVCs
ClubV US 2004 11

2: sVM Architecture
2.a. DUT & SVE
ClubV US 2004 12

System Level Verification: Definitions
• A system level DUT contains several unit level blocks
connected via interfaces, internally and externally.
• A module eVC is a verification component for a
specific DUT module (either hardware or software).
• Most module eVCs have one or more interfaces
• Most module eVC are developed in-house
• An interface eVC is a verification component for a
specific protocol.
• Most eVCs we dealt with in the past were interface eVCs
• An SVE is a Simulation and Verification Environment
for a system level DUT
• Most SVEs contains module eVCs for each unit and Interface
eVCs for each internal/external connection.
ClubV US 2004 13

Design for Reuse
What should be reused?
• All eVCs
• Sequences (libraries)
• Coverage definitions
• Checks and Scoreboards
• Reference models
• vPlan
Reuse aspects
Early version
of the P.O.S.
project
• From module to system
• TLM to RTL to post silicon
• Between projects
What is not intended for reuse?
• The SVE
• Not intended to be reused as
part of larger SVEs
• Portions of it may be copied
to larger SVEs
ClubV US 2004 14

2: sVM Architecture
2.b. Module eVCs
ClubV US 2004 15

The SVE
• The SVE is the top level verification environment
• Instantiates all the eVCs
• Has a virtual sequence driver
• Has address map and register sequence driver
• The SVE is not an eVC
• Each module eVC package contains one or more “sve”
sub-directory with:
• A configuration file
• Test files
• vManager related files (vPlan, vsif, vsof)
ClubV US 2004 16

SVE Architecture Diagram
SVE
Address map
RSD
DUT
VSD
eVC
eVC
eVC
Module
Module
Module
ClubV US 2004 17

Lets Look at a Bridge DUT
Looking at this example:
AHB
eVC
• What eVCs would be
involved?
• What would the
module eVC contain?
• What would be the
eVC interactions?
XBridge
Module
eVC
DUT
XBridge
AHB
XBus
XBus
eVC
ClubV US 2004 18

Module eVC Architecture
Module eVCs include
• Monitor (module specific)
• Events, checks and coverage
• May include scoreboard and ref model
• Memory and registers
• Active vs. passive behavior
• Active gives “stand-in” mode
• Sequence driver for stand-in mode
• Virtual sequence driver
• Defined in the eVC
• Instantiated typically in the SVE
• Reusable on the system level
• Pointers to other eVCs
• To the related interface eVCs
• Potentially also to their monitor and
BFM
VSD
XBridge module eVC
Reg_file
Monitor
Notice: there is no Agent in the module eVC
Scoreboard
Ref_model
Mem_block
ACTIVE
stand-in
model
VSD
ClubV US 2004 19

AHB-XBus Bridge
Normal Mode
Legend
Data flow, eVC DUT
Sequence calls
between seq-drivers
Pointers
Whitebox access
Pink: relates to virtual seq.
Green: relates to registers
Address map
1 Connector
XBridge SVE
Traffic
generator
Address map
AHB eVC
ACTIVE master
SD
MON BFM
PASSIVE slave
MON
Bus monitor
1
RSD
1
XBridge module eVC
Passive
DUT
AHB
Reg_file
MON
ACTIVE
stand-in
model
XBridge
VSD
Scoreboard
Ref_model
Traffic
generator
XBus
Address map
XBus eVC
ACTIVE master
SD
PASSIVE master
PASSIVE slave
Bus monitor
2
RSD
MON
BFM
MON
MON
2
ClubV US 2004 20

Stand-in mode
• In stand-in mode the module eVC drives the
simulation
• The module eVC uses the interface eVC sequence
drivers
• The module eVC sequence driver is layered on top of
the interface eVC sequence driver
• When the module eVC becomes active, its
corresponding agents become active as well
ClubV US 2004 21

AHB-XBus Bridge
Stand-in Mode
XBridge SVE
AHB eVC
Legend
Active
Data flow, eVC DUT
Sequence calls
between seq-drivers
Pointers
Whitebox access
Pink: relates to virtual seq.
Green: relates to registers
Address map
1 Connector
Address map
ACTIVE master
ACTIVE slave
SD
SD
Bus monitor
RSD
MON
BFM
MON
BFM
1
1
XBridge module eVC
Active
DUT
AHB
VSD
Reg_file
MON
ACTIVE
stand-in
model
XBridge
Stand-in
Scoreboard
VSD
Ref_model
Address map
Active
XBus
RSD
XBus eVC
ACTIVE master
ACTIVE master
2
SD
SD
PASSIVE slave
Bus monitor
MON
BFM
MON
BFM
MON
2
ClubV US 2004 22

2: sVM Architecture
2.c. Module to System
ClubV US 2004 23

The Golden Examples
• svm_lib contains golden examples
• Our example DUT will be
• Module: XCore (HW)
• Sub-system: QSoC (HW)
• System: QSoC_D (HW+SW)
SW_driver
QSoC
XBus
XCore0
XCore1
ClubV US 2004 24

The Module:
XCore SVE
Legend
Data flow, eVC DUT
Sequence calls
between seq-drivers
Pointers
Whitebox access
Pink: relates to virtual seq.
Green: relates to registers
Address map
1 Connector
XCore SVE
Address map
ACTIVE master
XBus eVC
RSD
MON
SD
BFM
PASSIVE slave
MON
Bus monitor
DUT
1
VSD
Program
registers
Program xserial
1
XCore module eVC
regfile
MON
SCBD
ACTIVE
stand-in
model
SD
XCore
XBus
XSerial eVC
Agent
MON
SD
BFM
2
2
ClubV US 2004 25

Sub-System:
QSoC SVE
Legend
Data flow, eVC DUT
Sequence calls
between seq-drivers
Pointers
Whitebox access
Pink: relates to virtual seq.
Green: relates to registers
Address map
1 Connector
QSoC SVE
Address map
RSD
ACTIVE master
MON
SD
BFM
PASSIVE slave
MON
XBus eVC
PASSIVE slave
MON
Bus monitor
DUT
1
QSoC eVC
XBus
VSD
Program
registers
1
XCore0 module eVC
regfile
MON
ACTIVE
stand-in
model
XCore1 module eVC
regfile
MON
ACTIVE
stand-in
model
XCore0
XCore1
Program xserial
SCBD
SD
SCBD
SD
XSerial0 eVC
XSerial1 eVC
Agent
SD
Agent
SD
2
3
MON
BFM
MON
BFM
2 3
ClubV US 2004 26

Instantiating vs. Pointing to eVCs
• Module eVCs are always instantiated in
larger system eVCs
• E.g. the QSoC eVC has two instances of XCore
• Interface eVCs need to be either instantiated
or pointed to:
• Pointed to: if the interface is NOT fully
encapsulated by current system
• Instantiated: if the interface IS fully encapsulated
by current system
• E.g. in the QSoC, XSerial and XBus eVCs may
be connected on a higher level, so they cannot be
instantiated in the eVC
Sub-system with local bus:
instantiate the bus eVC in the
module eVC
Sub-system on system bus:
instantiate the bus eVC in the
SVE
ClubV US 2004 27

Full system: QSoC_D SVE
QSoC_D SVE
Address map
SW Driver eVC
SD
MON BFM
1
RSD
ACTIVE master
SD
GSA
XBus eVC
PASSIVE slave PASSIVE slave
Bus monitor
DUT
1
SW_driver
MON
BFM
MON
MON
Activate SW driver
QSoC eVC
XCore0 module eVC
XCore1 module eVC
XBus
VSD
regfile
MON
ACTIVE
stand-in
model
regfile
MON
ACTIVE
stand-in
model
XCore0
XCore1
Program XSerial
SCBD
SD
SCBD
SD
XSerial0 eVC
XSerial1 eVC
Agent
SD
Agent
SD
2
23
MON
BFM
MON
BFM
2
3
ClubV US 2004 28

SW eVC
• Just like other eVCs
• env unit for connecting to the environment
• Monitor to perform checks and collect coverage
• Sequence driver to drive software sequences
• Generic software adaptor
• Clean interface to software
• Activating SW modules
• Collecting SW coverage
• Personalized to specific target
ClubV US 2004 29

3: The Register and
Memory Package
ClubV US 2004 30

Outline
• Introduction to registers
• Usage and examples
• Advanced features of the package
ClubV US 2004 31

3: The Register and
Memory Package
3.a. Introduction
ClubV US 2004 32

Motivation
• Registers and memory are the interface to a device
• Control the device by writing to its registers
• Pass data to/from the device using the device memory
• In verifying the device, one often needs to
• Configure the device by setting its registers
• Activate the device by writing/reading registers and memory
blocks
• Check the device by comparing registers and memory values to a
reference model
• The register and memory package provides a standard
solution to modeling and verifying registers and memory
ClubV US 2004 33

SW/HW Interface
• The registers and the address map are the
interface between the software and the hardware
SW view of the DUT:
• Wait until the DUT is ready
• Set the value of the memory
• Set the control registers to
go
• Poll the status registers (wait
for interrupt)
• Read the memory value
DUT
Memory
Register file
HW view of DUT:
• Reset the DUT (initialize)
• When control registers
are set perform the
associated logic on
memory
• Update the status
registers
ClubV US 2004 34

Modeling Registers and Memory
eVC
Agent
Mon
BFM
Multiple cores
Multiple register files
Multiple memory blocks
Multiple agents
Multiple address spaces
DUT
Address map
XCORE
Memory
tx_mode
tx_data
rx_mode
rx_data
Operations on regs:
• Write to register
• Read from register
• Monitor
• Check
• Collect coverage
Register Features:
•Name
• Address
•Fields
• Attributes
• Behavior
ClubV US 2004 35

Basic Concepts
• Register
• Register file
• Address map
• Memory bank
Memory
Register File
Memory
block
Address Map
Register
Register
ClubV US 2004 36

Register Model in eRM
Architecture
XSoc env
XBus env (interface eVC)
Reg.
Seq.
Driver
Address map
XCore1 env
(module eVC)
XSerial env
(interface eVC)
Master agent
Seq.
Driver
PASSIVE
Slave
Slave
reg_file
Seq.
Driver
Mon
BFM
Monitor
Mon
BFM
DUT
XCore1
XCore2
ClubV US 2004 37

3: The Register and
Memory Package
3.b. How it works
ClubV US 2004 38

How it Works
XSoC env
vr_ad_execute_op()
called by RSD
XBus env
RSD
Address map
update()
5
XCore1 env
(module eVC)
6
reg_file
Update method
updates register
model
vr_ad_execute_op()
Master SD drives
the register
operation
BFM writes
into DUT
register
DUT
Master Agent
SD
Mon
BFM
3
2
1
XCore1
PASSIVE
Slave
Monitor
4
Address map
notified
Monitor picks
up activity on
bus
ClubV US 2004 39

Main Features of the Package
• Standard way to describe registers
• Standard way to read and write DUT registers
• Simulating register behavior
• Checking DUT register behavior
• Emulating registers when DUT is not available
• Built in feature set
• Sequences for driving registers
• Protocol independent implementation
• Randomization
• Coverage
• Indirect access
• Backdoor access
• Standardized eRM compliant modeling
• Fine tuned for performance and scalability
ClubV US 2004 40

Using the Register Model
• Defining the Register File
• Defining the Address Map
• Allocating Address Space for the Register File
• Register Sequence Layering
• Updating the Register Model
• Accessing Registers
ClubV US 2004 41

Defining the Register File
• Define a register file (e.g. for the 4 registers in the XCORE as
defined in the golden eVC example)
extend vr_ad_reg_file_kind : [XCORE];
extend XCORE vr_ad_reg_file {
keep size == 16;
};
• Define the registers in the register file as follows:
// NAME FILE OFFSET WMASK RESET_VAL
def_reg EX_REGS_TX_MODE XCORE 8'h01 8'hff 8'h00 {
+%dest : uint(bits:2);
+%frame_kind : [DATA,MESSAGE,EX1,EX2](bits:2);
%reserved : uint(bits:4);
};
ClubV US 2004 42

Integrating the Register File
XSoC env
XBus env
RSD
Address map
update()
XCore1 env
(module eVC)
reg_file
Master Agent
SD
vr_ad_execute_op()
PASSIVE
Slave
Mon
BFM
Monitor
DUT
XCore1
ClubV US 2004 43

Instantiating the Register File
• Instantiate the new register file, with all its
registers under some unit in your
environment.
• In this case we put the register file in the
env.
extend xcore_env {
};
reg_file : XCORE vr_ad_reg_file;
ClubV US 2004 44

Integrating the Address Map
XSoC env
XBus env
RSD
Address map
update()
XCore1 env
(module eVC)
reg_file
Master Agent
SD
vr_ad_execute_op()
PASSIVE
Slave
Mon
BFM
Monitor
DUT
XCore1
ClubV US 2004 45

Defining the Address Map and the
Register Sequence Driver
• Create an address map and a register sequence driver.
• The register sequence driver must be linked to the address
map and it must have a default BFM sequence driver.
extend xbus_env {
};
addr_map : vr_ad_map;
rsd: vr_ad_sequence_driver is instance;
keep rsd.addr_map == value(addr_map);
keep rsd.default_bfm_sd == masters[0].driver;
• In this example we instantiate both the address map and the
register sequence driver in the env.
ClubV US 2004 46

Allocating Address Space for the
Register File
• Specify the actual address space occupied by the
register file.
extend xbus_env {
post_generate() is also {
addr_map.add_with_offset(0,reg_file);
};
};
• In this example allocate between 0 and 15
• Size extracted from allocated object (reg_file)
ClubV US 2004 47

Register Sequence Layering
• For the eVC master to be able to handle the register sequence items properly, you
must implement the vr_ad_execute_op() method.
XSoC env
XBus env
RSD
Address map
update()
XCore1 env
(module eVC)
reg_file
Master Agent
SD
vr_ad_execute_op()
PASSIVE
Slave
Mon
BFM
Monitor
DUT
XCore1
ClubV US 2004 48

Executing a Register Operation
• The vr_ad_execute_op() method takes the contents of the register operation and
executes it.
extend xbus_driver {
vr_ad_execute_op(op_item: vr_ad_operation):
list of byte @clock is {
if op_item is a REG vr_ad_operation (reg_op) {
if op_item.direction == WRITE {
sequence.write(op_item.address,
reg_op.reg.read_reg_val());
} else {
result = pack(packing.low,
sequence.read(op_item.address));
};
};
};
};
• Using predefined read() and write() methods of the sequence
ClubV US 2004 49

Keeping the Register Model
Updated
• A monitor is tied to the address map to update the register model. In the
example we use the transfer_end event detected by the monitor.
XSoC env
XBus env
RSD
Address map
update()
XCore1 env
(module eVC)
reg_file
Master Agent
SD
vr_ad_execute_op()
PASSIVE
Slave
Mon
BFM
Monitor
DUT
XCore1
ClubV US 2004 50

Updating the Register Model
• The update() method is called for write operations and
fetch_and_compare() for read operations.
extend xbus_monitor {
on transfer_end {
if transfer.read_write == WRITE {
env.addr_map.update(
transfer.addr,%{transfer.data},{});
} else {
env.addr_map.fetch_and_compare(
transfer.addr,%{transfer.data});
};
};
};
ClubV US 2004 51

Accessing Registers
• To access the registers use the read_reg and
write_reg macros.
extend MAIN vr_ad_sequence {
};
!tx_mode : EX_REG_TX_MODE vr_ad_reg;
body() @driver.clock is only {
};
write_reg tx_mode {.frame_kind == DATA};
read_reg tx_mode;
ClubV US 2004 52

3: The Register and
Memory Package
3.c. Advanced Features
ClubV US 2004 53

Advanced Features
• Side effects
• Backdoor
• Visualization
• Coverage collection
• Reset
ClubV US 2004 54

Side effects
• Perform some operation as a result of
accessing a register.
• Clear on read example:
extend EX_REGS_TX_MODE vr_ad_reg {
};
post_access (direction: vr_ad_rw_t) is only {
};
if direction == READ {
};
write_reg_val(0x0);
ClubV US 2004 55

Backdoor access
• Implemented using hdl_path defined in
static_info
extend RW vr_ad_sequence {
};
!r1 : R1 vr_ad_reg;
body() @driver.clock is {
};
read_reg {.backdoor == TRUE} r1;
write_reg {.backdoor == TRUE} r1 {.dest == 3};
ClubV US 2004 56

Address Map Detailed Info
• Detailed contents
of address map:
list of register
files and registers
ClubV US 2004 57

Register Read/Write Stripe Chart
ClubV US 2004 58

4: Summary
ClubV US 2004 59

System Verification Methodology
• sVM provides guidelines to
• Integrating modules to system
• Modeling and verifying registers and memory
• SW/HW co-verification
• Transaction level modeling and verification
• eCeleration of verification components
• And more…
ClubV US 2004 60