Subject: Re: More on ISSUE 1.7
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Mon Nov 25 2002 - 05:14:23 PST
Hello Doug,
also thanks a lot for this clarification. I think I have to agree about most points. My feeling is still that some check/debug mode
can be rather useful, but you are fully correct by pointing out that this can/should be invisible to the user. As such, it is
something that _should_not_ be in the LRM.
From that perspective, any option that is invisible to the user is possible and acceptable.
I think, I have to admit, you beat me with my own weapons.
Thanks again, this was a very important point.
Regards,
Michael
"Warmke, Doug" wrote:
> Michael,Thanks for the clarifications.Here is another way to think about things, which is one of the main reasonsI support
> solution c).In all current mixed language products (i.e. Verilog instantiates VHDL entityand VHDL instantiates Verilog module),
> there is no API needed by theuser 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'toften mess around with cross-language
> setups once they areinto the heat of their verification. Also, the direct mode is easierto read in user code due to lack of
> clutter.I don't see too much value in having debug API functions that fetch andsend data. The functions could catch illegal
> attempts at type conversionsat runtime. However, even without such debug functions, users will quicklybe able to get the cross
> language data passing mechanism workingby reading the docs and doing simple experiments.I would prefer to see our "mixed language"
> effort here more closelyfollow the mixed language type conversions I described above,rather than what is done in PLI. I find that
> rather cumbersome toprogram 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]
> > > 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 : Mon Nov 25 2002 - 05:14:56 PST