Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 125075

Article: 125075
Subject: Re: FPGA quiz: what can be wrong
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 16 Oct 2007 22:51:06 +1300
Links: << >>  << T >>  << A >>
>> Hi Jim,
>>
>> yes the signals are FULLY independant.
> 
> 
> That's as seen on a scope, at the pins ?
> That moves the issue to downstream of the FPGA .

Any answer on the Scope probe at the LED1,LED2  pins ?

-jg


Article: 125076
Subject: Re: FPGA quiz: what can be wrong
From: avrbasic@hotmail.com
Date: Tue, 16 Oct 2007 09:52:00 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 11:51, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> >> Hi Jim,
>
> >> yes the signals are FULLY independant.
>
> > That's as seen on a scope, at the pins ?
> > That moves the issue to downstream of the FPGA .
>
> Any answer on the Scope probe at the LED1,LED2  pins ?
>
> -jg

sorry, scope would show the LED1, LED2 signals switching in sync with
with some relatively small skew, perfect no glitch ouput signals

Antti


Article: 125077
Subject: Re: FPGA quiz: what can be wrong
From: "Amontec, Larry" <laurent.gauch@ANTI-SPAMamontec.com>
Date: Tue, 16 Oct 2007 11:55:48 +0200
Links: << >>  << T >>  << A >>
Antti wrote:
> vhdl code
> 
> LED1 <= some_signal;
> LED2 <= blink_one_second;
> 
> the LED1,2 are connected to LED's
> blink_one_second is simple wire that drives LED2 and nothing else.
> 
> now the code works in real FPGA with following behaviour:
> 
> when some_signal = 0, then LED2 blinks.
> when some_signal = 1, then both LEDs blink as full sync to each other.
> 
> what can cause this?
> 
> some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
> 
> eh, the solution to the problem was weird. but it does exist. sure I
> assumed FPGA fabric faulty first as I had overstressed the FPGA with
> 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> working, yet the weird behaviour exist. and this is actually correct
> behaviour in the particular case.
> 
> I wonder if somebody is able to quess the answer to the issue. happy
> thinking!
> 
> Antti
> 

different FPGA production version ?

Article: 125078
Subject: Re: FPGA quiz: what can be wrong
From: Manny <mloulah@hotmail.com>
Date: Tue, 16 Oct 2007 02:58:42 -0700
Links: << >>  << T >>  << A >>
LAST try.

Your I/O driving LED1 is not buffered i.e. no keeper in ucf. So same
input buffering one_second is actually driving LED1 because of the
combinatorial path. The rest of the story is as I speculated earlier---
LED2 is coupling LED1 and only when LED2 is ON LED1 gets properly
biased.


Article: 125079
Subject: Re: FPGA quiz: what can be wrong
From: avrbasic@hotmail.com
Date: Tue, 16 Oct 2007 10:02:07 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 11:55, "Amontec, Larry" <laurent.ga...@ANTI-
SPAMamontec.com> wrote:
> Antti wrote:
> > vhdl code
>
> > LED1 <= some_signal;
> > LED2 <= blink_one_second;
>
> > the LED1,2 are connected to LED's
> > blink_one_second is simple wire that drives LED2 and nothing else.
>
> > now the code works in real FPGA with following behaviour:
>
> > when some_signal = 0, then LED2 blinks.
> > when some_signal = 1, then both LEDs blink as full sync to each other.
>
> > what can cause this?
>
> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>
> > eh, the solution to the problem was weird. but it does exist. sure I
> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> > working, yet the weird behaviour exist. and this is actually correct
> > behaviour in the particular case.
>
> > I wonder if somebody is able to quess the answer to the issue. happy
> > thinking!
>
> > Antti
>
> different FPGA production version ?- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

NO
this issue could be re-created and it would re-appear as described on
FPGA's from many (maybe all) FPGA vendors

it is some FPGA feature that causes it. the reason it happens (in the
case described) is bound to one specific FPGA device family, but
similar case is also thinkable and repeatable on other family and
vendor FPGA with some minor changes (the VHDL code for other FPGA
family would stay the same, essentially single wire)

Antti







