RE: [sv-bc] RE: [sv-ec] Case @* - altera

From: Bresticker, Shalom <shalom.bresticker_at_.....>
Date: Tue May 19 2009 - 11:35:30 PDT
9.2.2.1 says,

"The implicit sensitivity list of an always_comb includes the expansions of the longest static prefix of each variable or select expression that is read within the block or within any function called within the block with the following exceptions:

a) Any expansion of a variable declared within the block or within any function called within the block
b) Any expression that is also written within the block or within any function called within the block" 

(b) refers to variables written within the block regardless of where they are declared.

There is a different gotcha in the way some tools have implemented that, but that is a different story.

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Clifford E. Cummings
> Sent: Tuesday, May 19, 2009 9:24 PM
> To: sv-bc@eda.org
> Subject: [sv-bc] RE: [sv-ec] Case @* - altera
> 
> Hi, Shalom -
> 
> Where does the SV standard omit the "i" from the sensitivity list? If 
> declared locally, I agree that the "i" variable is omitted, but I 
> can't find where it would be omitted when declared and 
> assigned globally.
> 
> Regards - Cliff
> 
> At 01:02 AM 5/19/2009, you wrote:
> >Hi, Daniel.
> >
> >...
> >
> >SV has solved this gotcha in always_comb by excluding such variables 
> >from the implicit sensitivity list. This is one of the advantages of 
> >always_comb over always @*.
> >
> >As a result of this gotcha, some vendors have started excluding such 
> >variables from the implicit sensitivity list of always @* anyway, 
> >like always_comb, as this is the desirable behavior.
> >
> >Regards,
> >Shalom
> >
> >
> >----------
> >From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] 
> >On Behalf Of Daniel Mlynek
> >Sent: Tuesday, May 19, 2009 9:56 AM
> >To: sv-ec@server.eda.org
> >Subject: [sv-ec] Case @* - altera
> >
> >Altera in their libs is using code patterns like below (it was 
> >simplified in order to show the root of the problem):
> >module top;
> >
> >integer i;
> >
> >initial i = 0;
> >
> >always @(*)
> >     for (i = 0; i < 10; i++)
> >     begin
> >         $display("1 ", i);
> >     end
> >
> >always @(*)
> >     for (i = 0; i < 10; i++)
> >     begin
> >         $display("2", i);
> >     end
> >
> >endmodule
> >
> >
> >The intention is that alwayses in above code  should be in-sensitive 
> >for changes of "i" - so nothing should be printed. I've analysed the 
> >LRM in context of above code and IMHO according to LRM alwayses 
> >should be sensivitve to i changes - as this is global variable 
> >readed in in both those process. There is no such rule in LRM that 
> >for loop index variable should be exluded from implicit 
> sensitivity list.
> >
> >Could you please take a look on above and point me how should it 
> >work and where is it described in LRM - or the author intention was 
> >wrong and code should be rewritten using local index 
> variables in for loop?
> >
> >
> >DANiel
> 
> ----------------------------------------------------
> Cliff Cummings - Sunburst Design, Inc.
> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
> Phone: 503-641-8446 / FAX: 503-641-8486
> cliffc@sunburst-design.com / www.sunburst-design.com
> Expert Verilog, SystemVerilog, Synthesis and Verification Training
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
---------------------------------------------------------------------
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, and is
believed to be clean.
Received on Tue May 19 11:52:41 2009

This archive was generated by hypermail 2.1.8 : Tue May 19 2009 - 11:53:45 PDT