Download to read offline
![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](https://image.slidesharecdn.com/dvclube2102-tlmbasedsoftwarecontrolofuvcsforverticalverificationreuse-krishnakumar-150911073316-lva1-app6891/75/DvClub-2102-tlm-based-software-control-of-uvcs-for-vertical-verification-reuse-krishna-kumar-10-2048.jpg)
More Related Content
Similar to DvClub 2102 tlm based software control of uvcs for vertical verification reuse - krishna kumar
DvClub 2102 tlm based software control of uvcs for vertical verification reuse - krishna kumar
- 1. TLM based softwarecontrol 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 BasedVerification 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. 3 Typical TLM BasedVerification environment LMIEMI PROC Test Code (in C) ICN IP1 IP2 TLM RTL User Code Transactor (Sc or SCEMI) BFM IO Injector Receiver Simulation Emulation SOC Memory Virtual Register SLM RTL IP3 BFM BFM UVC/ VIP
- 4. TLM based VerticalVerification Reuse 4 RTL IP3 PROC IP TESTS ICN IO Injector Receiver 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 BFM IO Injector Receiver SOC LMI SLM USB PCIe PROC BFM VIP uVC IP ->SOC
- 5. Challenges for VVR Withthe 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 BFM IO Injector Receiver SOC LMI USB Ethernet PROC BFM VIP uVCNo C control for VIPS Re - Usable C Test with minimal effort
- 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.
- 7. Solution – VAL/VRIto 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
- 8. Use Model: IPVerification TLM Memory TLM Processor Test Code (in C) Using VRI/VAL APIs TLM ICN IP1 IP2 RTL Testbench RTL DUT BFM BFM SATA eVC/Denali RTL Wrapper PCIe eVC/Denali RTL Wrapper Ethernet eVC/Denali RTL Wrapper USB eVC/Denali RTL Wrapper PCIe TLM 2 Wrapper USB TLM2 Wrapper SATA TLM2 Wrapper Ethernet TLM2 Wrapper AMBA/ ST bus protocol TLM RTL User Code Transactor (SystemC) Non physical link CDN
- 9. Connecte d on TLM RTLIP3 Use Model: SoC Verification ICNTLM TAC Channel EMI Test Code (in C) Transactor IP1 IP2 TLM RTL User Code Transactor (Sc or SCEMI) BFM IO Injector Receiver Simulation Emulation SOC LMI SLM USB Ethernet PROC BFM VIP uVC Test Code (in C) Using VRI/VAL C APIs
- 10. Test case usingCDN-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
- 11. Challenges for VVRrevisited RTL IP3 ICNTLM TAC Channel EMI Test Code (in C) Transactor IP1 IP2 BFM IO Injector Receiver SOC LMI USB Ethernet PROC BFM VIP uVC VIPs can now be controlled through C ReUsable C Test with minimal effort
- 12. Solution – SoftwareLayers 12 Global_hal <Team>_hal <IP>_hal SW virtual TOP tst tst tst tst tst tst tst tst tst tst Reusable Test code from IP to SoC S O F T W A R E Global API Services Team API Services IP API (I/O & env) Services(Driver) Platform Specific
- 13. Flexible Software Approachfor 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
- 14. VIPs controlled through C RTL IP3 FinalEnvironment ICNTLM TAC Channel EMI Test Code (in C) Using VRI/VAL C APIs Transactor IP1 IP2 BFM IO Injector Receiver SOC LMI SLM USB Ethernet PROC BFM VIP uVC ReUsable IP TESTs Global Test Layer Team Test Layer ReUsable C Test
- 15. 15 Benefits • Reuse ofexisting 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. 16 Conclusion • A complexIP/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.
- 18. 18 Verification Challenges • EachSOC 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
- 19. 19 Purpose In order toprovide 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
- 20. 20 Solution • In orderto 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 21 RTL IP3 HCE//ISS IPVERIF KIT ICN IO Injector Receiver 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 BFM IO Injector Receiver SOC LMI SLM USB PCIe HCE//ISS BFM VIP uVC IP ->SOC PCIe VIP
- 22. Impacts on testwriting 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 TLM Overview of VirtualRegister 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,arg 2,arg3…argn) Register Bank Argument 2 Argument 3 Argument n Argument 1 Command A D A P T O R
Editor's Notes
- #19 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.
- #24 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.