TLM Based Software Control of UVCs for Vertical Verification Reuse

777 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
777
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Vertical Verification Reuse Training
  • Vertical Verification Reuse Training
  • Vertical Verification Reuse Training
  • Vertical Verification Reuse Training
  • Vertical Verification Reuse Training
  • Vertical Verification Reuse Training
  • Vertical Verification Reuse Training
  • 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.
  • 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.
  • TLM Based Software Control of UVCs for Vertical Verification Reuse

    1. 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. 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 2
    3. 3. Typical TLM Based Verification environment UVC/ VIP SOC IO RTL IP3 Injector BFM Receiver 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 3
    4. 4. TLM based Vertical Verification Reuse SOC TLM IP RTL IP3 IO RTL IP3 IO Injector BFMInjector BFM ReceiverReceiver PCIe BFM VIP VIP PCIe USB uVC IP1 IP2 IP ->SOC ICN TLM TAC Channel ICN BFM Memory EMI LMI PROC Transactor PROC SLM SLMVirtual Register IP TESTS SOC Verif Kit TLM RTL User Code Transactor (Sc or SCEMI) Simulation Emulation 4
    5. 5. Challenges for VVR SOC IO RTL IP3 Injector BFM Receiver Ethernet VIP No C USB uVC IP1 IP2 control for VIPS TLM TAC Channel ICN BFM EMI LMI Transactor PROCWith the emergence of (UVM) the hardware verification interface has beenstandardized, however this is still out of bounds of test developers who primarily Test Code (in C)develop their tests in embedded C. Most of the embedded test infrastructuretoday use “trick-boxes” for controlling simple Bus functional models (BFM) froman embedded software. • These “trick-boxes” are not scalable to complex protocols like USB, Re - Usable C Test with PCIe, Ethernet etc. minimal effort • Do not provide advance stimulation generation or exhaustive coverage and data checks that a UVM based verification component (UVC) provides.
    6. 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. 6
    7. 7. Solution – VAL/VRI to control UVCs• What is Virtual Abstraction Layer/Virtual Register Interface? User Test Code • An interface layer over VIP (PS/eVC) to make it controllable through C-interface. CDN VAL C-APIs • 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 TLM Environment connect to a TLM environment. TLM 2.0 • Hides VIP intrinsic details irrespective of VIP type (eVC/PureSpec). • This controllability of VIPs are exposed to user through predefined C-APIs. CDN VAL Layer • APIs are provided by the VIP provider. • No physical layer to take care at VIP level Registers VIP (eVC, PureSpec) Platform
    8. 8. Use Model: IP Verification RTL Testbench Non SATA eVC/Denali Ethernet eVC/Denaliphysical RTL Wrapper RTL Wrapper link RTL DUT PCIe eVC/Denali USB eVC/Denali RTL Wrapper RTL Wrapper BFM BFM PCIe TLM 2 Wrapper USB TLM2 Wrapper IP1 IP2 AMBA/ ST bus protocol TLM ICN TLM SATA TLM2 Memory TLM Processor Ethernet TLM2 Wrapper Wrapper Test Code (in C) Using VRI/VAL APIs CDN TLM RTL User Code Transactor (SystemC)
    9. 9. Use Model: SoC Verification SOC IO RTL IP3 Injector BFM Receiver Ethernet VIP USB uVC IP1 IP2Connected on TLM TLM TAC Channel ICN BFM EMI LMI Transactor SLM PROC Test Code (in C) Test Code (in C) Using VRI/VAL C APIs TLM RTL User Code Transactor (Sc or SCEMI) Simulation Emulation
    10. 10. Test case using CDN-VRI-API static int error_count = 0; // main() void sata_main_test()int esw_main(int argc, char * argv[]) { { struct sata_register_htod_t reg_htod_info; // COB-init, boot, lmi-init, reg_htod_info.c_bit = 1; error_count = pre_test_config(); reg_htod_info.features = 0x21; reg_htod_info.secnum = 0x22; // sata specific test reg_htod_info.cyllow = 0x23; error_count = sata_main_test(); reg_htod_info.cylhigh = 0x24; // test post checking reg_htod_info.drvhead = 0xFF; error_count = test_post_processing(); reg_htod_info.secnum_exp = 0x25; reg_htod_info.cyllow_exp = 0x26; return error_count; reg_htod_info.cylhigh_exp = 0x27; } reg_htod_info.features_exp = 0x28; reg_htod_info.seccnt = 0x29; reg_htod_info.seccnt_exp = 0x2A; void vri_sata_register_htod ( reg_htod_info.hob = 0; unsigned long instance_num, reg_htod_info.srst = 1; struct sata_register_htod_t *reg_htod_info, reg_htod_info.ien = 0; unsigned long frame_count) { // implementation //call SATA VAL API } vri_sata_register_htod( 0, &reg_htod_info, 1); } Main test SATA Main test (using CDN- API) CDN-VRI-API
    11. 11. Challenges for VVR revisited SOC IO RTL IP3 Injector BFM Receiver Ethernet VIP VIPs can USB uVC IP1 IP2 now be controlled through C TLM TAC Channel ICN BFM EMI LMI Transactor PROC Test Code (in C) ReUsable C Test with minimal effort
    12. 12. Solution – Software LayersReusable Test code from IP to SoC tst tst tst tst tst tst tst tst tst tst S SW virtual TOP O F T <IP>_hal IP API (I/O & env) Services(Driver) W <Team>_hal Team API Services A R Global API Services E Global_hal Platform Specific 12
    13. 13. Flexible Software Approach for reusabletests 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
    14. 14. Final Environment SOC IO RTL IP3 Injector BFM Receiver Ethernet VIP VIPs USB uVC IP1 IP2controlledthrough C TLM TAC Channel ICN BFM EMI LMI Transactor SLM PROC Global Test(in C) Test Code Layer Using VRI/VAL C APIs Team Test Layer ReUsable C Test ReUsable IP TESTs
    15. 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 15
    16. 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 16
    17. 17. Thank You 17
    18. 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 18
    19. 19. PurposeIn order to provide full controllability to the C testdeveloper over the verification components, a virtual layercan be created using the capabilities of TLM 2.0 layer inboth SystemC and UVM. This Virtual layer exposes thesequences of the UVC into SystemC TLM2.0 whichenables the embedded software engineers to configureand control the Verification IPs from embedded softwareand generate the same advanced stimulation orexhaustive coverage as provided by UVCs.To address the Verification Challenges faced in the SOCverification , comprising of several high-end IPs, businterfaces and processors.To be able to develop the complex test scenarios at the 19
    20. 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. 20
    21. 21. Final Environment SOC TLM IP RTL IP3 IO RTL IP3 IO Injector BFMInjector BFM ReceiverReceiver BFM BFM VIP PCIe VIP USB uVC IP1 IP2 PCIe IP ->SOC ICN TLM TAC Channel ICN BFM Memory EMI LMI HCE//ISS Transactor HCE//ISS SLM SLMVirtual Register IP VERIF KIT SOC Verif Kit TLM RTL User Code Transactor (Sc or SCEMI) Simulation Emulation 21
    22. 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. 22
    23. 23. Overview of Virtual Register Interface  TLM target socket Register Bank  Memory mapped set of A Argument 1 registers D Argument 2 A  Sufficient number of P Argument 3TLM T registers to support all O number of arguments R Argument n Command  Command register written with enum corresponding to each command supported by APIs for SC uVC and exported from e methods e.g. command(arg1,arg  TLM adapter to convert C- 2,arg3…argn) processor write/read request to virtual register request 23 23

    ×