FPGA Groups

FPGA Groups (http://www.fpgacentral.com/group/index.php)
-   FPGA (http://www.fpgacentral.com/group/forumdisplay.php?f=14)
-   -   bizzare unexplained random errors w/ Lattice 4256V CPLD (http://www.fpgacentral.com/group/showthread.php?t=58520)

[email protected] 05-02-2006 11:06 PM

bizzare unexplained random errors w/ Lattice 4256V CPLD
 
We are using VHDL on a new design with a Lattice 4256V and are running
into problems with our shift registers. We're using ispLEVER 5.1 trial
along with Synplicity synthesis. Here's our generic 11-bit shift
register with async. parallel load:

--
-- 11 bit shifter for data serialization
--
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_arith.all;
use IEEE.STD_LOGIC_unsigned.all;

entity shifter11 is
port(
clk:in std_logic;
rst:in std_logic;
data_in:in std_logic_vector(10 downto 0);
shift_load_select:in std_logic;
shift_in:in std_logic;
data_out:out std_logic);
end shifter11;

architecture bhv of shifter11 is
signal data_latched: std_logic_vector(10 downto 0);
begin
process(clk,rst,data_in,shift_load_select)
begin
if(rst='0') then
data_latched <= "11111111111";
elsif(shift_load_select = '1') then
data_latched <= data_in;
elsif(clk'event and clk='1') then
data_latched <= shift_in & data_latched(10 downto 1);
end if;
end process;
data_out <= data_latched(0);
end bhv;


We have isolated the CPLD completely with nothing but a clock pin +
reset as external input. With hard-coded input to the shift register
and another test entity that does nothing but sniff the ouput and
verify its correctness, we are occasionally running into problems.
After many thousands of shifts + outputs over 20-60 seconds, there will
be one or more bits flipped in the shift register output. 99.999% of
the time the output is correct, we just can't figure out why this thing
is failing.

The issue seems to only occur when we place multiple shift registers in
our design working in parallel, a single shift register alone will work
error-free. To me this seems to indicate a tool issue when utilizing
resources close to the limits of the chip.

Another possibility is a hardware problem, however we have double and
triple checked all ground / VCC pins and reduced the external inputs to
the bare minimum.

I started going through the generated postfit equations, however I
started to get a headache after about the 100th flip flop.

Any suggestions on how to fix this?


Gabor 05-02-2006 11:31 PM

Re: bizzare unexplained random errors w/ Lattice 4256V CPLD
 
A shift register with asynchronous set and asynchronous load is
not entirely "generic". I would look carefully at the load and reset
logic generated. A glitch on a gated asynch input can cause
severe problems. How is the asynchronous load implemented
in the macrocell? Do you really need both load and reset terms
to be asynchronous?

[email protected] wrote:
> We are using VHDL on a new design with a Lattice 4256V and are running
> into problems with our shift registers. We're using ispLEVER 5.1 trial
> along with Synplicity synthesis. Here's our generic 11-bit shift
> register with async. parallel load:
>
> --
> -- 11 bit shifter for data serialization
> --
> library IEEE;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.STD_LOGIC_arith.all;
> use IEEE.STD_LOGIC_unsigned.all;
>
> entity shifter11 is
> port(
> clk:in std_logic;
> rst:in std_logic;
> data_in:in std_logic_vector(10 downto 0);
> shift_load_select:in std_logic;
> shift_in:in std_logic;
> data_out:out std_logic);
> end shifter11;
>
> architecture bhv of shifter11 is
> signal data_latched: std_logic_vector(10 downto 0);
> begin
> process(clk,rst,data_in,shift_load_select)
> begin
> if(rst='0') then
> data_latched <= "11111111111";
> elsif(shift_load_select = '1') then
> data_latched <= data_in;
> elsif(clk'event and clk='1') then
> data_latched <= shift_in & data_latched(10 downto 1);
> end if;
> end process;
> data_out <= data_latched(0);
> end bhv;
>
>
> We have isolated the CPLD completely with nothing but a clock pin +
> reset as external input. With hard-coded input to the shift register
> and another test entity that does nothing but sniff the ouput and
> verify its correctness, we are occasionally running into problems.
> After many thousands of shifts + outputs over 20-60 seconds, there will
> be one or more bits flipped in the shift register output. 99.999% of
> the time the output is correct, we just can't figure out why this thing
> is failing.
>
> The issue seems to only occur when we place multiple shift registers in
> our design working in parallel, a single shift register alone will work
> error-free. To me this seems to indicate a tool issue when utilizing
> resources close to the limits of the chip.
>
> Another possibility is a hardware problem, however we have double and
> triple checked all ground / VCC pins and reduced the external inputs to
> the bare minimum.
>
> I started going through the generated postfit equations, however I
> started to get a headache after about the 100th flip flop.
>
> Any suggestions on how to fix this?



Jim Granville 05-02-2006 11:59 PM

Re: bizzare unexplained random errors w/ Lattice 4256V CPLD
 
[email protected] wrote:

> We are using VHDL on a new design with a Lattice 4256V and are running
> into problems with our shift registers. We're using ispLEVER 5.1 trial
> along with Synplicity synthesis. Here's our generic 11-bit shift
> register with async. parallel load:
>
> --
> -- 11 bit shifter for data serialization
> --
> library IEEE;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.STD_LOGIC_arith.all;
> use IEEE.STD_LOGIC_unsigned.all;
>
> entity shifter11 is
> port(
> clk:in std_logic;
> rst:in std_logic;
> data_in:in std_logic_vector(10 downto 0);
> shift_load_select:in std_logic;
> shift_in:in std_logic;
> data_out:out std_logic);
> end shifter11;
>
> architecture bhv of shifter11 is
> signal data_latched: std_logic_vector(10 downto 0);
> begin
> process(clk,rst,data_in,shift_load_select)
> begin
> if(rst='0') then
> data_latched <= "11111111111";
> elsif(shift_load_select = '1') then
> data_latched <= data_in;
> elsif(clk'event and clk='1') then
> data_latched <= shift_in & data_latched(10 downto 1);
> end if;
> end process;
> data_out <= data_latched(0);
> end bhv;
>
>
> We have isolated the CPLD completely with nothing but a clock pin +
> reset as external input. With hard-coded input to the shift register
> and another test entity that does nothing but sniff the ouput and
> verify its correctness, we are occasionally running into problems.
> After many thousands of shifts + outputs over 20-60 seconds, there will
> be one or more bits flipped in the shift register output. 99.999% of
> the time the output is correct, we just can't figure out why this thing
> is failing.


"async. parallel load" can be dangerous - what releases the Load signal,
relative to the Clock ?
If your load has no release precautions, then yes, you can expect
nasty aperture effects if/when the release hits a shift clock edge.

>
> The issue seems to only occur when we place multiple shift registers in
> our design working in parallel, a single shift register alone will work
> error-free. To me this seems to indicate a tool issue when utilizing
> resources close to the limits of the chip.


If it mostly works, then it is not likely to be a tool-error.
Fuse/map errors tend to be hard, in nature.

If you added an Nth bock, and that (or other) blocks then fail (always),
that is (likely) a tool chain issue.

> Another possibility is a hardware problem, however we have double and
> triple checked all ground / VCC pins and reduced the external inputs to
> the bare minimum.
>
> I started going through the generated postfit equations, however I
> started to get a headache after about the 100th flip flop.
>
> Any suggestions on how to fix this?


-jg


bart 05-03-2006 02:48 AM

Re: bizzare unexplained random errors w/ Lattice 4256V CPLD
 
on the Lattice website forums
http://www.latticesemi.com/forums/fo...&enterthread=y
Lattice's response was as follows:
------------------------------------------------------
The fact that the error happens occasionally, and doesn't happen at all
with fewer shift registers, suggests that it's either a timing issue or
a board level issue. If the error occured all of the time, or when it
went bad it stayed bad, I would agree that it could be a logic problem.
By the way, does the design occasionally not drive a bit high (a hole
in the shift sequence) or does the shift sequence get off by a clock?
Is it happening on all shift registers, or just one?

Make sure that you have set proper timing contraints for your design
and that you check the log files for violations.

Assuming the timing looks good, I'd check your board level design. Make
sure you aren't overworking the outputs, take a look at page 20 of the
datasheet. Keep in mind that if you are driving many loads all at once
you can create ground bounce significant enough to affect the part. You
might try different input patterns to see if this changes things (use a
pattern that generates less toggling of the outputs). Also check that
you have sufficient numbers of high frequency (.1uf or .01uf) and mid
frequency (10uf to 47uf) capacitors. Check that your power supply isn't
drooping. Check that the power supply doesn't get more noisy as the
load increases.
------------------------------------------------------
Hope this helps!
Bart Borosky
Online Marketing Manager
Lattice Semiconductor


[email protected] 05-04-2006 06:13 PM

Re: bizzare unexplained random errors w/ Lattice 4256V CPLD
 
Thanks for the help everyone, I finally fixed the problem. It was an
issue with the the asynchronous load line.

[email protected] wrote:
> We are using VHDL on a new design with a Lattice 4256V and are running
> into problems with our shift registers. We're using ispLEVER 5.1 trial
> along with Synplicity synthesis. Here's our generic 11-bit shift
> register with async. parallel load:
>
> --
> -- 11 bit shifter for data serialization
> --
> library IEEE;
> use IEEE.STD_LOGIC_1164.all;
> use IEEE.STD_LOGIC_arith.all;
> use IEEE.STD_LOGIC_unsigned.all;
>
> entity shifter11 is
> port(
> clk:in std_logic;
> rst:in std_logic;
> data_in:in std_logic_vector(10 downto 0);
> shift_load_select:in std_logic;
> shift_in:in std_logic;
> data_out:out std_logic);
> end shifter11;
>
> architecture bhv of shifter11 is
> signal data_latched: std_logic_vector(10 downto 0);
> begin
> process(clk,rst,data_in,shift_load_select)
> begin
> if(rst='0') then
> data_latched <= "11111111111";
> elsif(shift_load_select = '1') then
> data_latched <= data_in;
> elsif(clk'event and clk='1') then
> data_latched <= shift_in & data_latched(10 downto 1);
> end if;
> end process;
> data_out <= data_latched(0);
> end bhv;
>
>
> We have isolated the CPLD completely with nothing but a clock pin +
> reset as external input. With hard-coded input to the shift register
> and another test entity that does nothing but sniff the ouput and
> verify its correctness, we are occasionally running into problems.
> After many thousands of shifts + outputs over 20-60 seconds, there will
> be one or more bits flipped in the shift register output. 99.999% of
> the time the output is correct, we just can't figure out why this thing
> is failing.
>
> The issue seems to only occur when we place multiple shift registers in
> our design working in parallel, a single shift register alone will work
> error-free. To me this seems to indicate a tool issue when utilizing
> resources close to the limits of the chip.
>
> Another possibility is a hardware problem, however we have double and
> triple checked all ground / VCC pins and reduced the external inputs to
> the bare minimum.
>
> I started going through the generated postfit equations, however I
> started to get a headache after about the 100th flip flop.
>
> Any suggestions on how to fix this?




All times are GMT +1. The time now is 06:53 PM.

Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved