A Question about FPGA IO Standard

[nba83]

hi,
I have a custom designed board with spartan 2 (XC2S150) with some inpu
data and clk line connected to a peripheral device, the clk level is 3.3
and FPGA IO standard(not defined in .ucf file so is the default) is LVTT
and VCCIO is 3.3 and VREF of FPGA is not connected to any voltage.
my problem is, sometimes reading data from peripheral is erroneous an
after some test I'm sure that the GND level of peripheral and FPGA i
changing so that some clk edges are missed in FPGA which result in the dat
corruption. inorder to resolve this problem, I connected the two board wit
a good ground wire and after that there was fewer data loss but not 100
correct. another thing that I wanted to do is changing input IO Level fro
LVTTL to LVCMOS2.5, but I'm not sure if it is possible regarding that th
VCCIO is connected to 3.3V? how should I know that the level of FPGA i
working at LVCMOS2.5?
is this presumtion going to fix my problem?
tnx in advance for any helpful comment,
Neda Baheri




---------------------------------------
Posted through http://www.FPGARelated.com

 

[Andrew Holme]

"nba83" wrote in message
news:4MGdnZrcOs1zsS7MnZ2dnUVZ_vidnZ2d@giganews.com...

I have a custom designed board with spartan 2 (XC2S150) with some input
data and clk line connected to a peripheral device, the clk level is 3.3V
and FPGA IO standard(not defined in .ucf file so is the default) is LVTTL
and VCCIO is 3.3 and VREF of FPGA is not connected to any voltage.
my problem is, sometimes reading data from peripheral is erroneous and
after some test I'm sure that the GND level of peripheral and FPGA is
changing so that some clk edges are missed in FPGA which result in the data
corruption. inorder to resolve this problem, I connected the two board with
a good ground wire and after that there was fewer data loss but not 100%
correct. another thing that I wanted to do is changing input IO Level from
LVTTL to LVCMOS2.5, but I'm not sure if it is possible regarding that the
VCCIO is connected to 3.3V? how should I know that the level of FPGA is
working at LVCMOS2.5?
is this presumtion going to fix my problem?

I doubt it; but to change input IO threshold to LVCMOS25 you must reduce
VDDIO to 2.5V.

What is the phase relationship between the clock and data? Do you have
adequate setup and hold times?

Are you using the same clock for all the logic inside the FPGA or is there
another clock? Are you handling the clock domain crossing correctly?

What is the rise time of the clock? FPGAs are very fast. If the rise time
is slow and there is any noise superimposed, the FPGA can actually clock
more than once on a single edge. Improving the grounding might well have
reduced the amount of superimposed noise. A better way to handle this is to
sample the clock and data using a faster internal clock and detect edges,
rather than using the external clock as a clock directly. Ideally you want
the sampling interval to be about the same as the rise time so you only get
one or two samples falling on each edge.

 

[rickman]

On 6/8/2013 9:09 AM, nba83 wrote:

hi,
I have a custom designed board with spartan 2 (XC2S150) with some input
data and clk line connected to a peripheral device, the clk level is 3.3V
and FPGA IO standard(not defined in .ucf file so is the default) is LVTTL
and VCCIO is 3.3 and VREF of FPGA is not connected to any voltage.
my problem is, sometimes reading data from peripheral is erroneous and
after some test I'm sure that the GND level of peripheral and FPGA is
changing so that some clk edges are missed in FPGA which result in the data
corruption. inorder to resolve this problem, I connected the two board with
a good ground wire and after that there was fewer data loss but not 100%
correct. another thing that I wanted to do is changing input IO Level from
LVTTL to LVCMOS2.5, but I'm not sure if it is possible regarding that the
VCCIO is connected to 3.3V? how should I know that the level of FPGA is
working at LVCMOS2.5?
is this presumtion going to fix my problem?
tnx in advance for any helpful comment,

If you have ground problems, they won't be fixed by changing the voltage
level to 2.5 volts... unless the chip on the other end is driving with
2.5 volts?

Look at your signals with a dual channel scope to see the wave shape to
make sure there is no point where the rising or falling edges of the
clock are glitching creating an extra clock edge and observe the setup
and hold time of the data with respect to the clock.

What is the peripheral device? Are you using the correct edge of the
clock?

--

Rick

 

[Mike Perkins]

On 08/06/2013 14:09, nba83 wrote:

hi, I have a custom designed board with spartan 2 (XC2S150) with some
input data and clk line connected to a peripheral device, the clk
level is 3.3V and FPGA IO standard(not defined in .ucf file so is the
default) is LVTTL and VCCIO is 3.3 and VREF of FPGA is not connected
to any voltage. my problem is, sometimes reading data from peripheral
is erroneous and after some test I'm sure that the GND level of
peripheral and FPGA is changing so that some clk edges are missed in
FPGA which result in the data corruption. inorder to resolve this
problem, I connected the two board with a good ground wire and after
that there was fewer data loss but not 100% correct. another thing
that I wanted to do is changing input IO Level from LVTTL to
LVCMOS2.5, but I'm not sure if it is possible regarding that the
VCCIO is connected to 3.3V? how should I know that the level of FPGA
is working at LVCMOS2.5? is this presumtion going to fix my problem?
tnx in advance for any helpful comment, Neda Baheri

How are the signals connected between the two boards?

The distance between them?

And the clock frequency?

I would stick to 3.3V unless there is good reason to do otherwise.

It's a long time since I looked at Spartan 2s, but what is the
significance of Vref when using the LVTTL IO standard?

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

 

[Theo Markettos]

rickman <gnuarm@gmail.com> wrote:

What is the peripheral device? Are you using the correct edge of the
clock?

Are there sufficient timing constraints set up so the tools can check
they're obeying the timing requirements of the peripheral?

Theo