Gord, FYI - I ran this code through the simulator I have access to and there were no compilation or simulation issues raised. Hummm. The proposed LRM changes appears to already be implemented in at least one simulator. Cool. thanks Gordon Vreugdenhil wrote: > Shalom, your suggested change corresponds to my expectations > for always_comb. > > > Here is an follow-up situation to consider on this. > > module testmod; > bit [1:0] a; > function automatic void write_something(input int idx); > a[idx] = 1; > endfunction > > always_comb write_something(0); > always_comb write_something(1); > endmodule > > Such a design will report a conflict in simulation even though I > would expect it to synthesize correctly. The basic point is the > "longest static prefix" is a locally determined property and > there is no dataflow analysis, inlining, or any similar effect > going on during the analysis. > > I would like an example such as the above to explicitly go into > the LRM to make this aspect of the analysis clear. > > My basic point here is that while things like "always_comb" bring > synthesis semantics closer to the simulator, simulation is > not going to match synthesis assumptions in all cases. > > Gord. > > > > > Bresticker, Shalom wrote: >> Please review. >> <<1360_D4.V2.htm>> >> Thanks, >> Shalom >> >> Shalom Bresticker >> Intel Jerusalem LAD DA >> +972 2 589-6852 >> +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. >> ------------------------------------------------------------------------ >> >> Mantis 1360 >> >> P1800-2008/Draft 4 >> >> Independent elements of a variable can be written by different >> always_comb processes. >> >> In Section 9.2.2.2 >> >> CHANGE >> >> The variables written on the left-hand side of assignments shall not >> be written to by any other process. >> >> TO >> >> The variables written on the left-hand side of assignments shall not >> be written to by any other process. However, multiple assignments >> made to independent elements of a variable are allowed as long as >> their /longest static prefixes/ do not overlap (see _11.5.3_). For >> example, an unpacked structure or array can have one bit assigned by >> an always_comb procedure and another bit assigned continuously or by >> another always_comb procedure, etc. See _6.5_ for more details. >> >> >> > -- ========================================================== Don Mills mills@lcdm-eng.com www.lcdm-eng.com ========================================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Nov 1 13:32:21 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 01 2007 - 13:32:29 PDT