Subject: RE: Pls. review and comment the requirements for a direct foreign language interface
From: Bassam Tabbara (bassam@novas.com)
Date: Mon Aug 12 2002 - 15:49:23 PDT
Indeed Andrzej, I doubt we all agree on everything :-)! The document is a
very good starting point. I thought we would start discussing the reqs in an
upcoming meeting, once all the proposals are in, in order to come up with a
master list. Let me try here to give a few comments on your list.
High level:
----------
1) I am more concerned about the -unstated- assumptions/limitations
(i.e. -scope-/-usage- of DFLI (direct foreign language interface :-)!)) in
the doc, than the clearly stated ones.
2) Closely related to #1, some of the reqs themselves do not mesh a 100% ...
and may be slightly contradictory even.
Practical:
---------
Here's a practical projection (into a set of questions/issues/comments) of
the 2 concerns above:
a) Is DFLI intended to be a complement to a "PLI" where PLI is the main
access/manipulation mechanism into internal simulation data structures
etc... If so (i.e. orthogonal to PLI) then the following trouble me:
- to get values of some common basic types (e.g. integer values) from the
foreign code
- synchronize the Verilog part of the design with non-Verilog concurrent
components
only via value changes
If not (see later), why is this so ? Is this really needed (see (d) below).
b) Is DFLI intended to be "side-effect" (using the term loosely...) free ?
If so, again the 2 reqs above (and the passing mechanism) trouble me.
c) you mention an excellent req of compiler optimization, yet:
i) you allow access to Verilog data ("get") from within the so-called black
boxes... how predictable can that be ? It's bad enough we have "black box"
boundaries, would be worse if black box is touching other parts (this would
be exacerbated if synchronization is allowed inside ...).
- .... "blackbox" ....
- 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
d) Again to harp on the same point, once we open the door to "get", people
will ask for "set", and you have a VCL soon people would want "end/begin of
timestep"... so we are back in PLI world. We already have those. I thought
we were serving a different set of apps with DFLI.... see counterproposal
below for how to do synchronization ...
**My counter proposal would be:
- let's adopt the "black box" as you suggest
- DFLI calls are "side-effect free" (Uhm that is let's not build problems
into it, user can always shoot themselves in the foot with an endless for
loop or something).
- let's clearly/cleanly define the -pass- and the -return-. This would be
only way to sample values (func gets a copy ...). More overhead... but we
need to "automatically" map the types back and forth so might as well build
it "safe".
- Verilog side is "master" i.e. if you want a VC trigger, or timestep sync
or whatever do:
@always(...)
func(...)
- Verilog is the medium where funcs communicate (as Andrzej suggests,
through the presence of "foreign objects" (not interpreted in Verilog).
** BTW, I think may be the concept of "shell"s with different access
"level"s is the answer to most of the issues I raise. BUT if we want to go
the route of providing different levels of services/access, the reqs should
be recategorized based on the level of access. We would then have a clearer
idea on the set of services and cost (compiler optimization, overhead
etc...). Did I answer my own questions ? If so, would you kindly mind
reorganizing, if you think it's a good way to tackle these issues ? I
suspect we would not all agree on the need for the "full access"/"full
interactivity/flexibility with simulator" since that is already VPI's
function ...
Ciao!
-Bassam.
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.http://www.novas.com (408) 467-7893
> -----Original Message----- > From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org]On > Behalf Of Andrzej Litwiniuk > Sent: Friday, August 09, 2002 2:11 PM > To: sv-cc@server.eda.org > Subject: Pls. review and comment the requirements for a direct foreign > language interface > > > 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 > > ================================================================== > ============ > 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 : Mon Aug 12 2002 - 15:51:03 PDT