Reply by Andreas Ehliar●February 26, 20072007-02-26
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 by Andreas Ehliar●February 5, 20072007-02-05
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
Reply by David R Brooks●February 2, 20072007-02-02
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.
Reply by ●February 2, 20072007-02-02
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 - -
Reply by ●February 2, 20072007-02-02
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
I think you really found a bug in XST.
Switch FSM Extraction to "none" and it seems to work.
Best regards
Klaus Falser
Reply by Andreas Ehliar●February 2, 20072007-02-02
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;