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
On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be> wrote: > avrba...@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- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - it was my first guess too, but no this is not the case AnttiArticle: 125101
Hi I would like to connect 3 FPGA devices together using a 32-bit bus. Also I would like all 3 to be masters on the bus. Is there any standard bus out there that would do this rather than me coming up with my own idea. JonArticle: 125102
Amontec, Larry 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
Please let us a VHDL example or a partial VHDL.
Then we will p&r to our FPGAs Platform, and we will see !
---------------
You do not test all conditions in your VHDL -> then synth. uses some
async D-latch?
---------------
BUT THIS IS A STUDENT-ISSUE KIND -> NOT AN ANTTI-ISSUE
-----------
- Laurent
www.amontec.com
Article: 125103Antti wrote: > > 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) > Is one of the signals involved connected to a global tristate or powerdown pin on the FPGA ? BrianArticle: 125104
On Oct 16, 2:48 pm, "maxascent" <maxasc...@yahoo.co.uk> wrote: > Hi > > I would like to connect 3 FPGA devices together using a 32-bit bus. Also I > would like all 3 to be masters on the bus. Is there any standard bus out > there that would do this rather than me coming up with my own idea. > > Jon Search for hypertunnel (HT) chip-to-chip bus. There is a chance that an HT implementation is at the OpenCores site. Nikolaos KavvadiasArticle: 125105
On 16 Okt., 13:56, Brian Davis <brimda...@aol.com> wrote: > Antti wrote: > > > 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) > > Is one of the signals involved connected to a global > tristate or powerdown pin on the FPGA ? > > Brian wau, keep getting nice suggestions! :) no power down or FPGA power management is not the issue AnttiArticle: 125106
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, This doesn't obviously answer my question. You don't mention LED1 in your description of the schematic. > 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 change the frequency of blink_one_second does the other LED change frequency with it? -- Philip Potter pgp <at> doc.ic.ac.ukArticle: 125107
On 16 Okt., 13:48, "Amontec, Larry" <laurent.ga...@ANTI- SPAMamontec.com> wrote: > Amontec, Larry 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 > > Please let us a VHDL example or a partial VHDL. > Then we will p&r to our FPGAs Platform, and we will see ! > > --------------- > You do not test all conditions in your VHDL -> then synth. uses some > async D-latch? > --------------- > > BUT THIS IS A STUDENT-ISSUE KIND -> NOT AN ANTTI-ISSUE > > ----------- > > - Laurent > www.amontec.com- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - Hi Laurent, the VHDL code for signal LED2 is essentially a single wire point-to- point it would be single horizontal stright wire in scheamatic version. ========== cut here ========== signal blink_one_second : std_logic; [snip] name_of_some_port => blink_one_second; -- connect blink signal to its source [snip] LED2 <= blink_one_second; -- connec the blink signal to IOB ==== and here ======== the VHDL name blink_one_second appears in the code exactly 3 times AnttiArticle: 125108
On 16 Okt., 14:10, Philip Potter <p...@see.sig.invalid> 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, > > This doesn't obviously answer my question. You don't mention LED1 in > your description of the schematic. > > > 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 change the frequency of blink_one_second does the other LED > change frequency with it? > > -- > Philip Potter pgp <at> doc.ic.ac.uk- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - yes, as long as some_signal is 1, LED1 blinks in sync and same polarity as LED2, no matter the frequency if the signal would be derived from human operated button then it would appear as button is connected to both LEDs AnttiArticle: 125109
Don't you people have anything better to do? We all come across puzzling and time-consuming problems where we've made what seems to be a reasonable assumption but which turns out to be false. The lesson is sobering, but the sterile chase after another's problem is little more than self-indulgence. As Gauss put it:(when others tempted him to become interested in Fermat's conjecture): "I confess that Fermat's Theorem as an isolated proposition has very little interest for me, because I could easily lay down a multitude of such propositions, which one could neither prove nor dispose of".Article: 125110
Antti wrote: > > no power down or FPGA power management is not the issue > Does your exclusion of global tristate and powerdown pin assignment problems also extend to other global pins, such as reset? Would the problem appear in a post-PAR gate level simulation of the design? Is one of the signals clocked, and the other strictly combinatorial? BrianArticle: 125111
On 16 Okt., 14:16, Brian Davis <brimda...@aol.com> wrote: > Antti wrote: > > > no power down or FPGA power management is not the issue > > Does your exclusion of global tristate and powerdown > pin assignment problems also extend to other global pins, > such as reset? > > Would the problem appear in a post-PAR gate level simulation of the > design? > > Is one of the signals clocked, and the other strictly combinatorial? > > Brian yes all global pins like reset, global tristate are excluded the problem would appear in simulation given __proper__ stimuly _and_ technology dependant simulaton libraries but I am not sure if simulation libraries from any FPGA vendor are accurate enough for the problem to become visible the issue would appear if only 2 outputs LED1 and LED2 are used no clocks connected to any FPGA IOB (only blink_one_second signal toggles) AnttiArticle: 125112
On 16 Okt., 14:13, MikeShepherd...@btinternet.com wrote: > Don't you people have anything better to do? We all come across > puzzling and time-consuming problems where we've made what seems to be > a reasonable assumption but which turns out to be false. The lesson > is sobering, but the sterile chase after another's problem is little > more than self-indulgence. > > As Gauss put it:(when others tempted him to become interested in > Fermat's conjecture): "I confess that Fermat's Theorem as an isolated > proposition has very little interest for me, because I could easily > lay down a multitude of such propositions, which one could neither > prove nor dispose of". Sorry Mike I did not expect so many replies ;) well, I th=EDnk there is something to learn in this, and hope you agree when the solution is revealed. OK, some more hints: the "perfect answer" to the original quiz would be one single 6 letter word. I do not expect someone to be guess it, but the possibilities of possible cause are getting low, the answer will soon be known so or so. Antti From laurent.pinchart@skynet.be Tue Oct 16 05:46:26 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!ecngs!feeder2.ecngs.de!novso.com!news.skynet.be!195.238.0.222.MISMATCH!newsspl501.isp.belgacom.be!tjb!not-for-mail Message-Id: <4714b2a2$0$22318$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 14:46:26 +0200 References: <1192462938.206319.120810@i13g2000prf.googlegroups.com> User-Agent: KNode/0.10.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 35 Organization: -= Belgacom Usenet Service =- NNTP-Posting-Host: 71385f48.news.skynet.be X-Trace: 1192538786 news.skynet.be 22318 194.78.198.49:51832 X-Complaints-To: usenet-abuse@skynet.be Xref: prodigy.net comp.arch.fpga:137100 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 Would the source and post p&r simulation exhibit the same behavior ? Laurent PinchartArticle: 125113
On Oct 16, 6:45 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be> > wrote: > > > > > avrba...@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- Zitierten Text ausblenden - > > > - Zitierten Text anzeigen - > > it was my first guess too, but no this is not the case > > Antti Is this the Spartan 3A that was originally going to be a Virtex family chip, then they rebranded it but did not change the ID? S WoodsArticle: 125114
On 16 Okt., 14:46, Laurent Pinchart <laurent.pinch...@skynet.be> 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 > > Would the source and post p&r simulation exhibit the same behavior ? > > Laurent Pinchart- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - I must think more to answer properly ;) a full simulation of the code with proper stimuly would simulate the same before and after P&R given the __needed__ accuracy of the technology dependand simulation libraries. but, as said I do not know if the current FPGA vendor simulation libraries are accurate for the issue become visible. It is likely that the behaviour as observed can not be seen in simulation (no matter proper stimuli). if it comes visible in sims then P&R step would make no difference to the simulation behaviour as FPGA fabric delays, have NO influence on the behaviour at all Antti From laurent.pinchart@skynet.be Tue Oct 16 06:02:43 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: <4714b674$0$22320$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 15:02:43 +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> <4714a3af$0$22307$ba620e4c@news.skynet.be> <1192535103.185944.294970@q5g2000prf.googlegroups.com> User-Agent: KNode/0.10.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 62 Organization: -= Belgacom Usenet Service =- NNTP-Posting-Host: 845cacbd.news.skynet.be X-Trace: 1192539764 news.skynet.be 22320 194.78.198.49:53803 X-Complaints-To: usenet-abuse@skynet.be Xref: prodigy.net comp.arch.fpga:137103 Antti wrote: > On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be> > wrote: >> avrba...@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- Zitierten Text ausblenden - >> >> - Zitierten Text anzeigen - > > it was my first guess too, but no this is not the case > > Antti Did the JTAGID change after you applied VCCINT=1.8V or was it already defective before ? Laurent Pinchart From laurent.pinchart@skynet.be Tue Oct 16 06:06:36 2007 Path: newssvr25.news.prodigy.net!newsdbm05.news.prodigy.net!newsdst01.news.prodigy.net!prodigy.com!newscon04.news.prodigy.net!prodigy.net!newshub.sdsu.edu!feeder.news-service.com!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!kramikske.telenet-ops.be!nntp.telenet.be!feed1.news.be.easynet.net!news.skynet.be!195.238.0.222.MISMATCH!newsspl501.isp.belgacom.be!tjb!not-for-mail Message-Id: <4714b75c$0$22320$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 15:06:36 +0200 References: <1192462938.206319.120810@i13g2000prf.googlegroups.com> <4714b2a2$0$22318$ba620e4c@news.skynet.be> <1192539703.614577.111460@e9g2000prf.googlegroups.com> User-Agent: KNode/0.10.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 60 Organization: -= Belgacom Usenet Service =- NNTP-Posting-Host: 845cacbd.news.skynet.be X-Trace: 1192539996 news.skynet.be 22320 194.78.198.49:53803 X-Complaints-To: usenet-abuse@skynet.be Xref: prodigy.net comp.arch.fpga:137104 Antti wrote: > On 16 Okt., 14:46, Laurent Pinchart <laurent.pinch...@skynet.be> > 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 >> >> Would the source and post p&r simulation exhibit the same behavior ? >> >> Laurent Pinchart- Zitierten Text ausblenden - >> >> - Zitierten Text anzeigen - > > I must think more to answer properly ;) > > a full simulation of the code with proper stimuly would simulate the > same before and after P&R given the __needed__ accuracy of the > technology dependand simulation libraries. > > but, as said I do not know if the current FPGA vendor simulation > libraries are accurate for the issue become visible. It is likely that > the behaviour as observed can not be seen in simulation (no matter > proper stimuli). if it comes visible in sims then P&R step would make > no difference to the simulation behaviour as FPGA fabric delays, have > NO influence on the behaviour at all So the post-map and post-p&r simulation would both exhibit the issue given proper vendor libraries, but source simulation (before synthesis) wouldn't, as it doesn't involve vendor libraries. Or does your design use vendor components in addition to pure VHDL code ? Laurent PinchartArticle: 125115
On 16 Okt., 14:46, Laurent Pinchart <laurent.pinch...@skynet.be> 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 > > Would the source and post p&r simulation exhibit the same behavior ? > > Laurent Pinchart- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - I must think more to answer properly ;) a full simulation of the code with proper stimuly would simulate the same before and after P&R given the __needed__ accuracy of the technology dependand simulation libraries. but, as said I do not know if the current FPGA vendor simulation libraries are accurate for the issue become visible. It is likely that the behaviour as observed can not be seen in simulation (no matter proper stimuli). if it comes visible in sims then P&R step would make no difference to the simulation behaviour as FPGA fabric delays, have NO influence on the behaviour at all AnttiArticle: 125116
On Oct 15, 7:31 pm, Duane Clark <junkm...@junkmail.com> wrote:
> paragon.j...@gmail.com wrote:
> > Hello all,
>
> > I am working on a design for a Xilinx V2P50 and I am trying to
> > diagnose possible timing issues because the hardware performance of my
> > design does not appear to match simulation.
>
> > I have run the design through Timing Analyzer (ISE 8.2) and notice a
> > huge number of unconstrained paths of the following format
>
> > "FROM *clk_pad* TO *register*"
>
> > where *clk_pad* is a clock pad in the design, and *register* is a
> > register in the design that is clocked...
>
> I think those only occur when a local net is used somewhere in the clock
> path. Are you using a gated clock? Is the clock pad using a pin other
> than the one with a direct connection to a global clock buffer?
>
> Why don't you post one of the unconstrained paths. That is, the part
> that should look something like:
>
> [removed for readability]
Thanks for your response.
I do have a gated clock of the following form: GATED_CLOCK <= ENABLE
and not GATED_CLOCK. This signal is not used to clock any flip flops
in the FPGA, it is immediately connected to an output buffer.
Unfortunately, this signal is needed. Maybe there are some
constraints I need to put on this signal that I am unaware of?
Here is an example unconstrained path:
--------------------------------------------------------------------------------
Delay: 1.435ns (data path)
Source: Clk_n (PAD)
Destination: [Flip-flop in hierarchy] (FF)
Data Path Delay: 1.435ns (Levels of Logic = 4)
Constraint Improvement Wizard
Data Path: Clk_n to [Flip-flop in hierarchy]
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tiopp 0.276 Clk_n
net (fanout=1) 0.000 U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN
Tdiffin 0.812 U_AD_IF/IBUFG_Clk/IBUFDS
net (fanout=1) 0.452 U_AD_IF/BUF_Clk
Tdcmino -2.529 U_AD_IF/DCM_Clk
net (fanout=1) 0.823 U_AD_IF/DCM_Clk_0
Tgi0o 0.050 U_AD_IF/BUFG_Clk
net (fanout=20886) 1.551 AD_Clk
---------------------------- ---------------------------
Total 1.435ns (-1.391ns logic, 2.826ns route)
Thanks!
Article: 125117> >Hi > >I would like to connect 3 FPGA devices together using a 32-bit bus. Also I >would like all 3 to be masters on the bus. Is there any standard bus out >there that would do this rather than me coming up with my own idea. > >Jon > PCI would fit the bill, especially if you leverage open-source RTL.Article: 125118
On 16 Okt., 15:02, Laurent Pinchart <laurent.pinch...@skynet.be> wrote: > Antti wrote: > > On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be> > > wrote: > >> avrba...@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- Zitierten Text ausblenden - > > >> - Zitierten Text anzeigen - > > > it was my first guess too, but no this is not the case > > > Antti > > Did the JTAGID change after you applied VCCINT=1.8V or was it already > defective before ? > > Laurent Pinchart- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - I did not observe the wrong ID before. I did some rework on the PCB, the VCCINT regulator VCCADJ did fell off, and i was suddenly measuring 1.8V after fixing the supply and completing my PCB rework, the ID was wrong. the problem has been fixed, and the same FPGA now works fully ok again and returns correct ID too. AnttiArticle: 125119
On Oct 16, 9:36 am, paragon.j...@gmail.com wrote: > On Oct 15, 7:31 pm, Duane Clark <junkm...@junkmail.com> wrote: > > > > > paragon.j...@gmail.com wrote: > > > Hello all, > > > > I am working on a design for a Xilinx V2P50 and I am trying to > > > diagnose possible timing issues because the hardware performance of my > > > design does not appear to match simulation. > > > > I have run the design through Timing Analyzer (ISE 8.2) and notice a > > > huge number of unconstrained paths of the following format > > > > "FROM *clk_pad* TO *register*" > > > > where *clk_pad* is a clock pad in the design, and *register* is a > > > register in the design that is clocked... > > > I think those only occur when a local net is used somewhere in the clock > > path. Are you using a gated clock? Is the clock pad using a pin other > > than the one with a direct connection to a global clock buffer? > > > Why don't you post one of the unconstrained paths. That is, the part > > that should look something like: > > > [removed for readability] > > Thanks for your response. > > I do have a gated clock of the following form: GATED_CLOCK <= ENABLE > and not CLOCK. This signal is not used to clock any flip flops > in the FPGA, it is immediately connected to an output buffer. > Unfortunately, this signal is needed. Maybe there are some > constraints I need to put on this signal that I am unaware of? > > Here is an example unconstrained path: > > -------------------------------------------------------------------------------- > Delay: 1.435ns (data path) > Source: Clk_n (PAD) > Destination: [Flip-flop in hierarchy] (FF) > Data Path Delay: 1.435ns (Levels of Logic = 4) > Constraint Improvement Wizard > Data Path: Clk_n to [Flip-flop in hierarchy] > Delay type Delay(ns) Logical Resource(s) > ---------------------------- ------------------- > Tiopp 0.276 Clk_n > net (fanout=1) 0.000 U_AD_IF/IBUFG_Clk/SLAVEBUF.DIFFIN > Tdiffin 0.812 U_AD_IF/IBUFG_Clk/IBUFDS > net (fanout=1) 0.452 U_AD_IF/BUF_Clk > Tdcmino -2.529 U_AD_IF/DCM_Clk > net (fanout=1) 0.823 U_AD_IF/DCM_Clk_0 > Tgi0o 0.050 U_AD_IF/BUFG_Clk > net (fanout=20886) 1.551 AD_Clk > ---------------------------- --------------------------- > Total 1.435ns (-1.391ns logic, 2.826ns route) > > Thanks! Correction to the above post: The gated clock should be GATED_CLOCK <= ENABLE and not CLOCK Note that this clock is a divided by 4 clock of the clock in the above constraint, generated by the DCM.Article: 125120
On 16 Okt., 15:06, Laurent Pinchart <laurent.pinch...@skynet.be> wrote: > Antti wrote: > > On 16 Okt., 14:46, Laurent Pinchart <laurent.pinch...@skynet.be> > > 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 > > >> Would the source and post p&r simulation exhibit the same behavior ? > > >> Laurent Pinchart- Zitierten Text ausblenden - > > >> - Zitierten Text anzeigen - > > > I must think more to answer properly ;) > > > a full simulation of the code with proper stimuly would simulate the > > same before and after P&R given the __needed__ accuracy of the > > technology dependand simulation libraries. > > > but, as said I do not know if the current FPGA vendor simulation > > libraries are accurate for the issue become visible. It is likely that > > the behaviour as observed can not be seen in simulation (no matter > > proper stimuli). if it comes visible in sims then P&R step would make > > no difference to the simulation behaviour as FPGA fabric delays, have > > NO influence on the behaviour at all > > So the post-map and post-p&r simulation would both exhibit the issue given > proper vendor libraries, but source simulation (before synthesis) wouldn't, > as it doesn't involve vendor libraries. Or does your design use vendor > components in addition to pure VHDL code ? > > Laurent Pinchart- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - I have indirectly answered this I think, given proper technology libraries the behaviour would appear in simulation. if proper simulation models are used it would appear before synthesis also. So it does indirectly say that there is vendor dependancy. and as also said the simulation models may be not accurate enough for the behaviour to become visible. I can not tell that for all vendors but for Xilinx as example last time I checked the model accuracy would not make the behaviour observable in simulations. well the FPGA device in question is not a Xilinx device anyway. AnttiArticle: 125121
On 12 oct, 04:32, "St=E9phane Julhes" <sjul...@adeneo.adetelgroup.com> wrote: > Hi all, > > Does anyone know a free/simple software that would use vhdl files to prod= uce > a graphical view ? > The goal is to have a easier and faster read of the architecture of a vhdl > file and its components. > > Thanks. > > St=E9phane. It will not help in your current situation, but I would recommend Active-HDL for your future designs (not free unfortunately). What we do is that we do the design in a graphical manner with boxes connected to each other in a schematic editor. Then each box is a VHDL file or another level of schematic. That way it us MUCH easier to understand the design than to try to understand the VHDL netlist. Each schematic is converted automatically to a VHDL file, so it's always possible to go back to a simple VHDL netlist if desired. PatrickArticle: 125122
"Antti" <Antti.Lukats@googlemail.com> wrote in message news:1192513850.557192.144210@q5g2000prf.googlegroups.com... > > FPGA_pin - RESISTOR - LED - GND > > but as said the LED connection really had nothing todo with the issue OK, what's the resistor's value, what's the LED's forward voltage, which buffer type is used (current limiting?), what's the VCC? Unfortunately, I'll be away from my computer for quite a few hours, so I am probably out of this game... /MikhailArticle: 125123
On 16 Okt., 14:59, naughty.z...@gmail.com wrote: > On Oct 16, 6:45 am, Antti <Antti.Luk...@googlemail.com> wrote: > > > > > > > On 16 Okt., 13:42, Laurent Pinchart <laurent.pinch...@skynet.be> > > wrote: > > > > avrba...@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- Zitierten Text ausblenden - > > > > - Zitierten Text anzeigen - > > > it was my first guess too, but no this is not the case > > > Antti > > Is this the Spartan 3A that was originally going to be a Virtex family > chip, then they rebranded it but did not change the ID? > > S Woods- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - WAU, thats good guess!! well on the plastic housing there is part of the text that has been laser-erased after chip marking for some reason but no, this is not the case for the wrong ID readback AnttiArticle: 125124
On Oct 16, 6:02 am, avrba...@hotmail.com wrote: > 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 Something to do with the IO protection diodes? Maybe even powering the device or at least an IO bank through the IO pins and those diodes, rather than through the supply pins?
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