Shalom, Yes. The value part of a "default:" specifier need not be a simple bit vector. It can have an aggregate data type as long as it's self-determined. The most common case is where the default value is some variable with an aggregate type. In those cases the type of the value is used to place it into the resulting assignment pattern. Example: For any type T, if you have a port or variable ZERO: T ZERO = T'( ... ); T my_array [4][4] = '{default: ZERO} 16 copies of ZERO fill all 16 positions in my_array. This works even when T is also an unpacked array data type. It uses both the recursion and the type matching rules given below. Greg Bresticker, Shalom wrote: > Can a default value be an aggregate value, such as a structure or an > array (sub-array)? > > This does not seem to be clearly stated. > > Thanks, > Shalom > > > >>-----Original Message----- >>From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com] >>Sent: Wednesday, December 21, 2005 1:41 AM > > >>>8.13.1 says, >>>"The default:value applies to elements or subarrays that are >> >>not matched by either index or type key. If the type of the >>element or subarray is a simple bit vector type, matches the >>self-determined type of the value, or is not an array or >>structure type, then the value is evaluated in the context of >>each assignment to an element or subarray by the default and >>must be castable to the type of the element or subarray; >>otherwise, an error is generated. For unmatched subarrays, the >>type and default specifiers are applied recursively according >>to the rules in this clause to each of its elements or >>subarrays. For unmatched structure elements, the type and >>default keys are applied to the element according to the rules >>for structures." >> >>>Although I think I understand the intent of this paragraph, I >> >>find the wording very difficult. >> >>>It seems to say the following (2nd sentence, my additions in >> >>uppercase): >> >>>"If the type of the element or subarray is a simple bit >> >>vector type OR IF THE TYPE matches the self-determined type of >>the value OR IF THE TYPE is not an array or structure type, >>then the value is evaluated in the context of each assignment >>to an element or subarray by the default and must be castable >>to the type of the element or subarray; otherwise, IF THE TYPE >>DOES NOT MEET ONE OF THESE 3 CONDITIONS, an error is >>generated." >> >>>It seems to say that either one of the 3 conditions is met or >> >>an error is generated. >> >>The second sentence here runs-on too long for its own good. >>Your parse is accurate, and shows that this text does not >>capture >>the design intent. >> >>One problem is the "; otherwise" conjunction, which should NOT >>be >>offering an alternative to the three-part conditional. It only >>describes what happens when a "default:value" clause matches >>some >>element (or subarray) under one of those three conditions but >>whose value fails to be castable to the element (subarray) >>type. >>In such a case, an error issues. The "match" succeeds - no >>further >>recursion happens - but the assignment operation fails! >> >>The larger problem is that it has proven hard to express the >>precedence order between the different clauses AND how the >>recursion (of "type:" and "default:" clauses) applies to all >>unmatched elements. >> >>I'd prefer rewriting these sentences; they should specify: >> - When defaults are considered >> - What it means for a default to "match" >> - What happens on a match >> - What happens to things that didn't match. >> >>"Elements or subarrays that do not match any "index:" or >>"type:" >> specifier become candidates to match a "default:value" >>specifier." >> >> >>"An element or subarray matches a given "default:value" >>specifier if it: >> - has a simple bit vector type, >> - has a type which matches the self-determined type of the >>value, OR >> - does not have an array or structure type." >> >> >>"Each element or subarray that matches a "default:value" >>specifier >> becomes (the left hand side of) an assignment context in >>which the >> (right hand side) value is actually evaluated. This value >>must be castable >> to the type of the element or subarray; otherwise, an error >>is generated." >> >> >>"Subarrays that do not match any "index:", "type:", or >>"default:" specifier >> are assigned a new pattern consisting of just the "type:" and >>"default:" >> specifiers of the current pattern by recursively applying the >>rules >> of this clause to each unmatched subarray." >> >> >>"Elements with a structure type that do not match any "index:", >>"type:", or >> "default:" specifier are assigned a new pattern consisting of >>just the >> "type:" and "default:" specifiers of the current pattern by >>recursively >> applying the rules for structure-valued assignment patterns >>(see 8.13.2)." >> >> >>An analogous edit for 8.13.2 should be pretty obvious. >> >>This is actually wordier than the C code needed to implement >>it. >>But we were too aggressive compressing it into a simple >>paragraph. >>So it's probably safer to lay it all out in tedious prose. >> >>As you can see, this longer version uses all of the clauses >>from >>the existing text and it captures the discussions we had in sv- >>bc >>committee during the several meetings devoted to resolving >>these >>issues. The key resolutions were: to consider the self- >>determined >>typee of the default specifiers, to use multiple context- >>determined >>evaluations of the default value expressions, to recurse into >>packed >>structure types, and to permit assignment coercions of scalar >>and simple bit vector types. It is not my intent to reconsider >>those choices - recall that they are rather intricately >>interrelated. >> >>Hope this helps, and sorry for my role in any confusion, >> >>Greg Jaxon >> >> >> >> >> >> >>>Then it says, >>>"For unmatched subarrays, ... For unmatched structure >> >>elements, ..." >> >>>These seem to talk about cases where none of the 3 conditions >> >>is met. But we said that an error is generated in that case. >> >>>Even if I am misreading the text, it means that the text is >> >>at best unclear. >> >>>Please clarify. >>> >>>8.13.2 has a similar problem. >>> >>> >>>Thanks, >>>Shalom > >Received on Mon Jan 2 10:29:14 2006
This archive was generated by hypermail 2.1.8 : Mon Jan 02 2006 - 10:30:09 PST