>From: "Bresticker, Shalom" <shalom.bresticker@intel.com> >But what did Dave Rich mean, >"In regard to the next() method, when the enumerated values are not in >ascending numerical order, it's not just a trivial matter to bump up the >values to the Nth member."? I believe he was saying that next() can't just add 1 in the general case. >[Shalom: ] This is not clear to me. You seem to be referring to Table >6-1 in clause 6.4. A similar table is Table 5-1 in 5.9.6, referring >specifically to associative arrays. That is the one. >However, this table seems to be describing specifically initial values >of variables, not generally of data types. The reference to "invalid >index" in 5.4.1 refers specifically to queues. >(BTW, the reference there to "Table 4-1" should be "Table 5-1"). > >It is not at all clear that a data type has a default initial value >which is independent of whether it is a variable or a net. I don't see >that this is clearly implied from Table 6-1. This would be a case where the evolution of the standard produced some unclear wording. In plain Verilog, we would have said in all these places that "the result shall be X". Then we might have remembered that some of these places had to deal with reals too, and gone back and said that "the result shall be X, unless it is a real, in which case it shall be 0.0". In SystemVerilog, there are too many types to make this approach practical. What was needed was a concise generic term for the value to be used in these situations. Since the most obvious place where this value is used is the default initial value of a variable, the term "default initial value" came into use. And as the standard was clarified and new situations needing an "undefined" value were identified, they were generally defined to use this "default initial value". When some of the new data types were allowed on nets, this phrase became less accurate. It really should have become "default initial value for a variable of this type", but that is no longer concise and may even be more confusing. Perhaps these places should have been changed to say "the value from Table 6-1". Though now that I compare Table 6-1 with Table 5-1, I see that there is an entry in Table 6-1 that is wrong for some of the places that say "default initial value". Any place where the type of the result is a named event should produce a null (as in Table 5-1), not a newly allocated event object (as in Table 6-1). The reason that Table 6-1 gives a new event as the default initial value for an event is to give backward compatibility with legacy Verilog code, where an event was a static object. With SystemVerilog events being handles, you would have to put an initialization to 'new' on the event declarations to get the old behavior otherwise. But this initialization of events to a new event means that the table is not specifying the "unknown" or "uninitialized" state for an event. Steven Sharp sharp@cadence.comReceived on Thu Nov 3 13:24:39 2005
This archive was generated by hypermail 2.1.8 : Thu Nov 03 2005 - 13:25:42 PST