Re: errata/84: Should @* include delay controls?

From: Shalom.Bresticker@motorola.com
Date: Wed Aug 14 2002 - 21:10:08 PDT


Precedence: bulk

The following reply was made to PR errata/84; it has been noted by GNATS.

From: Shalom.Bresticker@motorola.com
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/84: Should @* include delay controls?
Date: Thu, 15 Aug 2002 07:05:57 +0300 (IDT)

 On Wed, 14 Aug 2002, Steven Sharp wrote:
 
> It is not as trivial as you think. And how much analysis should a tool do?
> You either have to provide a precise algorithm for all tools to use, or a
> general statement that tools can eliminate variables from the list if they
> can guarantee that they never read a value set by any other process. The
> latter would allow for optional optimization, at the cost of differences
> in the behavior of different tools.
 
 Well, these days tools are pretty smart.
 But see my next comment.
 
 
> > E.g.,
> > always @*
> > begin
> > a = b ;
> > c = a ;
> > end
> >
> > It is trivial to see that a is always assigned before being used.
>
> And you are incorrect in seeing that. What if a is forced or
> quasi-continuous-assigned somewhere else? Then the assignment to a has
> no effect and c will be set to the value forced/assigned. Perhaps you
> would never do that, but the fact is that a is not guaranteed to be
> assigned before being used, even in such a trivial case.
 
 Two comments here:
 
 1. Let's again remember that we are talking about modeling combinational logic.
 In that case, the rule is what I said. That is, the way to write this explicitly
 is
 
         always @b
         begin
                 a = b ;
                 c = a ;
         end
 
 In fact, what a synthesis tool is going to give you is either a union between b
 and c, or at most a buffer from b to c. a is not going to appear at all.
 
 2. As for force or quasi-continuous assignment (deprecated in SystemVerilog
 3.0), this relates to my complaint about Section 5, that anyone who writes code
 like this thinks and expects and demands that a will not change between the two
 assignment statements. That is, he needs this code to be expected atomically
 (or at most that a not be assigned in the middle).
 
 Unfortunately, most of the WG did not accept my arguments. But some did, like
 Daryl Stewart. And I have seen the problem arise in several places in different
 contexts and by different people. I remain convinced that this is a major
 problem in Section 5.
 
 Shalom
 



This archive was generated by hypermail 2.1.4 : Thu Oct 10 2002 - 09:24:27 PDT and
sponsored by Boyd Technology, Inc.