Re: [sv-cc] RE: [sv-champions] Email vote - Ending December 13th

Mantis 2651 could be addressed by the sv-cc committee.
That would make a good fit since since several of the sections of the LRM
being quoted in mantis 2651 are related to the work done in the sv-cc.
Mantis 2651 can be reassigned to the sv-cc if the committee is willing
to work on it.

For this version of the PAR we are being constrained by what the Working
Group has allowed each of the Technical Committees to work on. In the
Working Group meeting of November 11, 2010 blanket approval was granted to the
TCs to work on mantis items that are "deemed to be precursors to the ones
already approved. The committees will mark these issues as children of the
approved issue." Mantis 2651 could be worked on and flagged as a child of
mantis 1477.

An email could also be sent out to the other TCs letting them know that the
sv-cc is working on this mantis item. That would give others a heads up
and allow interested parties to chime in.

Neil

On 01/06/11 08:21 AM, Bresticker, Shalom wrote:
> I think Neil Korpusik should advise what to do on that issue.
>
>
>
> Shalom
>
>
>
> *From:* owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] *On Behalf Of
> *Jim Vellenga
> *Sent:* Thursday, January 06, 2011 6:18 PM
> *To:* Bresticker, Shalom; Steven Dovich; Chuck Berking
> *Cc:* sv-cc@eda.org; Charlie Dawson
> *Subject:* RE: [sv-cc] RE: [sv-champions] Email vote - Ending December 13th
>
>
>
> Hmm, yes. 2651 points out that we use “deprecated” to mean either “not
> recommended” or
>
> “no longer recommended” or even “no longer part of the standard.” And
> our usage is
>
> not consistent.
>
>
>
> It would be nice to clear that up, but that is not really the province
> of any one committee,
>
> is it? Should we ask SV-BC for guidance?
>
>
>
> Jim Vellenga
>
>
>
> *From:* owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] *On Behalf Of
> *Bresticker, Shalom
> *Sent:* Thursday, 6 Jan 2011 11:03 AM
> *To:* Steven Dovich; Chuck Berking
> *Cc:* sv-cc@eda.org; Charlie Dawson
> *Subject:* RE: [sv-cc] RE: [sv-champions] Email vote - Ending December 13th
>
>
>
> See also Mantis 2651.
>
>
>
> Shalom
>
>
>
> *From:* Steven J. Dovich [mailto:dovich@cadence.com]
> *Sent:* Thursday, January 06, 2011 6:01 PM
> *To:* Chuck Berking
> *Cc:* Bresticker, Shalom; sv-cc@eda.org; Charlie Dawson
> *Subject:* Re: [sv-cc] RE: [sv-champions] Email vote - Ending December 13th
>
>
>
> Shalom is right, deprecations should be identified in Annex C. The PLI
> TF and ACC deprecations head that list, and the assorted VPI items
> should be added there for consistency.
>
>
>
>
>
>
>
>
>
> *Steven J. Dovich* | Sr Member of Consulting Staff, Advanced
> Verification Systems | Cadence
>
> P: 978.262.6413 M: 978.494.0519 www.cadence.com <http://www.cadence.com>
>
>
>
>
>
>
>
>
>
>
>
>
> On 1/6/2011 10:55 AM, Chuck Berking wrote:
>
> As I mentioned, I did see and fix this error in my latest proposal replacement:
>
>
>
> #define vpiInterfaceDeclvpiVirtualInterfaceVar /* interface decl deprecated */"
>
>
>
> Apparently there is a bug in Framemaker that does not map tab characters to at least an intervening space when generating .pdf files (it appears OK in my original Frame text).
>
>
>
> Re. #2:
>
>
>
> I see no precedent for noting VPI or PLI #defined symbol deprecation in C.2. I.e. there is a handful of these in VPI that are not mentioned here (e.g. vpiArray property). [ SV-CCers- should they be- or is this overkill ? ]
>
>
>
> - CB
>
>
>
>
>
> Chuck Berking | Member of Consulting Staff | Cadence
>
> P: 978.262.6522 M: 603.253.9130 www.cadence.com <http://www.cadence.com>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
>
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
>
> Sent: Thursday, January 06, 2011 3:50 AM
>
> To: Chuck Berking
>
> Cc: sv-cc@eda.org <mailto:sv-cc@eda.org>; Charlie Dawson
>
> Subject: RE: [sv-champions] Email vote - Ending December 13th
>
>
>
> Two more points on the new proposal:
>
>
>
> 1. In the change to M.2:
>
>
>
> "REPLACE:
>
> #define vpiInterfaceDecl 728
>
> WITH:
>
> #define vpiInterfaceDeclvpiVirtualInterfaceVar /* interface decl deprecated */"
>
>
>
> There should be a space between "vpiInterfaceDecl" and "vpiVirtualInterfaceVar".
>
>
>
>
>
> 2. If vpiInterfaceDecl is being deprecated, a new subclause describing it should probably be added to C.2.
>
>
>
>
>
> Thanks,
>
> Shalom
>
> ---------------------------------------------------------------------
>
> Intel Israel (74) Limited
>
>
>
> This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
>
>
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.