The message "signed to unsigned conversion occurs" in Design Compiler Environment

[Wei Luo]

Dear all,

I have a question about Verilog synthesis. A warning message "signed to unsigned conversion occurs..." always appears when I used Design Compiler to synthesize my Verilog module. The code and warning messages are shown below:
--------------------------------------------------
module PartialProdGen(out, A, B);
parameter BITWIDTH = 16;
input [BITWIDTH - 1 : 0] A, B;
output [BITWIDTH * BITWIDTH - 1 : 0] out;
wire [BITWIDTH * BITWIDTH - 1 : 0] out;

generate
genvar i, j;

for(i = 0; i < BITWIDTH; i = i + 1)
begin: gen_1
for(j = 0; j < BITWIDTH; j = j + 1)
begin: gen_2
assign out[BITWIDTH * i + j] = A[j] & B[i];
end
end
endgenerate
endmodule
-------------------------------------------------
Warning: Starting with the 2000.11-1 release, the Presto Verilog reader treats Verilog 'integer' types as signed; synthesized result may not match earlier versions of HDL Compiler. (VER-314)
Warning: /homes/mccc/DV_WORK4/source_code/PartialProdGen.v:17: signed to unsigned conversion occurs. (VER-318)
Warning: /homes/mccc/DV_WORK4/source_code/PartialProdGen.v:16: signed to unsigned conversion occurs. (VER-318)
-------------------------------------------------
The first warning also looks weird. The constant BITWIDTH declared by parameter and genvar variable could be the integer mentioned in the warning? Can someone help me explain this? Thanks in advance!

[GaborSzakacs]

Any constant not otherwise sized or specified is treated as a 32-bit
integer. So a parameter with an assignment to an integer is considered
an integer. Also anywhere you use a constant like 1 in an expression
theoretically gets converted as required. Most synthesis tools are
quiet about the conversions because it is well documented and
predictable. In your case it looks like the only integers would
be your genvars, the constant 1 and the BITWIDTH parameter. In this
case the need for conversion is not obvious to me. Also the warnings
are attached to lines 16 and 17, and I can't figure out where that falls
in the code you posted.

--
Gabor

[Wei Luo]

在 2014年10月20日星期一UTC-5上午10时19分01秒，gabor写道：

Thank you for reply, Gabor.
Sorry for the unclear statement. I posted the code again below,
--------------------------------------------------
01>module PartialProdGen(out, A, B);
02> parameter BITWIDTH = 16;
03> input [BITWIDTH - 1 : 0] A, B;
04> output [BITWIDTH * BITWIDTH - 1 : 0] out;
05> wire [BITWIDTH * BITWIDTH - 1 : 0] out;
06>
07> generate
08> genvar i, j;
09>
10> for(i = 0; i < BITWIDTH; i = i + 1)
11> begin: gen_1
12> for(j = 0; j < BITWIDTH; j = j + 1)
13> begin: gen_2
14> assign out[BITWIDTH * i + j] = A[j] & B[i];
15> end
16> end
17> endgenerate
18>endmodule

-------------------------------------------------
Warning: Starting with the 2000.11-1 release, the Presto Verilog reader treats Verilog 'integer' types as signed; synthesized result may not match earlier versions of HDL Compiler. (VER-314)
Warning: /homes/mccc/DV_WORK4/source_code/PartialProdGen.v:17: signed to unsigned conversion occurs. (VER-318)
Warning: /homes/mccc/DV_WORK4/source_code/PartialProdGen.v:16: signed to unsigned conversion occurs. (VER-318)
-------------------------------------------------

And I can't understand what the problem is in my code then. Thanks!

[Gabor]

Honestly it looks like a warning you can ignore. As far as I
can see, the only potentially signed variables are the genvars
i and j. Nowhere is there a need that I can see to convert
to unsigned. i.e. out[i] can use the integer (signed) i
as a bit select even though out itself is unsigned. Also the
fact that the lines referenced by the warnings are "end"
and "endgenerate" seems to show that even the tools couldn't
figure out where the conversion was necessary.

--
Gabor

[Wei Luo]