Article: 125080
Subject: Re: FPGA quiz: what can be wrong
From: avrbasic@hotmail.com
Date: Tue, 16 Oct 2007 10:04:45 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 11:58, Manny <mlou...@hotmail.com> wrote:
> LAST try.
>
> Your I/O driving LED1 is not buffered i.e. no keeper in ucf. So same
> input buffering one_second is actually driving LED1 because of the
> combinatorial path. The rest of the story is as I speculated earlier---
> LED2 is coupling LED1 and only when LED2 is ON LED1 gets properly
> biased.

eh, giving up SO EASY ???
NO NO NO
the issue is not related the "output device LED"
I only LEDs on FPGA pins as poor man FPGA debug tool, as the FPGA was
99% full, with maybe 9 cell free so I could not use any on-chip
instrumentiation tools

Antti


Article: 125081
Subject: Re: FPGA quiz: what can be wrong
From: Douglas <j.d.morrison@gmail.com>
Date: Tue, 16 Oct 2007 10:16:46 -0000
Links: << >>  << T >>  << A >>
On Oct 16, 8:48 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
> NO
> you do not - this is wrong suggestion. the VHDL code was checked many
> times by different people. there really isnt anything wrong with the
> VHDL, the led_blink signal has no route into the LED1 path
>
>

Nothing wrong with the _VHDL_ - were all other files ok? Especially
constraint files for I/O configuration - could you mis-configure the
on-chip termination/pull-up/I/O standard/drain/hold etc to cause this?
What's the FPGA?

Doug


Article: 125082
Subject: Re: FPGA quiz: what can be wrong
From: avrbasic@hotmail.com
Date: Tue, 16 Oct 2007 10:18:53 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 12:16, Douglas <j.d.morri...@gmail.com> wrote:
> On Oct 16, 8:48 am, Antti <Antti.Luk...@googlemail.com> wrote:
>
>
>
> > NO
> > you do not - this is wrong suggestion. the VHDL code was checked many
> > times by different people. there really isnt anything wrong with the
> > VHDL, the led_blink signal has no route into the LED1 path
>
> Nothing wrong with the _VHDL_ - were all other files ok? Especially
> constraint files for I/O configuration - could you mis-configure the
> on-chip termination/pull-up/I/O standard/drain/hold etc to cause this?
> What's the FPGA?
>
> Doug

yes

VHDL OK OK
constraint files
__all__ other FPGA files OK
FPGA configured properly

Antti






Article: 125083
Subject: Re: FPGA quiz: what can be wrong
From: joerg@zilium.de
Date: Tue, 16 Oct 2007 03:18:55 -0700
Links: << >>  << T >>  << A >>
On Oct 16, 12:04 pm, avrba...@hotmail.com wrote:

Antti,

Does your synthesis tool think of "blink_one_second" as clock signal?
Does it connect to
the clk input at your IOB ?

If that would be true: does your tool think "some_signal" is
syncronous to that clock signal?




  j.




Article: 125084
Subject: Re: FPGA quiz: what can be wrong
From: avrbasic@hotmail.com
Date: Tue, 16 Oct 2007 10:23:21 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 12:18, jo...@zilium.de wrote:
> On Oct 16, 12:04 pm, avrba...@hotmail.com wrote:
>
> Antti,
>
> Does your synthesis tool think of "blink_one_second" as clock signal?
> Does it connect to
> the clk input at your IOB ?
>
> If that would be true: does your tool think "some_signal" is
> syncronous to that clock signal?
>
>   j.

blink_one_second is not treated as clock signal
it is not connected to special clk IOB
FPGA tool does not think the signal are syncronous

as a matter fact the described behaviour could be re-created to
produce described visual behaviour no matter what synthesis/P&R tool
and FPGA device/family is being used.

Antti



Article: 125085
Subject: Re: FPGA quiz: what can be wrong
From: joerg@zilium.de
Date: Tue, 16 Oct 2007 03:51:33 -0700
Links: << >>  << T >>  << A >>
Hi,

Does this effect show up what ever combination of IO pins you choose
for LED1 and LED2?




  j.


Article: 125086
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 10:55:30 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 12:51, jo...@zilium.de wrote:
> Hi,
>
> Does this effect show up what ever combination of IO pins you choose
> for LED1 and LED2?
>
>   j.

