Subject: Re: More on ISSUE 1.7
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Nov 21 2002 - 18:05:37 PST
> From: "Warmke, Doug" <doug_warmke@mentorg.com>
>
> 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
I think we're probably forced into 3 by a) time constraints
- don't want to specify multiple APIs, b) any simulator
dependent data has to be accessed through an abstract interface,
and c) for efficiency (speed) I don't want to pick up data through
an API that I could have passed directly with a lot less effort.
Error checking the interface I would like to leave up to the tool
vendors and not specify much of it in the LRM.
Kev.
>
> > -----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 : Thu Nov 21 2002 - 18:06:09 PST