You are right - I was confusing packed with unpacked arrays. The proposed change is for unpacked arrays. So, yes, the tools is errant. What about diffent bits within a packed array. Could that also be part of this enhancement. Has this already been discussed in the past and tossed out? dm Gordon Vreugdenhil wrote: > 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. >>>> >>>> >>>> >>> >> > -- ========================================================== 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:55:20 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 01 2007 - 13:55:37 PDT