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.Received on Tue May 19 11:26:57 2009
This archive was generated by hypermail 2.1.8 : Tue May 19 2009 - 11:28:13 PDT