Generic and Automatic Specman Based Verification Environment

Imaging DivisionImaging Division

ST MicroelectronicsST Microelectronics 1

GENERIC AND AUTOMATIC SPECMAN GENERIC AND AUTOMATIC SPECMAN BASED VERIFICATION ENVIRONMENT FOR BASED VERIFICATION ENVIRONMENT FOR IMAGE SIGNAL PROCESSING IPsIMAGE SIGNAL PROCESSING IPs

Abhishek JainAbhishek Jain



IntroductionIntroduction

Image signal processing IP’s …

Image signal processing algorithms are developed and evaluated using ‘C’/Python before RTL implementation.

‘C’/Nathair(Python) models are used as a golden model for the IP development.

The common bus protocols are defined for internal register and data transfers.

A pool of configurable image signal processing IP modules are assembled

together to satisfy a wide range of complex video processing SoCs.



Interfaces of image signal Interfaces of image signal processing IPprocessing IP

Image Signal Processing IP

(RTL)

N

Input video data interfaces

S

Output

Interrupts

Q

Register

Interfaces(T1 interface)

T

Output video

data interfaces

M

Memory interfaces



Generic Verification Generic Verification EnvironmentEnvironment

Basic blocks of Generic Verification …

Q instances of register interface eVC(Everest eVC) agents are used for register interface.

P (P = max (N,T)) instances of video data interface eVC(IDP/VDB/RG/ISB) agents are used for video data interface.

S instances of interrupt checker and M instances of memory model are

used to interface with a DUT.



Basic blocks of Generic Basic blocks of Generic VerificationVerification

Image

Signal

Processing IP

(DUT)

Video

Data Bus interface

eVC

(IDP/VDB/RG/

ISB)

vr_ad

Register

Model

Memory Model

Register Bus

interface

eVC

(Everest)

Apply / Collect

Test

Vectors

Test Environment

Apply / Collect

Test

Vectors



Everest Testbench StructureEverest Testbench Structure



Everest instantiation within a Everest instantiation within a ‘wrapper’ unit. ‘wrapper’ unit.



IDP Env IDP Agent

Coverage

Signals

Monitors and checkers

Sequence

Item

Bfm

Sequence driver

Imaging DUT

IDP Testbench StructureIDP Testbench Structure



IDP instantiation within a ‘wrapper’ unit.IDP instantiation within a ‘wrapper’ unit.

sys

‘wrapper’ unit

data checking unit

Mandatory

idp_wrapper

Idp internal structure

Scoreboards

st_idp_env



Generic and Automatic Verification Generic and Automatic Verification Environment Environment

Test cases for registers and video data interface(s).

IP-XACT API clients are used for generation of IP specific files.

In Generic Verification Environment, Following the IP specific files

Register description file for ‘vr_ad’ register model.

Configuration files to configure the eVC’s.

Constraint file to generate constrained random data sequences.

Functional Coverage file.

Data checker file to compare the output of IP with output of ‘C’/Nathair model and



Generic and Automatic Verification Generic and Automatic Verification Environment (Continued …)Environment (Continued …)

IP-XACT view of register map

Map file

IP-XACT

API Clients

Data checker

Coverage

Driver /Input BFM (for Register/Video

Data interface eVCs)

Configuration

Sequence Generator

Constraint file

Coverage file

Data checker file

Configuration fileRTL

Receiver /Output BFM (for

Register/Video data interface

eVCs)

‘C’/Python

Model

Generated files Env. Read-only files



SPIRIT ScriptsSPIRIT Scripts



Spirit : OverviewSpirit : Overview

SPIRIT stands for “Structure for Packaging, Integrating and Re-using IP within Tool-flows”

Standard based on XML open format

Describes :Register Map

Bus Interfaces

Top-level I/O

Others including interconnect, constraints, …



spirit2regbankspirit2regbank

IP SPIRIT

Description

spirit2regbank –input_spirit_file <IP.xml> …

IP_regbank.v(verilog

Register Bank RTL)

Bus Protocol e.g. STBus T1

IP_regmap.vh (register

map defines)

IP_hwdefs.vh (enumerated Values for

Register fields)

IP_regmap.h (register

map defines)

IP_hwdefs.h (enumerated Values for

Register fields)

Custom format

(e.g. UDF)

IP Specification /

datasheet spec2spirit –i <IP.mif> –o <IP.xml>

IP_regbank.xml

(SPIRITDescriptionof Register

Bank)



spec2verilog - used to convert a mif/docx file spec2verilog - used to convert a mif/docx file into verilog and xml filesinto verilog and xml files SYNOPSIS : spec2verilog.sh -file <file-name>.mif/docx [-out <XMLFileName>.xml] [-log <logName>.log] [-inter] [-version] DESCRIPTION spec2verilog converts a .MIF/.docx file describing registers into : - 4 verilog register banks (8-bits big-endian, 8/16/32-bits little endian T1 data bus) - 4 verilog register banks (8-bits big-endian, 8/16/32-bits little endian T1 data bus) - 2 Verilog header file containing respectively registers offsets and registers values - 2 Corresponding C header file OPTIONS The following option is supported for mif2verilog : -out <XML-FileName>.xml Define the name of the XML file which will contain the Spirit description of the register bank. (Default : filename.xml) -log <log-fileName>.log Define the name of the log file generated by the .MIF parser (Default : display on screen) -inter Full script becomes interactive (user prompt) and step-by-step process. (Default : not interactive) -version Displays the version of each internal tool (ds2spirit, spirit2verilog, ...)



