Noise in Stratix3?

My stratix3 design simulates OK at RTL & gate-level.

On the PCB however, an internal module fails to read some M9K RAMS
properly all the time
when I connect an input signal to the chip, but which has nothing to
do with the failing module.

Are there any crosstalk/noise issues with Strarix3 devices that anyone
has encountered?

Basically, the s/w guys are testing the system and getting a lot of
errors on reading this particular RAM,
but removing this un-related signal (relative o the RAMs in question)
reduces the error count a lot. (but not totally, apparently, possibly
another signal also affecting?).

I have not floorplanned the design, but let Quartus do whatever it
wanted routing wise to meet timing and pin-out.

Regards, Kev P.

On Fri, 10 Apr 2009 02:00:15 -0700 (PDT), "Niv (KP)" wrote:

>My stratix3 design simulates OK at RTL & gate-level.
>
>On the PCB however, an internal module fails to read some M9K RAMS
>properly all the time
>when I connect an input signal to the chip, but which has nothing to
>do with the failing module.
>
>Are there any crosstalk/noise issues with Strarix3 devices that anyone
>has encountered?

I hate to say this, but it's *much* more likely to be a 
synchronization issue than crosstalk/noise - this external input,
is it propertly resynch'd before being used in your FPGA?

I know you are a very experienced designer, so I suspect
you already thought of that.  But just in case...  it *is*
by far the most common reason, in my experience, for such
random weirdnesses.

regards
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On Apr 10, 5:04=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 10 Apr 2009 02:00:15 -0700 (PDT), "Niv (KP)" wrote:
> >My stratix3 design simulates OK at RTL & gate-level.
>
> >On the PCB however, an internal module fails to read some M9K RAMS
> >properly all the time
> >when I connect an input signal to the chip, but which has nothing to
> >do with the failing module.
>
> >Are there any crosstalk/noise issues with Strarix3 devices that anyone
> >has encountered?
>
> I hate to say this, but it's *much* more likely to be a
> synchronization issue than crosstalk/noise - this external input,
> is it propertly resynch'd before being used in your FPGA?
>
> I know you are a very experienced designer, so I suspect
> you already thought of that. =A0But just in case... =A0it *is*
> by far the most common reason, in my experience, for such
> random weirdnesses.
>
> regards
> --
> Jonathan Bromley, Consultant
>
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
>
> Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.

Jonathan

OPs issue is not happening on the path where the signal is applied
that causes RAM corruption.

So, if the part of logic that reads the RAM works, then it should
work, not matter the unrelated signal.
And if whatever problems are on the path of that unrelated to RAM
signal, may cause problems, but those should not make the RAM
corrupted.

but yes, it is very much likely that there is some hidden dependancy
from the signal thats seems unrelated.

as of cross-talk inside FPGA.. maybe, just maybe i have once seen it.
but i was experimenting with actual fabric max speed measurements, and
was trying to feed 1GHz signals accross V-4 chip.
and even then, i am not sure what it was, as the signal speed was at
max fabric speeds
i succeeded to actually measure 975MHz signals inside V4 (slowest
speed grade) but those signal do not travel very far

so, the real cross talk, can not be 100% excluded, but it is VERY VERY
unlikely, but differences in routing can cause
things to be very different, and that may cause the unrelated part to
fail

if enabling external signal (unrelated to the RAM) caused ram
failures, while using 100% same bitstrream (that is the
unrelated signal path exists) then well if the unrelated signals is
say 250 mhz external clock that controls most of
the FPGA, then it could cause problems because of power supply

if VCCINT is out of spec has noise, then real weird things can happen.
spartan-3 can report JTAG ID of Virtex-4

faulty FPGA is sometimes also possible, the unrelated signal may put
change the placement to avoid damaged part
but, this is also very unlikely

seen only once a partially dead FPGA, Xilinx spartan3E, after power
supply IC burned, replaced IC, but FPGA
was only partially working

..
and as usual, issue between ears.. sleep over it, try again
make the test case simpler, try to remove all that isnt relevant and
retest.