YES



Article: 125087
Subject: Re: FPGA quiz: what can be wrong
From: Philip Potter <pgp@see.sig.invalid>
Date: Tue, 16 Oct 2007 12:01:24 +0100
Links: << >>  << T >>  << A >>
Antti wrote:
> vhdl code
> 
> LED1 <= some_signal;
> LED2 <= blink_one_second;
> 
> the LED1,2 are connected to LED's
> blink_one_second is simple wire that drives LED2 and nothing else.
> 
> now the code works in real FPGA with following behaviour:
> 
> when some_signal = 0, then LED2 blinks.
> when some_signal = 1, then both LEDs blink as full sync to each other.
> 
> what can cause this?
> 
> some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
> 
> eh, the solution to the problem was weird. but it does exist. sure I
> assumed FPGA fabric faulty first as I had overstressed the FPGA with
> 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> working, yet the weird behaviour exist. and this is actually correct
> behaviour in the particular case.
> 
> I wonder if somebody is able to quess the answer to the issue. happy
> thinking!
> 
> Antti
> 

I don't understand. You have said:

* No problem in VHDL, constraints, and all other FPGA files
* No problem in configuration
* No problem in PCB, power supply, connections, wiring.

When you say the VHDL file is "correct", to what specification does it 
conform? You haven't said what you *expect* or *require* the VHDL to do. 
  It looks like it should output some_signal to LED1 and 
blink_one_second to LED2 - but this isn't the case when the FPGA is 
configured.

What happens if you remove the blink_one_second signal completely? Does 
LED1 still blink?

-- 
Philip Potter pgp <at> doc.ic.ac.uk

Article: 125088
Subject: Re: FPGA quiz: what can be wrong
From: Bas Laarhoven <sjml@xs4all.nl>
Date: Tue, 16 Oct 2007 13:01:59 +0200
Links: << >>  << T >>  << A >>
Antti wrote:
> 
> I wonder if somebody is able to quess the answer to the issue. happy
> thinking!
> 
> Antti
> 

Somehow the compiler/optimizer thinks 'some_signal' will never reach '1'?
If e.g. both signals route through the same LUT the 'both blinking'  is 
a don't care as far as the compiler is concerned.

-- Bas

Article: 125089
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 11:07:15 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:01, Bas Laarhoven <s...@xs4all.nl> wrote:
> Antti wrote:
>
> > I wonder if somebody is able to quess the answer to the issue. happy
> > thinking!
>
> > Antti
>
> Somehow the compiler/optimizer thinks 'some_signal' will never reach '1'?
> If e.g. both signals route through the same LUT the 'both blinking'  is
> a don't care as far as the compiler is concerned.
>
> -- Bas

its nothing related to compiler (or any FPGA implementation too) to
think something wrong

Antti



Article: 125090
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 11:11:31 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:01, Philip Potter <p...@see.sig.invalid> wrote:
> Antti wrote:
> > vhdl code
>
> > LED1 <= some_signal;
> > LED2 <= blink_one_second;
>
> > the LED1,2 are connected to LED's
> > blink_one_second is simple wire that drives LED2 and nothing else.
>
> > now the code works in real FPGA with following behaviour:
>
> > when some_signal = 0, then LED2 blinks.
> > when some_signal = 1, then both LEDs blink as full sync to each other.
>
> > what can cause this?
>
> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>
> > eh, the solution to the problem was weird. but it does exist. sure I
> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> > working, yet the weird behaviour exist. and this is actually correct
> > behaviour in the particular case.
>
> > I wonder if somebody is able to quess the answer to the issue. happy
> > thinking!
>
> > Antti
>
> I don't understand. You have said:
>
> * No problem in VHDL, constraints, and all other FPGA files
> * No problem in configuration
> * No problem in PCB, power supply, connections, wiring.
>
> When you say the VHDL file is "correct", to what specification does it
> conform? You haven't said what you *expect* or *require* the VHDL to do.
>   It looks like it should output some_signal to LED1 and
> blink_one_second to LED2 - but this isn't the case when the FPGA is
> configured.
>
> What happens if you remove the blink_one_second signal completely? Does
> LED1 still blink?
>
> --
> Philip Potter pgp <at> doc.ic.ac.uk- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

