RE: [sv-bc] always_ff

Shalom,
     Is this legal?  
 
module test(input my_in, clk, output logic my_out);
 
always_ff
        begin
                @(posedge clk);
                        my_out = my_in;
        end
endmodule

 
If so, does always_ff follow the rules from 9.4.2.2 'Implicit
event_expression list' for making its sensitivity list?
Specifically
All net and variable identifiers that appear in the statement will be
automatically added to the event expression

with these exceptions:

- Identifiers that only appear in wait or event expressions.

 
The text in 9.2.2.4 that describes the always_ff behavior says
 
"The always_ff procedure imposes the restriction that it contains one
and only one event control and no
blocking timing controls."
 
So in my example is the "@(posedge clk)" the single event control, thus
following the rules.
 
Or is there 1 implicit event control on the always_ff and then the
@(posedge clk) is a 2nd, thus breaking the rules.
 
 
Note : off the top of my head, I don't know of any good reason you would
want to write a flipflop in the style I have done above, rather than
with the sensitivity list directly with the always_ff.
 
~Alex

________________________________

From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Bresticker, Shalom
Sent: Tuesday, July 01, 2008 11:53 PM
To: sv-bc
Subject: [sv-bc] always_ff



Hi, 

The LRM does not today require always_ff to be followed by a sensitivity
list with edge-sensitive event controls. Is that deliberate?

Thanks, 
Shalom 

Shalom Bresticker 
Intel Jerusalem LAD DA 
+972 2 589-6582 
+972 54 721-1033 

---------------------------------------------------------------------
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. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.