Re: [sv-bc] 8.13.1 Array assignment patterns

Yes, but this is not a problem because the only term that
requires a self-determined type is the expression you supply to
a "default:" clause.  But these expressions cannot be typeless
assignment patterns because default correspondences are NOT
"assignment-like contexts" (see 8.13).  This allows default values
to correspond to subcomponents of slightly different (singular)
types without opening the flood gates to full assignment patterns.
Default '{}s would become "puns" as they attempted to construct
various unrelated substructures.

Defaults are values in search of a suitable context (and the search
is recursive in the type structure).  They do not impose a particular
type context on the value unless it is a "good" match.  The only
good matches between aggregate-types are those given by section 6.9.1.
But for simple bit vector types, 6.9.3 assignment compatibility
is good enough.  "Default: '{ ... }"  is simply a syntax error.

One issue that's clumsy to define - but not difficult to
implement - is that the "self-determined" type here only
gets used by the "matching" step of the pattern.  If the default
expression is written as a simple bit vector, then it actually
evaluates in the context of the type of the receiving field.
Those cases continue to act like context-determined expressions
following all the (supposedly familiar) Verilog rules.

When you set out to implement those Verilog rules, you must
propagate type information both UP from subexpressions to parent
operators, and also DOWN, carrying maximum widths out to the
leaf operands.  At the halfway point of this, you have in hand
the top level "self-determined type".  The implementation must
finish the "matching" step of the assignment pattern before
the downward propagation of the type info - exactly what you
already do to implement Verilog assignment (the "match" in that
case being trivial).  This is why they are called assignment patterns.

Greg Jaxon

Bresticker, Shalom wrote:
> Greg,
> 
> Both the current text and your proposed text refer to the
> self-determined type of the value, but 8.13 states that assignment
> patterns do not have a self-determined type.
> 
> Shalom
> 
> 
> 
>>-----Original Message-----
>>From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
>>Sent: Monday, January 02, 2006 8:25 PM
>>To: Bresticker, Shalom
>>Cc: sv-bc@eda.org
>>Subject: Re: [sv-bc] 8.13.1 Array assignment patterns
>>
>>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
>>>
>>>