[sv-bc] RE: Mantis 1526, 1709

Shalom,

My knowledge of which data types are compatible with which is much
less detailed than yours, but as far as I can see we already have
this one covered.  Please feel free to explain very slowly and
monosyllabically if I'm wrong.

> >    It shall be an error to use a streaming_concatenation as an
> >    operand in an expression without first casting it to a bit-stream
> >    type. When a streaming_concatenation is used as the source of an
> >    assignment, the target of that assignment shall be either a data
> >    object of bit-stream type or a streaming_concatenation.
> 
> I think this text leaves an ambiguity that I was just asked about.
> 
> 6.24.3 defines bit-stream types as including unpacked arrays, but I
> believe you can't assign a streaming concatenation, which is a packed
> type, to an unpacked array without a bit-stream cast

But the immediately subsequent paragraph of the 1707 proposal says...

> If the target is a data object of bit-stream type, the stream
> created by the source streaming_concatenation shall be
> implicitly cast to the type of the target.

I don't see why that is either ambiguous or wrong for an unpacked target.

> 7.6 says, "A packed array cannot be directly assigned to an unpacked
> array without an explicit cast."

Yes, indeed, but the streaming_concatenation is not a packed array; 
it's a very special thing unto itself, and (I hope) the rules in the
new 1707 proposal say exactly what you can and can't do with it.

> The original text was a little clearer by referring to a bit-stream
> "variable".

That was an unhappy choice for things like 

   wire [15:0] my_bus = {>>{...}};

hence my somewhat ponderous use of "data object of bit-stream type".

> But both the original and new text say, "If the target represents a
> dynamically sized variable, such as a queue or dynamic array, the
> variable is resized to accommodate the entire stream," and these are
> unpacked arrays, not singular variables.

Agreed, but an unpacked array can be a bit-stream type, surely?
-- 
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.

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