RE: [sv-bc] 8.13.1 Array assignment patterns

Sorry, please ignore. I did not read your mail carefully enough.

But probably LRM should have an example and clarification of that point.

Shalom

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Bresticker, Shalom
> Sent: Sunday, January 08, 2006 4:14 PM
> 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
> > >
> > >