Subject: Technical Discussion of DirectC
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Mon Oct 07 2002 - 15:47:10 PDT
SVCC Team,
I would like to get the ball rolling with more
technical detail regarding DirectC's DFLI
(Direct Foreign Language Interface) capabilities.
Here are some observations on DirectC, along with
some suggestions for using/modifying/abandoning
particular features of the donation.
*** DFLI features vs. modeling features ***
DirectC is both a binding mechanism (DFLI) and a
modeling medium. The special language constructs
such as the event control statement are what I call
the modeling medium. Some of the API calls fit into
there as well. The "extern" syntax and "cmodule"
syntax are the binding mechanisms. (DFLI)
I would like to concentrate on the binding mechanisms.
The modeling medium has capabilities that are redundant
with SystemC and TestBuilder (and perhaps a few
home-brewed C environments). I suggest it is out
of the scope of SV to create C modeling semantics.
If we were to create C modeling semantics, why not
just use SystemC? It has support for hierarchy,
multiple-driver resolution, channels, and a host of
other interesting features. Or another C modeling
facility out there? It doesn't seem like we should
be making this kind of decision in the context of
our charter.
If this logic sounds good to everyone, then that would
suggest we drop the special DirectC "modeling medium"
features and exclusively focus on the DFLI features.
*** C-calls-HDL task/function feature ***
DirectC lacks a C-calls-HDL task/function feature.
We should add that feature with similar syntax.
i.e. the function call looks like C, but in fact
is implemented in SV. The linker/elaborator would
bind the runtime image based on function name,
just like a C linker. The CBlend binding mechanism
allowed for that. Would there be any problem from
the Synopsys/Co-Design point of view if that aspect
of CBlend was resurrected in the SV standard?
*** Abstract vs. Direct function parameter handling ***
There is some controversy on DirectC's parameter type
handling. There is both an Abstract and a Direct mode.
This is confusing to some and redundant to others.
In our experience with foreign VHDL subprograms, it is
sufficient to use a "direct mode" for simple pass-by-value
semantics. Type-binding has to be clearly documented for the
users. Once they set up their simulation, they don't tend to
churn the inter-language linkage very often. It stays stable
and they are productive.
In order to support more complex types across the DFLI
boundary, it is impractical to use a "direct mode".
To support array and struct types, an API is arguably
needed to help the user decompose the kernel's value
footprint. Similarly, enum type encodings need to be
accessible by the user-level code.
I think it's OK to have both "direct" and "abstract" modes
of DFLI programming, but not redundantly. i.e. simple scalar
types should always be handled directly and more complex types
should always be handled with an API. I suggest this is in
the best interest of the user, since it yields a good cross
between performance, productivity, and security.
Here is a question: What kind of performance gain has
the DirectC team seen when switching from Abstract to
Direct mode? It should be easy to cook a testcase that
stresses cross-language communication, and then benchmark
it with both implementations.
*** Analogy between DFLI and current mixed language tools ***
It's interesting to make an analogy of the C<->SV binding
interface with the Verilog<->VHDL binding interface of
the popular mixed language simulators. The user analyzes
the child module or function named, say, "A". Then
instantiates the child module or function in the other
language, also naming it "A". We can call this bind-by-name.
The parameter-passing mode is "direct". There are
implementation-specific limitations in all cases.
I don't think any implementation can pass parameters of
complex VHDL aggregate types into a Verilog region.
There is ample opportunity for users to get things wrong
in "direct" mode. But, users seem to like the interface
very much! Perhaps they don't need to pass complex types
across the language boundary very often. And as stated
before, once they read through the documents and understand
the type-matching scheme, they work through it, get it
right, then tend not to mess with it too much as they
do their verification work.
*** Driving output signals, sensitivity to input signals ***
One of the interesting points of DirectC is that it greatly
simplifies the user's "module signal i/o" task when compared
to PLI and other existing C language interfaces.
There is no need to use API calls to set up sensitivity to
a module's input signals. And there is no need to use API
calls to effect value changes on output signals. It's really
nice from the user's point of view. The user's code simply
writes and reads the C variables found in the cmodule's port
list, and the simulator automatically takes care of the
data transfer between the C and HDL domains.
However, there are some problems with this approach:
- What happens with complex types that would require API support
for type decomposition?
- There is a burden on implementors to parse the user's C code
and generate annotated C code that is then passed to the C or
C++ compiler. Function/module parameter sources and sinks
must be understood. The generated code must include all
kinds of kernel-related functionality, similar to the code
generated by a native HDL compiler.
- There is also a burden on the user in that they need to
run at least portions of their C code through the tool's
compiler.
I think this burden is probably acceptable, especially if it
can do away with the need for users to work with SV object
handles (such as signal id's to be driven, etc.), and they
can simply read or write their C port/parameter variables
as if they were writing pure C.
*** Threading concerns ***
We should discuss threading issues when working on DFLI.
As a starting point, we at MTI/Mentor would propose that the
syntax and tool infrastructure should not be required to
understand what threading system a user is using.
This would allow a variety of applications to be built
using the DFLI. For example, SystemC integrations
or TestBuilder integrations with their own threading,
or simple user-level models that exist only within
the process of the calling SV process (i.e. thread).
***
I hope at least some of you could stand this long email.
It would be great to get some dialogue going on a technical
level to start exposing and hashing through the different
issues we will face. Look forward to hearing your responses.
Thanks and regards,
Doug Warmke
Model Technology, Inc.
This archive was generated by hypermail 2b28 : Mon Oct 07 2002 - 15:50:51 PDT