RE: [sv-ec] Queue delete() method

No, I said the items in an unpacked array concatenation are not
self-determined. I said they were either in the context of an array
element, or an unpacked array of elements. 

You can think of it like bit-streaming, but there's no reason to
restrict this to bit-stream types. We're streaming unpacked array
elements into a single unpacked array dimension.

Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda-stds.org [mailto:owner-sv-ec@server.eda-
> stds.org] On Behalf Of Brad Pierce
> Sent: Tuesday, August 08, 2006 2:02 PM
> To: sv-ec@server.eda-stds.org
> Subject: Re: [sv-ec] Queue delete() method
> 
> A major difference between an assignment pattern and a concatenation
is
> that operands of an assignment pattern are evaluated in the contexts
of
> assignments to the corresponding elements on the left-hand side.
> 
> Given
> 
>      struct packed {logic [2:0] x; logic [1:0] y;} t;
> 
> the following assignment
> 
>      t = '{ 1'b1 << 2, 1'b1 << 2 };
> 
> has the same effect as
> 
>      t = {3'b001 << 2, 2'b01 << 2};
> 
> or
>      t = 5'b10000;
> 
> and not the same effect as
> 
>      t = { 1'b1 << 2, 1'b1 << 2 };
> 
> which would fill t with 0's.
> 
> Are the operands of a queue concatenation evaluated in a
self-determined
> context and the results bit-streamed in?
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-ec@eda-stds.org [mailto:owner-sv-ec@eda-stds.org] On
> Behalf Of Rich, Dave
> Sent: Tuesday, August 08, 2006 1:43 PM
> To: sv-ec@eda-stds.org
> Subject: RE: [sv-ec] Queue delete() method
> 
> 
> As I tried to argue a year ago when the ' (tick) was introduced in an
> assignment pattern, there are simulators even today that don't require
> the tick and in places don't even allow it. I think the committee
needs
> to accept this syntax and work towards finding the proper language to
> describe it.
> 
> {} is not an assignment pattern, it is a concatenation of an unpacked
> array with 0 elements. Each item in a concatenation may be of the
> destination array element type, or any unpacked array type of the
> destination array element type. All of the elements are recombined
into
> single dimension of the destination array type. If a fixed sized
array,
> the number of elements must match the size of the dimension, otherwise
> the array is resized to match the number of elements.
> 
> I think the two main problems we had trying to find the right language
> to describe this was
> a) Detailing the cases where {} might be ambiguous and generating an
> error.
> b) Determining the context of {} when nested. Since each item of an
> unpacked concatenation could be either an array element type or an
array
> of array element types. I think we could of just made a simple rule
that
> said that a nested {} could only be of the array element type.
> 
> Dave
> 
> 
> > -----Original Message-----
> > From: owner-sv-ec@server.eda-stds.org
[mailto:owner-sv-ec@server.eda-
> > stds.org] On Behalf Of Bresticker, Shalom
> > Sent: Friday, August 04, 2006 5:17 AM
> > To: sv-ec@server.eda-stds.org
> > Subject: RE: [sv-ec] Queue delete() method
> >
> > Doubly interesting.
> > So far as I can see, you can't have an empty assignment pattern. See
> > Syntax 8-2.
> > This would mean, for example, that you cannot clear a dynamic array
by
> 
> > assignment of an empty array literal.
> >
> > As previously pointed out many times, a problem specific to queues
> with
> > both {} and '{} is the use of a syntax like "q = { q, 6 };". In all
> > other types of arrays, that would be a literal of two elements,
where
> > the first is q and the second is 6, and not a shortcut for writing a
> > concatenation of all the elements of q.
> >
> > Finally, I also note that the sentence, "Unlike arrays, the empty
> queue,
> > {}, is a valid queue and the result of some queue operations," as
> > worded, says that empty dynamic and associative arrays are not
valid,
> > which is not the case.
> >
> > Shalom
> >
> > > -----Original Message-----
> > > From: owner-sv-ec@server.eda-stds.org
> [mailto:owner-sv-ec@server.eda-
> > > stds.org] On Behalf Of Steven Sharp
> > > Sent: Friday, August 04, 2006 12:04 AM
> > > To: sv-ec@server.eda-stds.org; Brad.Pierce@synopsys.com
> > > Subject: RE: [sv-ec] Queue delete() method
> > >
> > >
> > > >From: "Brad Pierce" <Brad.Pierce@synopsys.com>
> > >
> > > >The nonterminal "empty_queue" is defined as "{}" in A.8.1, and
used
> > in
> > > >"primary_literal" in  A.8.4.
> > >
> > > Interesting point.  So {} as an empty queue is not arising as the
> > > degenerate case of this undefined queue concatenation operation.
> > > It is specified as a separate thing.  And there is even normative
> > > text defining it in 5.14:
> > >
> > > "The empty array literal {} is used to denote an empty queue."
> > >
> > > The problem is that {} is not the empty array literal, so this
> > > statement is self-contradictory.  The empty array literal would
now
> > > be '{}.
> > >
> > > The text clearly states the intent to use the empty array literal,
> > > and refers to the old syntax for an empty array literal.  This
> > > appears to be a case where the syntax was not updated when the
array
> 
> > > literal syntax was changed.  This sentence should be updated to
the
> > > new syntax of '{}, as should empty_queue in A.8.1 and the attached
> > > note.
> > >
> > > I presume that the reason this is specified specially is that an
> > > empty assignment pattern is not normally legal.  Is that true?
> > > If so, then the purpose of this text in 5.14, and the empty_queue
> > > production in A.8.1 is to say that it is legal in the special case
> > > of an assignment pattern of type queue.  Or maybe empty array
> literals
> > > used to be illegal in older BNF, even if empty assignment patterns
> > > are legal in the current BNF.
> > >
> > > So I conclude that even if the special queue concatenation
operation
> 
> > > were defined, you would still have to use '{} for the empty queue.
> > >
> > > Steven Sharp
> > > sharp@cadence.com
> 
>