XST bug here ??

[info_]

Hello,

I stumbled on something weird while fitting one of my
Tornado exercises on a Xilinx board...
Worked fine with other synthesis tools, but wouldn't
with XST. By dichotomy, I think I caught the culprit :
a simple signed adder !?
IMO, it should sign-extend the 6 bits into 7 bits,
then add and produce a 7 bits vector. Having a look
at the RTL view didn't look too good to me :-(
I used ISE 6.3.03i.

Anyone any idea ?
I may have missed something obvious.

-- Bert

-- ----------------------------------------
-- XSR synthesis bug ?
-- (simplified code for debug purpose)
-- contact : info at alse-fr dot com
-- Author : Bert Cuzeau

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;

-- ---------------------------------------
Entity XST_BUG is
-- ---------------------------------------
Port ( Clk : In std_logic; -- Main System Clock
Rst : In std_logic; -- Asynchronous reset, active high
Addr1 : in unsigned (5 downto 0); -- for simple test
(std_logic_vector)
Addr2 : in unsigned (5 downto 0); -- for simple test
(std_logic_vector)
ToneV : out signed (6 downto 0) ); --for simple test
(std_logic_vector)
end;

-- ---------------------------------------
Architecture RTL of XST_BUG is
-- ---------------------------------------

subtype s6_t is integer range -32 to 31;
subtype s7_t is integer range -64 to 63;
type Sinewave_t is array (0 to 63) of s6_t; -- (natural range <>) in fact

constant Sinewave : Sinewave_t := (
0, 3, 6, 8, 11, 14, 17, 19,
21, 23, 25, 27, 28, 29, 30, 30,
31, 30, 30, 29, 28, 27, 25, 23,
21, 19, 17, 14, 11, 8, 6, 3,
0, -3, -6, -8, -11, -14, -17, -19,
-21, -23, -25, -27, -28, -29, -30, -30,
-31, -30, -30, -29, -28, -27, -25, -23,
-21, -19, -17, -14, -11, -8, -6, -3 );
-- Note : This table could be optimized (4 times shorter...)

signal Tone1 : s6_t;
signal Tone2 : s6_t;
signal Tone : s7_t;

begin

