On Apr 11, 4:29 pm, Mike Treseler <mtrese...@gmail.com> wrote:
> jleslie48 wrote:
> >>> I developed a message stream using a 32Mhz clock fpga ...
> >>> I switched to a 40Mhz clock fpga,
> > I still have no idea why making the loop iterate 10 times vs 9 would
> > result in such catastrophic failure.
>
> Maybe the failure is due to increasing the clock frequency.
> What does static timing say about Fmax?
>
>     -- Mike Treseler

Ok here's the current status.

The CRC error seems to be some kind of switch in the iMPACT download
facility, when I load directly from the
Boundary Scan in ISE10.1, I don't get the CRC error.   However I still
lock up the FPGA.

I dumped the offending code, re-wrote it completely, and the problem
went away...  so I thought.

I figured the way I was handling the timing of the signal was the
issue, and resolved myself with the idea that my redo of the transmit
routine avoided whatever issue I was having.

so now I move on, and I take my output signal (a 2mhz digital signal)
and decide to repeat its output on a new pin; so I add a new pin to
the .UCF file, add the label to the port, and attach my 2mhz signal to
the new pin, and guess what?

I lock up my FPGA again.  Something very weird is going on.  I started
a new thread where there are more details on this issue.  look for the
title:

" fpga locks up with slow signal, spartan chip, pin type issues."

jleslie48 wrote:

>>> I developed a message stream using a 32Mhz clock fpga ...
>>> I switched to a 40Mhz clock fpga, 

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

Maybe the failure is due to increasing the clock frequency.
What does static timing say about Fmax?


    -- Mike Treseler

On Apr 11, 10:57 am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Apr 11, 5:50 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On Apr 11, 9:20 am, "Antti.Luk...@googlemail.com"
>
> > <Antti.Luk...@googlemail.com> wrote:
> > > On Apr 9, 10:34 pm, jleslie48 <j...@jonathanleslie.com> 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.