the VHDL code driving LED when entered in schematic would be a single
line going to LED2,

the signal driving LED2 could be disconnected from LED2 IOB or
connected to some other IO or anything else, the LED1 would still have
the same behaviour, it would blink in sync with the signal that was
driving LED2  if some_signal is high, and be constant low if
some_signal is 0

Antti


Article: 125091
Subject: Re: application about hardeware attributes
From: "J.Wild" <diplom@julianwild.de>
Date: Tue, 16 Oct 2007 04:15:40 -0700
Links: << >>  << T >>  << A >>
Hi everyone,
to shorten my request:

What experiences do you have with non-functional requirements? Do you
have examples for these experiences?

I want to invite you to share your knowledge on
http://www-i11.informatik.rwth-aachen.de/2007dajwild/ (the above
mentioned URL will be disabled in a few months).

Thank you,
J. Wild


Article: 125092
Subject: Re: FPGA quiz: what can be wrong
From: Matthieu <m.a.t.t.h.i.e.u.m.i.c.h.o.n@laposte.net>
Date: Tue, 16 Oct 2007 20:23:48 +0900
Links: << >>  << T >>  << A >>
avrbasic@hotmail.com wrote:
> On 16 Okt., 10:08, Matthieu <m.a.t.t.h.i.e.u.m.i.c.h....@laposte.net>
> wrote:
>> Antti wrote:
>>> NO the FPGA is configured all the time
>> Too bad..  :-/
>>
>> You wrote earlier: "let say some_signal comes from external switch
>> directly, and has no FPGA logic except routing."
>>
>> Is the input "some_signal" pulled-up or down with enough strength to
>> maintain this input stable when the external switch is open ?
> 
> it doesnt matter, consider both signals going to LED1, LED2 being
> proper nice signals with no spikes and no glitches. they do not carry
> undefined value at any time
> 
> Antti
> 

What about having the boundary scan (JTAG) implementation shifting the 
value of the output connected to LED2 on the output connected to LED1   ;-)

Article: 125093
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 11:28:06 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:23, Matthieu <m.a.t.t.h.i.e.u.m.i.c.h....@laposte.net>
wrote:
> avrba...@hotmail.com wrote:
> > On 16 Okt., 10:08, Matthieu <m.a.t.t.h.i.e.u.m.i.c.h....@laposte.net>
> > wrote:
> >> Antti wrote:
> >>> NO the FPGA is configured all the time
> >> Too bad..  :-/
>
> >> You wrote earlier: "let say some_signal comes from external switch
> >> directly, and has no FPGA logic except routing."
>
> >> Is the input "some_signal" pulled-up or down with enough strength to
> >> maintain this input stable when the external switch is open ?
>
> > it doesnt matter, consider both signals going to LED1, LED2 being
> > proper nice signals with no spikes and no glitches. they do not carry
> > undefined value at any time
>
> > Antti
>
> What about having the boundary scan (JTAG) implementation shifting the
> value of the output connected to LED2 on the output connected to LED1   ;-)- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

NO that isnt the case either, the same behaviour would appear no
matter to what IO pads the LED1, LED2 are locked

Antti


Article: 125094
Subject: Re: FPGA quiz: what can be wrong
From: Brian Davis <brimdavis@aol.com>
Date: Tue, 16 Oct 2007 04:29:09 -0700
Links: << >>  << T >>  << A >>
Antti wrote:
>
> the signal driving LED2 could be disconnected from LED2 IOB or
> connected to some other IO or anything else, the LED1 would still have
> the same behaviour, it would blink in sync with the signal that was
> driving LED2  if some_signal is high, and be constant low if
> some_signal is 0
>

 What are the I/O standards and VCCO used for the two pins?

 Are they the same, or are they in different banks ?

 If you optically isolate the two LED's so LED1 can't see LED2,
does the problem go away ? ( i.e. one LED is almost but not quite
biased on, incident light from the other LED pushes it over the edge)

Brian


