Subject: Re: Pls. review and comment the requirements for a direct foreign language interface
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Sun Aug 11 2002 - 17:44:46 PDT
Hello,
as requested here are the comments.
Overview:
. I am unsure about the intended use; at least I see some discrepancies between the motivation and the stated requirements
. It looks like it is desired to build an extremely simple interface for calling of C functions, but not to
include components build by C/C++ functions into a SystemVerilog simulation
. There is nothing wrong with the simplistic approach, but we either clearly identify the intended scope
and its limitations or we adjust the requirements appropriately
Areas that are not covered by the identified requires are especially:
- support of sub-systems with local interconnects on the FL side; this results in
- need to synchronize with the sub-system (not covered at all)
- need for a solution when parts of a net are in Verilog and the rest is in FL (who does the resolution when and how,
- support for converting pin-wiggling based I/O to transaction-level I/O and vice-versa
[ it is of course possible to a lot of this conversions on the SV side, the problem are the cases, where transactions are not only encoding multiple nets, but also events over the time ]
- identification of sensitive ports to the FL side to minimize calling overhead
[ FL module is executed when at least one of the (sensitive) ports at its boundary changes its
value - this is important for performance reasons ]
- the specified requirements do not permit to post events or request for events from the FL side; this reduces the functionality available on the FL side
- information about simulation specific events (e.g. start-up, terminate, initial reset,
save/restore); the component on the FL side might also have internal data that must be resetted, saved, restored, cleaned up ...
Taken the provided requirements, the absence of the above features would still require to use PLI/VPI functionalilty for the stated motivation. We did this, it's a pain; it would be great if this is an inherent feature of a language like SystemVerilog.
IMHO support of C/C++ modules in SV result in the requirements I have tried to identify for the use cases UC3, UC4, UC5, and UC6.
I understand that this might be too much for SV 3.1; I just say we clearly need to state what we want to approach and what are the known limitations.
More comments on the requirements list are interspersed below.
Best regards,
Michael Rohleder
Andrzej Litwiniuk wrote:
> Dear fellow sub-committee members,
>
> There seems to be no response to "Requirements for a direct foreign language
> interface" proposed on July 30. The lack of any criticism shouldn't be
> mistaken for an unconditional endorsment for these requirements, I guess.
> On the other hand we may have no choice but to interprete this as
> the acceptance if nobody sends their comments or an alternative proposal.
>
> Therefore I ask you to review kindly the "Requirements" and send your
> comments. You may just point out what is missing or what you disagree with.
> Alternative proposals are of course welcome.
>
> Regards,
> Andrzej I. Litwiniuk
> Motivation
> ----------
> (1) Methodology:
> - heterogenous systems built up from Verilog and non-Verilog components
Referring to my use cases identified in an earlier email, is this UC3 or UC4. This statement looks more like UC4, but the requirements look more like UC3?
> (2) Practical needs:
> - need for an easy and efficient way to connect a C code without the knowledge and the overhead of PLI
100% agreed
> 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.
Be more specific about the components. Are these single FL modules or can this be a subsystem (meaning there are interconnects between these modules also on the FL side)?
> 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.
This sounds more like UC3 ...
> - 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.
I am not sure whether I really understand this ... Probably this is only a terminology problem: Do you mean that the 'definition' and the 'instantiation' of a component should be clearly separated? I'm sorry,
I am not a native english speaker.
> 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.
Yes
> 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
Agreed to all
> - 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.
I am not so sure why the different shells are sooo important, without having said what different
kinds of security, convenience and performance should be selectable. For me this looks like a
implementation detail instead of a requirement; aren't the requirements that:
- the integration of FL functionality must support multiple facets with the same API
[meaning there is _not_ a different set of functions for each facet]
- the facets are (this is only the list that comes into my mind)
. maximum performance (perform no validation of parameters, no debug support)
. enhanced security (validate correctness of parameters, check for errors in FL code when possible)
. provision of debug support (enable debug statement requried for debug of FL code and the I/F)
- the facets should be selectable by the SV compiler/simulator by (whatever you like: env vars, #pragmas, 'defines)
- is it intended to select different FL component definitions/implementation within different shells?
Also your statement says that the Verilog code (SV code) should stay the same. What about the FL code?
> 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
this are 3 requirements:
. the interface enables to execute a FL function/procedure from SV code
. no simulation time passed during the call [be more specific here - what about delta cycles]
. implementation should support at least calls to C functions [be more specific here - what means at least? C vs. C++ or what else]
> - 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
This is not enough. The API must permit to pass values of all kind of SV types; we might want to distinguish between scalar types and more complex types (arrays etc).
Do we want to support the modification of SV types within the FL code? Your statement does not look like this is the case ...
> - 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
same as above
> - 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.
agreed. I assume this also means to pass the handle between different components on the FL side?
> - 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.
Agreed. Beware.
> 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
Agreed to all.
> - 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)
Agreed; with the exception of the limitation to basic types used, as already stated above
> 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
this sounds again like there is more than one requirement:
. platform independence of the interface
. interface must use the C function call semantics
I am unsure what the statement "(Verilog compiled to C)" means?
> Effectivness/performance:
> -------------------------
>
> - there should be no intrinsic overhead at least for the simple scenarios
remove the part after "at least" or define what simple scenarios are
> - 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
Agreed to all.
-- Quote of the day: "Better to remain silent and be thought a fool than to speak out and remove all doubt." [Abraham Lincoln (1809-1865)]NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( ) when marked, please note: This e-mail and any attachments are confidential and Motorola reserves all rights of privilege in respect thereof. It is intended for the use by the addressee only. Please delete it from your system, if you are not the intended recipient. Any use, disclosure, or copying of the included information is unauthorised. ___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, ASA Methodology | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
This archive was generated by hypermail 2b28 : Mon Aug 12 2002 - 01:35:30 PDT