On Apr 11, 5:50=A0pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Apr 11, 9:20 am, "Antti.Luk...@googlemail.com"
>
>
>
> <Antti.Luk...@googlemail.com> wrote:
> > On Apr 9, 10:34 pm, jleslie48 <j...@jonathanleslie.com> 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. =A0this 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_00=
0
> > > numbers constant, my previous perfect divisor for the sampling rate
> > > now shifts to 40M/(8*2M) =3D=3D 2.5, and a bad drift occurs. =A0So I =
think
> > > no problem lets just use 10 samples per bit rather than 8 thus
> > > changing the formula to 40M/(10*2M) =3D=3D 2.000 and all will be fine
> > > again.
>
> > > And low and behold, Testbench confirms all is well. =A0 Now heres the
> > > problem, when I try and load this program onto the Spartan 3 chip, it
> > > dies. =A0with 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 =A0 changing hard coded '15' to (sb_tick-1) for length o=
f
> > > -- =A0 =A0 =A0 =A0 =A0 =A0 each bit. hard coded '7' for databits now =
(dbit-1) as
> > > well.
> > > -- JL 090312 =A0 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
> > > =A0 =A0generic(
> > > =A0 =A0 =A0 DBIT: integer:=3D64; =A0 =A0 -- # data bits
> > > =A0 =A0 =A0 SB_TICK: integer:=3D10 -- # ticks for each bit
> > > =A0 =A0);
> > > =A0 =A0port(
> > > =A0 =A0 =A0 clk,
> > > =A0 =A0 =A0 reset =A0 =A0 =A0: in std_logic;
> > > =A0 =A0 =A0 tx_start =A0 : in std_logic;
> > > =A0 =A0 =A0 s_tick =A0 =A0 : in std_logic;
> > > =A0 =A0 =A0 din =A0 =A0 =A0 =A0: in std_logic_vector((dbit-1) downto =
0);
> > > =A0 =A0 =A0 =A0 =A0 tx_done_tick =A0: out std_logic;
> > > =A0 =A0 =A0 =A0 =A0 tx =A0 =A0 =A0 =A0 =A0 =A0: out std_logic
> > > =A0 =A0);
> > > end uart40_tx ;
>
> > > architecture arch of uart40_tx is
> > > =A0 =A0type state_type is (idle, start, data, stop);
>
> > > =A0 =A0constant go_high : std_logic :=3D '1';
> > > =A0 =A0constant go_low =A0: std_logic :=3D '0';
>
> > > =A0 =A0signal state_reg, state_next: state_type;
> > > =A0 =A0signal s_reg, s_next: unsigned(7 downto 0);
> > > =A0 =A0signal n_reg, n_next: unsigned(7 downto 0);
> > > =A0 =A0signal b_reg, b_next: std_logic_vector((dbit-1) downto 0);
> > > =A0 =A0signal tx_reg, tx_next: std_logic;
> > > =A0 =A0signal bit_length: std_logic :=3D '0'; =A0 =A0 -- testbench wa=
tching
> > > only. =A0use with d
> > > begin
> > > =A0 =A0-- FSMD state & data registers
> > > =A0 =A0process(clk,reset)
> > > =A0 =A0begin
> > > =A0 =A0 =A0 if reset=3D'1' then
> > > =A0 =A0 =A0 =A0 =A0state_reg <=3D idle;
> > > =A0 =A0 =A0 =A0 =A0s_reg <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0n_reg <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0b_reg <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0tx_reg <=3D go_high;
> > > =A0 =A0 =A0 elsif (clk'event and clk=3D'1') then
> > > =A0 =A0 =A0 =A0 =A0state_reg <=3D state_next;
> > > =A0 =A0 =A0 =A0 =A0s_reg <=3D s_next;
> > > =A0 =A0 =A0 =A0 =A0n_reg <=3D n_next;
> > > =A0 =A0 =A0 =A0 =A0b_reg <=3D b_next;
> > > =A0 =A0 =A0 =A0 =A0tx_reg <=3D tx_next;
> > > =A0 =A0 =A0 end if;
> > > =A0 =A0end process;
> > > =A0 =A0-- next-state logic & data path functional units/routing
> > > =A0 =A0process(state_reg,s_reg,n_reg,b_reg,s_tick,
> > > =A0 =A0 =A0 =A0 =A0 =A0tx_reg,tx_start,din)
> > > =A0 =A0begin
> > > =A0 =A0 =A0 state_next <=3D state_reg;
> > > =A0 =A0 =A0 s_next <=3D s_reg;
> > > =A0 =A0 =A0 n_next <=3D n_reg;
> > > =A0 =A0 =A0 b_next <=3D b_reg;
> > > =A0 =A0 =A0 tx_next <=3D tx_reg ;
> > > =A0 =A0 =A0 tx_done_tick <=3D '0';
> > > =A0 =A0 =A0 case state_reg is
> > > =A0 =A0 =A0 =A0 =A0when idle =3D>
> > > =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_low;
> > > =A0 =A0 =A0 =A0 =A0 =A0 if tx_start=3D'1' then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state_next <=3D start;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s_next <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_next <=3D din;
> > > =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 =A0 =A0when start =3D>
> > > =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_high;
> > > =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(sb_tick-1) then =A0 =A0 --=
(A)
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state_next <=3D data;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 n_next <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> > > =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 =A0 =A0when data =3D>
> > > =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D b_reg(0);
> > > =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(sb_tick-1) then =A0 =A0 =
=A0 =A0 =A0 =A0--(A)
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bit_length <=3D not bit_length; =
=A0-- measure a bit.
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D (others=3D>'0');
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b_next <=3D '0' & b_reg((dbit-1) =
downto 1) ;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if n_reg=3D(DBIT-1) then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state_next <=3D idle; -- s=
top ; =A0 =A0--lets skip the
> > > stop bit.
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tx_done_tick <=3D '1'; =A0=
 =A0 =A0 =A0 =A0 =A0 -- moved in from
> > > stop
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n_next <=3D n_reg + 1;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> > > =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 =A0 =A0when stop =3D>
> > > =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_high;
> > > =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(SB_TICK*4-1) then =A0 -- l=
ets make it stick out
> > > for now.
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state_next <=3D idle;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx_done_tick <=3D '1';
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> > > =A0 =A0 =A0 =A0 =A0 =A0 end if;
> > > =A0 =A0 =A0 end case;
> > > =A0 =A0end process;
> > > =A0 =A0tx <=3D tx_reg;
> > > end arch;
>
> > > -----------------------------------------------------------------
>
> > > Now the above has perfect results in the testbench, but crashes the
> > > fpga on a real load. =A0For 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) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if s_reg=3D(sb_tick-1) then
>
> > > with this:
>
> > > (B) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if s_reg=3D(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. =A0I change the VHDL code, and I change
> the results.
>
> very strange. =A0 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. =A0That 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. =A0Again nothing unusual shows up
> on the "behavior" test bench. =A0I 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

On Apr 11, 9:20 am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Apr 9, 10:34 pm, jleslie48 <j...@jonathanleslie.com> 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.

On Apr 9, 10:34=A0pm, jleslie48 <j...@jonathanleslie.com> 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. =A0this 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) =3D=3D 2.5, and a bad drift occurs. =A0So I thin=
k
> no problem lets just use 10 samples per bit rather than 8 thus
> changing the formula to 40M/(10*2M) =3D=3D 2.000 and all will be fine
> again.
>
> And low and behold, Testbench confirms all is well. =A0 Now heres the
> problem, when I try and load this program onto the Spartan 3 chip, it
> dies. =A0with 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 =A0 changing hard coded '15' to (sb_tick-1) for length of
> -- =A0 =A0 =A0 =A0 =A0 =A0 each bit. hard coded '7' for databits now (dbi=
t-1) as
> well.
> -- JL 090312 =A0 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
> =A0 =A0generic(
> =A0 =A0 =A0 DBIT: integer:=3D64; =A0 =A0 -- # data bits
> =A0 =A0 =A0 SB_TICK: integer:=3D10 -- # ticks for each bit
> =A0 =A0);
> =A0 =A0port(
> =A0 =A0 =A0 clk,
> =A0 =A0 =A0 reset =A0 =A0 =A0: in std_logic;
> =A0 =A0 =A0 tx_start =A0 : in std_logic;
> =A0 =A0 =A0 s_tick =A0 =A0 : in std_logic;
> =A0 =A0 =A0 din =A0 =A0 =A0 =A0: in std_logic_vector((dbit-1) downto 0);
> =A0 =A0 =A0 =A0 =A0 tx_done_tick =A0: out std_logic;
> =A0 =A0 =A0 =A0 =A0 tx =A0 =A0 =A0 =A0 =A0 =A0: out std_logic
> =A0 =A0);
> end uart40_tx ;
>
> architecture arch of uart40_tx is
> =A0 =A0type state_type is (idle, start, data, stop);
>
> =A0 =A0constant go_high : std_logic :=3D '1';
> =A0 =A0constant go_low =A0: std_logic :=3D '0';
>
> =A0 =A0signal state_reg, state_next: state_type;
> =A0 =A0signal s_reg, s_next: unsigned(7 downto 0);
> =A0 =A0signal n_reg, n_next: unsigned(7 downto 0);
> =A0 =A0signal b_reg, b_next: std_logic_vector((dbit-1) downto 0);
> =A0 =A0signal tx_reg, tx_next: std_logic;
> =A0 =A0signal bit_length: std_logic :=3D '0'; =A0 =A0 -- testbench watchi=
ng
> only. =A0use with d
> begin
> =A0 =A0-- FSMD state & data registers
> =A0 =A0process(clk,reset)
> =A0 =A0begin
> =A0 =A0 =A0 if reset=3D'1' then
> =A0 =A0 =A0 =A0 =A0state_reg <=3D idle;
> =A0 =A0 =A0 =A0 =A0s_reg <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0n_reg <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0b_reg <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0tx_reg <=3D go_high;
> =A0 =A0 =A0 elsif (clk'event and clk=3D'1') then
> =A0 =A0 =A0 =A0 =A0state_reg <=3D state_next;
> =A0 =A0 =A0 =A0 =A0s_reg <=3D s_next;
> =A0 =A0 =A0 =A0 =A0n_reg <=3D n_next;
> =A0 =A0 =A0 =A0 =A0b_reg <=3D b_next;
> =A0 =A0 =A0 =A0 =A0tx_reg <=3D tx_next;
> =A0 =A0 =A0 end if;
> =A0 =A0end process;
> =A0 =A0-- next-state logic & data path functional units/routing
> =A0 =A0process(state_reg,s_reg,n_reg,b_reg,s_tick,
> =A0 =A0 =A0 =A0 =A0 =A0tx_reg,tx_start,din)
> =A0 =A0begin
> =A0 =A0 =A0 state_next <=3D state_reg;
> =A0 =A0 =A0 s_next <=3D s_reg;
> =A0 =A0 =A0 n_next <=3D n_reg;
> =A0 =A0 =A0 b_next <=3D b_reg;
> =A0 =A0 =A0 tx_next <=3D tx_reg ;
> =A0 =A0 =A0 tx_done_tick <=3D '0';
> =A0 =A0 =A0 case state_reg is
> =A0 =A0 =A0 =A0 =A0when idle =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_low;
> =A0 =A0 =A0 =A0 =A0 =A0 if tx_start=3D'1' then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state_next <=3D start;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0s_next <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b_next <=3D din;
> =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0when start =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_high;
> =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(sb_tick-1) then =A0 =A0 --(A)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state_next <=3D data;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 n_next <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0when data =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D b_reg(0);
> =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(sb_tick-1) then =A0 =A0 =A0 =
=A0 =A0 =A0--(A)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 bit_length <=3D not bit_length; =A0--=
 measure a bit.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D (others=3D>'0');
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 b_next <=3D '0' & b_reg((dbit-1) down=
to 1) ;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if n_reg=3D(DBIT-1) then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0state_next <=3D idle; -- stop =
; =A0 =A0--lets skip the
> stop bit.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tx_done_tick <=3D '1'; =A0 =A0=
 =A0 =A0 =A0 =A0 -- moved in from
> stop
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0n_next <=3D n_reg + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0when stop =3D>
> =A0 =A0 =A0 =A0 =A0 =A0 tx_next <=3D go_high;
> =A0 =A0 =A0 =A0 =A0 =A0 if (s_tick =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if s_reg=3D(SB_TICK*4-1) then =A0 -- lets =
make it stick out
> for now.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 state_next <=3D idle;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tx_done_tick <=3D '1';
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s_next <=3D s_reg + 1;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0end if;
> =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 end case;
> =A0 =A0end process;
> =A0 =A0tx <=3D tx_reg;
> end arch;
>
> -----------------------------------------------------------------
>
> Now the above has perfect results in the testbench, but crashes the
> fpga on a real load. =A0For 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) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if s_reg=3D(sb_tick-1) then
>
> with this:
>
> (B) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if s_reg=3D(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

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