Article: 125095
Subject: Re: FPGA quiz: what can be wrong
From: "Amontec, Larry" <laurent.gauch@ANTI-SPAMamontec.com>
Date: Tue, 16 Oct 2007 13:32:29 +0200
Links: << >>  << T >>  << A >>
Antti wrote:
> vhdl code
> 
> LED1 <= some_signal;
> LED2 <= blink_one_second;
> 
> the LED1,2 are connected to LED's
> blink_one_second is simple wire that drives LED2 and nothing else.
> 
> now the code works in real FPGA with following behaviour:
> 
> when some_signal = 0, then LED2 blinks.
> when some_signal = 1, then both LEDs blink as full sync to each other.
> 
> what can cause this?
> 
> some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
> 
> eh, the solution to the problem was weird. but it does exist. sure I
> assumed FPGA fabric faulty first as I had overstressed the FPGA with
> 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> working, yet the weird behaviour exist. and this is actually correct
> behaviour in the particular case.
> 
> I wonder if somebody is able to quess the answer to the issue. happy
> thinking!
> 
> Antti
> 

Not the VHDL
Not the UCF
Not the synth.
Not the P/R
Not FPGA fabric
Not the supply
Not the PCB
Not the Led
Not the FPGA version
Not the FPGA vendor
Not the DCI
Not the DCM
Not the Ground Loop
Not Coupling issue
Not the LED itself
...

Maybe in Absolute Maximum Rating ?
You are stocking your FPGA boards under -65 Celcius ;-) (storage 
temperature) just funny

----------------------
More serious: Junction temperature ?
----------------------

- Laurent
   www.amontec.com

Article: 125096
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 11:35:42 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:32, "Amontec, Larry" <laurent.ga...@ANTI-
SPAMamontec.com> wrote:
> Antti wrote:
> > vhdl code
>
> > LED1 <= some_signal;
> > LED2 <= blink_one_second;
>
> > the LED1,2 are connected to LED's
> > blink_one_second is simple wire that drives LED2 and nothing else.
>
> > now the code works in real FPGA with following behaviour:
>
> > when some_signal = 0, then LED2 blinks.
> > when some_signal = 1, then both LEDs blink as full sync to each other.
>
> > what can cause this?
>
> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>
> > eh, the solution to the problem was weird. but it does exist. sure I
> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> > working, yet the weird behaviour exist. and this is actually correct
> > behaviour in the particular case.
>
> > I wonder if somebody is able to quess the answer to the issue. happy
> > thinking!
>
> > Antti
>
> Not the VHDL
> Not the UCF
> Not the synth.
> Not the P/R
> Not FPGA fabric
> Not the supply
> Not the PCB
> Not the Led
> Not the FPGA version
> Not the FPGA vendor
> Not the DCI
> Not the DCM
> Not the Ground Loop
> Not Coupling issue
> Not the LED itself
> ...
>
> Maybe in Absolute Maximum Rating ?
> You are stocking your FPGA boards under -65 Celcius ;-) (storage
> temperature) just funny
>
> ----------------------
> More serious: Junction temperature ?
> ----------------------
>
> - Laurent
>    www.amontec.com- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

no temperature
no environment issue

Antti





From laurent.pinchart@skynet.be Tue Oct 16 04:38:11 2007
Path: newssvr25.news.prodigy.net!newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin1!goblin.stu.neva.ru!feeder.news-service.com!feed.xsnews.nl!border-1.ams.xsnews.nl!68.142.88.75.MISMATCH!hwmnpeer01.ams!news.highwinds-media.com!kramikske.telenet-ops.be!nntp.telenet.be!news.skynet.be!195.238.0.222.MISMATCH!newsspl501.isp.belgacom.be!tjb!not-for-mail
Message-Id: <4714a2a3$0$22307$ba620e4c@news.skynet.be>
From: Laurent Pinchart <laurent.pinchart@skynet.be>
Subject: Re: FPGA quiz: what can be wrong
Newsgroups: comp.arch.fpga
Date: Tue, 16 Oct 2007 13:38:11 +0200
References: <1192462938.206319.120810@i13g2000prf.googlegroups.com> <ff25m4$onn$1@aioe.org> <1192533091.696838.39990@v29g2000prd.googlegroups.com>
User-Agent: KNode/0.10.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 66
Organization: -= Belgacom Usenet Service =-
NNTP-Posting-Host: 02627e60.news.skynet.be
X-Trace: 1192534691 news.skynet.be 22307 194.78.198.49:57702
X-Complaints-To: usenet-abuse@skynet.be
Xref: prodigy.net comp.arch.fpga:137082

