Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > XST bug here ??

Reply
Thread Tools

XST bug here ??

 
 
info_
Guest
Posts: n/a
 
      03-26-2005
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;


 
Reply With Quote
 
 
 
 
info_
Guest
Posts: n/a
 
      03-26-2005
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;
 
Reply With Quote
 
 
 
 
info_
Guest
Posts: n/a
 
      03-30-2005
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.
>

 
Reply With Quote
 
info_
Guest
Posts: n/a
 
      04-03-2005
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Anyone can check if XST v11 has fixed this bug ? Bert_Paris VHDL 4 06-06-2009 11:42 AM
*bug* *bug* *bug* David Raleigh Arnold Firefox 12 04-02-2007 03:13 AM
FF with CE doesn't synthesize correctly by XST? MM VHDL 16 09-28-2003 01:43 AM
XST fails to recognize FSM with registered outputs E. Backhus VHDL 2 07-25-2003 07:48 AM
XST Process Failure Jeremy Pyle VHDL 0 07-14-2003 04:35 AM



Advertisments