Can't determine definition of operator ""xor"

[knip]

I have the following type definitions

    subtype msgBlock_t is std_logic_vector((Z-1) downto 0);
    subtype msgBlock_u_t is unsigned((Z-1) downto 0);

    type msgBlocks_t is array((K_B-1) downto 0) of msgBlock_t;
    type msgBlocks_u_t is array((K_B-1) downto 0) of msgBlock_u_t;

    signal shMsgBlocks_u: msgBlocks_u_t;
    signal shMsgBlocks: msgBlocks_t;

I tried to convert the unsigned vector into a std_logic_vector using

shMsgBlocks = msgBlocks_t(shMsgBlocks_u);

but it doesn't work so now I'm using

        c_g: for i in 0 to K_B-1 generate
            c_g_i: shMsgBlocks(i) <= std_logic_vector(shMsgBlocks_u(i));
        end generate c_g;

but when I do a XOR operation:

    xor_L1: for i in 0 to (K_B/2)-1 generate
        xor_L1_i: out_xor_L1 <= shMsgBlocks(2*i) xor shMsgBlocks(2*i+1);
    end generate xor_L1;

the following error appears

Error (10327): VHDL error at lambda.vhd(112): can't determine definition of operator ""xor"" -- found 0 possible definitions

I know that std_logic_vector has to be used for memories/registers, while the unsigned type for binary numbers without sign.
I need to use the unsigned type in my circuit because of the rol (rotate left) function.
I cannot avoid to mix the two types.
What is better to do in these cases ?

 

[barry]

I think you've identified your problem: you can't use XOR with two different types. You need to convert one or the other. (Not sure if XOR works with both std_logic_vector and unsigned)

 

[TrickyDicky]

you can use unsigned just fine for memories and registers. Avoid std_logic_vector as much as possible where its not needed.

 

[knip]

Is it possible to use the xor operator for unsigned ?

 

[TrickyDicky]

yes it is.

You didnt show the definition of out_xor_L1

 

[knip]

subtype msgBlock_t is std_logic_vector((Z-1) downto 0);	
type xorL1_t is array ((K_B/2)-1 downto 0) of msgBlock_t;

 

[FvM]

Missing index for out_xor_L1? I guess you got confused with the various subtypes and types.

 

[knip]

I replaced all std_logic_vector with unsigned and I fixed that error. Now it compiles. The problem is that I have a very long vector as input (unsigned(323 downto 0)) and so the Fitter gave me an error because there are not enough pins. Can I store this vector in a pre-initiliazed register ? Or is there something else I can do to avoid this problem?

 

[mrflibble]

Or is there something else I can do to avoid this problem?

Yes. By not defining a 324 bit wide input into the fpga. One simple solution that will work and does not require me to understand the full details of your design is ... use a shift register to shift in this data. Since you ask if you can also use a pre-initialized register I am guessing the time it takes to shift in data is not going to be an issue.

 

[FvM]

I replaced all std_logic_vector with unsigned and I fixed that error.

Fine. But not plausible according to the information you gave. Most likely you changed another detail...

 

[barry]

you can use unsigned just fine for memories and registers. Avoid std_logic_vector as much as possible where its not needed.

Oftentimes the vendor IP tools will generate memories (and even math functions like accumulators) with std_logic_vector rather than signed or unsigned. Then you are stuck with having to convert.

And I've heard the warning to 'use unsigned rather than slv'. Why? It would seem to me that the tools are going to optimize everything anyway.

 

[FvM]

Oftentimes the vendor IP tools will generate memories (and even math functions like accumulators) with std_logic_vector rather than signed or unsigned. Then you are stuck with having to convert.

They are apparently trying to keep strict downwards compatibility to legacy designs, including their own junk IP that still uses Synopsis libraries internally. But it's easy to write wrappers around the vendor IP. Or put the conversion directly into the component instantation.

And I've heard the warning to 'use unsigned rather than slv'. Why? It would seem to me that the tools are going to optimize everything anyway.

In terms of gate level logic, signed/unsigned is just a bit vector as well. Which unwanted optimization should take place that doesn't occur for std_logic_vector?

 

[TrickyDicky]

Oftentimes the vendor IP tools will generate memories (and even math functions like accumulators) with std_logic_vector rather than signed or unsigned. Then you are stuck with having to convert.

I meant creating memories by inference. At least with quartus you can infer a ram from any bit type (signed, unsigned, std_logic_vector, ufixed and sfixed) plus also constrained integers.
So why use unsigned over std_logic_vector? well thats the whole point of strong typing. If you dont like the type system, go to verilog.

 

[barry]

So why use unsigned over std_logic_vector? well thats the whole point of strong typing. If you dont like the type system, go to verilog.

WHAT'S the whole point of strong typing? I've seen this "mandate" many times, but never a good explanation. I can't see any difference in operations on unsigned vs slv.

 

[TrickyDicky]

Re: Can't determine definition of operator ""xor"

With strong typing, you can often convey your intent without having to explain in the code.
With SLV, lets say you have 3 SLVs, one carrying an unsigned value, one a signed, and a 3rd just a bus. There is no way to tell this without context or commenting. With strong typing this information is placed with the declaration, so it should be clear isntantly what it's doing.

If strong typing, you are first forced to ensure all items are the correct type, so some errors are picked up by the compiler that would be allowed through in other languages. This is why there arnt really any serious linting tools for VHDL, as its quite difficult to force something with VHDL.

- - - Updated - - -

Also, with SLV arithmatic, without specific typing, its a bit of a pain in the arse and long winded to do signed and unsigned arithmatic in the same file.