Different VHDL-interpretation between Xilinx ISE/ModelSimXE?

If have been experimenting with VHDL in ModelSim XE, and made a design (a
DeltaSigma-modulator) that works and simulates properly. I tried putting it
all into Xilinx ISE (the webpack) to synthesise it to get an idea about how
to do it. However, the VHDL that worked in ModelSim does not work unchanged
in Xilinx, and i have no clue why. Any help is appreciated. Here is the line
of code that is causing the problem:

sumx <= std_logic_vector(signed(X1C1) + signed(X2C2) + signed(X3C3));

The three input signals and sumx are of type std_logic_vector. This works
fine in ModelSim but when running "Check Syntax" process in Xilinx, it
complains about the following:

ERROR:HDLParsers:3329 -
"D:/Profil/Skrivebord/Delt/P9/CRFB1/CascadeElement.vhd" Line 80. Expression
in type conversion to std_logic_vector has 2 possible definitions in this
scope, for example, SIGNED and std_logic_vector.

In the top of the file i have these definitions:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

I was told to use numeric_std (no one can provide good arguments), and so i
did. However, in one other entity, which i instantiate in this entity, i
internally use std_logic_arith because the resize-function in numeric_std
doesn't work "correctly" (the conv_signed in std_logic_arith does). All
entity ports are declared as std_logic_vector and signed types are only used
inside entities. I have a suspicion that this is causing the problem - but
why can ModelSim do it ? Is there a way to explicitly tell Xilinx which
conversion/arithmetic functions to use, when it cannot decide by itself? Or
is the root to this problem to be found elsewhere?

Thomas Thorsen

Thomas Thorsen wrote:

> ERROR:HDLParsers:3329 -
> "D:/Profil/Skrivebord/Delt/P9/CRFB1/CascadeElement.vhd" Line 80. Expression
> in type conversion to std_logic_vector has 2 possible definitions in this
> scope, for example, SIGNED and std_logic_vector.

I expect that Modelsim has it right, but
errors like the above can result from user
defined vector types or subtypes.
Use only signed, unsigned or std_logic_vector for vectors.

> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.numeric_std.all;

That should be all you need.

> I was told to use numeric_std (no one can provide good arguments),

The best argument is that it is an IEEE standard
while std_logic_arith is not. However both are
widely used and supported.

> However, in one other entity, which i instantiate in this entity, i
> internally use std_logic_arith because the resize-function in numeric_std
> doesn't work "correctly" (the conv_signed in std_logic_arith does).

I disagree that there is any problem.
Here is the discussion. You can decide for yourself:
http://groups.google.com/groups/sear...signed+rushton
In any case, you might try backing out std_logic_arith to
see if it solves your problem.

> Is there a way to explicitly tell Xilinx which
> conversion/arithmetic functions to use, when it cannot decide by itself?

There is no decision to be made.
The library and use clauses make the selection.

> Or is the root to this problem to be found elsewhere?

I would bet on either a code or an ISE problem.
You might get a second opinion from the free quartus download.

And here are some more resize examples.
http://groups.google.com/groups/sear...+resize+signed

Good luck.

-- Mike Treseler

Mike Treseler

"Mike Treseler" <> skrev i en meddelelse
news:...
> Thomas Thorsen wrote:
>
>> ERROR:HDLParsers:3329 -
>> "D:/Profil/Skrivebord/Delt/P9/CRFB1/CascadeElement.vhd" Line 80.
>> Expression in type conversion to std_logic_vector has 2 possible
>> definitions in this scope, for example, SIGNED and std_logic_vector.
>
> I expect that Modelsim has it right, but
> errors like the above can result from user
> defined vector types or subtypes.
> Use only signed, unsigned or std_logic_vector for vectors.

I solved the problem by using a type qualifier:

sumx <= std_logic_vector(signed'(signed(X1C1) + signed(X2C2) +
signed(X3C3)));

This removes the ambiguity and both Xilinx and ModelSim accepts it. However,
i found out that if i used std_logic_arith instead, i could reduce it all
to:

sumx <= signed(X1C1) + signed(X2C2) + signed(X3C3);

since this package defines so many different add-functions that it can
actually output a std_logic_vector from the second add-operation (while
using a function that returns a signed from the first add).

I like that, but still i'm being told to use numeric_std that doesn't have
this nice abundant supply of different operators.

>> However, in one other entity, which i instantiate in this entity, i
>> internally use std_logic_arith because the resize-function in numeric_std
>> doesn't work "correctly" (the conv_signed in std_logic_arith does).
>
> I disagree that there is any problem.
> Here is the discussion. You can decide for yourself:
> http://groups.google.com/groups/sear...signed+rushton
> In any case, you might try backing out std_logic_arith to
> see if it solves your problem.

Well, i don't think there's a "problem", i just think the way conv_signed
std_logic_arith works is more intuitive than resize in numeric_std. If you
want the sign-preservation-behaviour (and i agree with Andrew Rushton that
it is odd behaviour), you can easily emulate it:

res = X(X'left) & conv_signed(X,res'length-1);

>> Is there a way to explicitly tell Xilinx which conversion/arithmetic
>> functions to use, when it cannot decide by itself?
>
> There is no decision to be made.
> The library and use clauses make the selection.

Well, i found (in Andrew Rushtons excellent book) that using type qualifiers
is a very effective (but not very readable) solution for indirectly
specifying which function to use.

> And here are some more resize examples.
> http://groups.google.com/groups/sear...+resize+signed

The figures in Rushton's book says it all!

Thomas Thorsen