05-11-2020 10:16 PM
I have found a bug concerning assignment to aggregates. The assignment fails when one of the target signals has a width of 0.
Here is an example I have been testing on:
library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity EXAMPLE is generic( WIDTH : natural := 8 ); port( CLK : in std_logic; IN_A : in std_logic_vector(WIDTH-1 downto 0); IN_B : in std_logic_vector(WIDTH-1 downto 0); OUT_A : out std_logic_vector(WIDTH+1-1 downto 0); OUT_B : out std_logic_vector(0-1 downto 0) ); end entity; architecture FULL of EXAMPLE is signal result : unsigned(WIDTH+1-1 downto 0); begin my_process : process (CLK) begin if (rising_edge(CLK)) then result <= ("0" & unsigned(IN_A)) + ("0" & unsigned(IN_B)); (OUT_A, OUT_B) <= std_logic_vector(result); end if; end process; end architecture;
This code should correctly calculate the sum of IN_A and IN_B and propagate the result to OUT_A. However, in the aggregate assignment Vivado (2019.1.1) synthesis incorrectly evaluates the width of OUT_B as 2 and the result of is signal OUT_A is actually 'OUT_A <= "00" & result(WIDTH+1-1 downto 2)'.
This is the result of synthesis:
05-11-2020 11:12 PM
As far as i know the definition of std_logic_vector is :
type std_logic_vector is array (natural range <> ) of std_logic;
And therefore OUT_B : out std_logic( -1 downto 0 ) is illegal.
05-11-2020 11:57 PM
There seems to be an issue in the handling of null type ports when used in aggregate slices. Simulation mismatch can be seen in a simple assignment-
(OUT_A, OUT_B) <= ("1" & IN_A);
I will keep you posted on my findings further.
05-12-2020 02:59 AM
I suspect its related to Vivado's bad handling of port ranges - see the following bug report
While std_logic_vector is ranged with a natural, the VHDL standard allowed any index if the range results a null range. So -ve values here are allowed. It means you can have a standard genericed port map and allow 0 length and not give an elaboration error.
generic ( W : natural;
port ( ip : in std_logic_vector(W-1 downto 0);
05-12-2020 06:10 AM
This is an issue with handling on null ranges and I have filed bug report for this. This issue will be fixed in future release.