Subject: RE: ISSUE: cmodules vs. external "C" tasks
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Nov 06 2002 - 23:05:30 PST
Team,
Here are a few items to consider when deciding between
cmodules and external "C" tasks:
1) cmodules impose a C/C++ modeling medium on SV.
Users are obliged to accept the syntax, API, and
threading scheme provided for use inside cmodules.
2) external "C" tasks are simply an interface mechanism.
Inside the C code, any function could be called.
This could include C threading and synchronization
systems provided by the simulator vendor, such as
built-in SystemC.
3) SystemC is a more mature and robust modeling medium.
I don't think we should include SystemC in SV, or even
mention its existence in our proposed C interface.
However, I feel the same way about the modeling
facilities inside DirectC cmodules. Instead, we should
just provide an interface that can be used with any
C modeling medium that tool providers intend to support.
4) If we discard the modeling capabilities of cmodules, we are
left with the port and instance binding capabilities.
It is not that straightforward for users to put together
module-based binding without cmodules.
I can think of two ways users could do that:
a) Instead of a C module, the user would instantiate an
SV module that "stubs in" for the C module. Inside that
module, an external "C" task/function is called. Then
inside the external "C" function, PLI is used to register
callbacks on the module's input/inout ports. PLI is used
to drive values onto the module's output/inout ports.
In both cases, as Andrjez states, PLI context pointers
would have to be set up by the runtime system (actually
he said "compiler", but I think he means runtime system).
b) Another way is to use that "stub" SV module, and set up
an always block with all the modules input and inout ports
in its sensitivity list. Then call an external "C" function
each time one of those inputs changes. Assign function
output reg parameters to the SV modules outputs/inouts.
This way is probably highly inefficient.
Both ways are pretty cumbersome on users when compared
to the current cmodule binding mechanism.
Hopefully we can get some good technical debate going on
this tomorrow and really make up our minds on cmodules
vs. external "C" tasks.
Regards,
Doug
This archive was generated by hypermail 2b28 : Wed Nov 06 2002 - 23:06:20 PST