XST broken for XC9536?

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 . INFO:Xst:1799 - State stop is never reached in FSM . INFO:Xst:1799 - State data_1 is never reached in FSM . INFO:Xst:1799 - State data_2 is never reached in FSM . INFO:Xst:1799 - State data_3 is never reached in FSM . INFO:Xst:1799 - State data_4 is never reached in FSM .

and

WARNING:Xst:1710 - FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block . WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch (without init value) has a constant value of 0 in block .

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

Reply to
Andreas Ehliar
Loading thread data ...

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

Best regards Klaus Falser

Reply to
Klaus Falser

Seems to work on quartus 6.1

formatting link

Reply to
Mike Treseler

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

Reply to
cs_posting

seems okay in Synplicity and PrecisionRTL under ispLEVER - -

Reply to
mikeandmax

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.

Reply to
David R Brooks

Thanks, I'll recommend that to our students in the future.

/Andreas

Reply to
Andreas Ehliar

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

Reply to
Andreas Ehliar

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.