Subject: Re: Some thoughts on ISSUE lifecycle and schedule
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Nov 12 2002 - 15:37:51 PST
Swapnajit,
Thanks for taking this initiative.
The lifecycle sounds fine to me.
The other ISSUE I had entered was that one about
"Direct vs. Abstract" access methods. Maybe that can
be consolidated into one of the issues Michael has
brought up. We probably need to bring that up for
more serious discussion. Today we touched on it
for a while but made no progress. Most people
indicated they preferred a direct-access-only approach
(keep-it-simple-sally), whereas Michael wanted a
C function approach where all access is done through
function calls provided by the implementation.
Maybe to make progress on this we need to discuss
extending Andrzej's proposal to encompass more
complex types at the interface. I suggest we either
continue his enumeration of supported types,
or we postpone that to 3.2. OR, we could make the
decision that we will never allow complex types
across this language boundary. If so, we would
probably go for the direct-only access method.
If not, we have to decide between procedural-access-only
and combined direct/procedural access. i.e. direct
access for simple types and procedural for complex ones.
Regards,
Doug
Swapnajit Mittra wrote:
> Hello all,
>
> I have put together some thoughts on the ISSUE
> lifecycle and schedule. Please review this and
> let me know if you have any comment.
>
> Regards,
> - Swapnajit.
>
> 1) ISSUE Lifecycle:
>
> Open -> Accepted -> Closed.
> -> Rejected
> -> Deferred
> -> Transferred
>
> 'Accepted' implies that SV-CC has accepted the item
> either unanimously or by majority vote for inclusion
> or modification in the LRM. The issuer of the item
> will work with the editor of the LRM to make sure this
> is done.
>
> 'Closed' implies the necessary modification has been
> made in the LRM.
>
> 'Rejected' implies items that are unacceptable.
>
> 'Deferred' implies items that are deferred till SV 3.2.
> It will be the responsibility of the issuer of the item
> to follow this up for the SV 3.2 discussion in the future
> if an item is deferred.
>
> 'Transferred' implied the item has been moved to the
> domain of another committee.
>
> 2) LRM schedule:
>
> Given the roadmap presented by Yatin to Accellera, we
> should focus on the LRM-related activities as soon as
> possible.
>
> I propose the following deadlines.
>
> Requirement Proposal Document Document
> Analysis Review Published Voting
>
> DirectC 11/26/02 12/10/02 12/24/02 01/15/03
> Assertion 12/03/02 12/17/02 01/15/03 01/31/03
> Coverage 12/10/02 12/24/02 01/22/03 02/07/03
>
> - Deadline for the 'Requirement Analysis': No new
> PROPOSAL/ISSUE can be filed after this date, unless a
> new ISSUE is generated due to an existing ISSUE (i.e. the
> new ISSUE is a clarification on an existing ISSUE). Please
> specify the parent ISSUE number for such an ISSUE.
>
> - Deadline for the 'Proposal Review': No new ISSUE
> can be filed on the existing ISSUEs. This marks the end
> of discussion on all the ISSUEs and PROPOSALs.
>
> - Deadline for the 'Document Published': The respective
> owner of each ISSUE/PROPOSAL will work with the LRM
> editor to get this done.
>
> - Note that these dates are already few weeks behind Yatin's
> initial schedule.
>
> --
> Swapnajit Mittra
> Project VeriPage ::: http://www.angelfire.com/ca/verilog
>
> ________________________________________________________________
> Sign Up for Juno Platinum Internet Access Today
> Only $9.95 per month!
> Visit www.juno.com
This archive was generated by hypermail 2b28 : Tue Nov 12 2002 - 15:38:18 PST