Subject: Requirements for a direct foreign language interface
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Jul 30 2002 - 14:44:25 PDT
Committee members:
Please find enclosed the Synopsys requirements for the direct
interface between Verilog and a foreign language.
Regards,
Andrzej I. Litwiniuk
====================================================
Motivation
----------
(1) Methodology:
- heterogenous systems built up from Verilog and non-Verilog components
(2) Practical needs:
- need for an easy and efficient way to connect a C code without the knowledge
and the overhead of PLI
The requirements are manifold and come from the different angles.
--------------------
General requirements
--------------------
Very high level abstract design considerations:
----------------------------------------------
- the interface should allow to build a heterogenous system (a design or
a testbench) in which some components may be written in a language (or
more languages) different than Verilog, hereinafter called the foreign language.
In the simplest typical scenario there is a Verilog design and/or a testbech and
the non-Verilog environment (file system, etc.), usually in C.
- A principle of a black box should be followed, i.e. the specification and the
implementation of a component should be clearly separated and the actual
implementation should be transparent to the rest of the system. Therefore also
the actual programming language should be transparent.
This seems to suggest that in Verilog parts the separation between Verilog code
and the foreign language should follow the natural encapsulation units in Verilog:
functions, tasks, modules and interfaces. It seems to be desirable that any
function/module/interface might be treated as a black box and implemented either
in Verilog or in the foreign language in a transparent way.
Practical considerations:
-------------------------
- changes to the Verilog language should be as small as possible
- the actual foreign language should be transparent and irrelevant to the Verilog user
- the interface should not require any changes to the foreign language nor its compiler
- both sides of the interface should be fully isolated, i.e. neither of the two
compilers (Verilog compiler and the foreign language compiler) should be required
to analyze the source code in the other language
- it is desirable that the Verilog language side/facet of the interface would be based
upon the Verilog constructs in order to facilitate an ease of use and to minimize
the learning curve
- the foreign language side/facet of the interface should be transparent and irrelevant
to the Verilog user. It is desirable that there would be several shells of the foreign
side of the interface, with different balance of security, convenience and performance.
The Verilog compiler/simulator should generate/use the representation/protocol required
for the intended shell. It should be possible to use the same Verilog code with
different shells regardless of the data access method assumed in a given shell.
Functionality:
-------------
The interface should allow (in the order from the most rudimentary to more
sophisticated requirements):
- to execute a foreign procedure from Verilog code (master-slave model with
Verilog side being the master and no simulation time passing during the call);
the implementation should support at least calls to C functions
- to pass values of some common basic types (e.g. integer values) from Verilog
to the foreign code
- to pass string literals (i.e. text in quotes) to the foreign code
- to get values of some common basic types (e.g. integer values) from the foreign code
- to pass values of Verilog data types between the Verilog code and the foreign code,
in either direction
- to pass foreign data from the foreign code via Verilog code back to the foreign code;
an ability to pass a handle (pointer, reference) to a foreign data type between the
foreign code and the Verilog code and store it temporary on the Verilog side seems
sufficient;
such a handle may be meaningless on the Verilog side and should not be interpreted there.
- synchronize the Verilog part of the design with non-Verilog concurrent components
only via value changes
We don't require the ability to call a Verilog function or task from the foreign code.
The rationale is as follows.
Verilog functions/tasks are usually defined within some context (module or interface scope)
and may access non-local data (functions/tasks declared in $root are an exception).
Hence a caller should provide the context of a call (e.g. a module or interface instance).
In a non-Verilog part such context is simply not visible/available.
The interface specification should not attempt to enhance the other
programming language with new constructs for supporting Verilog.
Usage:
-----
- the learning curve should be minimal
- simple things should be simple and intuitive
- preferably there should be no changes in the syntax of behavioral Verilog code
- the implementation should provide an automatic and transparent convertion between
the basic type used in the interface and the relevant Verilog types (reg/wire,
scalars and vectors)
Portability:
-----------
- the interface should be available also on the platforms on which the native
code is not supported and where C code is the only way to go (Verilog compiled to C);
hence the interface must be built upon the C function calling protocol
Effectivness/performance:
-------------------------
- there should be no intrinsic overhead at least for the simple scenarios
- the usage of the interface should not prohibit compiler optimizations by introducing
unpredictability in accessing and/or modifying Verilog data
- the ability of access of the foreign code to the Verilog data should be easily
visible to the compiler in order to minimize performance penalty
==============================================================================
Andrzej I. Litwiniuk, PhD Principal Engineer VCS R&D
Synopsys, Inc TEL: (508) 263-8056
154 Crane Meadow Road, Suite 300, FAX: (508) 263-8069
Marlboro, MA 01752, USA
==============================================================================
This archive was generated by hypermail 2b28 : Tue Jul 30 2002 - 15:19:28 PDT