It's interesting that Brad should raise this now - I was tripped up by some related issues recently. It is not obvious that X/Z bits should make an enum value be an invalid index in the way described in 7.4.6. There are good practical reasons why an enum might have literals containing X/Z, and it is quite irksome that you cannot directly use such enums as the index type for an associative array (or, at least, you can't index using any of the enum's literals that contain X/Z). Note, I'm not trying to argue that there should be a *general* lifting of the restriction on using 4-state unknowns as associative array indices. The limitation is not fundamentally troublesome, as it's easy to construct a class that provides the desired behavior (associative array indexed by any enum value even if it contains unknowns). So it's probably not worth burning up much brain bandwidth on it. Jonathan On 23 March 2014 10:10, Bresticker, Shalom <shalom.bresticker@intel.com>wrote: > I could make an argument for either way. > > > > By the way, 7.4.6 says, > > > > If an index expression is out of bounds or if any bit in the index > expression is x or z, then the index shall be invalid. Reading from an > unpacked array of any kind with an invalid index shall return the value > specified in Table 7-1. Writing to an array with an invalid index shall > perform no operation, with the exceptions of writing to element [$+1] of > a queue (described in 7.10.1) and creating a new element of an > associative array (described in 7.8.6). Implementations may issue a > warning if an invalid index occurs for a read or write operation on an > array. > > > > and 7.8.6 says, > > > > *7.8.6 Accessing invalid indices* > > If a read operation uses an index that is a 4-state expression with one or > more x or z bits, or an attempt is made to read a nonexistent entry, then > a warning shall be issued and the nonexistent entry value for the array > type shall be returned, as shown in Table 7-1 (see 7.4.6). A > user-specified default shall not issue a warning and returns the value > specified in 7.9.11. > > If an invalid index is used during a write operation, the write shall be > ignored, and a warning shall be issued. > > > > The two sections seem to be using the term 'invalid' with different > meanings. Specifically, in 7.4.6 an index is invalid if it is out of > bounds, whereas that is not included in the definition in 7.8.6. The > reference in 7.4.6 to creating a new element of an associative array should > probably be to 7.8.7 instead of 7.8.6. > > > > Shalom > > > > *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf Of *Brad > Pierce > *Sent:* Sunday, March 23, 2014 01:37 > *To:* sv-ec@eda.org > *Subject:* [sv-ec] Enum type as associative array index type (7.8.6) > > > > As discussed in http://www.eda.org/svdb/view.php?id=4510 , if an enum > variable has been assigned a value outside the enumeration set, and it is > used as the index when writing to an associative array, is the write > ignored as an "invalid index" in 7.8.6? For example, > > > > *module* test; > > *typedef* *enum* {A, B, C} ET; > > *bit* assoc[ET]; > > *initial begin* > > assoc[ET'(100)] = 1'b1; > > $display(assoc.exists(ET'(100))); > > *end* > > *endmodule* > > > > -- Brad > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. > > --------------------------------------------------------------------- > 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. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sun Mar 23 11:08:46 2014
This archive was generated by hypermail 2.1.8 : Sun Mar 23 2014 - 11:08:55 PDT