Re: [sv-bc] always_comb question

Dave,

On Mon, 26 Jul 2004, Dave Rich wrote:

> >Even from a legalistic point of view, where we assume that each word is
> >carefully chosen, 9.2.1 says, "shall not be written to by any other
> >process", and does not mention the word "assignment".
> >
> >
> One has to read the SV LRM with the understanding that is was written by
> a committee, four committees in fact. So there are different choices of
> words all over the place. I understand "written to" and "assignment" to
> mean the same thing.

I realize that the LRM was not written with a consistent style.

However, in this case, the 1364-2001 standard does define 'force' as a type
of assignment. SV cannot change that. The statement that a 'force' is not
to be considered an assignment came in a certain context, which is not
relevant to this section, and is legitimately interpreted to be restricted
to that context. However, even assuming that the term 'assignment' is to be
interpreted everywhere in the SV LRM as excluding 'force', then it is
doubly legitimate to interpret a place where the term 'assignment' is not used
as not excluding 'force'.

In any case, a standard must use precise language.
Both tool developers and users depend on it.
Impreciseness causes ambiguity.
1364-2001 has that problem as well, but the problem should not be made
worse than it already is.

> >Assume for the moment that a force is legal.
> >
> >Then, since I have written d as a function of a, The Right Thing to do
> >would be to trigger the always_comb again in order to update a,
> >even those d is only an intermediate variable and thus not in the implicit
> >sensitivity list.
> >
> >
> I think you meant to say "update *d*, even though *a* is only an
> intermediate variable"

Yes. Am I dislexic?

> In any case, I disagree for two reasons. Had I explicitly wrote out the
> sensitivity list, as many people would using Verilog, the sensitivity
> list does not change when the force is applied.

Of course. The question was whether the fact that the list does not
include the intermediate variables is a problem.

Jonathan Bromley has already provided a convincing argument that it is not.

> The other reason is that
> making the always_comb block sensitive to changes on all intermediate
> variables puts unnecessary overhead on top of updating all the
> intermediate variables.

That is questionable, since they will never be triggered.

Shalom

-- 
Shalom Bresticker                        Shalom.Bresticker @freescale.com
Design & Reuse Methodology                           Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                 Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 5441478
  
[ ]Freescale Internal Use Only      [ ]Freescale Confidential Proprietary