Re: warning:impact:2217 error shows in the status register, CRC Error Bit is NOT 0. - on clocks.

On Apr 11, 10:57 am, "Antti.Luk...@xxxxxxxxxxxxxx"
<Antti.Luk...@xxxxxxxxxxxxxx> wrote:
On Apr 11, 5:50 pm, jleslie48 <j...@xxxxxxxxxxxxxxxxxx> wrote:



On Apr 11, 9:20 am, "Antti.Luk...@xxxxxxxxxxxxxx"

<Antti.Luk...@xxxxxxxxxxxxxx> wrote:
On Apr 9, 10:34 pm, jleslie48 <j...@xxxxxxxxxxxxxxxxxx> wrote:

Ok here's the story.

I developed a message stream using a 32Mhz clock fpga putting out 64
bits asynchronously using a dividing the clock by 8*2_000_000 (where
2_000_000 is the baud rate, I know that's very fast for a baud rate)
to get the sample rate for the bits. this resulted in a 2.00000
perfect divisor for the sampling rate for the comm line.

I switched to a 40Mhz clock fpga, and with keeping the 8 and 2_000_000
numbers constant, my previous perfect divisor for the sampling rate
now shifts to 40M/(8*2M) == 2.5, and a bad drift occurs. So I think
no problem lets just use 10 samples per bit rather than 8 thus
changing the formula to 40M/(10*2M) == 2.000 and all will be fine
again.

And low and behold, Testbench confirms all is well. Now heres the
problem, when I try and load this program onto the Spartan 3 chip, it
dies. with the above warning and the chip needs a power reset.
Leaving the value of 10 in the sampling rate I can change the program
from working to non working by playing with the following:

-- Listing 7.3

-- JL 090309 changing hard coded '15' to (sb_tick-1) for length of
-- each bit. hard coded '7' for databits now (dbit-1) as
well.
-- JL 090312 custom version of uart_tx for the 2mhz comm link.

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity uart40_tx is
generic(
DBIT: integer:=64; -- # data bits
SB_TICK: integer:=10 -- # ticks for each bit
);
port(
clk,
reset : in std_logic;
tx_start : in std_logic;
s_tick : in std_logic;
din : in std_logic_vector((dbit-1) downto 0);
tx_done_tick : out std_logic;
tx : out std_logic
);
end uart40_tx ;

architecture arch of uart40_tx is
type state_type is (idle, start, data, stop);

constant go_high : std_logic := '1';
constant go_low : std_logic := '0';

signal state_reg, state_next: state_type;
signal s_reg, s_next: unsigned(7 downto 0);
signal n_reg, n_next: unsigned(7 downto 0);
signal b_reg, b_next: std_logic_vector((dbit-1) downto 0);
signal tx_reg, tx_next: std_logic;
signal bit_length: std_logic := '0'; -- testbench watching
only. use with d
begin
-- FSMD state & data registers
process(clk,reset)
begin
if reset='1' then
state_reg <= idle;
s_reg <= (others=>'0');
n_reg <= (others=>'0');
b_reg <= (others=>'0');
tx_reg <= go_high;
elsif (clk'event and clk='1') then
state_reg <= state_next;
s_reg <= s_next;
n_reg <= n_next;
b_reg <= b_next;
tx_reg <= tx_next;
end if;
end process;
-- next-state logic & data path functional units/routing
process(state_reg,s_reg,n_reg,b_reg,s_tick,
tx_reg,tx_start,din)
begin
state_next <= state_reg;
s_next <= s_reg;
n_next <= n_reg;
b_next <= b_reg;
tx_next <= tx_reg ;
tx_done_tick <= '0';
case state_reg is
when idle =>
tx_next <= go_low;
if tx_start='1' then
state_next <= start;
s_next <= (others=>'0');
b_next <= din;
end if;
when start =>
tx_next <= go_high;
if (s_tick = '1') then
if s_reg=(sb_tick-1) then --(A)
state_next <= data;
s_next <= (others=>'0');
n_next <= (others=>'0');
else
s_next <= s_reg + 1;
end if;
end if;
when data =>
tx_next <= b_reg(0);
if (s_tick = '1') then
if s_reg=(sb_tick-1) then --(A)
bit_length <= not bit_length; -- measure a bit.
s_next <= (others=>'0');
b_next <= '0' & b_reg((dbit-1) downto 1) ;
if n_reg=(DBIT-1) then
state_next <= idle; -- stop ; --lets skip the
stop bit.
tx_done_tick <= '1'; -- moved in from
stop
else
n_next <= n_reg + 1;
end if;
else
s_next <= s_reg + 1;
end if;
end if;
when stop =>
tx_next <= go_high;
if (s_tick = '1') then
if s_reg=(SB_TICK*4-1) then -- lets make it stick out
for now.
state_next <= idle;
tx_done_tick <= '1';
else
s_next <= s_reg + 1;
end if;
end if;
end case;
end process;
tx <= tx_reg;
end arch;

-----------------------------------------------------------------

Now the above has perfect results in the testbench, but crashes the
fpga on a real load. For a while I never got any message, but now I'm
getting the

warning:impact:2217 error shows in the status register, CRC Error Bit
is NOT 0.

as a pop-up window on the PC when I load the software via Impact.

if I replace the two occurances of this line:

(A) if s_reg=(sb_tick-1) then

with this:

(B) if s_reg=(sb_tick-2) then

I no longer crash the fpga and all loads up fine and runs, albiet my
message is no longer running at the
right rate.

I'm scratching my head as to what causes the error in the (A)
situation that is not there in the (B) situation.

Any insight greatly appreciated.

Sincerely,

Jonathan Leslie

IF small change in FPGA code causes the bitstream load CRC error to
"come and go", then:

1) bad and faulty FPGA - very unlikely
2) power supply issue VCCINT - more likely
3) xilinx tools generating bad bitfile - very unlikely

