TLM based software control of UVCs for Vertical
Verification Reuse
Sandeep Jana (ST),
Sonik Sachdeva (ST),
Krishna Kumar (ST),
Swami Venkatesan (Cadence)
, Debajyoti Mukherjee (Cadence)
Agenda
•
•
•
•
•
Typical TLM Based Verification Environment
TLM Based Vertical Verification Reuse
Challenges for VVR
Summary of Challenges
Solution – VAL/VRI to control UVCs
– Use Model: IP Verification
– Use Model: SoC Verification
– Test case using CDN-VRI-API
• Solution – Software Layers
– Flexible Software Approach for reusable tests
• Final Environment
• Benefits
• Conclusion
2
Typical TLM Based Verification environment
UVC/
VIP
SOC
IO
Injector
Receiver
RTL IP3
BFM
BFM
IP1
BFM
IP2
ICN
Memory
EMI LMI
SLM
Virtual Register
TLM
RTL
User Code
PROC
Test Code (in C)
Transactor (Sc or SCEMI)
Simulation
Emulation
3
TLM based Vertical Verification Reuse
SOC
TLM IP
RTL IP3
IO
Injector
Receiver
BFM
PCIe
VIP
RTL IP3
IO
Injector
Receiver
BFM
BFM
VIP
PCIe
USB
uVC
IP1
IP2
IP ->SOC
ICN
ICN
TLM TAC Channel
BFM
Memory
EMI
PROC
LMI
PROC
Transactor
SLM
SLM
Virtual Register
IP TESTS
SOC Verif Kit
TLM
RTL
User Code
Transactor (Sc or SCEMI)
Simulation
Emulation
4
Challenges for VVR
SOC
IO
Injector
Receiver
BFM
Ethernet
No C control
for VIPS
RTL IP3
VIP
USB
uVC
IP1
IP2
TLM TAC Channel
ICN
BFM
EMI LMI
Transactor
With the emergence of (UVM) the hardware verification interface has been
standardized, however this is still out of bounds of test developers who primarily
develop their tests in embedded C. Most of the embedded test infrastructure
today use “trick-boxes” for controlling simple Bus functional models (BFM) from
an embedded software.
• These “trick-boxes” are not scalable to complex protocols like USB,
PCIe, Ethernet etc.
• Do not provide advance stimulation generation or exhaustive coverage
and data checks that a UVM based verification component (UVC)
provides.
PROC
Test Code (in C)
Re - Usable C
Test with minimal
effort
Summary of Challenges
• A Interface to configure and control VIPs from C
• Ease of integration in verif environment
• Ease of reusability from IP to SOC.
• Provides VIP sequence library that can be used for developing C
test suites
• A test case infrastructure providing a well defined test layers
facilitation easy re-use of IP Tests to SOC.
6
Solution – VAL/VRI to control UVCs
• What is Virtual Abstraction Layer/Virtual
Register Interface?
CDN VAL C-APIs
TLM Environment
TLM
2.0
• An interface layer over VIP (PS/eVC) to
make it controllable through C-interface.
• Verification Abstraction Layer is a high
level API that hides the low level Register
interface to UVC which is VRI.
• Provides a TLM 2.0 target socket to
connect to a TLM environment.
• Hides VIP intrinsic details irrespective of
VIP type (eVC/PureSpec).
• This controllability of VIPs are exposed to
user through predefined C-APIs.
• APIs are provided by the VIP provider.
• No physical layer to take care at VIP level
User Test Code
CDN VAL Layer
Registers
VIP (eVC, PureSpec)
Platform
Use Model: IP Verification
RTL Testbench
Non
physical
link
SATA eVC/Denali
RTL Wrapper
Ethernet eVC/Denali
RTL Wrapper
RTL DUT
PCIe eVC/Denali
RTL Wrapper
USB eVC/Denali
RTL Wrapper
BFM
BFM
PCIe TLM 2
Wrapper
USB TLM2
Wrapper
IP1
IP2
AMBA/ ST bus
protocol
TLM ICN
TLM
Memory
SATA TLM2
Wrapper
TLM Processor
Ethernet TLM2
Wrapper
Test Code (in C)
Using VRI/VAL APIs
CDN
TLM
RTL
User Code
Transactor (SystemC)
Use Model: SoC Verification
SOC
IO
Injector
Receiver
RTL IP3
BFM
Ethernet
VIP
USB
uVC
IP1
IP2
Connected
on TLM
TLM TAC Channel
ICN
BFM
EMI LMI
Transactor
PROC
SLM
Test
Test Code
Code (in
(in C)
C)
Using VRI/VAL C APIs
TLM
RTL
User Code
Transactor (Sc or SCEMI)
Simulation
Emulation
Test case using CDN-VRI-API
static int error_count = 0;
// main()
int esw_main(int argc, char * argv[])
{
// COB-init, boot, lmi-init,
error_count = pre_test_config();
// sata specific test
error_count = sata_main_test();
// test post checking
error_count = test_post_processing();
return error_count;
}
void vri_sata_register_htod(
unsigned long instance_num,
struct sata_register_htod_t *reg_htod_info,
unsigned long frame_count)
{
// implementation
}
Main test
SATA Main test (using CDN-API)
CDN-VRI-API
void sata_main_test()
{
struct sata_register_htod_t reg_htod_info;
reg_htod_info.c_bit = 1;
reg_htod_info.features = 0x21;
reg_htod_info.secnum = 0x22;
reg_htod_info.cyllow = 0x23;
reg_htod_info.cylhigh = 0x24;
reg_htod_info.drvhead = 0xFF;
reg_htod_info.secnum_exp = 0x25;
reg_htod_info.cyllow_exp = 0x26;
reg_htod_info.cylhigh_exp = 0x27;
reg_htod_info.features_exp = 0x28;
reg_htod_info.seccnt = 0x29;
reg_htod_info.seccnt_exp = 0x2A;
reg_htod_info.hob = 0;
reg_htod_info.srst = 1;
reg_htod_info.ien = 0;
//call SATA VAL API
vri_sata_register_htod(0, &reg_htod_info, 1);
}
Challenges for VVR revisited
SOC
IO
Injector
Receiver
BFM
Ethernet
VIPs can now
be controlled
through C
RTL IP3
VIP
USB
uVC
IP1
IP2
TLM TAC Channel
ICN
BFM
EMI LMI
Transactor
PROC
Test Code (in C)
ReUsable C Test with
minimal effort
Solution – Software Layers
Reusable Test code
from IP to SoC
tst tst tst tst tst tst tst tst tst tst
S
O
F
T <IP>_hal
W
<Team>_hal
A
R
E Global_hal
SW virtual TOP
IP API (I/O & env)
Services(Driver)
Team API
Services
Global API
Services
Platform Specific
12
Flexible Software Approach for reusable
tests
Generic functions like Read/Write, print messages etc
goes into Global API’s
IP Testbench specific tasks goes into IP API layer. For
example interrupt handling,VC configuration etc
Configuration of IP (driver layer) goes into service layer
Api’s implementation will differ from env to env. Services
will remain unchanged.
Testcases will be written by using global and IP
API’s/services.
13
Final Environment
SOC
IO
Injector
Receiver
Ethernet
VIPs
controlled
through C
RTL IP3
BFM
VIP
USB
IP1
uVC
IP2
TLM TAC Channel
ICN
BFM
EMI LMI
Transactor
SLM
PROC
Test Code
C)
Global
Test(in
Layer
Using VRI/VAL C APIs
Team Test Layer
ReUsable
C Test
ReUsable IP TESTs
Benefits
• Reuse of existing IP verification platforms and strategy
• Development of SOC verification environment in short time
• Reuse of existing test suites across the platform
• Develop complex system-level test case
15
Conclusion
• A complex IP/SOC Verification effort and time can be
significantly reduced using the VIP with TLM
infrastructure
• This verification environment architecture is reusable
and scalable from IP to SOC level
• Exposing the complete VIP sequence library to TLM
interface is required to allow development of platform
independent test suites
16
Thank You
17
Verification Challenges
• Each SOC is designed to cater various applications in the market
But the time to market window is shrinking
• Today in SOC design, 30% effort is spend on design and 70% on
verification
Hence the verification methodology plays a crucial role
• Individual blocks are thoroughly verified
But the same methodology cannot be scaled up at SOC level
• Verification Components (VC) are available in multi-languages
(Verilog, e, Vera, System Verilog, SystemC)
Need to plug-in different VCs irrespective of the language
• Legacy test suites are available
But not re-usable across verification platforms
18
Purpose
In order to provide full controllability to the C test
developer over the verification components, a virtual layer
can be created using the capabilities of TLM 2.0 layer in
both SystemC and UVM. This Virtual layer exposes the
sequences of the UVC into SystemC TLM2.0 which
enables the embedded software engineers to configure
and control the Verification IPs from embedded software
and generate the same advanced stimulation or
exhaustive coverage as provided by UVCs.
To address the Verification Challenges faced in the SOC
verification , comprising of several high-end IPs, bus
interfaces and processors.
To be able to develop the complex test scenarios at the
19
Solution
• In order to provide full controllability to the C test developer over
the verification components, a virtual layer can be created using
the capabilities of TLM 2.0 layer in both SystemC and UVM.
• This Virtual layer exposes the sequences of the UVC into SystemC
TLM2.0 which enables the embedded software engineers to
configure and control the Verification IPs from embedded software
and generate the same advanced stimulation or exhaustive
coverage as provided by UVCs.
• A TLM Vertical Verification ReUse Methodology that enables reuse
of the IP verification environment and test cases to SOC verif/valid
environment.
20
Final Environment
SOC
TLM IP
RTL IP3
IO
Injector
Receiver
BFM
BFM
RTL IP3
IO
Injector
Receiver
BFM
BFM
VIP
VIP
PCIe
USB
uVC
IP1
IP2
PCIe
IP ->SOC
ICN
ICN
TLM TAC Channel
BFM
Memory
EMI
HCE//ISS
LMI
HCE//ISS
Transactor
SLM
SLM
Virtual Register
IP VERIF KIT
SOC Verif Kit
TLM
RTL
User Code
Transactor (Sc or SCEMI)
Simulation
Emulation
21
Impacts on test writing for Reuse
• main() to be replaced with <ip_name>_tcode () which will be
called within the SoC level main()
• Use parameters instead of Hard Coded values (IP Base
Addresses & TAC Memory Base Addresses)
• Dummy functions for triggering the Harnesses, Clock
generator & DMA Engines to be provided within the test
code. These will be defined differently at IP/SoC level.
• Similar TAC Memory loading/dumping process to be used
at IP/SoC level. Memory Load/Dump must be controlled by
software within C code.
• Test MUST be self checking and pass a Error Count
variable to the SoC layer at the end of test.
22
Overview of Virtual Register Interface
 TLM target socket
Register Bank
TLM
A
D
A
P
T
O
R
Argument 1
Argument 2
Argument 3
Argument n
Command
APIs for SC
methods e.g.
command(arg1,arg
2,arg3…argn)
 Memory mapped set of
registers
 Sufficient number of
registers to support all
number of arguments
 Command register written
with enum corresponding to
each command supported by
uVC and exported from e
 TLM adapter to convert Cprocessor write/read request
to virtual register request
23
23