Re: [sv-bc] variable driven by continous assignment and ref port

In a way. That analysis is quite conservative and only depends on
collecting
the non-local variables. There is nothing that depends on the "actuals"
to a
call in the analysis. In addition, it isn't at all clear to me that
everyone applies
the always_comb rule to all hierarchical calls. Such a partial
implementation of
the rules would make sense for a synthesis view due to synthesis
restrictions on
hierarchical references. It would also make the implementation much less
expensive.

One of the ongoing issues in all of these discussions is trying to minimize
simulation/synthesis mismatches. It isn't clear to me that doing
anything other
than what has already been suggested (const ref doesn't count as a
write, ref does)
is going to really be that much more accurate in practice unless we mandate
things like "inlining" of logic, constant propagation from actuals, and
other
kinds of analysis to mimic some of the synthesis effect.

So at this point, I wouldn't be in favor of doing anything more than the
simple rule.

Gord.

On 10/26/2011 3:38 AM, Bresticker, Shalom wrote:
>
> Doesn't always_comb, for example, already do a similar type of analysis?
>
> Shalom
>
> *From:*Steven Sharp [mailto:sharp@cadence.com]
> *Sent:* Wednesday, October 26, 2011 4:26 AM
> *To:* Rich, Dave; Bresticker, Shalom; Daniel Mlynek
> *Cc:* sv-bc@eda.org
> *Subject:* RE: [sv-bc] variable driven by continous assignment and ref
> port
>
> Good language design strives for rules which are simple to check and
> enforce, especially if it doesn't impair the functionality. In this
> case you can always declare the arguments as const ref if you aren't
> writing to them, so the simpler rule does not restrict the available
> functionality.
>
> Note that this is not just a matter of implementation. It also makes
> it easier for users to determine whether they are coding by the
> rules. With the simple rules, you just need to check whether the ref
> argument is const ref to know whether this is considered an
> assignment. Otherwise you might have to track down every subroutine
> that this subroutine calls and passes the ref argument to, to see
> whether it assigns to it. That could be a very arduous task.
>
> *From:*Rich, Dave [mailto:Dave_Rich@mentor.com]
> *Sent:* Tuesday, October 25, 2011 10:55 AM
> *To:* Bresticker, Shalom; Steven Sharp; Daniel Mlynek
> *Cc:* sv-bc@eda.org
> *Subject:* RE: [sv-bc] variable driven by continous assignment and ref
> port
>
> There /could/ be a procedural write; therefore you have to assume
> there will be. Otherwise you would have to expand all nested
> subroutine calls that pass that argument by reference to check for a
> write.
>
> Dave
>
> Mentor Graphics**
>
> *From:*owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf Of
> *Bresticker, Shalom
> *Sent:* Tuesday, October 25, 2011 4:16 AM
> *To:* Steven Sharp; Daniel Mlynek
> *Cc:* sv-bc@eda.org
> *Subject:* RE: [sv-bc] variable driven by continous assignment and ref
> port
>
> Why would there be a procedural write if the subroutine contains no
> assignment to the ref argument?
>
> Shalom
>
> *From:*Steven Sharp [mailto:sharp@cadence.com]
> <mailto:[mailto:sharp@cadence.com]>
>
> This analysis is possible because module port connections are part of
> the static hierarchy. On the other hand, ref arguments to
> tasks/functions are done procedurally at runtime. Therefore I think
> passing a variable as a non-const ref argument to a task/function
> should be considered a procedural write. If the subroutine isn't
> intended to write to the ref argument, then it should be declared a
> const ref.
>
> ---------------------------------------------------------------------
> 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* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.