Subject: RE: More on ISSUE 1.7
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Fri Nov 22 2002 - 09:05:09 PST
Michael,
Thanks for the clarifications.
Here is another way to think about things, which is one of the main reasons
I support solution c).
In all current mixed language products (i.e. Verilog instantiates VHDL
entity
and VHDL instantiates Verilog module), there is no API needed by the
user to fetch and pass data values that cross the language boundary.
The system naturally converts one type system to the other,
following certain well-defined and documented rules.
Users really like this approach. They take a little while to set it up,
and once it's running it stays stable for a long time, since users don't
often mess around with cross-language setups once they are
into the heat of their verification. Also, the direct mode is easier
to read in user code due to lack of clutter.
I don't see too much value in having debug API functions that fetch and
send data. The functions could catch illegal attempts at type conversions
at runtime. However, even without such debug functions, users will quickly
be able to get the cross language data passing mechanism working
by reading the docs and doing simple experiments.
I would prefer to see our "mixed language" effort here more closely
follow the mixed language type conversions I described above,
rather than what is done in PLI. I find that rather cumbersome to
program and too hard to read once it's finished.
Thanks and regards,
Doug
-----Original Message-----
From: Michael Rohleder [mailto:michael.rohleder@motorola.com]
Sent: Friday, November 22, 2002 4:45 AM
To: Warmke, Doug
Cc: sv-cc@eda.org
Subject: Re: More on ISSUE 1.7
Hi all,
I think I need to clarify my proposal. Andrzej has made a nice example how a
simple version of this would look in his email 'ISSUE 1.7:DirectC:Abstract
Access Method requires rewrite of code' (also quoted at the end of this
email). This is a rather simple version of it, but I think it shows that
always using access methods do not neccessarily result in overhead (when
this is defined away).
As such, I think all our proposals are pretty similar (this is my
viewpoint):
a) Andrzej says: you have two modes, the abstract modes permits additional
checking, when you just want to write one code do the #define on your own.
b) Michael says: I don't want to write two times code; one possibility to do
so is something like Andrzej says. Make this distinction in your header
files and don't bother user's with it. By the way, this will make all
parameter accesses look similar; there is always a function (sometimes not a
real one -- see Andrzejs example) for retrieving a parameter.
AS SUCH I DON'T SAY AT ALL THAT YOU HAVE TO USE THE ABSTRACT MODE ALL THE
TIME. IT WILL JUST LOOK FOR THE USER THAT WAY ...
c) Doug says: use direct mode for simple paramters and abstract mode for
parameters having a higher complexity (e.g. arrays)
As such a) and b) are pretty similar; the only difference is who has to
provide the #define ...
a)|b) and c) are different, since there is no abstract mode for simple
parameters in c)
I think we should not underestimate the benefit of good check and debug
capabilities. I think there was a good reason for introducing the abstract
mode into Direct C. B.t.w. ModelSim has something similar than b) for its
PLI calls, which I found pretty useful ...
-Michael
"Warmke, Doug" wrote:
Swapnajit, Andrzej, team,
Last week Swapnajit asked me and some others to put
together a proposal that would address this issue.
I've been thinking about it and this mail summarizes
what I propose as the first step in the process.
There are actually a few approaches available to us.
Before digging in and fleshing out details, I think
the group needs to vote on the general philosophy
to be followed. Once that is done, we can spend
time on detailed specification. If we don't agree
on this early, we will waste time on email and
in meetings.
Here are the possible approaches I can see:
1) Use system currently in place in DirectC.
i.e. both abstract and direct are redundant
with each other. Both are available to user,
the user decides which to use.
(Andrzej recommends).
2) Use abstract mode all the time.
All access is done through API functions.
Different #define or -D could be used to
specify an optimization level. The API
"function tray" would be switched around
depending on what user wants (e.g. detailed
debug messages, normal mode with checking,
or fully optimized mode where many API
functions are actually just macros).
(Michael recommends).
3) Use combination of direct and abstract modes,
but with no redundancy. In this approach,
almost all access is done in Direct mode.
There are some items which must be done using
abstract programming interface calls:
1) Determining # of array dimensions
2) Determining bounds of each dimension
3) Equating enum ordinals to ASCII strings (optional)
4) Maybe more that I can't think of right now
(Doug recommends, maybe Francoise if I understood right?)
Swapnajit,
I recommend that we take a vote on which approach to use,
and then we stick with that approach and define the C side
of the interface using the agreed upon approach.
Otherwise there will be too much controversy and
progress will be slower than it could be.
Please advise if you agree, and if not, what would be
your recommendation for making further progress?
Thanks and regards,
Doug
> -----Original Message-----
> From: Andrzej Litwiniuk [ mailto:Andrzej.Litwiniuk@synopsys.com
<mailto:Andrzej.Litwiniuk@synopsys.com> ]
> Sent: Thursday, November 21, 2002 2:24 PM
> To: sv-cc@server.eda.org
> Subject: ISSUE 1.7:DirectC:Abstract Access Method requires rewrite of
> code
>
>
> Team,
>
> I believe that the abstract access mode is useful for debugging
> and should be used in the first cut of any SV + C system.
>
> IMO the following methodology could be advised for writing,
> testing and
> debugging heterogenous systems built up from SV and C components:
>
> - initially only abstract access mode is used (except
> standard library functions).
> This will allow to catch all interface related bugs, such
> as discrepancies
> between the types of formal and actual arguments, wrong
> port directions,
> wrong declarations on the C side, etc.
>
> - once the correctness of the interface is verified, the access mode
> may be switched to direct access, to improve simulation
> performance.
>
>
> Michael Rohleder had valid and understandable concerns (ISSUE 1.7):
> "From a user perspective it is NOT acceptable that I have to
> rewrite a DirectC
> function after I have debugged it. This is a manual, error
> prone process I will
> want to avoid under any circumstance. It is also a problem,
> since after changing
> the already debugged version, I might just introduce some
> more problems. There
> must be some way to automate this work, something I would
> regard as a critical
> and important feature."
>
> Well, I believe that this problem can be easy avoided with a
> little programming
> discipline. Really, there is no need to modify source C code
> when switching
> between abstract and direct access mode. The access mode matters only
> in getting the values of inputs/inouts and putting values to
> outputs/inouts.
> And such tiny fragments of code may be easily isolated.
> Access mode is irrelevant
> for the algorithm's proper!
>
> Let me illustrate this with - perhaps a bit simplistic - VCS
> DirectC example.
>
> The following two versions of VCS command line will deploy
> compilation with,
> respectively, direct or abstract access mode, for the same
> source code:
>
> vcs design.v aux_C_code.c +vc
> vcs design.v aux_C_code.c +vc+abstract -CFLAGS "-D ABSTRACT"
>
> In the above command lines:
>
> 'design.v' contains Verilog code, 'aux_C_code.c' contains C code.
>
> +vc enables DirectC.
>
> +vc+abstract enables DirectC and specifies abstract access
> for all functions
> (unless extern "C" was specified for a particluar function)
>
> -CFLAGS "-D ABSTRACT" defines flags ("-D ABSTRACT") to be passed to
> the C compiler.
>
> The trick is to use C conditional compilation.
>
> ============ design.v ================
> extern void cfunc(input int i; output int o);
> ...
> // Verilog stuff
> ...
>
> ============ aux_C_code.c ============
>
> #ifndef ABSTRACT /* i.e. DIRECT access mode */
>
> /* input passed by value, output passed by reference */
> extern void cfunc(/*input*/ int i; /*output*/ int *o)
>
> #define GET_INT_VALUE(arg) (arg)
> #define PUT_INT_VALUE(arg,value) {*arg=value;}
>
> #else /* ABSTRACT access mode */
>
> /* input and output passed by handle */
> extern void cfunc(/*input*/ vc_handle i; /*output*/ vc_handle o)
>
> #define GET_INT_VALUE(arg) (vc_getInteger(arg))
> #define PUT_INT_VALUE(arg,value) {vc_putInteger(arg,value);}
>
> #endif /* DIRECT vs. ABSTRACT */
>
> {
> int n = GET_INT_VALUE(i); /* value of the input arg */
>
> ... /* function body not depending on the access mode */
>
> PUT_INT_VALUE(o, ...); /* value to be assigned to the
> output arg */);
> }
>
> ======================================
>
> Of course, the same effect can be achieved in several ways;
> what is key, however, is the separation of the algorithm's
> proper and the access
> to the formal arguments. It doesn't seem to be a big deal.
>
> Regards,
> Andrzej
This archive was generated by hypermail 2b28 : Fri Nov 22 2002 - 09:06:00 PST