I'm afraid if we go into detailed discussion right now, we would need a separate thread for that :) I'll just mention what I think about it. As a thumb rule, I think that the type of part select should be the same as the type of the data selected by it. I.e., if we have "bit [2:1] a [7:5][4:3];", the type of "a[5]" should be "bit [2:1] (imaginary placeholder) [4:3]", without further normalization. There is one situation where the type may be normalized without any bad consequences, which is when a part select selects more than one element of an array, like in "a[6:5]". In this case, the topmost array type (corresponding to the range of selected elements of the array) may be normalized, while the type of the elements of this array should still be left in their original form (I believe). I.e, the type of "a[6:5]" can be either the partly normalized to "bit [2:1] (placeholder) [1:0][4:3]" or be left in a more-or-less "original" form like "bit [2:1] (placeholder) [6:5][4:3]". I do agree that normalizing the top-most array for part selects selecting more than one element of an array may be preferable over not normalizing it, though I'm not sure it really matters for tool's performance. If we simplify the above example and look on a simple one-dimensional packed array, like "bit [7:5] b;", then, if we normalize the topmost array, the type of "b[6:5]" will be "bit [1:0] b;". So, unless you think that the whole type should normalized, and not only that of the topmost array, we may be still thinking the same. If you believe everything should be normalized, then we indeed have a disagreement, and we will have to discuss it. In my eyes, normalizing all types, in whatever way, would make this type information mostly, if not completely, useless. --Yulik. -----Original Message----- From: Gordon Vreugdenhil [mailto:gordonv@model.com] Sent: Tuesday, October 16, 2007 4:12 PM To: Feldman, Yulik Cc: Brad Pierce; sv-bc@server.eda.org Subject: Re: [sv-bc] confusion in determining the type of an self determined binary expression during evalution of type operator Feldman, Yulik wrote: > I didn't imply that it has a self-determined type. I just gave examples > of expression kinds that may have a complex data type, self-determined > or context-determined. Yulik, I believe that you are suggesting that a (part)select should not necessarily be normalized but should carry its range information around (more like VHDL). I would almost certainly object to that approach as a general requirement. The reason for the objection is that there is no Verilog precedent for needing that information in general and adding such a requirement would definitely have an impact on simulation performance. Given the limited contexts in which the information is used, it would be better to assume normalization everywhere other than a very few specific circumstances. I know that various people have talked about wanting to have selects on general expressions and that this position impacts that. If someone wants to try to write up a full description of normalization rules and/or un-normalized cases, I'd certainly review it, but I'm likely going to be wary of any deep requirement regarding non-normalized expressions. Gord. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com --------------------------------------------------------------------- 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, and is believed to be clean.Received on Tue Oct 16 08:30:32 2007
This archive was generated by hypermail 2.1.8 : Tue Oct 16 2007 - 08:30:47 PDT