[sv-bc] RE: [sv-ac] RE: 3398 and 3625

From: Bresticker, Shalom <shalom.bresticker@intel.com>
Date: Fri Jun 17 2011 - 06:42:20 PDT

1. Legacy code.

2. Making them automatic requires adding that keyword. Default is static. Engineers love defaults and hate adding extra code.

Shalom

> -----Original Message-----
> From: Francoise Martinolle [mailto:fm@cadence.com]
> Sent: Friday, June 17, 2011 4:36 PM
> To: Arturo Salz; Bresticker, Shalom
> Cc: sv-dc@eda.org; sv-ac@eda-stds.org; SV-BC; SV_EC List
> Subject: RE: [sv-ac] RE: 3398 and 3625
>
>
> I see now the reason for the wording in parenthesis.
> Is there value in allowing these static functions? If they do not
> preserve any state, why can't they be made automatic?
> With the current wording we do allow static functions but the tool will not
> make
> any check since this is informational.
> Francoise
> '
>
> -----Original Message-----
> From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> Sent: Friday, June 17, 2011 4:39 AM
> To: Bresticker, Shalom
> Cc: Francoise Martinolle; sv-dc@eda.org; sv-ac@eda-stds.org; SV-BC; SV_EC
> List
> Subject: Re: [sv-ac] RE: 3398 and 3625
>
> Shalom is right to point this out. I believe the new proposal would make
> illegal static functions that would be legal today. For example, a static
> function with only input arguments that are thus overriden on each function
> call. Likewise, the function's output variable stores the last return value
> unless it is overwritten on each call. The previous verbiage was intended to
> allow such uses without forcing the tool to check for compliancy and instead
> inform users of the requirements.
>
> - Arturo
>
>
> On Jun 17, 2011, at 6:36 AM, "Bresticker, Shalom"
> <shalom.bresticker@intel.com<mailto:shalom.bresticker@intel.com>> wrote:
>
> Francoise,
>
> In the past, I have interpreted "or preserve no state information" as being
> a real "or", i.e., "shall either be automatic or otherwise preserve no state
> information", and not an additional restriction. That is, a static function
> that preserves no state information would be legal.
>
> Are there automatic functions that preserve state information?
>
> Also see Mantis 2928.
>
> This change would affect both assertions and constraints.
>
> Regards,
> Shalom
>
> From: owner-sv-dc@eda.org<mailto:owner-sv-dc@eda.org> [mailto:owner-sv-
> dc@eda.org] On Behalf Of Francoise Martinolle
> Sent: Friday, June 17, 2011 3:29 AM
> To: <mailto:sv-dc@eda.org> sv-dc@eda.org<mailto:sv-dc@eda.org>
> Subject: [sv-dc] 3398 and 3625
>
> I have updated 3398 with the latest versio of the proposal for nettypes. I
> have deleted all previous versions.
> I also have submitted a new mantis item 3625 for the BC to consider to
> change Functions shall be automatic (or preserve no state information) and
> have no side effects.
>
> to:
> Functions shall be automatic, preserve no state information and have no side
> effects.
> I wil lmake a proposal to for 3625 and ask BC to add it to the agenda of
> next meeting.
>
> Francoise
> '
>
>
>
> --
> 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<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.
Received on Fri Jun 17 06:43:11 2011

This archive was generated by hypermail 2.1.8 : Fri Jun 17 2011 - 06:43:15 PDT