Scribd
Upload
16 views14 pages

Reusable DPI Flow Across Verification Validation SW

Uploaded by

doomachaley
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
16 views14 pages

Reusable DPI Flow Across Verification Validation SW

Uploaded by

doomachaley
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
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