FPGARelated.com
Forums

XST broken for XC9536?

Started by Andreas Ehliar February 2, 2007
I was a TA for an introductory VHDL lab yesterday and
I encountered a very weird problem. In the source code
included below I get the following interesting messages
from XST when I try to synthesize the file:

INFO:Xst:1799 - State start is never reached in FSM <stage>.
INFO:Xst:1799 - State stop is never reached in FSM <stage>.
INFO:Xst:1799 - State data_1 is never reached in FSM <stage>.
INFO:Xst:1799 - State data_2 is never reached in FSM <stage>.
INFO:Xst:1799 - State data_3 is never reached in FSM <stage>.
INFO:Xst:1799 - State data_4 is never reached in FSM <stage>.

and

WARNING:Xst:1710 - FF/Latch  <timer_3> (without init value) has a constant value of 0 in block <transmitter>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch  <timer_2> (without init value) has a constant value of 0 in block <transmitter>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch  <timer_1> (without init value) has a constant value of 0 in block <transmitter>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch  <timer_0> (without init value) has a constant value of 0 in block <transmitter>.

Personally I cannot see any reason why stage shouldn't leave
the waiting state. On the other hand I might just have missed
something blindingly obvious. If I simulate the design in
ModelSim it does leave the waiting state immediately. I don't
get any such messages if I try to synthesize to for example a
Virtex 4.

The sad thing is that this is the first time the students were
exposed to Xilinx tools and VHDL and I fear that the first
impression wasn't very good :(

In ISE 7.1, 8.1, and 9.1 for Linux xst gives the same warnings.
ISE 6.3 for Solaris does not emit any warning however.
8.1 for Windows also gives the warnings about the timer but I
haven't double checked that they give the same INFOs for the
stage signal.

Do we have to go back to ISE 6.3 to have functioning XC9536
support?

I guess this posting is mainly a way to vent some irritation,
but I do hope that someone at Xilinx sees this because the
last time I tried to report a possible bug to Xilinx my
request for a webcase account was denied. (At that time they
referred me to the University program forums and I never
got any useful reply to my message.)

/Andreas

------------------------------------------------------
-- The following code has been modified somewhat
-- by removing as much stuff as possible while still
-- retaining the problematic code.
------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity transmitter is
    port( clk: in std_logic;
                reset: in std_logic;
                debug:out std_logic_vector(1 downto 0));
end transmitter;

architecture arch of transmitter is
    type state is (waiting, start, data_1, data_2, data_3, data_4, stop);
    signal stage: state;
    signal timer: std_logic_vector(3 downto 0);
begin

    process(clk)
    begin
        if rising_edge(clk) then
            
            timer <= timer+1;

            if ((stage=waiting)) then
                timer<="0000";
                stage<=start;
            elsif timer="1111" then
                if stage=stop then                 stage <= waiting;
                elsif stage=start then stage <= data_1;
                elsif stage=data_1 then stage <= data_2;
                elsif stage=data_2 then stage <= data_3;
                elsif stage=data_3 then stage <= data_4;
                elsif stage=data_4 then stage <= stop;
                end if;
            end if;


            if reset='1' then
                timer<="0000";
                stage<=waiting;
            end if;
        end if;
    end process;
    
    debug(1) <= '0' when stage=waiting else '1';
    debug(0) <= timer(3); 

end arch;

I think you really found a bug in XST.
Switch FSM Extraction to "none" and it seems to work.

Best regards
Klaus Falser

Seems to work on quartus 6.1

http://home.comcast.net/~mike_treseler/transmitter.pdf
On Feb 2, 5:42 am, Andreas Ehliar <ehl...@isy.liu.se> wrote:

> timer <= timer+1; > > if ((stage=waiting)) then > timer<="0000"; > stage<=start;
(unrelated portion removed)
> end if; > > if reset='1' then > timer<="0000"; > stage<=waiting; > end if;
It doesn't seem to solve the problem, and there may be some obscure language "rule" for disambiguation, but I don't like seeing what appear to be three different attempts to assigned a value to the timer register. Wouldn't it be better practice to "else" them? If (reset)... elsif(waiting)... else
On Feb 2, 5:42 am, Andreas Ehliar <ehl...@isy.liu.se> wrote:
> I was a TA for an introductory VHDL lab yesterday and > I encountered a very weird problem. In the source code > included below I get the following interesting messages > from XST when I try to synthesize the file:
seems okay in Synplicity and PrecisionRTL under ispLEVER - -
cs_posting@hotmail.com wrote:
> On Feb 2, 5:42 am, Andreas Ehliar <ehl...@isy.liu.se> wrote: > >> timer <= timer+1; >> >> if ((stage=waiting)) then >> timer<="0000"; >> stage<=start; > (unrelated portion removed) >> end if; >> >> if reset='1' then >> timer<="0000"; >> stage<=waiting; >> end if; > > > It doesn't seem to solve the problem, and there may be some obscure > language "rule" for disambiguation, but I don't like seeing what > appear to be three different attempts to assigned a value to the timer > register. > > Wouldn't it be better practice to "else" them? If (reset)... > elsif(waiting)... else >
Within a process (as this is), that's explicitly valid VHDL. The statements are defined to execute sequentially, leaving the signal set to the value given by the last statement executed.
On 2007-02-02, Klaus Falser <kfalser@IHATESPAMdurst.it> wrote:
> I think you really found a bug in XST. > Switch FSM Extraction to "none" and it seems to work.
Thanks, I'll recommend that to our students in the future. /Andreas
I just wanted to post an update to this problem. I was contacted by
someone from Xilinx technical support some time ago and I just got a
confirmation that they are investigating the cause of this issue. 
The recommended workaround is to turn off FSM extraction.

1 point to Klaus for recommending the same workaround shortly after I
submitted the original posting :)

/Andreas