spirit2vradspirit2vrad

IP SPIRIT

Description

spirit2vrad –input_spirit_file <IP.xml> …

IP_coverage.e (Define coverage

on fields)

IP_test_seq.e (Drive test seq.

on DUT)

IP Specification /

datasheetspec2spirit –i <IP.mif> –o <IP.xml>

IP_scoreboard.eIP_constraint.e (Constraints on

random sequence generation)

IP_vrad_def.e (‘vrad’ register

description)



OPTIONS

-i <filename> Specify the input XML file with complete path (Mandatory)

-o <directory> Specify the destination directory to write RTL (Optional : Default is ./vrad_verif)

-c <integer> Specify the coverage option (Optional: 0 for NO and 1 for YES, Default: 1)

-h To get access to help -v To know tool version

spirit2vrad - used to convert a xml filespirit2vrad - used to convert a xml fileinto e filesinto e files



Register VerificationRegister Verification

Standard ‘vr_ad’ eVC is used in conjuction with register interface eVC(Everest) for efficient register verification.

Whenever the IP registers are read/written, the associated ‘vr_ad’ eVC pre-defined registers are also updated and IP register contents will be verified by a self-checking scheme.



Registers in the Register Interface Registers in the Register Interface eVC(Everest ) ArchitectureeVC(Everest ) Architecture

Register Interface eVC(Everest) Env

Address map

Master Agent Sequence

Driver

Monitor BFM

Image Signal Processing IP module

Reg. Seq.Driver

reg_file



Image Processing Algorithm Bit Accurate Image Processing Algorithm Bit Accurate VerificationVerification

For the purpose of output video data checking, ’C’/Nathair model is integrated with the generic verification environment.

Output of ‘C’/Nathair model is compared with the output of the IP in data checkers

Separate data checkers are used for the register interface eVC(Everest) and video data interface eVC(IDP/VDB/RG/ISB).

Data checkers of register and video data interface eVC’s are automatically generated by IP-XACT API clients.



Data Checker and ‘C’/Nathair ModelData Checker and ‘C’/Nathair Model

Testcase for imagedata

Control Data

Register interface eVC(Everest)

Video Data interface eVC

Image Signal Processing IP (RTL)

C/Nathair Model

IP Output(Status or/and data)

C/Nathair Model Output(Status or/and data (image))

Data Checker

Image Generator

Testcase for registersdata

vr_ad register model (generator)

Memory

Model



Usage of Verification Environment at Usage of Verification Environment at Sub-System LevelSub-System Level

All the R IP’s in Image signal processor pipe are connected serially. Thus, Either ‘C’ models of the image signal processing IP’s are connected serially in the same order as the corresponding Image signal processing IP’s or Single Nathair(Python) model of Image signal processor pipe is developed.

Input image Data will be driven to the first image signal processing IP and ‘C’/Nathair Model and Output data of Rth image signal processing IP and ‘C’/Nathair model will be compared.

R register files (of vr_ad register model) are required for R IP’s. R register files can be added to the address map (by setting the absolute base address for each register file). This can be done at runtime or at post-generate.



Environment for Verification of Environment for Verification of Image signal processor pipe Image signal processor pipe (Sub-System Level)(Sub-System Level)

Score

board

Nathair(Python) model of Image signal processor pipe

Image signal processing IP1

Video Data

Interface eVC

output BFM

Image signal processing IP2

Image signal processing IPr

Video Data

Interface eVC

input BFM

Register Interface eVC

vr_ad register model with reg files

for IP1, IP2 …, IPr


ST MicroelectronicsST MicroelectronicsApr 12, 2023

24

Verification CockpitVerification Cockpit

It isA Linux compatible product installed & already used on several ST sites by lots of users

An infrastructure tool that bridges other tools such as Specman, NCSim, eManager, Certitude

A tool that integrates with LSF & Clearcase

Highly customizable to fit your needs

A tool that will enhance your productivity

It is not A Cadence tool

A replacement of Specman, Enterprise Manager or Certitude


ST MicroelectronicsST MicroelectronicsApr 12, 2023

25

vManager using Verification CockpitvManager using Verification Cockpit

For running regressions and coverage analysis, vManager tool is used.

Verification Cockpit is helpful for simple setup of vManager Automatic generation of VSIF file from CSV file.

Option for launching regressions from web server.

Central maintenanceBenefits of best practices and avoid common mistakes.

Technology

Generic and Automatic Specman Based Verification Environment