在 2014年10月20日星期一UTC-5下午7时28分52秒，gabor写道：

Hi Gabor,
I ignored the warnings and do further simulations using the synthesized module. It worked good and I saw no problem about that. Actually, if I remove the "BITWIDTH" statement in generate block and change it into real number ("16"), the last two warnings will disappear, but the first one is still there. In general, I can ignore this and have a good result. Thanks a lot!

[rickman]

On 10/20/2014 4:48 PM, Wei Luo wrote:
>

Being more of a VHDL user, I am not overly fluent in Verilog. Perhaps
you could explain to me what this line means.


--

Rick

[rickman]

On 10/20/2014 4:48 PM, Wei Luo wrote:
>

Fat fingered the first post.

Being more of a VHDL user, I am not overly fluent in Verilog. Perhaps
you could explain to me what this line means.

output [BITWIDTH * BITWIDTH - 1 : 0] out;

I would read this as BITWIDTH "squared" minus 1 downto 0. Or does the
'*' character have a special meaning in this context? I'm assuming the
intention is to have a bus twice as wide as the BITWIDTH parameter.

--

Rick

[Gabor]

You are correct, this is BITWIDTH squared minus 1. And the nested loops
actually fill in all BITWIDTH squared output bits. The name of the
module seems to imply multiplication, but it actually just does a lot
of bitwise ANDs to form partial products. Presumably another module
will reduce these (using addition) to a final product of just 2 times
BITWIDTH.

--
Gabor

[rickman]

Yes, of course. I didn't even look to see what the code did. It has
two nested loops, so n^2 iterations.

Curious about the warnings. I expect there is something different about
the i,j variables and the BITWIDTH parameter. One defaults to a signed
and the other to an unsigned. Does Verilog have explicit type casts or
type conversions?

The other warning about the compiler not working the same as earlier
versions is one that I don't need to see every time I compile a file.
The VHDL tools I use do similar things and the P&R tools generate lots
of warnings that have nothing to do with my code. Synthesis generates
modules for the FPGA that include unneeded outputs, like a carry on an
adder. When the P&R tools strips them out it generates warnings as if
some of your own code is being stripped out. A royal PITA to check
every time. Warnings are there for a reason and need to be checked. If
it warns me something I didn't ask for was taken out, that is of no value.

--

Rick

[GaborSzakacs]

Verilog has very well defined behavior when using mixed types, although
unlike VHDL it doesn't require explicit conversion funcions or
libraries. The standard should require that a genvar which is not
otherwised sized or typed will be an integer (32-bits signed). That's
why the two additional warnings bothered me. i.e. there should have
been no need to go from signed to unsigned when using BITWIDTH with
these genvars. One possibility is that parameter BITWIDTH, which
should have taken on the integer type due to the assignment to an
integer constant, was actually given an unsigned type by the
compiler. In any case, since the values are all positive, there
would be no reason for any change in behavior due to the signed to
unsigned conversion regardless of where it actually happened. And
of course the fact that the lines referenced by the warnings had no
actual code in them (just ends) makes it hard to tell where the
conversion occured.

> The other warning about the compiler not working the same as earlier
> versions is one that I don't need to see every time I compile a file.
> The VHDL tools I use do similar things and the P&R tools generate lots
> of warnings that have nothing to do with my code. Synthesis generates
> modules for the FPGA that include unneeded outputs, like a carry on an
> adder. When the P&R tools strips them out it generates warnings as if
> some of your own code is being stripped out. A royal PITA to check
> every time. Warnings are there for a reason and need to be checked. If
> it warns me something I didn't ask for was taken out, that is of no value.
>

The warning that remains about the compiler versions is probably
appropriate if there were a lot of designs that relied on the
previous incorrect compiler behavior, especially since it would
potentially change the behavior of the synthesized logic. One
would hope that future versions would remove this warning. Xilinx
would call this an "info" rather than a warning.

Xilinx tools, which also do what you describe (adding their own stuff
and later stripping it out with warnings) at least allow you to filter
warnings that you've already seen, so you don't need to go through
the whole list on the next build.

--
Gabor