Subject: Re: More on ISSUE 1.7
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Fri Nov 22 2002 - 04:44:37 PST
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]
> > 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 - 04:46:01 PST