once I called a fellow engineer to monitor what i was doing, to
document
an issue that was by all means something that shouldnt be possible.

try lock the failing RAM to different locations, and try those
change at random some optimization setting, and try

all not very funny solution, i know

Antti

On Apr 10, 2:00=A0am, "Niv (KP)" <kev.pars...@mbda-systems.com> wrote:
> My stratix3 design simulates OK at RTL & gate-level.
>
> On the PCB however, an internal module fails to read some M9K RAMS
> properly all the time
> when I connect an input signal to the chip, but which has nothing to
> do with the failing module.
>
> Are there any crosstalk/noise issues with Strarix3 devices that anyone
> has encountered?
>
> Basically, the s/w guys are testing the system and getting a lot of
> errors on reading this particular RAM,
> but removing this un-related signal (relative o the RAMs in question)
> reduces the error count a lot. (but not totally, apparently, possibly
> another signal also affecting?).
>
> I have not floorplanned the design, but let Quartus do whatever it
> wanted routing wise to meet timing and pin-out.
>
> Regards, Kev P.

This type of problem can be very frustrating to solve.  Given the
strange interaction
you observe between supposedly unrelated signal & ram, I'd look into
the following
things:
a) are all the power supplies to the part clean & solid?  Good ground
plane under the FPGA?
b) did the design met all the timing constraints?
c) is there a "bus fight" between external signals and FPGA output
signals?
d) are there any floating inputs that could be drifting into the no-
mans land of neither on nor off?
e) are the input clocks all high quality?

Good luck - let us know what you find.

John Providenza

"Niv (KP)" <kev.parsons@mbda-systems.com> wrote in message 
news:fd286f17-b434-4b03-aa38-f77e6f69f608@v28g2000vbb.googlegroups.com...
> My stratix3 design simulates OK at RTL & gate-level.
>
> On the PCB however, an internal module fails to read some M9K RAMS
> properly all the time
> when I connect an input signal to the chip, but which has nothing to
> do with the failing module.
>
> Are there any crosstalk/noise issues with Strarix3 devices that anyone
> has encountered?
>
> Basically, the s/w guys are testing the system and getting a lot of
> errors on reading this particular RAM,
> but removing this un-related signal (relative o the RAMs in question)
> reduces the error count a lot. (but not totally, apparently, possibly
> another signal also affecting?).
>
> I have not floorplanned the design, but let Quartus do whatever it
> wanted routing wise to meet timing and pin-out.
>
> Regards, Kev P.

Niv - having been using Stratix 3's for the past 2 years, and recently 
started using Stratix 4's on some complex Image processing and 
communications functions that are heavily internal RAM dependent, I cannot 
say I have ever come across this problem.

As you are not floor planning the design - and I assume you have not also 
back annotated proven modules, then I suspect that you DO have a timing 
problem. Removing the unrelated signal in an unconstrained design merely 
gives the router more options to screw your layout on the next compile.

I suggest that at the very least you logic-lock your RAM/RAM control module 
in to a minimal area to constrain the routing options - and when you 
verified all the routing delays are not a problem in that module - LOCK IT!

But then what do I know - I design using schematics LOL!

Dave 

