Direct Programming Interface for SystemVerilog and C

SystemVerilog DPI defines a practical foreign-function interface between SystemVerilog and C. It enables C routines to be imported as SystemVerilog tasks or functions, and enables selected SystemVerilog subroutines to be exported into the C global namespace. The result is a direct bidirectional call mechanism that feels like ordinary subroutine usage while allowing external C computation and SystemVerilog behavior to work together inside simulation. DPI is built around strict interface declarations. Imported routines require matching names, return types, argument types, and argument directions between the SystemVerilog declaration and the C implementation. Exported routines require the same kind of agreement between the SystemVerilog task or function and the C extern declaration. Since the C and SystemVerilog compilers do not fully communicate across the language boundary, correctness depends on accurate prototypes, compatible data types, and disciplined linkage naming. Data type handling is a major part of DPI integration. Simple SystemVerilog types map directly to corresponding C types, while scalar bit and logic values use DPI-defined representations from svdpi.h. Enumerations are visible through their base type, without enumeration value names. Packed arrays and packed structures require vector-based or implementation-dependent handling, while unpacked arrays, structures, and unions of simple types can map more naturally to C aggregates. These rules shape which interfaces are portable and which require tool-specific care. Context and pure imports control how imported routines interact with simulation state and optimization. A context import carries scope information and is required when C code calls exported SystemVerilog routines or accesses SystemVerilog objects beyond actual arguments. A pure import promises deterministic, input-only behavior with no side effects, allowing the simulator to reuse or remove calls. Incorrect use of either property can cause invalid callbacks, unsafe access, or unexpected optimized behavior. Compilation and linking connect the declared interface to actual C object code. C source is compiled separately and linked into a shared object library, while SystemVerilog code is compiled and simulated in the normal flow. Options such as -sv_lib, -sv_liblist, and -sv_root provide simulator access to the shared library. DPI remains lighter than PLI because it does not require a new simulator executable, but it also does not provide PLI-style access to simulator data structures or arbitrary simulation-event synchronization. Disable handling adds an advanced reliability rule for imported routines that call exported routines. When a SystemVerilog disable affects the original imported call, the C layer must detect the disabled state after returning from the exported call, stop further callbacks, and acknowledge the disable. Imported tasks and imported functions acknowledge the condition differently, so correct handshake coding is required to preserve SystemVerilog disable semantics across the DPI boundary. Catalogue: Verilog PLI: Powerful but Complex SystemVerilog DPI: Lightweight Foreign Interface DPI Layer Independence and Data Mapping SystemVerilog to C Data Type Mapping (I) SystemVerilog to C Data Type Mapping (II) Importing DPI Tasks and Functions DPI Type Compatibility Warning DPI Import Linkage Names DPI Import Rules and Types Context Tasks and Functions Pure Functions and Simulation Optimization Exporting DPI Tasks and Functions DPI Export Linkage Names DPI Export Rules and Timing Imported and Exported Functions Example DPI Compilation and Linking DPI Benefits and Limits DPI Disable Handshake Disable Handshake for Functions Disable Handshake for Tasks