Re: [sv-bc] Signed after typedef

From: Greg Jaxon <Greg.Jaxon@synopsys.com>
Date: Thu May 22 2014 - 10:36:20 PDT
My recollections match Steve's.
Apparently some committee member could not carry signedness per-axis in their type system.

I don't recall a syntactic problem with this, unless it is somewhere essential to be able to distinguish
packed_dims from unpacked_dims in order to get LALR(1) grammars to work.
At the worst, one could define "signed [" and "unsigned [" as early reductions of the grammar
and admit a packed_or_unpacked_dims non-terminal that you'd disambiguate later in semantic rules.

No, I think the problem came from type systems, and possibly type-checking or typeinfo marshalling rules when
writing designs out in verilog netlist... Not a happy limitation, that's for sure.

Greg Jaxon

On 5/21/2014 4:41 PM, Steven Sharp wrote:

He isn’t trying to modify the signedness of T, or create a new type that is like T but with a different signedness.  He is trying to construct a packed array with elements of type T, and set the signedness of that new packed array type.

 

This is related to another deficiency in the language.  When you compose packed arrays of packed arrays, there is no way to independently control the signedness of each level.  The language only allows you to set the array to signed at one level.  You can declare an unsigned word that is an array of 4 signed bytes, or a signed word that is an array of unsigned bytes.  But there is no way to declare a signed word that is an array of signed bytes.

 

For the 2005 standard, Cadence proposed a syntax for declaring packed arrays that would allow separately specifying the signedness at each dimension. But nobody else seemed to understand what that meant, until after something had been standardized that was incompatible with it and it was too late.  It should still be possible to support it in a backward compatible way using typedefs for each level that needs to be signed, but it requires allowing the syntax Radoslaw is trying to use here, i.e.

 

typedef logic signed [7:0] mybyte;

typedef mybyte signed [3:0] myword; //signed word composed of signed bytes

 

 

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rich, Dave
Sent: Wednesday, May 21, 2014 5:13 PM
To: Bresticker, Shalom; Radosław Nawrot; 'SV_BC List'
Subject: RE: [sv-bc] Signed after typedef

 

And type T is implicitly unsigned. There are no rules to explain how you could override the signedness of a type.

 

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom
Sent: Wednesday, May 21, 2014 5:18 AM
To: Radosław Nawrot; 'SV_BC List'
Subject: RE: [sv-bc] Signed after typedef

 

I don't see that the BNF allows it.

 

type_identifier can be followed by packed_dimension, but I don’t see that it can be followed by 'signing'.

 

Shalom

 

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Rados?aw Nawrot
Sent: Wednesday, May 21, 2014 15:02
To: 'SV_BC List'
Subject: [sv-bc] Signed after typedef

 

Hi,

I have a code:

 

typedef reg T;
T signed [1:0] r;

 

Is it legal ?
I cannot find reason why nobody supports it

 

Regards,

Radek

 


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

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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


--
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 Thu May 22 10:36:35 2014

This archive was generated by hypermail 2.1.8 : Thu May 22 2014 - 10:36:51 PDT