5 Requirements

  • Attribute FOREIGN should allow to define more than one foreign “language” or “implementation”. For example, it should be possible to use the same VHDL source to co-simulate with either GHDL’s VHPIDIRECT or Mentor Graphics’ FLI. Currently, the format of the attribute string is not standarized, and the implementation of those tools is incompatible. Apart from that, VHDL sources are fully compatible.
  • Currently, providing a (dummy) body for foreign functions is required, which cannot be used, because the function is precisely declared as foreign. It would be nice for the body not to be required. Alternatively, the body might be used as a fallback in case a foreign implementation is not found. Currently, it is required but unused, even as a fallback.
  • Currently, if a procedure/function is decorated with the foreign attribute, apart from a matching body in VHDL, the foreign subprogram must be defined (linked) for elaboration to succeed. This is required even when it is not used in the design. In contexts where conditional inclusion of VHPIDIRECT features is required, it is suggested to provide alternative (dummy) sources for either VHDL packages or C sources. Can this be solved/simplified through conditional compilation (VHDL 2019)?
  • Attribute FOREIGN should allow to bind a either foreign function name or a pointer/reference. This is useful for defining foreign functions at runtime through interpreted languages such as Python. Currently, function pointers need to be dereferenced for VHPIDIRECT to call them.
  • It is currently possible to define foreign procedures or functions. However, the format of the complex data types that can be passed as arguments, is not defined. Assuming that most simulators are written in a language “similar enough to C”, passing simple data types is straightforward. E.g., integers are int32_t or int64_t and reals are doubles. Nevertheless, complex data types -such as (multidimensional) (un)constrained arrays, nested records, etc.- can be implemented very differently. More precisely, since data types in VHDL are strongly typed, many of them cannot be passed as a single reference; instead, fat pointers need to be used. The format of such fat pointers should be standardized.
    • By the same token, VHDL procedures/functions can have arguments of mode in, out or inout, whereas in C functions are allowed to return a single argument. Hence, this is currently implementation-dependent.
  • It is possible to import a C subprogram in VHDL. However, it is currently undefined how to call a VHDL function/procedure from C. For C to find it, apart from making the symbol visible, it needs to have a known name. Such name is currently not standarized.
    • The same issues about non-standarized argument type conversion applies.
  • Memory management needs to be defined. When pointers are passed between VHDL and the foreign language, users might attempt to allocate some variable/array in one language and deallocate/free the memory in the other language. That might or might not be possible and/or supported. Currently, it is undefined.
  • Is it possible to support varargs so that calling printf from VHDL is a “built-in” feature in the language?