Re: [sv-ec] RE: [sv-bc] Question on 'Unpacked array concatenation'

hi Surya

> I did not get the answer of my question - whether
> 'Unpacked array concatenation' is considered as
> aggregate expression or not, as comparison etc.
> will be allowed or not on that.

I believe the answer is unequivocally "no".

When writing Mantis 1702 I did my best to be not only
unambiguous but also reasonably conservative so that the
new unpacked array concatenation would be implementable. 
Draft 8 clause 10.10 says

  An unpacked array concatenation may appear as the 
  source expression in an assignment-like context, 
  and shall not appear in any other context.

So, for example...

  typedef int A3[3];
  function bit compare(A3 x,y);
    return (x==y);
  endfunction
  ...
  A3 a;
  a = {1, 2, 3}; // OK, assignment-like
  if (a == {1, 2, 3}) ...  // illegal
  if (compare(a, {1,2,3})) ... // OK

To answer your question about multiple dimensions,
clause 10.10 carefully talks about the "slowest-varying
dimension" everywhere, making it clear that the unpacked
array concatenation effectively thinks of its target as
a one-dimensional array.  Because it must appear in an
assignment-like context, the type of the target and the
type of its slowest-varying dimension's elements are 
both perfectly well known.

If we were to use some different syntax for unpacked array
concatenation, then we would invalidate large amounts
of legacy code that uses queues.  The current proposal
legitimizes the old queue syntax and also provides a 
very helpful new feature, the ability to construct unpacked
array values from a mixture of elements and slices. 
Continuing the example above:

  a = {a[1:2], a[0]};  // OK, yields a == '{2,3,1};

This should now work for any unpacked array, not just
for queues, and is useful for many applications.

Clause 10.10.3 tries to clarify the use of both unpacked 
array concatenation and assignment patterns in more
complicated situations.

If I contrived to write a proposal that is unimplementable,
then obviously I sincerely apologize and we need to do
something about it.  But I don't believe that to be the
case, and I took considerable trouble to circumscribe the
proposal so that it had the minimum of unexpected side-effects.

As far as your "bad experience" with tool transition to 
assignment patterns is concerned, it's worth bearing in 
mind that assignment patterns were desperately needed 
to fix some very serious ambiguities with concatenation
syntax;  it would have been unbearable to leave things
as they were, without '{}.  But the introduction of
assignment patterns messed-up queues, and several of
us felt the strong need to do something about it.
Assignment patterns are now well-supported by all the
mainstream tools, as far as I can tell.

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

Thismessage may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.