Don Mills wrote: > 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? No. Due to the definition of "longest static prefix" the difference is moot. If an index expression in a prefix is not a constant expression, an implementation would have to assume that ALL possible index values are used. Packed or unpacked is immaterial. In the example I gave, the fact that 'idx' is not a constant expression is the critical consideration. More than one process calling "write_something" would cause the conflict. Gord. > > 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. >>>>> >>>>> >>>>> >>>> >>> >> > -- -------------------------------------------------------------------- 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 14:46:53 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 01 2007 - 14:47:06 PDT