Overview

The DPI Interface is described in the provided evidence as an interface layer used in SystemVerilog-based verification flows to reach system-level functionality and C/C++ components. In the cited DVCon paper, a SystemVerilog testbench is characterized as being able to interface to the system level only through the DPI layer, and SystemVerilog/UVM environments are described as needing DPI when interfacing with C/C++ for emulation-platform interaction. [DPI role in SystemVerilog verification]

Use in verification architectures

The evidence shows DPI being used as a bridge between verification testbenches and native-code infrastructure. One cited example is a multicore predictor architecture that uses a C++ thread pool via the Direct Programming Interface. [DPI used with C++ thread pool]

DPI also appears as one of several simulator-integration mechanisms. The eUVM implementation is described as integrating with any RTL simulator via PLI, VHPI, FLI, or DPI, while also interfacing natively with Verilator. [DPI as RTL simulator integration option]

Performance considerations

The evidence repeatedly frames DPI as useful but potentially costly. The DVCon paper states that SystemVerilog lacks native data types and therefore requires C/C++ interfacing through DPI for emulation-platform connections; it further notes that runtime overhead from data exchange through DPI can adversely affect testbench performance. [DPI data exchange overhead]

A related comparison is made with eUVM, which is implemented in the D programming language and described as having ABI-level compatibility with C/C++. In that comparison, C/C++ functions can be called directly from eUVM testbenches and vice versa without runtime overhead, whereas a SystemVerilog testbench must use the DPI layer for system-level interfacing and may incur a significant performance penalty. [DPI contrasted with ABI-level native calls]

Position among adjacent interfaces

Within the cited material, DPI is positioned alongside other simulator and foreign-language integration mechanisms, including PLI, VHPI, and FLI. It is specifically named as one of the mechanisms by which eUVM can integrate with RTL simulators. [DPI as one of several simulator interfaces]