Acronym · Verification & Validation
DPI (Direct Programming Interface)
The SystemVerilog mechanism for calling C or C++ functions from HDL code and vice versa, more simply than through the older PLI. It is the standard way to attach reference models, random generators and firmware to a testbench.
- Also known as
- DPI-C
- Type
- Acronym
- Domain
- Verification & Validation, Testbench & methodology
Notes
Import and export declarations must match C types exactly; mismatches cause silent corruption rather than compile errors.
Overview
DPI, short for Direct Programming Interface, is the SystemVerilog feature that lets SystemVerilog code call functions written in C, and lets C code call SystemVerilog functions and tasks. It is the usual way to connect a testbench to software such as reference models, algorithm code and utility libraries without writing simulator-specific interface code. DPI belongs to IEEE 1800, the SystemVerilog standard, which provides interfaces to foreign programming languages.
How it works
Calls in each direction are declared in SystemVerilog. An import "DPI" declaration names a C function and gives its SystemVerilog prototype, after which it can be called like any SystemVerilog function. An export "DPI" declaration makes a SystemVerilog function or task callable from C. Functions run in zero simulation time; tasks can consume simulation time, so C code can call an exported task that waits on clocks or drives a bus.
Imported functions can be marked pure, meaning the result depends only on the inputs and the call has no side effects. Functions that call back into SystemVerilog or use the simulator's other programming interfaces must be marked context, which costs some performance.
Arguments are mapped between the languages. Small types such as integers, reals and handles pass by value, others by reference, and open arrays are passed as handles that C reaches through library functions. The standard header svdpi.h is implementation-independent, so compiled C code can work with different simulators. The compiled code is loaded with a simulator switch or a bootstrap file.
DPI lets teams reuse existing C code without learning the older Verilog programming interfaces, PLI and VPI. It covers many, but not all, of the tasks those interfaces handle.
Examples
- A scoreboard calling a C model of a video codec to compute the expected output for each frame.
- Importing the C maths library sine function as a pure function for use in a testbench.
- C test code calling an exported SystemVerilog task that performs bus writes on the simulated design.
- Allocating and freeing memory in a testbench by importing the C malloc and free functions.
Why it matters
Much of the expected behaviour of a chip already exists as C or C++ code, from algorithm models to firmware, and DPI lets verification reuse it instead of rewriting it. Testbench software engineers and verification engineers write DPI layers, verification IP developers use it inside their components, and hardware-software co-verification teams use it to run software against simulated hardware. Mainstream simulators support it; Synopsys, for example, lists DPI among the direct interfaces of its VCS simulator.
Related terms
Part of the Verification & Validation glossary, with every term in the topic and the lifecycles, tools and standards that use them.
Where it appears on the Hub
Used on 4 pages of the Hub. In each group, the pages that mention it most come first.
Suggest an improvement
Suggest an improvement to this entry
A clearer definition, an example, a correction or a source an editor can check. Editors review every suggestion before the entry changes.
Last reviewed . Written by The Semiconductor Hub editorial team. The full glossary