From: Steven Sharp (sharp@cadence.com)
Date: Wed Apr 17 2002 - 13:14:19 PDT
Precedence: bulk
>A few more questions regarding @*:
>
>> Here are a couple of examples which I would like someone to explain to
>> me: what is the outcome _supposed_ to be. I have my own opinions, of
>> course....by you know what they say about opinions...
>>
>> module foo;
>> reg a;
>> reg mem [0:15];
>> reg [3:0] b;
>>
>> always @*
>> a = #10 mem[b];
>>
>> initial begin
>> b = 0; // everyone agrees - the block should fire.
No, everyone does not agree. This depends on whether the always block
executed first at time zero and reached the event control, or whether
the initial block executed first at time zero before the always block
reached the event control. This is a race condition and the result is
technically undefined.
But if there were a delay at the start of the initial block, then the
always block would be waiting at the event control and would fire.
>> #5 mem[1] = 0; // fire, or not?
If it fired at time 0, then it can't fire now, since it is still waiting
at the #10. That is separate from the issue of whether a block waiting
at an @* on a statement that reads a memory will fire when any word in
the memory is changed. I would have to re-read the standard carefully
to try to determine that. It may very well be unclear.
>> #5 b = 1; // fire, or not (note that we can't fire now, if we fired at #5
Correct.
>> another one: lets say that you can determine the range of some value.
>> Do you use that knowledge, or not?
No. The standard may have areas where it is unclear on what sensitivity
should result from a statement. However, it is clear that the sensitivity
is defined only in terms of what is in the attached statement. There is
no dependence on information from elsewhere.
That doesn't mean that information from elsewhere can't be used. But it
can only be used if analysis can guarantee that the results still match
the standard semantics that don't use that information. If @* is only
used to implement purely combinational logic, which was presumably the
intent, then most of these issues are moot.
Steven Sharp
sharp@cadence.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:55:35 PDT
and
sponsored by Boyd Technology, Inc.