Re: [sv-bc] RE: Query related with signedness of an expression.

From: Greg Jaxon <Greg.Jaxon@synopsys.com>
Date: Fri Nov 16 2012 - 10:40:14 PST

Hi Dhiraj,

I hope the signed property is propagated through multilevel typedef.

Such a semantics would be surprising in any language, and requires a clear explanation in prose, and possibly a demonstration in an example.
Your hope is misplaced here.

, otherwise LRM does not mention following text:

The individual elements of the array are unsigned unless they are of a named type declared as signed.

The LRM text speaks precisely to the testcase in Dhiraj's question.
The individual elements of reg4 have the named type reg2; reg2 is declared as signed.

If the LRM had intended "propagation" here, it could have easily said
"If a packed array is declared as, or defaults to, unsigned, then the array viewed as a single vector shall be unsigned,
unless any element along any dimension has been declared as signed, or by this clause has inherited the signed property."
But it doesn't say anything close to that, and if you think about how unsigned propagates and poisons the signedness
of expressions in which it is used, it would seem mighty peculiar for the LRM to suddenly show any bias toward signed
vectors!

One facet of this definition that the LRM is not so clear about, but which I believe can be "hoped for" with more
basis is "A part-select of a packed array shall be unsigned." Certainly, part-select from a signed vector must discard
the signedness of the selected axis. But, just as certainly, the part-selected result var1[1:0] comprises two elements of named type reg2,
and both of these remain signed for the purposes of a "bit-select" var1[0].

Best regards,
Greg

 

Regards

Surya

 

From: Dhiraj Kumar Prasad [mailto:dhiraj@cadence.com]
Sent: 16 November 2012 14:09
To: Surya Pratik Saha; sv-bc@eda.org
Subject: RE: Query related with signedness of an expression.

 

Hello Surya,

 

Thanks and I have notice that section but the section says about packed array declaration. So will it be applicable for packed array declaration through multilevel typedef ??

 

as reg4 can’t be equivalent to ‘typedef reg signed [1:0][1:0] reg4_n;’  because in previous case var1[1] is signed but var1 declared with type of ‘reg4_n’, then var1[1] is unsigned.

 

Regards,

dhiRAj

 

 

 

 

From: Surya Pratik Saha [mailto:surya.pratik.saha@xilinx.com]
Sent: Friday, November 16, 2012 2:04 PM
To: Dhiraj Kumar Prasad; sv-bc@eda.org
Subject: RE: Query related with signedness of an expression.

 

Hi Dhiraj,

SV 2009 LRM mentioned (page 103):

If a packed array is declared as signed, then the array viewed as a single vector shall be signed. The individual

elements of the array are unsigned unless they are of a named type declared as signed. A part-select of a

packed array shall be unsigned.

 

Hence ‘var1’ has to be treated as signed.

 

Regards

Surya

 

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Dhiraj Kumar Prasad
Sent: 16 November 2012 13:57
To: sv-bc@eda.org
Cc: Dhiraj Kumar Prasad
Subject: [sv-bc] Query related with signedness of an expression.

 

Hello,

 

I have an query related with signedness of the expression.

 

Please see the following example

 

module top(output reg [7:0] out1);

 

typedef reg signed [1:0] reg2;

typedef reg2 [1:0] reg4;

 

reg4 var1;

 

always_comb

begin

        var1 = '1;

        out1 = var1;

end

endmodule

 

Here the var1 should be treated as signed or unsigned. I am seeing the different result in different standard tools. Some tool’s are assigning out1 with 8’b11111111 (treated as signed) while some other tools are assigning out1 with 8’b00001111.

 

So my query is should var1 be treated as signed or unsigned ??

 

Regards,

dhiRAj

 

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

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.



--
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 Fri Nov 16 10:40:55 2012