Antti wrote:

> On 16 Okt., 13:01, Philip Potter <p...@see.sig.invalid> wrote:
>> Antti wrote:
>> > vhdl code
>>
>> > LED1 <= some_signal;
>> > LED2 <= blink_one_second;
>>
>> > the LED1,2 are connected to LED's
>> > blink_one_second is simple wire that drives LED2 and nothing else.
>>
>> > now the code works in real FPGA with following behaviour:
>>
>> > when some_signal = 0, then LED2 blinks.
>> > when some_signal = 1, then both LEDs blink as full sync to each other.
>>
>> > what can cause this?
>>
>> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>>
>> > eh, the solution to the problem was weird. but it does exist. sure I
>> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
>> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
>> > working, yet the weird behaviour exist. and this is actually correct
>> > behaviour in the particular case.
>>
>> > I wonder if somebody is able to quess the answer to the issue. happy
>> > thinking!
>>
>> > Antti
>>
>> I don't understand. You have said:
>>
>> * No problem in VHDL, constraints, and all other FPGA files
>> * No problem in configuration
>> * No problem in PCB, power supply, connections, wiring.
>>
>> When you say the VHDL file is "correct", to what specification does it
>> conform? You haven't said what you *expect* or *require* the VHDL to do.
>>   It looks like it should output some_signal to LED1 and
>> blink_one_second to LED2 - but this isn't the case when the FPGA is
>> configured.
>>
>> What happens if you remove the blink_one_second signal completely? Does
>> LED1 still blink?
>>
>> --
>> Philip Potter pgp <at> doc.ic.ac.uk- Zitierten Text ausblenden -
>>
>> - Zitierten Text anzeigen -
> 
> the VHDL code driving LED when entered in schematic would be a single
> line going to LED2,
> 
> the signal driving LED2 could be disconnected from LED2 IOB or
> connected to some other IO or anything else, the LED1 would still have
> the same behaviour, it would blink in sync with the signal that was
> driving LED2  if some_signal is high, and be constant low if
> some_signal is 0

If you desolder LED2 from the board, would LED1 still blink in sync with the
signal at the LED2 I/O pad when some_signal is low ?

Laurent Pinchart


Article: 125097
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 11:39:04 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:29, Brian Davis <brimda...@aol.com> wrote:
> Antti wrote:
>
> > the signal driving LED2 could be disconnected from LED2 IOB or
> > connected to some other IO or anything else, the LED1 would still have
> > the same behaviour, it would blink in sync with the signal that was
> > driving LED2  if some_signal is high, and be constant low if
> > some_signal is 0
>
>  What are the I/O standards and VCCO used for the two pins?
>
>  Are they the same, or are they in different banks ?
>
>  If you optically isolate the two LED's so LED1 can't see LED2,
> does the problem go away ? ( i.e. one LED is almost but not quite
> biased on, incident light from the other LED pushes it over the edge)
>
> Brian

wau, also good guesses!!

the io banking is not issue
the io standard is ir-relevant
also not the supply to different banks
there is no opto coupling issue
the same behaviour on pads could be observed with no connections (no
LED)

Antti






