Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
>> 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 ? -jgArticle: 125076
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 AnttiArticle: 125077
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
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
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) AnttiArticle: 125080
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 AnttiArticle: 125081
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? DougArticle: 125082
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 AnttiArticle: 125083
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
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. AnttiArticle: 125085
Hi, Does this effect show up what ever combination of IO pins you choose for LED1 and LED2? j.Article: 125086
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. YESArticle: 125087
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.ukArticle: 125088
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. -- BasArticle: 125089
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 AnttiArticle: 125090
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 AnttiArticle: 125091
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. WildArticle: 125092
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
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 AnttiArticle: 125094
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) BrianArticle: 125095
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.comArticle: 125096
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 PinchartArticle: 125097
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) AnttiArticle: 125098
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 PinchartArticle: 125099
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:
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