Re: [sv-bc] 8.13.1 Array assignment patterns

Shalom,

The value in a default:value cannot be an assignment pattern, because
the following is not an assignment-like context --

   "A default correspondence between an expression in an assignment
pattern and a field or element in a data object or data value"

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Sunday, January 08, 2006 6:14 AM
To: Greg Jaxon
Cc: sv-bc@eda.org
Subject: RE: [sv-bc] 8.13.1 Array assignment patterns

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
> >
> >