Application Binary Interface (ABI)

An Application Binary Interface (ABI) is the binary-level compatibility boundary that allows compiled software components to interoperate. In the provided verification-system context, ABI compatibility is discussed as the mechanism that lets code written in one language call compiled functions from another language directly, without requiring an additional runtime bridge layer.

Role in language interoperability

The evidence contrasts two approaches to interoperability in hardware-verification testbenches:

• A SystemVerilog UVM testbench interfaces with system-level software through the DPI layer, which may introduce a significant performance penalty.^[1]
• eUVM, implemented in the D programming language, provides ABI-level compatibility with C/C++, allowing C/C++ functions to be called directly from eUVM testbenches and allowing eUVM code to be called from C/C++ without runtime overhead.^[1]

This makes ABI compatibility important when verification environments need tight integration with existing C or C++ software models, firmware, drivers, or system-level components.

ABI in eUVM

In eUVM, ABI compatibility is a central part of its systems-centric testbench architecture. Unlike the traditional SystemVerilog UVM stack, which is tightly coupled to RTL simulation, eUVM is described as taking a top-down, system-centric approach.^[1] Because it is implemented in D, it can interoperate directly with C/C++ at the ABI level.^[1]

This has two major implications:

1. Direct function calls
   C/C++ functions can be invoked directly from eUVM testbenches, and eUVM functions can be invoked from C/C++.^[1]

2. No runtime bridge overhead
   The evidence states that this direct ABI-level interoperability occurs “without any runtime overhead,” in contrast to DPI-based interfacing, which may impose a performance penalty.^[1]

Relationship to data interoperability

The evidence also notes that eUVM uses D language metaprogramming features such as User-Defined Attributes, Compile-Time Function Evaluation, code introspection, and generative programming for its constraint-processing implementation.^[1] User-Defined Attributes allow eUVM to maintain a native memory footprint for randomized data elements, which improves interoperability with C and C++.^[1]

In ABI terms, this is significant because binary interoperability is not only about calling functions; it also depends on whether data can be represented and exchanged in a form that native compiled code can use efficiently.

Portability considerations

The evidence describes eUVM as portable across multiple operating systems and machine architectures, including Windows, Android, macOS, and most Linux versions.^[1] It also states that eUVM testbenches can be cross-compiled for embedded platforms running Linux or Android, including SoCFPGA boards.^[1]

This indicates that ABI-aware interoperability is useful not only on desktop simulation platforms but also in embedded and co-emulation environments where compiled C/C++ components are common.

Use in verification flows

eUVM can integrate with RTL simulators through PLI, VHPI, FLI, or DPI interfaces, and it interfaces natively with Verilator.^[1] However, for system-level C/C++ interaction, its ABI-level compatibility provides a lower-overhead path than relying solely on simulator interface layers.^[1]

Summary

In the cited eUVM context, an ABI is significant because it enables direct binary-level interoperability between D-based eUVM testbenches and C/C++ code. This allows bidirectional function calls without runtime overhead and supports efficient data interoperability, making ABI compatibility especially valuable for systems-centric verification environments.

References

^[1]: Evidence a16763d2-b8de-49ce-b68e-a8597fad2f98.