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, &reg_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