From: Shalom Bresticker (shalom@msil.sps.mot.com)
Date: Mon Aug 17 1998 - 07:34:54 PDT
My comments inside:
Content-Length: 4765
X-Lines: 106
X-Status: $$$$
X-UID: 0000000626
Status: RO
> Date: Wed, 12 Aug 1998 11:20:55 -0700
> From: Stefen Boyd <stefen@boyd.com>
> Subject: BTF B08 - Implicit sensitivity
>
> Ok, here's my initial cut at B08... let me know what I've
> done wrong!
>
> Regards,
> Stefen
> Insert new 9.7.5 after 9.7.4
>
> 9.7.4 Implicit sensitivity list
Should be 9.7.5.
> The event control immediately following an always construct is considered a sensitivity list.
An event control need not follow always. It can appear in many places.
Similarly, always need not be followed by an event control.
(By the way, "always construct" is the combination of "always" and the statement which follows it.)
Also, the term "sensitivity list" is not defined. Maybe the intention was to say,
"is called a sensitivity list" instead of "is considered".
As for the term itself, although many people, including myself, do use the term
"sensitivity list", it would be more consistent and 1364-ish to call it an
"event expression list".
Anyway, I propose that @(*) may appear anywhere that @ may, not just after always.
What does it matter to the compiler?
On the contrary, it is easier for the compiler if the legal syntax is not context-dependent.
The compiler looks at the statement following the event control, and "copies" all the "read" variables.
If that fits what the code writer wants, fine. If not, he won't use it.
Remember, in contrast to other enhancements to Verilog, this change does not affect functionality.
It simply gives the user a short-hand which he can choose to use or not.
<p>>This sensitivity list is a common source of simulation miscompares between rtl and gate level versions of a design because users forget to add some of the nets or registers read in the statement to the sensitivity list.
While this statement is true, it is incomplete. Why does the mismatch occur ?
Not because the gate-level is wrong, but rather because the sensitivity list in the high-level
is incomplete. In other words, even without connection to the gate-level, the high-level
is wrong in many cases without the complete sensitivity list.
<p>> For a sensitivity list without edge control, the list can be determined automatically by using @(*).
This statement misuses the term "edge control" (which actually is not defined).
@a means "on any edge of a". The example at the bottom of page 115, for example,
uses @r as an example of an edge-control.
<p>> The asterisk is an implicit sensitivity list and will be equivalent to explicitly placing all the nets and registers read by the triggered statement into the sensitivity list. Registers which are always used on the left hand side of an assignment before being read shall not be included in the implicit sensitivity list.
> The use of the implicit sensitivity list shall be limited to triggered statements which do not contain any delays. This includes delay control (Section 9.7.1), event control (Section 9.7.2), wait statements (Section 9.7.5), blocking assignments with intra-assignment delay, and tasks calls with any of these delays in the body of the task definition. Task calls shall be limited to declarations local to the module containing the calls.
Why all these restrictions ?
As I suggested above, allow it anywhere.
If it fits, the coder can use it. If not, he won't.
Very often, a latch is written for example as:
always @(clk or data)
if (clk) #1 out = data;
<p>> Example1:
> always @(*) // equivalent to @(a or b or c or d or f)
> y = (a & b) | (c & d) | myfunction(f);
>
> Example 2:
> always @(*) begin // equivalent to @(a or b or c or d or e)
> tmp1 = a & b; // tmp1 and tmp2 are written before reading
> tmp2 = c & d;
> y = tmp1 | tmp2;
> end
<p>I also noticed a problem in 9.7 while looking at this.
Syntax 9-8 says:
event_control ::=
@ event_identifier
| @ ( event_expression )
event_expression ::=
expression
| event_identifier
| posedge expression
| negedge expression
| event_expression or event_expression
These say that only event_identifiers are legal here, not others.
But actually net and reg identifiers are also legal, as in the example at the bottom of page 115.
So it needs to be generalized. In the new 1998 BNF, we defined many different
types of identifiers. I don't know whether any of them fits here.
Identifiers which would not be legal here are: arrays, functions, tasks.
******************************************************************************
Shalom Bresticker email: shalom@msil.sps.mot.com
Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522444
http://www.motorola-semi.co.il/
******************************************************************************
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:52:59 PDT
and
sponsored by Boyd Technology, Inc.