RE: [sv-bc] Musings on array assignment compatibility

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Tue Jun 02 2009 - 14:35:46 PDT
I think there's another problem with using casts for this copying element-by-element: they are too easy to confuse with bit-stream casts. Generally, redundant casts do not change the semantics of the assignments, but a generalized (redundant) cast that changes from bit-stream cast to element-by-element copy would.
I was thinking that there's another option: add a specialized cast form such as:

        b = foreach'(a);

IMHO this makes it very clear what the intent is.

        Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of jonathan.bromley@doulos.com
Sent: Tuesday, June 02, 2009 9:07 AM
To: sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-bc] Musings on array assignment compatibility

Gord wrote:

> I think I prefer (4).  I could live with (5) but
> I like the "obviousness" of (4).  If array assignments
> require equivalent types in all but one case, I
> really prefer to make that case very obvious.  Using
> an explicit $cast is a pretty clear indication that
> the user understands that there is a special assignment
> rule in play.

OK.  That's important.

> That also avoids a double assignment
> in cases when you want to do a converting assignment.

>        int   a[100];
>        byte  b[100];
>        byte  c[];
>
>        initial  $cast(b,a);

Yes, but that's unhelpful for coercion across a
port connection or subprogram argument, where $cast
requires that you create an additional variable.

>       initial begin
>          c = new[100](a);
>          b = c;
>       end

Alternatively:

  typedef byte bq[$];
  initial c = bq'(a);  // assignment-like cast

I know that's kinda convoluted, using a queue as an
intermediate step between two fixed-size arrays, but
it has the considerable advantage that it's just an
expression - and, with careful choice of the typedef
name, it could easily be made quite self-evident.
It doesn't help for output port connections, though,
where something like VHDL's type conversion function
across a port mapping would be neat.

I'm not disagreeing with you, but I'm concerned about
the risk of creating something that is too clumsy
to be widely acceptable.

Thanks.
--
Jonathan Bromley
Consultant

Doulos - Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * 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                        http://www.doulos.com
--------------------------------------------------------------------------------
Doulos Ltd is registered in England and Wales with company no. 3723454
Its registered office is 4 Brackley Close, Bournemouth International
Airport, Christchurch, BH23 6SE, UK.

This message may contain personal views which are not the views of
Doulos, unless specifically stated.


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


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jun 2 14:36:43 2009

This archive was generated by hypermail 2.1.8 : Tue Jun 02 2009 - 14:39:22 PDT