Re: [sv-bc] Erratum and proposal in casting BNF

Stu,

I agree with you about concatenations and modifying their types,
but I don't believe that casting concatenations was the intent of
the '{} syntax.

Instead, I think the intent of the "tic-curlies" syntax was to
explicitly construct aggregate expressions, independent of the
surrounding context.

To achieve the effect of signing a concatenation, the '() syntax
can be used --

    if ( c < signed'({a,b}) )

Within a "tic-parens" cast, I think it's clear that any naked curlies
could only denote concatenation, so that for example, the following
would be illegal syntax

    if ( c < signed'({int:3}) )

Likewise, I believe that within a tic-curlies cast, the curlies always
denote an aggregrate expression, never a concatenation.

So the following would be legal syntax

    if ( c < signed'(T'{int:3}) )
     
-- Brad

-----Original Message-----
From: Stuart Sutherland [mailto:stuart@sutherland-hdl.com]
Sent: Tuesday, June 15, 2004 2:24 PM
To: Brad.Pierce@synopsys.COM; sv-bc@eda.org
Subject: RE: [sv-bc] Erratum and proposal in casting BNF

Brad,

I think casting the signedness of a concatenation does make sense. The
result of a concatenation is always unsigned, even if its members are
signed. If the concatenation is in a compound expression, I may still wish
to treat the msb of the resultant concatenation as a sign bit, instead of a
significant bit. E.g.:

  reg signed [31:0] a;
  reg [15:0] b;
  reg signed [47:0] c;

  if ( c < signed'{a,b} ) ...

I also consider it practical to resize the result of a concatenation, just
as with any expression. Casting the size gives me more control of the
vector widths used in compound expressions.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
503-692-0898

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Brad Pierce
> Sent: Monday, June 14, 2004 12:09 PM
> To: sv-bc@eda.org
> Subject: [sv-bc] Erratum and proposal in casting BNF
>
> I think that the following syntactic possibilities in the
> current BNF don't make semantic sense
>
> signed'{...}, unsigned'{...}, 13'{...}
>
> and that the original intent was for {}-style casts to
> always use an actual type, not one of the type modifiers.
>
> Attached is a proposal that would bring the BNF into alignment
> with that intent.
>
> -- Brad
>
>
Received on Tue Jun 15 15:01:46 2004