Download presentation
Presentation is loading. Please wait.
1
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
UVC/ VIP SOC RTL IP3 IO Injector Receiver BFM BFM BFM IP1 IP2 ICN EMI LMI Memory PROC SLM Virtual Register Test Code (in C) TLM RTL User Code Transactor (Sc or SCEMI) Simulation Emulation Vertical Verification Reuse Training
4
TLM based Vertical Verification Reuse
SOC TLM IP RTL IP3 RTL IP3 IO Injector Receiver IO Injector Receiver BFM BFM PCIe VIP PCIe VIP IP1 IP2 IP ->SOC USB uVC ICN TLM TAC Channel ICN EMI LMI BFM Memory PROC Transactor PROC SLM SLM Virtual Register IP TESTS SOC Verif Kit TLM RTL User Code Transactor (Sc or SCEMI) Simulation Emulation
5
Re - Usable C Test with minimal effort
Challenges for VVR SOC RTL IP3 IO Injector Receiver BFM No C control for VIPS Ethernet VIP IP1 IP2 USB uVC TLM TAC Channel ICN EMI LMI BFM Transactor PROC 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. Test Code (in C) Re - Usable C Test with minimal effort Vertical Verification Reuse Training
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.
7
Solution – VAL/VRI to control UVCs
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 User Test Code CDN VAL C-APIs TLM Environment TLM 2.0 CDN VAL Layer VIP (eVC, PureSpec) Registers Platform
8
Use Model: IP Verification
Non physical link RTL Testbench SATA eVC/Denali RTL Wrapper RTL DUT Ethernet eVC/Denali RTL Wrapper 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) Vertical Verification Reuse Training
9
Use Model: SoC Verification
RTL IP3 IO Injector Receiver BFM Ethernet VIP IP1 IP2 Connected on TLM USB uVC TLM TAC Channel ICN EMI LMI BFM Transactor PROC SLM Test Code (in C) Using VRI/VAL C APIs Test Code (in C) TLM RTL User Code Transactor (Sc or SCEMI) Simulation Emulation Vertical Verification Reuse Training
10
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 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); } 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 Vertical Verification Reuse Training
11
Challenges for VVR revisited
SOC RTL IP3 IO Injector Receiver BFM VIPs can now be controlled through C Ethernet VIP IP1 IP2 USB uVC TLM TAC Channel ICN EMI LMI BFM Transactor PROC Test Code (in C) ReUsable C Test with minimal effort Vertical Verification Reuse Training
12
Solution – Software Layers
Reusable Test code from IP to SoC tst tst tst tst tst tst tst tst tst tst S O F T W A R E SW virtual TOP <IP>_hal IP API (I/O & env) Services(Driver) <Team>_hal Team API Services Global API Services Global_hal Platform Specific
13
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.
14
VIPs controlled through C
Final Environment SOC RTL IP3 IO Injector Receiver BFM VIPs controlled through C Ethernet VIP IP1 IP2 USB uVC TLM TAC Channel ICN EMI LMI BFM Transactor PROC SLM Global Test Layer Team Test Layer Test Code (in C) Using VRI/VAL C APIs ReUsable C Test ReUsable IP TESTs Vertical Verification Reuse Training
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 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 3. 4. Shifting verif env from verilog to e or systemVerilog , unable to use the test case. Need to rewrite. Lot of effort spend on test suite development and if not reused it is wasted.
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.
21
Transactor (Sc or SCEMI)
Final Environment SOC TLM IP RTL IP3 RTL IP3 IO Injector Receiver IO Injector Receiver BFM BFM PCIe VIP IP1 IP2 VIP IP ->SOC USB PCIe uVC ICN TLM TAC Channel ICN EMI LMI BFM Memory HCE//ISS Transactor HCE//ISS SLM SLM Virtual Register IP VERIF KIT SOC Verif Kit TLM RTL User Code Transactor (Sc or SCEMI) Simulation Emulation
22
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.
23
Overview of Virtual Register Interface
TLM 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 Register Bank Argument 2 Argument 3 Argument n Argument 1 Command A D P T O R APIs for SC methods e.g. command(arg1,arg2,arg3…argn) Just while explaining you can tell that writing to the command register will simultaneously call the api corresponding to that command. The flow was from RTL to TLM. So TLM module took care for software compatibility. 23 23
Similar presentations