in theory, NO MATTER you write in the VHDL, it CAN NOT make the CRC
error during download to happen.

hm idea.. use USERCLOCK as startup clock

it may make the CRC error to go away or not

Antti

Its definitely in the vhdl code. I change the VHDL code, and I change
the results.

very strange. If this was a C program, I'd say this is similar to a
divide by zero execution.

I re-wrote the entire routine without the 8 or 10 looping iterations,
and I get the results I want so the crisis is over, but it still bugs
me that I can lock up my entire FPGA with code that I wrote.

I still have no idea why making the loop iterate 10 times vs 9 would
result in such catastrophic failure

I even tried leaving it looping 9 times, and then putting an interim
state to make the 9th iteration last for two clock cycles, it still
would not run. That test changed my thinking to the 9,10 doesn't
directly cause the problem, but rather that driving the signal is
somehow messed up on the 10th cycle. Again nothing unusual shows up
on the "behavior" test bench. I don't know how to use the place and
route simulation, or whether or not modelsim will show the error.

nothing that ANY simulation could ever show can have any relevance
to the CRC error during configuration

Antti

when I first encountered the error, I didn't get a CRC error. It
simply would load the program,
and then my heartbeat led would not blink, I got no response from any
of my other outputs,
and I could no longer communicate to the FPGA until I recycled power
on the board.

.

Relevant Pages

  • Re: Newbie PCB
    ... I've done it with the FPGA trainer boards with Xilinx chips, ... different power planes,... ... 50 ohms impedance on clock traces _hopefully_ only applies ...
    (comp.arch.fpga)
  • Re: How to add some SDRAM to a FPGA board ?
    ... I think that it is possible with the FPGA that I use, ... clock you need to match trace length/impedence on all the pins from FPGA ... wired directly between the power and ground pins. ... that it's possible to downclock SDRAM chips, ...
    (comp.arch.embedded)
  • Re: Frequency synthesis
    ... is not a power of two division of the input frequency. ... accumulator's width and the divider. ... Another interesting point with baud rate dividers is the standard ... use of the 16x clock for receiving. ...
    (comp.lang.verilog)
  • Re: 0805 size high power resistors, 250mW ok on FR-4?
    ... coming on board, so prices will drop. ... In that second pic I posted, we thought that the FPGA (under the blue ... were looking into clock gating and tedious stuff like that. ... Suppose a power rail is collapsed. ...
    (sci.electronics.design)
  • Re: Decoupling for Altera Cyclone II 2C8
    ... FPGA, or at least the first one that's made it as far as actual PCBs ... I/O routing is probably a non-issue at these frequencies; clock routing ... I'd be looking at 22 capacitors to find space for... ... with power supply, capacitors to ground on both sides). ...
    (comp.arch.fpga)