0% found this document useful (0 votes)
8 views

Reusable DPI Flow Across Verification Validation SW

Uploaded by

doomachaley
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

Reusable DPI Flow Across Verification Validation SW

Uploaded by

doomachaley
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 14

Reusable DPI flow across

Verification, Validation & SW


Prasad Haldule, Macom India
Pushkar Naik, Macom India

© Accellera Systems Initiative 1


Background
• ASICs usually have large number of configuration
registers.
• Depending on Use-Case, these need to be
programmed in a particular sequence with
appropriate values.
• Verification(pre-silicon), validation(post-silicon) and
finally SW engineers have their own approaches for
these configuration sequences.
• Can we have a coherent configuration
flow across teams?
© Accellera Systems Initiative 2
Introduction
• Verification team can develop “final SW-deliverable
quality” C DPIs and use these to configure the chip.
• Validation and SW can leverage these DPIs in their
respective setups.
• C functions can easily be imported or ported across
in System Verilog (typical Verification language) and
Python (typical language used for Validation)
• Thus, along with HW, SW also gets tested before
delivering to customer, thrice!!!

© Accellera Systems Initiative 3


Objective
The main objectives of this paper are,
• to discuss the original flows employed by
Verification, Validation and SW teams to configure a
chip before starting the application, and
• to demonstrate how these can be replaced with a
common layer of DPI which could be accessed by all
three teams, without compromising on their key
goals and quality.

© Accellera Systems Initiative 4


Application Flows-1

Validation
SV Test
Test

Python/C
SV Configuration
Configuration
tasks routines

HW Registers HW Registers

VERIFICATION VALIDATION

© Accellera Systems Initiative 5


Application Flows-2
Host Processor
Application Embedded
SW Processor

API LIB + DB FW

ISR DPI FW DPI ISR


INT INT

HW Registers

SOFTWARE

© Accellera Systems Initiative 6


Common C-DPI Layer

SW APIs Verification Tests Validation scripts

C-DPI Library

HW Registers

© Accellera Systems Initiative 7


SW Stack With C-DPI
Application

SW API
DB

High Level DPI

ISR Low Level DPI

HW Registers

© Accellera Systems Initiative 8


Types of DPIs
• Low Level DPIs
– These are the DPIs which directly access the registers.
– A low level DPI can be called by a high-level DPI or by API
directly.
• High Level DPIs
– intelligent DPIs which take minimal input arguments, and
from these, derive the values to be passed to one-or-many
low-or-high level DPIs below
– All the sequencing and data path selection logic is
embedded in such high level DPIs.

© Accellera Systems Initiative 9


C-DPI in Verification Environment-1
SV Environment
Linked

SV Test

Shared Object
ChipDpiFunc1

SV DPI Lib C DPI Lib


ChipDpiFunc1
Imports Exports
ChipDpiFieldAccessor
ChipDpiFieldAccessor
Exports Imports
Context

HW Access

HW
© Accellera Systems Initiative 10
C-DPI in Verification Environment-2
• A test or configuration sequence in Verification
environment is just a series of high level DPI calls.
• If some randomization needs to be achieved,
corresponding low-level DPIs are called once again,
with the randomized values, after calling high-level
DPIs.

© Accellera Systems Initiative 11


Challenges
• Design, Verification, Validation and SW teams have to
be involved right from the beginning of the project
• A small amount of hit in terms of simulation time is
caused because of re-writing of some of the registers
with randomized values using LDPI, after being
already programmed using HDPI.
• For SoCs, the SW should be modularized enough so
that the Verification does not end up using bulk of
the SW and slow up simulations.

© Accellera Systems Initiative 12


SUMMARY
• The common DPI flow helped in better structuring and
re-use of the configuration code.
• Any fix required by Validation and SW teams was re-
verified in Verification environment.
• A good portion of SW testing happens during
Verification phase itself
• As configuration sequences were well stabilized, the chip
bring-up time in lab (post-silicon) was reduced by 40%.
• This flow has become an integral part of every chip
development cycle in our company now.

© Accellera Systems Initiative 13


Questions

© Accellera Systems Initiative 14

You might also like