On Apr 10, 11:38=A0am, "Dave Wilson" <d...@noaddress.net> wrote:
> "Niv (KP)" <kev.pars...@mbda-systems.com> wrote in message
>
> news:fd286f17-b434-4b03-aa38-f77e6f69f608@v28g2000vbb.googlegroups.com...
>
>
>
>
>
> > My stratix3 design simulates OK at RTL & gate-level.
>
> > On the PCB however, an internal module fails to read some M9K RAMS
> > properly all the time
> > when I connect an input signal to the chip, but which has nothing to
> > do with the failing module.
>
> > Are there any crosstalk/noise issues with Strarix3 devices that anyone
> > has encountered?
>
> > Basically, the s/w guys are testing the system and getting a lot of
> > errors on reading this particular RAM,
> > but removing this un-related signal (relative o the RAMs in question)
> > reduces the error count a lot. (but not totally, apparently, possibly
> > another signal also affecting?).
>
> > I have not floorplanned the design, but let Quartus do whatever it
> > wanted routing wise to meet timing and pin-out.
>
> > Regards, Kev P.
>
> Niv - having been using Stratix 3's for the past 2 years, and recently
> started using Stratix 4's on some complex Image processing and
> communications functions that are heavily internal RAM dependent, I canno=
t
> say I have ever come across this problem.
>
> As you are not floor planning the design - and I assume you have not also
> back annotated proven modules, then I suspect that you DO have a timing
> problem. Removing the unrelated signal in an unconstrained design merely
> gives the router more options to screw your layout on the next compile.
>
> I suggest that at the very least you logic-lock your RAM/RAM control modu=
le
> in to a minimal area to constrain the routing options - and when you
> verified all the routing delays are not a problem in that module - LOCK I=
T!
>
> But then what do I know - I design using schematics LOL!
>
> Dave- Hide quoted text -
>
> - Show quoted text -

If I understand the OP correctly, the FPGA design/placement/routing is
not changing, but the FPGA behavior is changing based on whether this
unrelated, external signal is connected to the IC or not. I would look
closely at that signal.

Is it properly referenced to the local ground for the FPGA?

Does it violate any input signal specs (abs min/max voltage, vinH/
vinL, rise/fall time, min pulse width, etc.)?

Is the signal active before/during when the FPGA is powering up and/
or  configuring?

Is the signal synchronized properly? I suppose a massively parallel
synchronized input could cause excess power draw during metastable
conditions.

Some of these issues can cause power problems on the FPGA die that can
lead to wierd behavior in seemingly unrelated parts of the chip.

If you have a relatively static spare output on the same bank (powered
from the same bank supply), you could watch it and make sure it does
not droop and/or spike.

Andy

"Andy" <jonesandy@comcast.net> wrote in message 
news:012ccb0d-615b-4443-9a58-093f73daedce@z1g2000yqn.googlegroups.com...
On Apr 10, 11:38 am, "Dave Wilson" <d...@noaddress.net> wrote:
> "Niv (KP)" <kev.pars...@mbda-systems.com> wrote in message
>
> news:fd286f17-b434-4b03-aa38-f77e6f69f608@v28g2000vbb.googlegroups.com...
>
>
>
>
>
> > My stratix3 design simulates OK at RTL & gate-level.
>
> > On the PCB however, an internal module fails to read some M9K RAMS
> > properly all the time
> > when I connect an input signal to the chip, but which has nothing to
> > do with the failing module.
>
> > Are there any crosstalk/noise issues with Strarix3 devices that anyone
> > has encountered?
>
> > Basically, the s/w guys are testing the system and getting a lot of
> > errors on reading this particular RAM,
> > but removing this un-related signal (relative o the RAMs in question)
> > reduces the error count a lot. (but not totally, apparently, possibly
> > another signal also affecting?).
>
> > I have not floorplanned the design, but let Quartus do whatever it
> > wanted routing wise to meet timing and pin-out.
>
> > Regards, Kev P.
>
> Niv - having been using Stratix 3's for the past 2 years, and recently
> started using Stratix 4's on some complex Image processing and
> communications functions that are heavily internal RAM dependent, I cannot
> say I have ever come across this problem.
>
> As you are not floor planning the design - and I assume you have not also
> back annotated proven modules, then I suspect that you DO have a timing
> problem. Removing the unrelated signal in an unconstrained design merely
> gives the router more options to screw your layout on the next compile.
>
> I suggest that at the very least you logic-lock your RAM/RAM control 
> module
> in to a minimal area to constrain the routing options - and when you
> verified all the routing delays are not a problem in that module - LOCK 
> IT!
>
> But then what do I know - I design using schematics LOL!
>
> Dave- Hide quoted text -
>
> - Show quoted text -

>>f I understand the OP correctly, the FPGA design/placement/routing is
>>not changing, but the FPGA behavior is changing based on whether this
>>unrelated, external signal is connected to the IC or not. I would look
>>closely at that signal.

