If there *weren't* errors then the simulator is *not* compliant with the proposed rules since a compliant tool would report errors. Gord. Don Mills wrote: > 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. >>> >>> >>> >> > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.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:47:47 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 01 2007 - 13:48:03 PDT