1 Introduction

Traditionally, algorithms and systems are modeled using software languages. After developing refinements, defining the data flow and adjusting data types, specific parts of high-performance systems are typically accelerated by designing custom hardware IP (using hardware description languages). In the transition from a software algorithm to the hardware description of a circuit, expertises of hardware designers and software developers overlap. In such contexts, co-simulation, being able to co-execute HDL designs with foreign languages, is a very valuable feature. On the one hand, it allows software developers and verification engineers to test a given HDL black box, while using the languages and/or frameworks they are familiar with. On the other hand, it allows hardware designers to reuse in HDL the vast libraries available from software ecosystems (e.g. scipy.org). Moreover, most modern designs are complex SoCs where ad-hoc IP are placed along with general purpose (embedded) CPUs. Hence, testing co-execution of hardware and software is a must.

During the last two decades, multiple different and not exactly compatible interfaces/APIs have been proposed for co-simulation of HDL languages and foreign languages (mainly C/C++):

  • VHDL Programming Interface (VHPI)
  • Foreign Language Interface (FLI)
  • Xilinx Simulator Interface (XSI)
  • Verilog Procedural Interface (VPI)
  • SystemVerilog Direct Programming Interface (DPI)

The underlying workflow in most of them is based on accessing the (V)HDL hierarchy of a given design at runtime, from a foreign language. Typically, callbacks are defined in C/C++ (as specified by the API). Some of the interfaces allow declaring additional models in C/C++/SystemC and having them registered for analysis/elaboration. Yet, the procedure is typically described from a software perspective, minimizing the usage of HDL language features, and keeping HDL sources unmodified. As far as the authors are aware, almost none of them is expected to support workflows where most of the co-simulation plumbing is handled in (V)HDL instead. By the same token, executing specific VHDL functions/procedures from the foreign language is typically not supported.

A subset of VHPI which is named VHPIDIRECT (thus, part of VHDL 2008) allows to define an attribute (FOREIGN) of subprograms in VHDL for importing functions written in foreign languages, and linking them during elaboration. It is a significant difference compared to mainstrain workflows that this approach requires writing both VHDL and C/C++ (or other foreign language, such as Python). However, at the same time, metadata/context that needs to be defined when using an external language, is implicit in VHDL. Hence, VHPIDIRECT should feel more familiar to hardware developers, but it might be less intuitive to software developers. VHPIDIRECT is kind of similar to SystemVerilog’s DPI, since the main language is an HDL in both cases, and the main purpose is to interface C/C++. However, SystemVerilog is per se a language flavoured for software.

There is an existing proposal in the VASG since 2011, which has been maintained by Peter Flake, regarding extensions to the current FOREIGN attribute: [P1076/DpiProposal] Direct Programming Interface. The list of individuals that have commented in that proposal is the following (in chronological order): John Shields, Tristan Gingold, David Koontz, Ryan Hinton and Peter Ladow. Furthermore, the following individuals did sign as supporters: David Smith, Brent Hayhoe and Radoslay Nawrot.

The purpose of this document is to find common requirements and to conciliate the differences between VHPI, the existing DPI proposal and GHDL’s VHPIDIRECT implementation. Opposed to existing VPI or VHPI, the purpose is to standardize an interface that feels natural to hardware designers (thus VHDL-centric), by allowing users/developers to reuse existing calling conventions in foreign languages, instead of requiring glue logic.