TLM based software control of UVCs for Vertical Verification Reuse

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. Transactor (Sc or SCEMI) TLM RTL User Code Typical TLM Based Verification environment UVC/ VIP SOC RTL IP3 IO InjectorReceiver BFM BFM BFM IP1 IP2 ICN LMI EMI Memory PROC SLM Virtual Register Test Code (in C) Emulation Simulation

4. TLM based Vertical Verification Reuse BFM PCIe VIP BFM TLM RTL User Code Transactor (Sc or SCEMI) SOC RTL IP3 TLM IP IO InjectorReceiver RTL IP3 IO InjectorReceiver BFM PCIe VIP IP2 IP1 USB IP ->SOC uVC Emulation Simulation ICN TLM TAC Channel ICN LMI EMI BFM Memory PROC PROC Transactor SLM SLM Virtual Register IP TESTS SOC Verif Kit

5. Challenges for VVR SOC RTL IP3 IO InjectorReceiver BFM No C control for VIPS Ethernet VIP IP1 IP2 USB uVC TLM TAC Channel ICN LMI EMI BFM PROC Transactor Test Code (in C) • 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. 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.

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 TLM Processor SATA TLM2 Wrapper Ethernet TLM2 Wrapper Test Code (in C) Using VRI/VAL APIs Transactor (SystemC) TLM RTL User Code CDN

9. Transactor (Sc or SCEMI) TLM RTL User Code Use Model: SoC Verification SOC RTL IP3 IO InjectorReceiver BFM Ethernet VIP IP1 IP2 Connected on TLM USB uVC TLM TAC Channel ICN LMI EMI BFM PROC Transactor SLM Test Code (in C) Test Code (in C) Using VRI/VAL C APIs Emulation Simulation

10. Test case using CDN-VRI-API static interror_count = 0; // main() intesw_main(intargc, 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, &reg_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

11. Challenges for VVR revisited SOC RTL IP3 IO InjectorReceiver BFM VIPs can now be controlled through C Ethernet VIP IP1 IP2 USB uVC TLM TAC Channel ICN LMI EMI BFM PROC Transactor Test Code (in C) ReUsable C Test with minimal effort

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 PlatformSpecific

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. Final Environment SOC RTL IP3 IO InjectorReceiver BFM Ethernet VIPs controlled through C VIP IP1 IP2 USB uVC TLM TAC Channel ICN LMI EMI BFM PROC Transactor SLM Global Test Layer Test Code (in C) Using VRI/VAL C APIs Team Test Layer ReUsable C Test ReUsable IP TESTs

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 inmulti-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

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. Final Environment BFM BFM BFM TLM RTL User Code Transactor (Sc or SCEMI) SOC RTL IP3 TLM IP IO InjectorReceiver RTL IP3 IO InjectorReceiver BFM PCIe VIP IP2 IP1 VIP USB IP ->SOC uVC PCIe Emulation Simulation ICN TLM TAC Channel ICN LMI EMI BFM Memory HCE//ISS HCE//ISS Transactor SLM SLM Virtual Register IP VERIF KIT SOC Verif Kit

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 Register Bank 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 A D A P T O R Argument 1 Argument 2 Argument 3 Argument n Command APIs for SC methods e.g. command(arg1,arg2,arg3…argn) 23