RE: [sv-bc] Signed after typedef

I agree that Radoslaw seems to be bringing up a different issue.

As you say, a "bit select" (actually an array indexing operation) into a packed array could return either signedness, based on the element type.

A part select is extracting a set of adjacent bits that may not correspond to any declared element type, signed or unsigned.  The rules fall back on always treating these as unsigned.  Instead of your "ugly" suggestion for a signed part select, users can simply use a $signed() or signed`() cast to convert a part select to signed if they really want to.

Perhaps Radoslaw is calling an array indexing operation on a packed array a "part select", because it can give the same result of selecting a block of adjacent bits.  Such an array indexing operation can produce a signed value.  But that is not a part select.  The LRM is talking about actual part selects, with a range.  Those are always unsigned.


From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
Sent: Thursday, May 22, 2014 1:44 PM
To: Radosław Nawrot; Steven Sharp; 'Rich, Dave'; 'Bresticker, Shalom'; 'SV_BC List'
Subject: Re: [sv-bc] Signed after typedef

On 5/22/2014 2:35 AM, Radosław Nawrot wrote:

7.4.1 Packed arrays

"

A partselect

of a packed array shall be unsigned.

"
Should be removed

Thanks,
Radek
This is an altogether different issue!
Bit select (actually single element extraction) can already return either signedness.
In fact, it can return any element type you've used.

Here's an ugly proposal:
Allow " { left : right ] " to either declare or to part-select access a signed packed dimension.

The mnemonic here is that the sign-extension rule affects the leftmost bits, thus the squishier bracket ;-)
Wouldn't that cross your eyes trying to match brackets?  I'll bet the emacs syntax coloring fans would throw a fit!

Greg Jaxon

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