The OP actually stated "I have not floorplanned the design, but let Quartus 
do whatever it
wanted routing wise to meet timing and pin-out." which implies (to me) a new 
roll of the dice each compile .....

But then what do I know - I design using schematics LOL!

Dave 

Niv (KP) wrote:
> My stratix3 design simulates OK at RTL & gate-level.
> 
> On the PCB however, an internal module fails to read some M9K RAMS
> properly all the time
> when I connect an input signal to the chip, but which has nothing to
> do with the failing module.
> 
> Are there any crosstalk/noise issues with Strarix3 devices that anyone
> has encountered?
> 
> Basically, the s/w guys are testing the system and getting a lot of
> errors on reading this particular RAM,
> but removing this un-related signal (relative o the RAMs in question)
> reduces the error count a lot. (but not totally, apparently, possibly
> another signal also affecting?).
> 
> I have not floorplanned the design, but let Quartus do whatever it
> wanted routing wise to meet timing and pin-out.
> 
> Regards, Kev P.
A bit more information would be helpful.  What type of interface have 
you implemented that the software is using to read the internal RAMS?  I 
had a problem once where software claimed they were getting corrupt 
information but it turned out that they they were reading the ASIC 
(which interfaced to my FPGA) too fast, thus giving the appearance of 
corrupt registers.

Have you used the JTAG interface when you get into a software reported 
corruption issue.  There are some implementations of RAM that can be 
read (via JTAG) using the in-system memory editor.

Rob

Niv (KP) wrote:
> My stratix3 design simulates OK at RTL & gate-level.
> 
> On the PCB however, an internal module fails to read some M9K RAMS
> properly all the time
> when I connect an input signal to the chip, but which has nothing to
> do with the failing module.
> 
> Are there any crosstalk/noise issues with Strarix3 devices that anyone
> has encountered?
> 
> Basically, the s/w guys are testing the system and getting a lot of
> errors on reading this particular RAM,
> but removing this un-related signal (relative o the RAMs in question)
> reduces the error count a lot. (but not totally, apparently, possibly
> another signal also affecting?).
> 
> I have not floorplanned the design, but let Quartus do whatever it
> wanted routing wise to meet timing and pin-out.
> 
> Regards, Kev P.
A bit more information would be helpful.  What type of interface have 
you implemented that the software is using to read the internal RAMS?  I 
had a problem once where software claimed they were getting corrupt 
information but it turned out that they they were reading the ASIC 
(which interfaced to my FPGA) too fast, thus giving the appearance of 
corrupt registers.

Have you used the JTAG interface when you get into a software reported 
corruption issue.  There are some implementations of RAM that can be 
read (via JTAG) using the in-system memory editor.

Rob

Niv (KP) wrote:
> My stratix3 design simulates OK at RTL & gate-level.
> 
> On the PCB however, an internal module fails to read some M9K RAMS
> properly all the time
> when I connect an input signal to the chip, but which has nothing to
> do with the failing module.
> 
> Are there any crosstalk/noise issues with Strarix3 devices that anyone
> has encountered?
> 
> Basically, the s/w guys are testing the system and getting a lot of
> errors on reading this particular RAM,
> but removing this un-related signal (relative o the RAMs in question)
> reduces the error count a lot. (but not totally, apparently, possibly
> another signal also affecting?).
> 
> I have not floorplanned the design, but let Quartus do whatever it
> wanted routing wise to meet timing and pin-out.
> 
> Regards, Kev P.
A bit more information would be helpful.  What type of interface have 
you implemented that the software is using to read the internal RAMS?  I 
had a problem once where software claimed they were getting corrupt 
information but it turned out that they they were reading the ASIC 
(which interfaced to my FPGA) too fast, thus giving the appearance of 
corrupt registers.

Have you used the JTAG interface when you get into a software reported 
corruption issue.  There are some implementations of RAM that can be 
read (via JTAG) using the in-system memory editor.

Rob