RE: [sv-ec] issues on queue syntax

Shalom,

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

If someone can provide an example of the *existing* queue
syntax that is ambiguous in some way, then we should 
review that.  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.

(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.)

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.