S3A starterkit weird behaviou (mini quiz)

Xilinx S3A starterkit

8 LEDs are programmed to display some debug value

rocker switch is used as system reset input

FPGA design set LED to constant value, all I/O are output only that
control LEDs

now the funny thing comes:

there are two different possibilities for the LEDs depening the slide
switch (reset!)
this is normal (reset and run states)

but there is also 3rd possibility when the LEDs are about 50% of
intensity!!

ah, let it be mini Quiz:

what is the reason? how come the LEDs be at 50% intensity?
FPGA is configured all the time, the leds are driven with constant
value. (no PWM)

Antti

> now the funny thing comes:
> 
> there are two different possibilities for the LEDs depening the slide
> switch (reset!)
> this is normal (reset and run states)
> 
> but there is also 3rd possibility when the LEDs are about 50% of
> intensity!!

Which position is the switch then - reset or run?

What's the state of the LEDs during reset? What after reset, i.e. the
next pattern?

> what is the reason? how come the LEDs be at 50% intensity?
> FPGA is configured all the time, the leds are driven with constant
> value. (no PWM)

First guess: 50% intentsity is caused by the design looping
reset->run->reset->run. I'd investigate for ground bounce affecting the
reset input. A weak pull-up is probably also involved.

Arnim

On Apr 11, 10:07=A0am, Arnim <clv.5.min...@spamgourmet.com> wrote:
> > now the funny thing comes:
>
> > there are two different possibilities for the LEDs depening the slide
> > switch (reset!)
> > this is normal (reset and run states)
>
> > but there is also 3rd possibility when the LEDs are about 50% of
> > intensity!!
>
> Which position is the switch then - reset or run?
>
> What's the state of the LEDs during reset? What after reset, i.e. the
> next pattern?
>
> > what is the reason? how come the LEDs be at 50% intensity?
> > FPGA is configured all the time, the leds are driven with constant
> > value. (no PWM)
>
> First guess: 50% intentsity is caused by the design looping
> reset->run->reset->run. I'd investigate for ground bounce affecting the
> reset input. A weak pull-up is probably also involved.
>
> Arnim

100% hit (i was just curious if somebody guesses it)

yes that it was, the slide switch was in middle position
there is no onboard resistor and fpga pulls disabled

it worked also like CAPACITIVE touch sensor
touching PCB at LED0 (close to the switch) made leds on, taking finger
away led off

Antti

>> First guess: 50% intentsity is caused by the design looping
>> reset->run->reset->run. I'd investigate for ground bounce affecting the
>> reset input. A weak pull-up is probably also involved.
> 
> 100% hit (i was just curious if somebody guesses it)
> 
> yes that it was, the slide switch was in middle position
> there is no onboard resistor and fpga pulls disabled
> 
> it worked also like CAPACITIVE touch sensor
> touching PCB at LED0 (close to the switch) made leds on, taking finger
> away led off

Ouch :-)
Resets can be as troublesome as clocks. We once debugged a sporadically
failing board only to find that the reset input of the central chip
glitches from time to time (cross-talk from other PCB traces). Even if
the wire was clamped to supply rail. Only workaround was to clip off the
respective pin (PGA) since we didn't need it at all.

People argued whether it was bad PCB design (no shielding of async
signal) or bad chip design (no low-pass filter at async input). I'd say
both :-)

Arnim

>
>>> First guess: 50% intentsity is caused by the design looping
>>> reset->run->reset->run. I'd investigate for ground bounce affecting
the
>>> reset input. A weak pull-up is probably also involved.
>> 
>> 100% hit (i was just curious if somebody guesses it)
>> 
>> yes that it was, the slide switch was in middle position
>> there is no onboard resistor and fpga pulls disabled
>> 
>> it worked also like CAPACITIVE touch sensor
>> touching PCB at LED0 (close to the switch) made leds on, taking finger
>> away led off
>
>Ouch :-)
>Resets can be as troublesome as clocks. We once debugged a sporadically
>failing board only to find that the reset input of the central chip
>glitches from time to time (cross-talk from other PCB traces). Even if
>the wire was clamped to supply rail. Only workaround was to clip off the
>respective pin (PGA) since we didn't need it at all.
>
>People argued whether it was bad PCB design (no shielding of async
>signal) or bad chip design (no low-pass filter at async input). I'd say
>both :-)
>
>Arnim
>