Article: 125098
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 11:41:16 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:38, Laurent Pinchart <laurent.pinch...@skynet.be>
wrote:
> Antti wrote:
> > On 16 Okt., 13:01, Philip Potter <p...@see.sig.invalid> wrote:
> >> Antti wrote:
> >> > vhdl code
>
> >> > LED1 <= some_signal;
> >> > LED2 <= blink_one_second;
>
> >> > the LED1,2 are connected to LED's
> >> > blink_one_second is simple wire that drives LED2 and nothing else.
>
> >> > now the code works in real FPGA with following behaviour:
>
> >> > when some_signal = 0, then LED2 blinks.
> >> > when some_signal = 1, then both LEDs blink as full sync to each other.
>
> >> > what can cause this?
>
> >> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>
> >> > eh, the solution to the problem was weird. but it does exist. sure I
> >> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
> >> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> >> > working, yet the weird behaviour exist. and this is actually correct
> >> > behaviour in the particular case.
>
> >> > I wonder if somebody is able to quess the answer to the issue. happy
> >> > thinking!
>
> >> > Antti
>
> >> I don't understand. You have said:
>
> >> * No problem in VHDL, constraints, and all other FPGA files
> >> * No problem in configuration
> >> * No problem in PCB, power supply, connections, wiring.
>
> >> When you say the VHDL file is "correct", to what specification does it
> >> conform? You haven't said what you *expect* or *require* the VHDL to do.
> >>   It looks like it should output some_signal to LED1 and
> >> blink_one_second to LED2 - but this isn't the case when the FPGA is
> >> configured.
>
> >> What happens if you remove the blink_one_second signal completely? Does
> >> LED1 still blink?
>
> >> --
> >> Philip Potter pgp <at> doc.ic.ac.uk- Zitierten Text ausblenden -
>
> >> - Zitierten Text anzeigen -
>
> > the VHDL code driving LED when entered in schematic would be a single
> > line going to LED2,
>
> > the signal driving LED2 could be disconnected from LED2 IOB or
> > connected to some other IO or anything else, the LED1 would still have
> > the same behaviour, it would blink in sync with the signal that was
> > driving LED2  if some_signal is high, and be constant low if
> > some_signal is 0
>
> If you desolder LED2 from the board, would LED1 still blink in sync with the
> signal at the LED2 I/O pad when some_signal is low ?
>
> Laurent Pinchart- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

read my posting again
when some_signal is 0, then only LED2 blinks
when some_signal is 1, then both LEDs blink

the actual connection of the LEDs has influence to the behaviour

Antti




From laurent.pinchart@skynet.be Tue Oct 16 04:42:39 2007
Path: newssvr25.news.prodigy.net!newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!goblin2!goblin.stu.neva.ru!feeder2.ecngs.de!ecngs!feeder.ecngs.de!feed1.news.be.easynet.net!news.skynet.be!195.238.0.222.MISMATCH!newsspl501.isp.belgacom.be!tjb!not-for-mail
Message-Id: <4714a3af$0$22307$ba620e4c@news.skynet.be>
From: Laurent Pinchart <laurent.pinchart@skynet.be>
Subject: Re: FPGA quiz2: spartan3A return Virtex JTAGID. Also prizes for quiz1 and quiz2
Newsgroups: comp.arch.fpga
Date: Tue, 16 Oct 2007 13:42:39 +0200
References: <1192516229.210765.81880@i38g2000prf.googlegroups.com> <47146d74$0$22318$ba620e4c@news.skynet.be> <1192521253.554269.233090@k35g2000prh.googlegroups.com> <471473a0$0$22304$ba620e4c@news.skynet.be> <1192526478.079175.263900@k35g2000prh.googlegroups.com>
User-Agent: KNode/0.10.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 48
Organization: -= Belgacom Usenet Service =-
NNTP-Posting-Host: 02627e60.news.skynet.be
X-Trace: 1192534959 news.skynet.be 22307 194.78.198.49:57702
X-Complaints-To: usenet-abuse@skynet.be
Xref: prodigy.net comp.arch.fpga:137086

 avrbasic@hotmail.com wrote:

> On 16 Okt., 10:17, Laurent Pinchart <laurent.pinch...@skynet.be>
> wrote:
>> Antti wrote:
>> > On 16 Okt., 09:51, Laurent Pinchart <laurent.pinch...@skynet.be>
>> > wrote:
>> >> Antti wrote:
>> >> > Xilinx Spartan3A on custom PCB.
>> >> > was working ok
>> >> > was stressed VCCINT=1.8V (regulator IC current limit 150ma)
>> >> > it does configure ok from external configuration memory
>>
>> >> > JTAG scan returns JTAGID from Virtex-II family.
>>
>> >> > what is wrong?
>>
>> >> Delays in the JTAG chain that shift the data by 1 bit ? Was the JTAGID
>> >> manufacturer field still the Xilinx ID ?
>>
>> >> Laurent Pinchart
>>
>> > JTAG ID returned
>> > vendor Xilinx
>> > family Virtex-II
>> > device 0 (invalid)
>>
>> > this same (wrong!) JTAGID returned all the time
>>
>> TDO driven by more than one component ? If two Xilinx parts drive TDO in
>> sync (instead of being properly chained) conflicts will occur for the
>> family and device ID by not the vendor ID.
>>
>> Laurent Pinchart- Zitierten Text ausblenden -
>>
>> - Zitierten Text anzeigen -
> 
> single IC chain
> 
> Antti
> (sorry for posting from different account, google goups asserted temp.
> block on my primary account)

