Subject: Re: More on ISSUE 1.7
From: Stickley, John (john_stickley@mentorg.com)
Date: Thu Nov 21 2002 - 16:25:03 PST
Team,
Doug has framed this issue quite nicely.
My vote would be #3.
There really should be no overlap between the two.
I would also add that the option to use API trays to switch
between robust error checking variants of functions
and high performing functions could easily be
used with option #3 and should be orthogonal
to the issue how we represent data types. It should also probably
be an implementor's decision and not the role of the standard
to stipulate.
-- johnS
So my thinking
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 <mailto: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 email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient. Any review, reliance or distribution by others or
forwarding without express permission is strictly prohibited.
If you are not the intended recipient, please contact the sender
and delete all copies.
__
______ | \
______________________/ \__ / \
\ H Dome ___/ |
John Stickley E | a __ ___/ / \____
Principal Engineer l | l | \ /
Verification Solutions Group | f | \/ ____
Mentor Graphics Corp. - MED C \ -- / /
17 E. Cedar Place a \ __/ / /
Ramsey, NJ 07446 p | / ___/
| / /
mailto:John_Stickley@mentor.com <mailto:John_Stickley@mentor.com> \ /
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Thu Nov 21 2002 - 16:28:28 PST