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
>
> (serious snippage above)
>
> You are trying to build with a mixture of 7.0 and 7.2 components.
>
> That will NOT work, web-pack or subscription. At least it never has
> for me...
>
> G.
>
I thought that might be the problem after I posted so I upgraded to
v7.2. I still got errors so I tried a clean install on a different PC.
The errors are different this time, but I had thought maybe it was still
the license issue so I didn't update. I also tried different builds with
different components. All I really need is the SDRAM controller but it
says I need the avalon master if that's all I select. So I guess I need
the NIOS processor, on-board memory, and SDRAM. With those selected, I
get the errors below.
Thanks for your help,
Eric
-----------------
Info: Info: Elapsed time: 00:00:00
Info: Starting PTF file elaboration.
3 [main] sh 4480 fork: child 4880 - died waiting for longjmp
before initialization, errno 11
c:/altera/72/quartus/sopc_builder/bin/nios_sh: fork: Resource
temporarily unavailable
.
.
.
c:/altera/72/quartus/sopc_builder/bin/nios_sh: fork: Resource
temporarily unavailable
Error: System generation failed.
Article: 125051Antti schrieb: > 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. > Hi Antti, what is considered as a bad PCB? And what as a bad power supply? My guess would be that you have voltage drops on some of the GND or VCC lines. Maybe the circuit draws high currents synchronous to the blinking LED, causing the LED1 to blink too. This can even happen when you are using ground/vcc planes with an unlucky placement. regards EilertArticle: 125052
Nevermind, I read in another section of the thread that it wasn't a code problem. ---Matthew Hicks > Why don't you show a more meanngful code snippet? > > ---Matthew Hicks > >> On 16 Okt., 03:45, "MM" <mb...@yahoo.com> wrote: >> >>> "Antti" <Antti.Luk...@googlemail.com> wrote in message >>> >>> news:1192473204.719381.50050@t8g2000prg.googlegroups.com... >>> >>>> eh, but no one is getting closer to my issue. >>>> another hint, no flip flip or any sync logic thing is causing this >>>> problem. >>>> its also not in any way some compiler or P&R weirdness at all. >>> I think you should explain how the LEDs are connected. I don't think >>> what you are describing would be possible if the LEDs were connected >>> through individual current-limiting resistors with their anodes to >>> FPGA pins and with their cathodes to GND. Also, I assume no FPGA >>> special-purpose pins are involved... >>> >>> /Mikhail >>> >> FPGA_pin - RESISTOR - LED - GND >> >> but as said the LED connection really had nothing todo with the issue >>Article: 125053
On 16 Okt., 08:41, backhus <n...@nirgends.xyz> wrote: > Antti schrieb: > > > > > 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. > > Hi Antti, > what is considered as a bad PCB? And what as a bad power supply? > > My guess would be that you have voltage drops on some of the GND or VCC > lines. Maybe the circuit draws high currents synchronous to the blinking > LED, causing the LED1 to blink too. This can even happen when you are > using ground/vcc planes with an unlucky placement. > > regards > Eilert- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - nothing on PCB and nothing related with power supply has anything todo with the issue AnttiArticle: 125054
Could it have anything to do with your FPGA I/O simultaneous switching power merit for that particular I/O bank?Article: 125055
when Debug in NIOS II,,the waring message is :RTM ERROR:fail to get the remote thread list.. why?Article: 125056
Antti wrote: > On 16 Okt., 05:01, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>Antti wrote: >> >>>On 15 Okt., 20:26, "MM" <mb...@yahoo.com> wrote: >> >>>>I had a somewhat similar puzzle quite a few years ago. The code had a >>>>flip-flop generating out1 and an async assignment out2 = not out1. The two >>>>outputs were driving external buffers. Somehow the outputs got enabled >>>>together and the buffers smoked. I traced the problem to the synthesizer >>>>setting, which created another flop for the out2 and moved negation to its >>>>input. I don't remember all the details now, but IIRC the clock was missing >>>>for whatever reason when I first powered the board... Apparently debugging >>>>that board was my first assignment at a new job. Imagine how I felt when it >>>>smoked :) >> >>>>/Mikhail >> >>>eh, but no one is getting closer to my issue. >>>another hint, no flip flip or any sync logic thing is causing this >>>problem. >>>its also not in any way some compiler or P&R weirdness at all. >> >> Candidates are >>* Post-Pin error - Verifiable by checking the PIN levels, and >>dual-mapping the outputs. >>* Config/Mapping error (eg terminator enabled by accident, really slow >>clock etc ) >>* Logic Error. If the FPGA is OK, and the Compile/P&R is also OK >> that leaves the classic 'Cockpit error' >> >>-jg- Zitierten Text ausblenden - >> >>- Zitierten Text anzeigen - > > > NO > NO > NO > > all FPGA tools did exact and correct and proper job. no fuzz. > > in the matter of fact IF the LED behaviour would have been any > different then that would have been an ERROR. > > so the described behaviour of the signals named LED1 and LED2 was > CORRECT behavior. So, a scope applied per my first item shows what ? 'Correct' is what ? To me, correct is LED1 = ON; LED2 = blink_one_second; ie one signal, from your first description is supposed to be fully independant of oneSecond, and dependant ONLY on SomeSignal. From the results description there is some "errant coupling", and LED1 is clearly dependant on One-Second, or at least a One-Second clock. Conclusion: Insufficent information. -jgArticle: 125057
Marlboro schrieb: > On Oct 15, 1:22 am, backhus <n...@nirgends.xyz> wrote: >> Hi, >> Your transmitter is sending 640kbit/s, but your receiver is reading only >> 480kbit/s. With a continous operation on both sides your fifo needs to >> be infinite. >> >> Missing data: Are there gaps in the transmitted data stream or some sort >> of handshake? >> >> The average transmitted data has to be below 480kbit/s. It depends on >> the method that is used to reduce the transmitters data rate how to >> calculate the fifo size. >> >> have a nice synthesis >> Eilert >> >> vishnuprasa...@gmail.com schrieb: >> >> >> >>> I have doubt in calculating FIFO depth. >>> Transmitter is writing 16 bit data with a frequency of 40 KHz. >>> Receiver is reading 8 bit data with a frequency of 60 KHz. >>> What is the depth of FIFO I need to use and how I need to calculate >>> the FIFO depth?- Hide quoted text - >> - Show quoted text - > > I can't afford infinite fifo > That's just a question of marketing... :-) Let the custumer pay (e.g.) 1,00$ for every Transmitted bit, and offer him a payback of 1,10$ for every received bit assuming the given datarates with no gaps or idles! Then you can easyly update the system with any ammount of fifo needed, until the cusumer is broke. For the beginning I woud implement a FIFO-Subsystem with a 500GB HDD. It's considerably cheap, and with the above contract you are soon quite rich. after second 1: 640000$ - 528000$ = 112000$ earned after one hour: 403.2 Million Dollars earned After one Day: 9.67 Billion Dollars earned You can afford all the FIFOs in the world now! Good Luck :-) EilertArticle: 125058
Antti wrote: > LED1 <= some_signal; > LED2 <= blink_one_second; > > 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? I will try again ;) Could the signal "blink_one_second" when held low, deconfigure the FPGA and delay it's reconfiguration only once this signal goes back to a high level ?Article: 125059
On 16 Okt., 09:38, Matthieu <m.a.t.t.h.i.e.u.m.i.c.h....@laposte.net> wrote: > Antti wrote: > > LED1 <= some_signal; > > LED2 <= blink_one_second; > > > 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? > > I will try again ;) > > Could the signal "blink_one_second" when held low, deconfigure the FPGA > and delay it's reconfiguration only once this signal goes back to a high > level ? NO the FPGA is configured all the timeArticle: 125060
On 16 Okt., 08:52, Manny <mlou...@hotmail.com> wrote: > Could it have anything to do with your FPGA I/O simultaneous switching > power merit for that particular I/O bank? No From laurent.pinchart@skynet.be Tue Oct 16 00:51:16 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!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!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: <47146d74$0$22318$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 09:51:16 +0200 References: <1192516229.210765.81880@i38g2000prf.googlegroups.com> User-Agent: KNode/0.10.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 16 Organization: -= Belgacom Usenet Service =- NNTP-Posting-Host: e88d2d05.news.skynet.be X-Trace: 1192521076 news.skynet.be 22318 194.78.198.49:60699 X-Complaints-To: usenet-abuse@skynet.be Xref: prodigy.net comp.arch.fpga:137044 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 PinchartArticle: 125061
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 timeArticle: 125062
On 16 Okt., 08:38, Matthew Hicks <mdhic...@uiuc.edu> wrote: > Why don't you show a more meanngful code snippet? > > ---Matthew Hicks > there isnt any to show, really the signal driving LED2 comes from FPGA primitive and goes to LED2 IOB. the signal is not going anywhere else. So there is no code, just 1 point to point connection. it was in VHDL, but I could also do it in schematic, it would be 1 single stright wire and nothing else.Article: 125063
On 16 Okt., 09:04, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Antti wrote: > > On 16 Okt., 05:01, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > > >>Antti wrote: > > >>>On 15 Okt., 20:26, "MM" <mb...@yahoo.com> wrote: > > >>>>I had a somewhat similar puzzle quite a few years ago. The code had a > >>>>flip-flop generating out1 and an async assignment out2 = not out1. The two > >>>>outputs were driving external buffers. Somehow the outputs got enabled > >>>>together and the buffers smoked. I traced the problem to the synthesizer > >>>>setting, which created another flop for the out2 and moved negation to its > >>>>input. I don't remember all the details now, but IIRC the clock was missing > >>>>for whatever reason when I first powered the board... Apparently debugging > >>>>that board was my first assignment at a new job. Imagine how I felt when it > >>>>smoked :) > > >>>>/Mikhail > > >>>eh, but no one is getting closer to my issue. > >>>another hint, no flip flip or any sync logic thing is causing this > >>>problem. > >>>its also not in any way some compiler or P&R weirdness at all. > > >> Candidates are > >>* Post-Pin error - Verifiable by checking the PIN levels, and > >>dual-mapping the outputs. > >>* Config/Mapping error (eg terminator enabled by accident, really slow > >>clock etc ) > >>* Logic Error. If the FPGA is OK, and the Compile/P&R is also OK > >> that leaves the classic 'Cockpit error' > > >>-jg- Zitierten Text ausblenden - > > >>- Zitierten Text anzeigen - > > > NO > > NO > > NO > > > all FPGA tools did exact and correct and proper job. no fuzz. > > > in the matter of fact IF the LED behaviour would have been any > > different then that would have been an ERROR. > > > so the described behaviour of the signals named LED1 and LED2 was > > CORRECT behavior. > > So, a scope applied per my first item shows what ? > 'Correct' is what ? > > To me, correct is > LED1 = ON; > LED2 = blink_one_second; > > ie one signal, from your first description is supposed to be > fully independant of oneSecond, and dependant ONLY on SomeSignal. > From the results description there is some "errant coupling", > and LED1 is clearly dependant on One-Second, or at least a One-Second > clock. > > Conclusion: Insufficent information. > > -jg- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Hi Jim, yes the signals are FULLY independant. there is no ERRANT coupling, I myself also looked for the this coupling but it really isnt there. as I made already REAL PRIZE (fpga miniconsole) for the first answer (or question close enough) so I will not reveal the answer or any other information as reply to direct question. there is a explanation. and I am really glad I did solve the issue without going nuts. AnttiArticle: 125064
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 > DCM ?Article: 125065
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 ?Article: 125066
Ok here is my plausible version of the story: Your LED1 is weakly (marginally) forward biased when some_signal is high. The trace of LED2 is capacitively coupled with that of LED1. The duty cycle of blink_one_second is 1 sec. Now while LED2 is ON, a negative potential appears at the ground of LED2 (momentarily) with respect to the ground of LED1 causing a transient current to flow through LED1 until the "standing capacitance" between the two is charged and hence the blinking. When blink_one_second goes OFF, the operation is reset and LED1 goes OFF as well because the weak bias can't turn it ON without the extra kick of the capacitive coupling. Too dramatic I know :). From laurent.pinchart@skynet.be Tue Oct 16 01:17:36 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!eweka.nl!hq-usenetpeers.eweka.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: <471473a0$0$22304$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 10:17:36 +0200 References: <1192516229.210765.81880@i38g2000prf.googlegroups.com> <47146d74$0$22318$ba620e4c@news.skynet.be> <1192521253.554269.233090@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: 32 Organization: -= Belgacom Usenet Service =- NNTP-Posting-Host: 8d3b20a8.news.skynet.be X-Trace: 1192522657 news.skynet.be 22304 194.78.198.49:64623 X-Complaints-To: usenet-abuse@skynet.be Xref: prodigy.net comp.arch.fpga:137051 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 PinchartArticle: 125067
Antti wrote: > On 16 Okt., 09:04, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > >>Antti wrote: >> >>>On 16 Okt., 05:01, Jim Granville <no.s...@designtools.maps.co.nz> >>>wrote: >> >>>>Antti wrote: >> >>>>>On 15 Okt., 20:26, "MM" <mb...@yahoo.com> wrote: >> >>>>>>I had a somewhat similar puzzle quite a few years ago. The code had a >>>>>>flip-flop generating out1 and an async assignment out2 = not out1. The two >>>>>>outputs were driving external buffers. Somehow the outputs got enabled >>>>>>together and the buffers smoked. I traced the problem to the synthesizer >>>>>>setting, which created another flop for the out2 and moved negation to its >>>>>>input. I don't remember all the details now, but IIRC the clock was missing >>>>>>for whatever reason when I first powered the board... Apparently debugging >>>>>>that board was my first assignment at a new job. Imagine how I felt when it >>>>>>smoked :) >> >>>>>>/Mikhail >> >>>>>eh, but no one is getting closer to my issue. >>>>>another hint, no flip flip or any sync logic thing is causing this >>>>>problem. >>>>>its also not in any way some compiler or P&R weirdness at all. >> >>>> Candidates are >>>>* Post-Pin error - Verifiable by checking the PIN levels, and >>>>dual-mapping the outputs. >>>>* Config/Mapping error (eg terminator enabled by accident, really slow >>>>clock etc ) >>>>* Logic Error. If the FPGA is OK, and the Compile/P&R is also OK >>>> that leaves the classic 'Cockpit error' >> >>>>-jg- Zitierten Text ausblenden - >> >>>>- Zitierten Text anzeigen - >> >>>NO >>>NO >>>NO >> >>>all FPGA tools did exact and correct and proper job. no fuzz. >> >>>in the matter of fact IF the LED behaviour would have been any >>>different then that would have been an ERROR. >> >>>so the described behaviour of the signals named LED1 and LED2 was >>>CORRECT behavior. >> >>So, a scope applied per my first item shows what ? >>'Correct' is what ? >> >>To me, correct is >>LED1 = ON; >>LED2 = blink_one_second; >> >>ie one signal, from your first description is supposed to be >>fully independant of oneSecond, and dependant ONLY on SomeSignal. >> From the results description there is some "errant coupling", >>and LED1 is clearly dependant on One-Second, or at least a One-Second >>clock. >> >>Conclusion: Insufficent information. >> >>-jg- Zitierten Text ausblenden - >> >>- Zitierten Text anzeigen - > > > 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 . > there is no ERRANT coupling, I myself also looked for the this > coupling but it really isnt there. > > as I made already REAL PRIZE (fpga miniconsole) for the first answer > (or question close enough) so I will not reveal the answer or any > other information as reply to direct question. > > there is a explanation. and I am really glad I did solve the issue > without going nuts. Now you are contradicting yourself. You have stated there is no coupling in code, and P&R/FPGA is OK The Visual operation is not as you described expecting, logically. So, not working as logically described, means some errant coupling, or dependance. (it does not have to be inside the FPGA, just somewhere between your eyeballs, and the source code ! :) I thought the quizz was to find the errant cause, but now you state "there is no ERRANT coupling" - does that mean you imagined it ? -jgArticle: 125068
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)Article: 125069
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 AnttiArticle: 125070
On 16 Okt., 10:12, Manny <mlou...@hotmail.com> wrote: > Ok here is my plausible version of the story: > > Your LED1 is weakly (marginally) forward biased when some_signal is > high. The trace of LED2 is capacitively coupled with that of LED1. The > duty cycle of blink_one_second is 1 sec. Now while LED2 is ON, a > negative potential appears at the ground of LED2 (momentarily) with > respect to the ground of LED1 causing a transient current to flow > through LED1 until the "standing capacitance" between the two is > charged and hence the blinking. When blink_one_second goes OFF, the > operation is reset and LED1 goes OFF as well because the weak bias > can't turn it ON without the extra kick of the capacitive coupling. > > Too dramatic I know :). you say it, too dramatic. the issue is much more "elegant" in solutionArticle: 125071
There's got to be some coupling somewhere. Is 'errant' coupling just bad VHDL code? My guesses are (1) the cathodes of LED1 and LED2 have a high-impedance connection to GND, possibly via an input structure on the FPGA (the LED1 input switch?). Of course, this means that there's a PCB error, and I think you said the PCB was Ok. This isn't enough to explain what you're seeing, but maybe you created an SCR in the input structure when you fried it, or (2) you created some output pin coupling when you fried the chip, presumably through the Vcco protection diodes. EvanArticle: 125072
On 16 Okt., 10:35, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Antti wrote: > > On 16 Okt., 09:04, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote: > > >>Antti wrote: > > >>>On 16 Okt., 05:01, Jim Granville <no.s...@designtools.maps.co.nz> > >>>wrote: > > >>>>Antti wrote: > > >>>>>On 15 Okt., 20:26, "MM" <mb...@yahoo.com> wrote: > > >>>>>>I had a somewhat similar puzzle quite a few years ago. The code had a > >>>>>>flip-flop generating out1 and an async assignment out2 = not out1. The two > >>>>>>outputs were driving external buffers. Somehow the outputs got enabled > >>>>>>together and the buffers smoked. I traced the problem to the synthesizer > >>>>>>setting, which created another flop for the out2 and moved negation to its > >>>>>>input. I don't remember all the details now, but IIRC the clock was missing > >>>>>>for whatever reason when I first powered the board... Apparently debugging > >>>>>>that board was my first assignment at a new job. Imagine how I felt when it > >>>>>>smoked :) > > >>>>>>/Mikhail > > >>>>>eh, but no one is getting closer to my issue. > >>>>>another hint, no flip flip or any sync logic thing is causing this > >>>>>problem. > >>>>>its also not in any way some compiler or P&R weirdness at all. > > >>>> Candidates are > >>>>* Post-Pin error - Verifiable by checking the PIN levels, and > >>>>dual-mapping the outputs. > >>>>* Config/Mapping error (eg terminator enabled by accident, really slow > >>>>clock etc ) > >>>>* Logic Error. If the FPGA is OK, and the Compile/P&R is also OK > >>>> that leaves the classic 'Cockpit error' > > >>>>-jg- Zitierten Text ausblenden - > > >>>>- Zitierten Text anzeigen - > > >>>NO > >>>NO > >>>NO > > >>>all FPGA tools did exact and correct and proper job. no fuzz. > > >>>in the matter of fact IF the LED behaviour would have been any > >>>different then that would have been an ERROR. > > >>>so the described behaviour of the signals named LED1 and LED2 was > >>>CORRECT behavior. > > >>So, a scope applied per my first item shows what ? > >>'Correct' is what ? > > >>To me, correct is > >>LED1 = ON; > >>LED2 = blink_one_second; > > >>ie one signal, from your first description is supposed to be > >>fully independant of oneSecond, and dependant ONLY on SomeSignal. > >> From the results description there is some "errant coupling", > >>and LED1 is clearly dependant on One-Second, or at least a One-Second > >>clock. > > >>Conclusion: Insufficent information. > > >>-jg- Zitierten Text ausblenden - > > >>- Zitierten Text anzeigen - > > > 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 . > > > there is no ERRANT coupling, I myself also looked for the this > > coupling but it really isnt there. > > > as I made already REAL PRIZE (fpga miniconsole) for the first answer > > (or question close enough) so I will not reveal the answer or any > > other information as reply to direct question. > > > there is a explanation. and I am really glad I did solve the issue > > without going nuts. > > Now you are contradicting yourself. > > You have stated there is no coupling in code, and P&R/FPGA is OK > The Visual operation is not as you described expecting, logically. > > So, not working as logically described, means some errant coupling, > or dependance. (it does not have to be inside the FPGA, just > somewhere between your eyeballs, and the source code ! :) > > I thought the quizz was to find the errant cause, but now you state > "there is no ERRANT coupling" - does that mean you imagined it ? > > -jg- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Hi Jim, the quizz is to find solution to the behaviour as described. no coupling in code, no P&R error, visual inspection as desribed. and no, I did not imagine it. I called my wife to stand by me and look the code and LED behaviour to out-rule the Human-factor and the possibility of problem in my eyes. her advice was also that is likely to be "bad damage FPGA IC" issue. but, that is not the case, the FPGA is not damaged. AnttiArticle: 125073
On 16 Okt., 11:25, Evan Lavelle <nos...@nospam.com> wrote: > There's got to be some coupling somewhere. Is 'errant' coupling just > bad VHDL code? > > My guesses are > > (1) the cathodes of LED1 and LED2 have a high-impedance connection to > GND, possibly via an input structure on the FPGA (the LED1 input > switch?). Of course, this means that there's a PCB error, and I think > you said the PCB was Ok. This isn't enough to explain what you're > seeing, but maybe you created an SCR in the input structure when you > fried it, or > > (2) you created some output pin coupling when you fried the chip, > presumably through the Vcco protection diodes. > > Evan no PCB error. I had one PCB only, so I quickly made another PCB where FPGA was not stressed and the second PCB had exact the same behaviour!! I was not to belive my eyes, I was so sure it must be fried FPGA problem! it was notArticle: 125074
On 16 Okt., 10:02, "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 > > DCM ?- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - NO DCM issue. the FPGA in question doesnt have DCM ;) but the PLL on that FPGA was not used at all 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