A reset or any input may be left floating at a testing stage. I used a
cpld to configure FPGA and it will either fail or work on power up or upon
touching some board pins.
It turned out that the reset was floating being supposed to be driven from
a mother board which was not ready yet. The remedy was internal pull-up.

kadhiem

On Apr 11, 2:12=A0am, "Antti.Luk...@googlemail.com"
<Antti.Luk...@googlemail.com> wrote:
> On Apr 11, 10:07=A0am, Arnim <clv.5.min...@spamgourmet.com> wrote:
>
>
>
>
>
> > > now the funny thing comes:
>
> > > there are two different possibilities for the LEDs depening the slide
> > > switch (reset!)
> > > this is normal (reset and run states)
>
> > > but there is also 3rd possibility when the LEDs are about 50% of
> > > intensity!!
>
> > Which position is the switch then - reset or run?
>
> > What's the state of the LEDs during reset? What after reset, i.e. the
> > next pattern?
>
> > > what is the reason? how come the LEDs be at 50% intensity?
> > > FPGA is configured all the time, the leds are driven with constant
> > > value. (no PWM)
>
> > First guess: 50% intentsity is caused by the design looping
> > reset->run->reset->run. I'd investigate for ground bounce affecting the
> > reset input. A weak pull-up is probably also involved.
>
> > Arnim
>
> 100% hit (i was just curious if somebody guesses it)
>
> yes that it was, the slide switch was in middle position
> there is no onboard resistor and fpga pulls disabled
>
> it worked also like CAPACITIVE touch sensor
> touching PCB at LED0 (close to the switch) made leds on, taking finger
> away led off
>
> Antti- Hide quoted text -
>
> - Show quoted text -

Floating causes head ache

;-)

On Wed, 15 Apr 2009 07:30:24 -0700 (PDT), 
halong <ccon67@netscape.net> wrote:

>Floating causes head ache

Indeed.  Unhappy memories of my first-ever CMOS
project, where I left the reset input floating.
It would often work for a few minutes.  Or it 
would fail to work until you moved a finger
close to it.

Sensible people don't make that sort of mistake
twice.  I think it took me three or four such
situations before I learnt my lesson :-(
-- 
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.

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message 
news:i0sbu4ho61tdp17511b4em80i2d9vn1u5h@4ax.com...

> Unhappy memories of my first-ever CMOS
> project, where I left the reset input floating.
> It would often work for a few minutes.

I've had two CMOS idiocies that I can remember.
One was a RAM that would perform writes when
the addresses were floating (even though the CS
and WE inputs were held to the appropriate levels).

The other was debugging a system with a fair chunk
of CMOS (as well as some analog and ECL).
It was working, but not reliably, and it took me about
15 minutes to realize I wasn't applying power to the
CMOS section. The whole section seemed to be
powering itself off the inputs. 

On Apr 15, 5:34=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Wed, 15 Apr 2009 07:30:24 -0700 (PDT),
>
> halong <cco...@netscape.net> wrote:
> >Floating causes head ache
>
> Indeed. =A0Unhappy memories of my first-ever CMOS
> project, where I left the reset input floating.
> It would often work for a few minutes. =A0Or it
> would fail to work until you moved a finger
> close to it.
>
> Sensible people don't make that sort of mistake
> twice. =A0I think it took me three or four such
> situations before I learnt my lesson :-(
> --
> 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.

LOL,

eh, well the reason why it happened, was well, lets say acceptable...

I wanted to connect to reset input to switch in such way that i can
not make mistake about polarity..:)
thats why i did not choose a push button (what has pullup on board), i
did just select the slide switch
as it has 2 stable positions..

and well.. yes a 3rd one that is also possible made stable, and in
such case remains as floating

was just a funny misbehaviour, not a mistake,, well if then well, yes
i should have enabled the onchip pullup
right away what i didnt.

when design actual boards, the reset is most sensitive, and i am
always VERY paranoid about anything
connected to reset pin

Antti

Pete Fraser <pfraser@covad.net> wrote:
(snip)
 
> The other was debugging a system with a fair chunk
> of CMOS (as well as some analog and ECL).
> It was working, but not reliably, and it took me about
> 15 minutes to realize I wasn't applying power to the
> CMOS section. The whole section seemed to be
> powering itself off the inputs. 

With protection diodes on the inputs, it will likely do
that as long as at least one input is high (enough).

I believe that there are circuits powered off RS-232 that
use a similar power method, though likely with a capacitor
to keep it running.  

-- glen