RE: [sv-ec] issues on queue syntax

Hi, Jonathan.

You have some nice suggestions.

Just for the record, most of the description in 1702 is simply quotes
from the old issues and not my own opinions.

Having said that, the existing LRM is certainly confusing. It certainly
implies that queues use the same or similar syntax to that of arrays.

Consider:

5.14 appears in the clause on arrays.

1.6 says, "Clause 5 describes SystemVerilog arrays, including packed and
unpacked arrays, dynamic arrays, associative arrays, queues, and various
array methods," calling queues arrays.

4.16 says, "A bit-stream type is a type consisting of the following:
... - Dynamically sized arrays (dynamic, associative, or queues) of any
of the above types".

5.1 says, "A queue type of array grows or shrinks to accommodate
the number of elements written to the array at run time."

5.2 says, "If an unpacked array has one or more dynamic, associative, or
queued dimensions, it is considered a variable-size array."

5.14 says, "Thus, like arrays, queues can be manipulated using the
indexing, concatenation, slicing operator syntax, and equality
operators." (As pointed out in the Mantis, while arrays did use the
concatenation syntax in SV 3.1a, this is no longer true in 1800.)

5.14.1 says, " Queues and dynamic arrays have the same assignment and
argument passing semantics. Also, queues support the same operations
that can be performed on unpacked arrays and use the same operators and
rules except as defined below:..."

Add to that the fact that up to and including SV 3.1a, both arrays and
queues used the concatentation syntax, and that any dimension of an
unpacked array can be a queue dimension, and it certainly seems clear
that queues were intended to use the same assignment syntax as arrays.

Even if you added a concatenation syntax to queues, it would still have
to support the regular assignment pattern syntax. While possible, it is
confusing. 

However, I recognize that the assignment pattern syntax has a problem
with queues, so I am willing to support any reasonable solution.

You yourself recognize the need for some clarifications and
enhancements, implying that the current LRM does not quite work.

A few comments inside:

> > I filed a new Mantis 1702 on queue syntax.
> > The purpose of this issue is simply to put together
> > all the related issues 412, 517-521, and 801 into a
> > single issue, with the proposal to close those 6 and
> > just leave 1702.
> 
> That is great, but reading your commentary (pace your
> note about Dave Rich's dissent) it seems that you take it
> as a foregone conclusion that queue expressions should be
> written using the assignment pattern syntax.  It seems to
> me that this is not at all self-evident.
> 
> Apart from the backward-compatibility issues involved
> (queues have been around for a long time) there is a

[SB] Arrays were around a long time also.

> big problem if we wish to continue to be able to support
> something like
> 
>   q = {expr1, q1, expr2, q2, expr3};
> 
> since at present the assignment pattern syntax offers no
> way to replicate this behaviour.  As we have discussed
> before, it could do so only if there were some way to
> describe the operation of array flattening, so that we
> could explode q1 and q2 (in my example) into the equivalent
> of comma-separated lists of their elements:
> 
>   q = '{expr1, $explode(q1), expr2, $explode(q2), expr3};
> 
> Since this ability to concatenate in arbitrary ways is a
> key benefit of queues, it is not acceptable to give it up.

[SB] I think something like $explode is a great idea. It would be useful
for all types of arrays, not just queues, and in many contexts (e.g.,
$display).

> 
> If someone can provide an example of the *existing* queue
> syntax that is ambiguous in some way, then we should
> review that.  

[SB] But without the note that you suggest below, the existing syntax IS
ambiguous, because concatenations do not work that way. See Mantis 412,
for example.

> But in the absence of such a counter-example,
> it seems to me that queue-concatenation is easy enough to
> define, and it remains useful.  All that's needed is to
> note that when {,,,} appears in a queue context it's
> to be handled thus:
> - any item in the concatenation whose type is assignment-
>   compatible with the context's element type should be
>   considered an element of the queue expression;
> - any item that is a one-dimensional unpacked array, or
>   queue, of such type should be flattened and treated as
>   a comma-separated list of its elements, this flattening
>   to be limited to only one dimension;
> - it is an error for the concatenation to contain items
>   of any other data type.

[SB] What is the definition of a 'queue context'? Remember that
expressions can have complex sub-expressions of many types.

> 
> (I think my second point contains a new extension, since
> it allows any kind of unpacked array - not just a queue -
> to be copied to a queue.)

[SB] A good idea.

Shalom


> 
> If you want a true bitwise concatenation to appear in
> a queue, you would need another nested set of braces:
> 
>   int q[$] = { {2'b11, 2'b00} };
> 
> declares a queue of ints and initializes it to
> contain one element whose value is 12.
> 
> OK, so where might it go wrong?  Anywhere you try to use
> queue concatenation syntax without there being a queue-like
> context from which it can infer its data type:
> 
>   if ( {1,2,3} == {1,2,3} ) ...
> 
> is clearly bad syntax, but how about this?
> 
>   typedef int IntQ[$];
>   ...
>   if ( IntQ'({1,2,3}) == {1,2,3} ) ...
> 
> There are things you can do with '{} syntax that you can't
> do with queue concatenation syntax: specifically, replication
> and setting defaults.
> 
> The lack of defaults is OK.  In an assignment pattern
> it's the assignment target that determines the size of the
> array being written, and so it makes good sense to have
> defaults.  But in a queue, the number of elements is determined
> by the concatenation, not by the target.  So it makes no
> sense to specify a default, since there is nothing to say
> how many elements should be defaulted!
> 
> Replication is a little more vexatious.  I can readily
> imagine that I would like to be able to write
> 
>   int q[$] = {32{0}};
> 
> or somesuch.  I don't think it's a good idea to go there,
> because it would bog us down in the same nonsense about
> brace-stripping that we suffered before assignment patterns
> were created.  Anyhow, if you accept my suggestion about
> coercing arrays to queues, you could write
> 
>   int q[$] = { '{32{0}} };
> 
> so that the inner assignment pattern is treated as an
> unpacked array of 32 ints.
> 
> --
> Jonathan Bromley, Consultant
> 
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
> 1AW, UK
> Tel: +44 (0)1425 471223                   Email:
> jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web:
> http://www.doulos.com
> 
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.