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
Let me guess - are these Digilent 2SB boards, with the Spartan2E 200K FPGA? I work in a university also, and those are the boards that we got as a donation. 3 out of 5 are down, with the same symptoms... -VadimArticle: 75301
zerang shah wrote: > I work at a university, and we just got a bunch of FPGA boards with > Spartan 2E's on them. It's like five weeks into the quarter, and > already 6 of 20 boards have died. (snip) > So here's my question: How do you fry an FPGA?? I guess running like > 50 volts through it would do the job, but I don't think the cause of > these failures is a malicious user. Is there anyway to "accidentally" > synthesize a design that causes an FPGA to destroy itself??? As far as I know, the tools are supposed to generate files that don't do things that would internally fry the chip. In the days of tristate internal buses, I don't think they could stop you from turning on two drivers to the same bus line, but as I understand it that problem is gone. As far as contention on output buffers, it might be that you can burn out the output transistor. If you manage to load random bits with a legal CRC, I suspect you could have some very strange effects. -- glenArticle: 75302
I am experimenting with Xilinx CoreGen Counters. Right now at a very basic level. What I find is puzzling is first there seems to be no carry output - ripple or registered. Second, a free running counter has a logic one feeding the input carry. That's OK. But with the RPM option selected, this logic 1 does not move with the other L slices. Nor does its net autoroute. Is this a problem with the CoreGen?Article: 75303
I got my Spartan 3s mighty toasty by outputing to a tristate data bus at the wrong time. This could happen if you have a memory device on the board. The Spatan 3s survived.Article: 75304
Oops, answered my own question... I must have missed the "show configuration parameters" box, and that's why I didn't see the field "Accumilator Width".Article: 75305
Hmm,
My first thought is that they are suffering from electrostatic discharge
(ESD) damage, or perhaps problems with connecting the power supply such
that the voltage regulator is getting damaged. Could be a series of bad
bitstreams loaded, but I don't find that to be high on the likely
candidate list. What do these boards have for a power supply? Is it
possible the polarity is getting reversed? Is the on-board regulator
sufficient for the designs the students are putting in to the FPGA? Are
the boards being used in an environment where there is no ESD mitigation
in place?
Another possibility is that the computer on the other end of the JTAG
cable is not on the same ground system as the board. Both should be
plugged into a common outlet to avoid possible problems. I recall an
instance in a lab where I once worked where connecting an oscilloscope
that was plugged in across the aisle to a board killed the board. Turned
out there was a ground problem and the grounds on the two adjacent benches
had a several hundred volt difference between them!!
>
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 75306>So here's my question: How do you fry an FPGA?? I guess running like >50 volts through it would do the job, but I don't think the cause of >these failures is a malicious user. Is there anyway to "accidentally" >synthesize a design that causes an FPGA to destroy itself??? The classic way to toast any chip is contention on a tri-state bus. The stronger chip wins and the other chip tries real hard. The short-circuit current at the IO voltage turns into heat in the pad driver. (Old data sheets used to have a only-one-at-a-time warning on measuring the short curcuit current.) The short circuit current on modern chips is pretty hefty. Multiply by 16 or 32 and you can get a lot of heat. I've burned my thumb on an FPGA and cracked the case on a 16 bit bus driver. (Makes locating the bad chip simple.) You can also turn a FPGA into a toaster by just toggling a lot of FFs at high speed. Play with one of the power estimator tools to get some numbers. You can also make a chip very unhappy if you can get it to latch up. The usual way to do that is to inject too much current into a protection diode. What happens depends upon your power supply. If you have a big/beefy power supply, then your chip draws lots of power and gets real hot. It can turn to mush in a fraction of a second. If your power supply is just-right, it will shut down because of too much current. If it does that fast enough, your chip will recover. My guess would be that your problem is caused by ESD. Maybe ESD triggering latchup. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 75307
"zerang shah" <ninjak@gmx.de> wrote in message news:4d6c559c.0411011707.fba22e8@posting.google.com... >I work at a university, and we just got a bunch of FPGA boards with > Spartan 2E's on them. It's like five weeks into the quarter, and > already 6 of 20 boards have died. I contacted tech support for the > board manufacturer, and it seems that the FPGAs have been "fried" on > all six of the bad boards, judging from the fact that both the onboard > voltage regulators and FPGAs both get really hot, and the power-on LED > fails to turn on. Looking at the boards very closely I see no signs of > physical mistreatment though. > > The boards are being programmed using jtag cables + iMPACT with > bitfiles created with Foundation. At first I thought that maybe a > backward jtag cable would fry the FPGA, but it turns out that's not > the case. Really I have no idea what people could be doing to these > boards. > > So here's my question: How do you fry an FPGA?? I guess running like > 50 volts through it would do the job, but I don't think the cause of > these failures is a malicious user. Is there anyway to "accidentally" > synthesize a design that causes an FPGA to destroy itself??? They might be going into a 'latch-up' state. This can happen with CMOS, although manufacturers do a lot to prevent it happening. The Inmos transputer was prone to it if one touched the top of the package whilst it was running. The package lid wasn't grounded and a static charge on it could induce latch-up. They always recovered if they were switched off soon enough. With your systems it might be caused by connecting the JTAG with the unit powered up. LeonArticle: 75308
I am seeing messages like Time Borrowing Information -------------------------------------------------------------- CLK pulse width 0.75 library setup time -0.11 -------------------------------------------------------------- max time borrow 0.64 actual time borrow 0.50 -------------------------------------------------------------- in Design Compiler log file... can anyone tell me what is this time borrowing .. thanks whizkidArticle: 75309
Hi! I would like to design a high-speed memory interface using a Xilinx Virtex-II Pro and DDR SDRAM. To increase the data throughput i thought about connecting two 64-bit DDR-SDRAMs (as DIMM) in parallel. That results in a 128-bit wide interface. My question may be a little bit silly but I haven't got any experience in interfacing memory so far. How should i connect the data and adress lines? My first idea was to seperate the data lines but use the same address lines for both memory modules. Is that correct??? Regards, QuinnArticle: 75310
On Tue, 2 Nov 2004 08:50:34 +0100, "Quinn" <quinn_the_esquimo@freenet.de> wrote: >Hi! > >I would like to design a high-speed memory interface using a Xilinx >Virtex-II Pro and DDR SDRAM. To increase the data throughput i thought about >connecting two 64-bit DDR-SDRAMs (as DIMM) in parallel. That results in a >128-bit wide interface. My question may be a little bit silly but I haven't >got any experience in interfacing memory so far. How should i connect the >data and adress lines? My first idea was to seperate the data lines but use >the same address lines for both memory modules. Is that correct??? That would be correct in the functional sense. Only the data lines (and byte strobes, if used) would need to be separate. However, it might be easier (from a signal integrity P.O.V.) to use separate address and control lines for each DIMM. Regards, AllanArticle: 75311
Hi Allan, thanks for your immediate reply. But could you please elaborate on the pro's and con's regarding the seperate and combined data and adress lines (the last thing you mentioned in your answer)?! That would really help me in making the right decision... Thank you very much in advance! "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> schrieb im Newsbeitrag news:6ufeo09u6p3kl4c8uu6srbnh7j06j8sfn4@4ax.com... > On Tue, 2 Nov 2004 08:50:34 +0100, "Quinn" > <quinn_the_esquimo@freenet.de> wrote: > > >Hi! > > > >I would like to design a high-speed memory interface using a Xilinx > >Virtex-II Pro and DDR SDRAM. To increase the data throughput i thought about > >connecting two 64-bit DDR-SDRAMs (as DIMM) in parallel. That results in a > >128-bit wide interface. My question may be a little bit silly but I haven't > >got any experience in interfacing memory so far. How should i connect the > >data and adress lines? My first idea was to seperate the data lines but use > >the same address lines for both memory modules. Is that correct??? > > That would be correct in the functional sense. Only the data lines > (and byte strobes, if used) would need to be separate. > > However, it might be easier (from a signal integrity P.O.V.) to use > separate address and control lines for each DIMM. > > Regards, > AllanArticle: 75312
On Tue, 2 Nov 2004 09:12:11 +0100, "Quinn" <quinn_the_esquimo@freenet.de> wrote: >Hi Allan, > >thanks for your immediate reply. But could you please elaborate on the pro's >and con's regarding the seperate and combined data and adress lines (the >last thing you mentioned in your answer)?! That would really help me in >making the right decision... Download a copy of a signal integrity analysis tool such as hyperlynx and play with it for a while. It will soon become apparent that a simple "point to point" connection can be made to work at speeds up to several hundred MHz without too much pain, but things are a little harder if you have multiple loads. The signal will take longer to settle, and this will eat into your timing margin. I assume that you will be using a clock of >= 200MHz, which means that your timing margin is probably less than 1ns. Also, when simulating, don't forget to take the DIMM tracks into account. You care about the signal quality at the chip pins, not the DIMM pins. Regards, AllanArticle: 75313
Hal Murray <hmurray@suespammers.org> wrote: : >So here's my question: How do you fry an FPGA?? I guess running like : >50 volts through it would do the job, but I don't think the cause of : >these failures is a malicious user. Is there anyway to "accidentally" : >synthesize a design that causes an FPGA to destroy itself??? : The classic way to toast any chip is contention on a tri-state : bus. The stronger chip wins and the other chip tries real hard. : The short-circuit current at the IO voltage turns into heat in : the pad driver. (Old data sheets used to have a only-one-at-a-time : warning on measuring the short curcuit current.) Using UCF to set the buffers to a weak drive strength might help in that situation ( people learning how to programm FPGA, not doing really timing dependant work...) Also using a weaker regulator mmight be another option... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 75314
Hi all, Does anyone know how to preserve the "wire" names in the netlist so that it is wasy for debugging the netlist. I used dont_touch command with net name , but I think this will reduce the logic optimization by the tool.. what do u think thanks whizkidArticle: 75315
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:418681AE.A5147A3D@yahoo.com... <snip> > Just like I suspected all along, it was a user error. I had a function > with the same name as an enumeration value. The other tools seemed to > figure it out by context, but XST didn't like it. > > So I have fixed that, but I am getting another set of errors where it > does not like my constants I think. I have defined a set of constant > SLVs to match my opcodes. To make defining them easier I entered their > values as function calls... > > constant LTRL : INSTVAL := TO_INTEGER(INSTBITS'(0,0,0)); -- 0 - 00 > constant NOP : INSTVAL := TO_INTEGER(INSTBITS'(7,0,0)); -- 1 - 80 > constant CALL : INSTVAL := TO_INTEGER(INSTBITS'(0,1,2)); -- 2 - 87 > > INSTBITS is an array of three integers (range 0 to 7) which TO_INTEGER > converts to a single integer equal to the weighted sum, (i.e. binary > positions to integer value). Logically this works and again, two other > tools compile this just fine. XST barfs when I try to use one of these > constants as a case statement choice saying "Choice call is not a > locally static expression". Does the use of a function in a constant > initialization make the constant not "locally static"? I tried looking > in the LRM for a definition of "locally static" and could not find it. > > I did find on a web page that a locally static expression (LSE) can be > either a literal, a constant that is init'd by an LSE or a call to an > "implicitly predefined operator". So I guess my function calls make my > constants only globally static and not locally static? > Something that is locally static can have its value determined purely during analysis of that design unit, it doesn't require elaboration of the complete design hierarchy. The standard defines static and locally static in section 7.4. It does look to me as though XST may be correct, as it says that a constant is only locally static if it is initialized by a locally static primary (which doesn't include a function call). I don't understand what your TO_INTEGER function does, sorry :-( Alan -- Alan Fitch Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: alan.fitch@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 75316
have 1701 eeprom and i want to configure two spartan fpgas how can i do thisArticle: 75317
On Tue, 2 Nov 2004 09:23:56 -0000, "Alan Fitch" <alan.fitch@doulos.com> wrote: > >"rickman" <spamgoeshere4@yahoo.com> wrote in message >news:418681AE.A5147A3D@yahoo.com... ><snip> >> Just like I suspected all along, it was a user error. I had a >function >> with the same name as an enumeration value. The other tools seemed >to >> figure it out by context, but XST didn't like it. >> >> So I have fixed that, but I am getting another set of errors where >it >> does not like my constants I think. I have defined a set of >constant >> SLVs to match my opcodes. To make defining them easier I entered >their >> values as function calls... >> >> constant LTRL : INSTVAL := TO_INTEGER(INSTBITS'(0,0,0)); -- 0 - >00 >> constant NOP : INSTVAL := TO_INTEGER(INSTBITS'(7,0,0)); -- 1 - >80 >> constant CALL : INSTVAL := TO_INTEGER(INSTBITS'(0,1,2)); -- 2 - >87 >> >> INSTBITS is an array of three integers (range 0 to 7) which >TO_INTEGER >> converts to a single integer equal to the weighted sum, (i.e. binary >> positions to integer value). Logically this works and again, two >other >> tools compile this just fine. XST barfs when I try to use one of >these >> constants as a case statement choice saying "Choice call is not a >> locally static expression". Does the use of a function in a >constant >> initialization make the constant not "locally static"? I tried >looking >> in the LRM for a definition of "locally static" and could not find >it. >> >> I did find on a web page that a locally static expression (LSE) can >be >> either a literal, a constant that is init'd by an LSE or a call to >an >> "implicitly predefined operator". So I guess my function calls make >my >> constants only globally static and not locally static? >> > >Something that is locally static can have its value determined purely >during analysis of that design unit, it doesn't require elaboration >of the complete design hierarchy. > >The standard defines static and locally static in section 7.4. > >It does look to me as though XST may be correct, as it says that >a constant is only locally static if it is initialized by a locally >static primary (which doesn't include a function call). > >I don't understand what your TO_INTEGER function does, sorry :-( I understand that the new version of VHDL will remove this restriction and allow globally static expressions to be used in case statements. Regards, AllanArticle: 75318
Greetings Antti, We do have one ML300 and can easily get 5 units, we're a University - this board is supposedly cheaper and we're not "phasing it out" for our project.... :) I might be wrong. Thanks for any info you provide, I relay all these Newsgroups postings to our group professor/leader and fellow PhD stuidents (without disclosing your emails).Article: 75319
P.S> Mark Levitski is a bogus for security (on Newsgroups), my real last name is similar but not exact.Article: 75320
Hello everybody, I am trying to gain a deeper understanding of the way an FPGA is programmed. For SRAM based FPGAs, I know the configuration is loaded either by row, column or frame. But how exactaly are the SRAM cells programmed? Are they part of a long shift register, which is filled in by the configuration bitstream? Or is there something I am missing? If there is any paper or article describing this, I'd be glad if anyone could point it out to me. I realize that, for manufacturers, this might be proprietry information, but surely there's some work out there describing the process? Thank you very much for your help.Article: 75321
sidney@jigsaw.nl (Sidney Cadot) wrote in message news:<741e0fbf.0411011110.1fcf2e1b@posting.google.com>... > Marc Randolph <mrand@my-deja.com> wrote in message news:<vf-dnWXXTflpvxvcRVn-vg@comcast.com>... > > > I still must be missing something... I don't see how pushing the pin > > location assignments deep into the hierarchy makes anything easier. > > It enhances the maintainability of the code, by concentrating all the > knowledge about the particular hardware devices available in one > place. For example, adding support for yet another board is then a > matter of making one "mmapped_io_<boardtype>.vhdl" and recompiling. But you may not even need different vhdl files if you use your .ucf file (or whatever it is called in XST) to call out pin numbers. Have fun, MarcArticle: 75322
gabor@alacron.com (Gabor Szakacs) wrote in message news:<8a436ba2.0411011155.4bc2ebdf@posting.google.com>... > alann@accom.com (Alan Nishioka) wrote in message news:<a2db9b48.0410312049.a22a5ae@posting.google.com>... > > Can I safely connect Xilinx fpga pins to an external connector in a > > commercial product? > I do this, but not on a truly external connector, i.e. not > one that leaves the box. It's generally O.K. to have mezzanine > connectors, but your guess on ESD is correct if you want an > external cable plugged in. I don't have a problem with internal connectors. No one should be in the box, so the chance of something bad happening is much lower. > > What circuitry should I add to protect the fpga? > I'd say the best way is to insert transceivers, but > that would require picking a logic family. At a minimum > I'd put Schottky clamps on the lines and even better something like > a QuickSwitch if you can afford the delay due to on resistance > and capacitive loading. I have always used a transceiver in the past, but I was wondering what I could get away with. quickswitch is a good idea. I certainly can afford it (it's for user inputs/outputs). Thank you, Alan Nishioka alann@accom.comArticle: 75323
OK, so I'm trying to synthesize a huge design. Just for quick reference, the inferred macros are below: HDL Synthesis Report Macro Statistics # Block RAMs : 112 16x24-bit dual-port block RAM : 64 1024x12-bit single-port block RAM : 48 # ROMs : 3 16x10-bit ROM : 3 # Multipliers : 480 12x12-bit registered multiplier : 480 # Adders/Subtractors : 3856 10-bit adder : 20 8-bit adder : 32 9-bit adder : 16 7-bit adder : 16 12-bit adder : 1792 24-bit adder : 480 12-bit subtractor : 1472 4-bit subtractor : 15 5-bit adder : 1 4-bit adder : 12 # Counters : 1 5-bit up counter : 1 # Registers : 13434 4-bit register : 30 24-bit register : 577 12-bit register : 480 10-bit register : 20 5-bit register : 1 1-bit register : 12325 3-bit register : 1 # Comparators : 44 10-bit comparator greatequal : 12 5-bit comparator lessequal : 2 5-bit comparator greater : 2 10-bit comparator greater : 7 10-bit comparator less : 11 10-bit comparator lessequal : 8 5-bit comparator greatequal : 1 5-bit comparator less : 1 # Multiplexers : 1070 4-bit 2-to-1 multiplexer : 10 1-bit 2-to-1 multiplexer : 2 12-bit 2-to-1 multiplexer : 1040 24-bit 2-to-1 multiplexer : 1 24-bit 64-to-1 multiplexer : 1 24-bit 16-to-1 multiplexer : 16 # Xors : 480 1-bit xor2 : 480 The code is fairly well-optimized and functionally correct. However, it is a huge design, and it should be about 47,000 SLICEs once all is said and done. But, alas: "ERROR: Portability:3 - This Xilinx application has run out of memory or has encountered a memory conflict..." I'm sure plenty of you have gotten this error before. On a machine with 2.5 GB of memory and dual 3.0 GHz processors, should I be getting this error? I've been working on optimizing my code but I was wondering if there is a point where the design is simply too large.Article: 75324
In article <4d6c559c.0411011707.fba22e8@posting.google.com>, zerang shah wrote: > So here's my question: How do you fry an FPGA?? I guess running like Do you have a signal generator or something like that attached into the board somewhere? Check what's its maximum voltage. We have here one which can generate voltage enough to fry DSP boards.
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