Re: SV-CC Proposal revision 7


Subject: Re: SV-CC Proposal revision 7
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Dec 12 2002 - 15:07:33 PST


John,

The proposal is looking good now.
A few items to contemplate remain:

1) I think you should add "pure" and "context"
    back into the language per se, rather than
    keep them as attributes. "queueable" deserves
    being an attribute, since it is only looked at
    by certain implementations and does not change
    semantics for the general case. The others do.

2) It would be interesting to merge your LRM-style
    work here with Andrzej's 17 points. Building
    towards a complete LRM.

3) We still need to resolve if all those tf_ and vpi_
    calls used for grabbing the calling instance are
    needed, or if we should indeed expand Andrzej's
    API to include *all* functionality required by
    various SVC features. There are good cases for
    both ways.

Thanks and regards,
Doug

Stickley, John wrote:
> Team,
>
> In addition to formlizing my proposal in LRM style as requested
> by Swapnajit I've made a number of revisions that are summarized below.
> Each of these revisions is also added as "author's notes" in italicized
> red text in the document itself.
>
> Author’s Note: Should we change the extern keyword to import ? This
> would make it more symetrical with export for the C-to-SV direction.
>
> Author’s Note: I changed attributes to follow standard SystemVerilog
> attribute syntax as per chapter 6. This avoids pollution of keyword
> space by making attributes pre-standardized identifiers rather than
> reserved keywords. A concern was raised at the general SystemVerilog
> face to face meeting that keyword pollution is getting to be a problem.
>
> Author’s Note: One change I made here was the removal of the need to
> call tf_getinstance() to get the calling instance. I felt that it was
> cleaner just to have the infrastructure pass the SV module context
> directly if the context attribute is used. This avoids an extra call and
> reduces reliance on VPI even more - while still avoiding the need to add
> new API calls which is the intent of Joao’s original request that we
> replace dedicated calls with pre-existing VPI calls.
>
> -- johnS
>
> __
> ______ | \
> ______________________/ \__ / \
> \ 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 \ /
> Phone: (201)818-2585 \ /
> ---------
>
>
>



This archive was generated by hypermail 2b28 : Thu Dec 12 2002 - 15:08:02 PST