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

My personal interpretation of a function that does not "preserve its state"
is a function that does not use or rely on having stored values from a
previous call.

In the original Verilog language, all functions retained, or preserved, the
return value of the previous call, but synthesis did not support the
***use*** of that static storage. In essence, synthesis wanted automatic
functions, but the Verilog HDL did not have that language feature. To
prevent the use of functions that relied on state preservation, synthesis
compilers support functions that are not declared as automatic by simply
checking that every branch within the function either assigns to the
function name or has a return statement with a value. Possibly, but I'm not
sure, synthesis compilers also check that the name of the function is not
read before being assigned (they should check for that, anyway). These
simple rules prevent most, if not all, cases where a function is relying on
preserving its state.

Can similar rules be added to the LRM to explain the meaning of a function
that does not preserve its state (or, more correctly, rely on state
preservation)?

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
www.sutherland-hdl.com

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Friday, June 17, 2011 6:42 AM
To: Francoise Martinolle; Arturo Salz
Cc: sv-dc@eda.org; sv-ac@eda-stds.org; SV-BC; SV_EC List
Subject: [sv-ec] RE: [sv-ac] RE: 3398 and 3625

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.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.