ToneV <= to_signed(Tone,ToneV'length);

-- F1 / F2 Tone
process (Rst,Clk)
begin
if Rst='1' then
Tone <= 0;
elsif rising_edge (Clk) then
-- PROBLEM MIGHT BE LOCATED BELOW :
Tone <= Sinewave(to_integer(Addr1)) + Sinewave(to_integer(Addr2));
-- note : 6 bits + 6 bits -> 7 bits (... but not for XST ???)
-- for some reason, the Adder's Carry Out seems lost...
-- works fine with Quartus, Precision synthesis...
end if;
end process;

end RTL;

 

[info_]

It definitely looks like a bug !
I did a post-layout simulation comparison vs RTL and it's no good.
Note that I haven't check with ISE 7.1. We will probably still stay
for a little while with the mature 6.3.03i, since we have complex
Virtex 2V6000 projects under maintenance -which work

Thx for letting me know if 7.1 does fix this.

-- tb_xst_bug.vhd
-- ----------------------------------------
-- Self-Verifying Testbench for XST bug
-- ----------------------------------------
-- (c) ALSE - Bert Cuzeau
--
-- Compares Post-layout simulation model vs RTL model
-- no good :-(
-- (don't forget to wipe out the entity section in the post-layout simulation model)
--
-- Simu.do file for ModelSim :
-- ---simu.do-----------
-- # Don't compile those below with ModelSim XE !!!!
-- #vlib simprim
-- #vcom -work simprim D:/Xilinx/vhdl/src/simprims/simprim_Vpackage_mti.vhd
-- #vcom -work simprim D:/Xilinx/vhdl/src/simprims/simprim_Vcomponents_mti.vhd
-- #vcom -work simprim D:/Xilinx/vhdl/src/simprims/simprim_VITAL_mti.vhd
-- #vcom -work simprim D:/Xilinx/vhdl/src/simprims/simprim_SMODEL_mti.vhd
-- vlib work
-- vcom xst_bug.vhd
-- vcom xst_bug_timesim.vhd
-- vcom TB_xst_bug.vhd
-- vsim -sdftyp /uut2=xst_bug_timesim.sdf -t ps tb_xst_bug
-- add wave clk
-- add wave -radix hexadecimal tonev1
-- add wave -radix hexadecimal tonev2
-- add wave -radix hexadecimal addr2
-- add wave -radix hexadecimal addr1
-- add wave okay
-- run -a
-- ------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.numeric_std.all;

entity TB_xst_bug is
end TB_xst_bug;

architecture TBX_ARCH of TB_xst_bug is

constant Period : time := 100 ns; -- 10 MHz to play safe with timings

signal Rst : STD_LOGIC;
signal Clk : STD_LOGIC := '0';
signal ToneV1 : signed ( 6 downto 0 );
signal ToneV2 : signed ( 6 downto 0 );
signal Addr2 : unsigned ( 5 downto 0 );
signal Addr1 : unsigned ( 5 downto 0 );
signal Done : boolean;
signal Okay : boolean := true;

begin

-- Clock and Reset generation
Clk <= '0' when done else not CLK after Period / 2;
Rst <= '1', '0' after Period;

-- Test exhaustively with on-the-fly comparison
process
begin
Addr1 <= (others=>'0');
Addr2 <= (others=>'0');
for i in 0 to 63 loop
for j in 0 to 63 loop
wait until Clk = '0';
Okay <= ToneV1 = ToneV2;
assert ToneV1 = ToneV2 report "Timing Model mismatch vs RTL !" severity error;
Addr1 <= to_unsigned(i,Addr1'length);
Addr2 <= to_unsigned(j,Addr2'length);
end loop;
end loop;
Done <= true;
wait;
end process;

-- instanciate the RTL "golden" model
UUT1 : entity work.xst_bug(RTL)
port map (
Rst => Rst,
Clk => Clk,
ToneV(6) => ToneV1(6),
ToneV(5) => ToneV1(5),
ToneV(4) => ToneV1(4),
ToneV(3) => ToneV1(3),
ToneV(2) => ToneV1(2),
ToneV(1) => ToneV1(1),
ToneV(0) => ToneV1(0),
Addr2(5) => Addr2(5),
Addr2(4) => Addr2(4),
Addr2(3) => Addr2(3),
Addr2(2) => Addr2(2),
Addr2(1) => Addr2(1),
Addr2(0) => Addr2(0),
Addr1(5) => Addr1(5),
Addr1(4) => Addr1(4),
Addr1(3) => Addr1(3),
Addr1(2) => Addr1(2),
Addr1(1) => Addr1(1),
Addr1(0) => Addr1(0)
);

-- instanciate the Post-Layout Simulation Model
UUT2 : entity work.xst_bug(Structure)
port map (
Rst => Rst,
Clk => Clk,
ToneV(6) => ToneV2(6),
ToneV(5) => ToneV2(5),
ToneV(4) => ToneV2(4),
ToneV(3) => ToneV2(3),
ToneV(2) => ToneV2(2),
ToneV(1) => ToneV2(1),
ToneV(0) => ToneV2(0),
Addr2(5) => Addr2(5),
Addr2(4) => Addr2(4),
Addr2(3) => Addr2(3),
Addr2(2) => Addr2(2),
Addr2(1) => Addr2(1),
Addr2(0) => Addr2(0),
Addr1(5) => Addr1(5),
Addr1(4) => Addr1(4),
Addr1(3) => Addr1(3),
Addr1(2) => Addr1(2),
Addr1(1) => Addr1(1),
Addr1(0) => Addr1(0)
);

end TBX_ARCH;

 

[info_]

I have reported the bug to Xilinx support, no news so far.
I think the table (rom) does somehow "hide" the nature of the
data to XST which "forgets" one bit in the adder.

I'll post a follow up if/when I receive feedback.

 

[info_]

This has been acknnowledged by Xilinx tech support as a bug which
they said got fixed in version 7.1. (I didn't double-check).

Bert Cuzeau