Issue with library ieee.std_logic_signed and Vivado 2017.4

[sacatak]

I've discovered a strange behaviour in upgrading a project between Vivado 2015.4 and 2017.4

For example for a simple counter in a vhdl file where I use the  ieee.std_logic_signed library, I've a different behaviour on target between the binaries generated with both versions.

The code is:

use ieee.std_logic_signed.all;
[...]
signal sCPT_ATO : std_logic_vector(31 downto 0) := (others => '0');
[...]
P_CPT_ATO : process(CLK_39Mhz) 
begin 
   if( rising_edge(CLK_39Mhz)) then 
      sCPT_ATO <= sCPT_ATO + '1'; 
   end if; 
end process;

• With Vivado 2015.4, on target the counter works as expected: it grows up
• With Vivado 2017.4, on target the counter decreases

What I've understood is that in Vivado 2017.4, the synthetizer probably use an sign extension between the std_logic '1' and the std_logic_vector(31:0) and add the value x"FFFFFFFF" to the counter

In Vivado 2015.4, it adds the value x"00000001"

I've used google to seach a solution and I've seen that people do not recommend to use this library.

I've a project of over 150 files and it could be time consuming to replace this library by another.

I've two questions:

1. Why Vivado doesn't synthetise the same result between versions?
2. Does an option exist to find the previous behaviour on Vivado 2017.4?

[richardhead · Accepted solution]

There are two issues here I see

1. The difference in behaviour between 2015..4 and 2017.4

2. The problem that std_logic_signed behaviour is not standardised anywhere, and is not part of the VHDL LRM (language reference manual ie. The VHDL standard).

But honestly, std_logic_signed has been around so long, most people just use the version provided by synopsys nearly 30 years ago. 

So while 1. is likely a bug, it's unlikely to get fixed because of 2). Plus also, most people are FINALLY migrating numeric_std (25 years after it's standardisation and release!!!)

Looking through the synopsys version of the library (if the vivado one is the same), then 2017.4 has a bug (as it appears to be following the Verilog way of doing things instead of the following signed conversion function):

function CONV_SIGNED(ARG: STD_ULOGIC; SIZE: INTEGER) return SIGNED is
	subtype rtype is SIGNED (SIZE-1 downto 0);
	variable result: rtype;
	-- synopsys built_in SYN_ZERO_EXTEND
	-- synopsys subpgm_id 380
    begin
	-- synopsys synthesis_off
	result := rtype'(others => '0');
	result(0) := MAKE_BINARY(ARG);
	if (result(0) = 'X') then
	    result := rtype'(others => 'X');
	end if;
	return result;
	-- synopsys synthesis_on
    end;

Here, conv_signed (this is from std_logic_arith - also a non-standard VHDL library whos used is definitely not recommended) should zero extend the bit, not sign extend it. I assume they forsaw the counters you are trying to implement.

Any reason you're using 2017.4 and not 2018.3? Does it exhibit the same behaviour.

Dont expect this to be fixed soon, and unless you're a big Xilinx customer, dont expect a patch for a legacy version of Vivado.

I also suggest you move to using numeric_std from now on, as it's behaviour is standardised.

[drjohnsmith]

personally, ieee.std_logic_signed should have been shot .....

I'd take the hit, and get rid of ieee.std_logic_signed .

The other thing for future, if you use unsigned for counters, then you can still do the + 1, and its still a defined size.

[sacatak]

I use Vivado 2017.4 because a supplier provide us part of the code with this version.