tlm based software control of uvcs for vertical verification reuse
Post on 31-Jan-2016
24 Views
Preview:
DESCRIPTION
TRANSCRIPT
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)
2
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
3
Typical TLM Based Verification environment
LMI EMI PROC
Test Code (in C)
ICN
IP1 IP2
TLM RTL User Code Transactor (Sc or SCEMI)
BFMIO
InjectorReceiver
Simulation Emulation
SOC
MemoryVirtual RegisterSLM
RTL IP3
BFM BFM
UVC/ VIP
TLM based Vertical Verification Reuse
4
RTL IP3
PROC
IP TESTS
ICN
IO InjectorReceiver
TLM RTL User Code Transactor (Sc or SCEMI) Simulation Emulation
TLM IP
Memory
Virtual Register
SLM
BFM
PCIe VIP
BFM
RTL IP3
ICNTLM TAC Channel
EMI
SOC Verif Kit
Transactor
IP1 IP2
BFMIO
InjectorReceiver
SOC
LMI
SLM
USB
PCIe
PROC
BFM
VIP
uVC
IP ->SOC
Challenges for VVR
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.
RTL IP3
ICNTLM TAC Channel
EMI
Test Code (in C)
Transactor
IP1 IP2
BFMIO
InjectorReceiver
SOC
LMI
USB
Ethernet
PROC
BFM
VIP
uVCNo C control for
VIPS
Re - Usable C Test with
minimal effort
6
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.
Solution – VAL/VRI to control UVCs
CDN VAL C-APIs
User Test Code
VIP (eVC, PureSpec)
Registers
CDN VAL Layer
Platform
TLM
2.0
• What is Virtual Abstraction Layer/Virtual Register Interface?• 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
TLM Environment
Use Model: IP Verification
TLM Memory TLM Processor
Test Code (in C)Using VRI/VAL APIs
TLM ICN
IP1 IP2
RTL Testbench
RTL DUT
BFM BFM
SATA eVC/DenaliRTL Wrapper
PCIe eVC/DenaliRTL Wrapper
Ethernet eVC/DenaliRTL Wrapper
USB eVC/DenaliRTL Wrapper
PCIe TLM 2Wrapper USB TLM2
Wrapper
SATA TLM2 Wrapper
Ethernet TLM2 Wrapper
AMBA/ ST bus protocol
TLM RTL User Code Transactor (SystemC)
Non physical
link
CDN
Connected on TLM
RTL IP3
Use Model: SoC Verification
ICNTLM TAC Channel
EMI
Test Code (in C)
Transactor
IP1 IP2
TLM RTL User Code Transactor (Sc or SCEMI)
BFMIO
InjectorReceiver
Simulation Emulation
SOC
LMI SLM
USB
Ethernet
PROC
BFM
VIP
uVC
Test Code (in C)Using VRI/VAL C APIs
Test case using 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, ®_htod_info, 1);
}
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
Challenges for VVR revisited
RTL IP3
ICNTLM TAC Channel
EMI
Test Code (in C)
Transactor
IP1 IP2
BFMIO
InjectorReceiver
SOC
LMI
USB
Ethernet
PROC
BFM
VIP
uVCVIPs can now be
controlled through C
ReUsable C Test with minimal effort
Solution – Software Layers
12
Global_hal
<Team>_hal
<IP>_hal
SW virtual TOP
tst tst tst tst tst tst tst tst tst tst
Reusable Test codefrom IP to SoC
SOFTWARE
Global API Services
Team API Services
IP API (I/O & env) Services(Driver)
Platform Specific
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
VIPs controlled through C
RTL IP3
Final Environment
ICNTLM TAC Channel
EMI
Test Code (in C)Using VRI/VAL C APIs
Transactor
IP1 IP2
BFMIO
InjectorReceiver
SOC
LMI SLM
USB
Ethernet
PROC
BFM
VIP
uVC
ReUsable IP TESTs
Global Test Layer
Team Test Layer
ReUsable C Test
15
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
16
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
17
Thank You
18
Verification Challenges
• Each SOC is designed to cater various applications in the marketBut the time to market window is shrinking
• Today in SOC design, 30% effort is spend on design and 70% on verificationHence 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 availableBut not re-usable across verification platforms
19
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 system-level which are very close to the real applications.
20
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.
Final Environment
21
RTL IP3
HCE//ISS
IP VERIF KIT
ICN
IO InjectorReceiver
TLM RTL User Code Transactor (Sc or SCEMI) Simulation Emulation
TLM IP
Memory
Virtual Register
SLM
BFM
BFM BFM
RTL IP3
ICNTLM TAC Channel
EMI
SOC Verif Kit
Transactor
IP1 IP2
BFMIO
InjectorReceiver
SOC
LMI
SLM
USB
PCIe
HCE//ISS
BFM
VIP
uVC
IP ->SOC
PCIe
VIP
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
23
TLM
Overview of Virtual Register Interface
23
TLM target socket
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 C-processor write/read request to virtual register request
APIs for SC methods e.g.
command(arg1,arg2,arg3…argn)
Register Bank
Argument 2
Argument 3
Argument n
Argument 1
Command
ADAPTOR
top related