Could the family and device ID be stored as some kind of fuses that got
burnt when VCCINT was raised to 1.8V ?

Laurent Pinchart


Article: 125099
Subject: Re: FPGA quiz: what can be wrong
From: Antti <Antti.Lukats@googlemail.com>
Date: Tue, 16 Oct 2007 11:43:03 -0000
Links: << >>  << T >>  << A >>
On 16 Okt., 13:41, Antti <Antti.Luk...@googlemail.com> wrote:
> On 16 Okt., 13:38, Laurent Pinchart <laurent.pinch...@skynet.be>
> wrote:
>
>
>
>
>
> > Antti wrote:
> > > On 16 Okt., 13:01, Philip Potter <p...@see.sig.invalid> wrote:
> > >> Antti wrote:
> > >> > vhdl code
>
> > >> > LED1 <= some_signal;
> > >> > LED2 <= blink_one_second;
>
> > >> > the LED1,2 are connected to LED's
> > >> > blink_one_second is simple wire that drives LED2 and nothing else.
>
> > >> > now the code works in real FPGA with following behaviour:
>
> > >> > when some_signal = 0, then LED2 blinks.
> > >> > when some_signal = 1, then both LEDs blink as full sync to each other.
>
> > >> > what can cause this?
>
> > >> > some wrong answers: faulty FPGA fabric, bad PCB, bad power supply.
>
> > >> > eh, the solution to the problem was weird. but it does exist. sure I
> > >> > assumed FPGA fabric faulty first as I had overstressed the FPGA with
> > >> > 5V supply, and reversed 3.3V supply too. but FPGA is alive and fully
> > >> > working, yet the weird behaviour exist. and this is actually correct
> > >> > behaviour in the particular case.
>
> > >> > I wonder if somebody is able to quess the answer to the issue. happy
> > >> > thinking!
>
> > >> > Antti
>
> > >> I don't understand. You have said:
>
> > >> * No problem in VHDL, constraints, and all other FPGA files
> > >> * No problem in configuration
> > >> * No problem in PCB, power supply, connections, wiring.
>
> > >> When you say the VHDL file is "correct", to what specification does it
> > >> conform? You haven't said what you *expect* or *require* the VHDL to do.
> > >>   It looks like it should output some_signal to LED1 and
> > >> blink_one_second to LED2 - but this isn't the case when the FPGA is
> > >> configured.
>
> > >> What happens if you remove the blink_one_second signal completely? Does
> > >> LED1 still blink?
>
> > >> --
> > >> Philip Potter pgp <at> doc.ic.ac.uk- Zitierten Text ausblenden -
>
> > >> - Zitierten Text anzeigen -
>
> > > the VHDL code driving LED when entered in schematic would be a single
> > > line going to LED2,
>
> > > the signal driving LED2 could be disconnected from LED2 IOB or
> > > connected to some other IO or anything else, the LED1 would still have
> > > the same behaviour, it would blink in sync with the signal that was
> > > driving LED2  if some_signal is high, and be constant low if
> > > some_signal is 0
>
> > If you desolder LED2 from the board, would LED1 still blink in sync with the
> > signal at the LED2 I/O pad when some_signal is low ?
>
> > Laurent Pinchart- Zitierten Text ausblenden -
>
> > - Zitierten Text anzeigen -
>
> read my posting again
> when some_signal is 0, then only LED2 blinks
> when some_signal is 1, then both LEDs blink
>
> the actual connection of the LEDs has influence to the behaviour
>
> Antti- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

ups sorry, my mistypo: should read: the actual connection of the LED's
has _no_ influence on the signal behaviour.
sorry

Antti







Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMar2019

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search