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
After upgrade ace file and some software code from application in linux, we seen some compact flash booting up 15 seconds longer than the "normal" system. The problem seems to be CF dependent. The CF content is ok, but the boot time is 15 seconds longer on some flash and not everyone. Copying or "dd" the content of CF to a good flash and the good flash works. Therefore I don't think this is a FAT16 related issues. I am guessing it is flash write relocation software in the SanDisk CF create long/complex bad block link list in the "failure" CF. The "failure" CF still works on PC disk reader, but our FPGA have a watchdog to reboot the system if the software is not up in certain period of time, thus we notice the problem. Has anyone else seen this? and maybe have a guess on what else can cause this? -TonyArticle: 96276
Symon wrote: > But the Helium is superfluid so we can make it flow past the balls between > the package and the FR4 with no viscous drag. Tiny balls at near 0K. OK? > :-) No the tiny balls are the dia attach to the carrier FR4 pcb to convert the die pad pitch to the external ball array pitch. So you have heat spreader on one side, sealed die ball attached to FR-4 carrier, thru vias and traces to the external ball array for customer attach. The FR-4 and via's have significantly higher thermal resistance than the heat spreader side. That aside .. probably violates the storage and operating temp range for the part. Anyway, the point is that everyone assumes the designs are thermally limited, which given the xtreme case of He cooling may not be the case. The limit after that is the voltage drop between customer attach balls and the die for both ground and VccInt paths, which is not spec'dArticle: 96277
On 1 Feb 2006 10:01:47 -0800, fpga_toys@yahoo.com wrote: >The limit after that is the voltage drop between customer attach balls >and >the die for both ground and VccInt paths, which is not spec'd Is it difficult to measure typical values of the voltage drop on actual hardware though? Just set some outputs to be CMOS highs and lows and measure their voltage at some convenient spot on the board. I can't remember the IBIS curves, but I think the CMOS outputs do pull all the way to the rail if the current is low enough. Regards, AllanArticle: 96278
Why is there a reluctance to publish accurate die area information? Some purchasing agents try to equate die area with cost and thus price. "If this chip is 10% smaller than xyz chip, it should be 10% cheaper". Such argumentation misses many important points, and is easiest avoided by not publishing die area data. Some military users equate transistor count with (un)reliability. A totally meaningless measure, easiest avoided by not publishing the number. There are also competitive aspects: No need to tell A how much (less) are we need to achieve the same function (but they will find it out anyhow, sooner or later). Don't help your competitor! The basic question is: Why do you want (or need) to know? Tell us... Peter Alfke, Xilinx Applications ============== nhurley wrote: > Hi Guys > > I'm looking for some die area information on FPGAs. It is prooving > quite difficult to find any information so if anyone has some pointers > or datapoints it'd be much appreciated. > > Thanks!Article: 96279
On 1 Feb 2006 10:15:00 -0800, "Peter Alfke" <peter@xilinx.com> wrote: >The basic question is: Why do you want (or need) to know? Tell us... 1) Nosiness; 2) It tells us how much the die costs you, and whether the chip is likely to get to a reasonable price in the longer term; 3) It's a more useful metric than 'gate count' when comparing to ASICs and other FPGA vendors.Article: 96280
Allan Herriman wrote: > Is it difficult to measure typical values of the voltage drop on > actual hardware though? Just set some outputs to be CMOS highs and > lows and measure their voltage at some convenient spot on the board. Measuring VccInt from an I/O pad? ... some trick?Article: 96281
<fpga_toys@yahoo.com> wrote in message news:1138820483.937142.234800@g43g2000cwa.googlegroups.com... > > Allan Herriman wrote: >> Is it difficult to measure typical values of the voltage drop on >> actual hardware though? Just set some outputs to be CMOS highs and >> lows and measure their voltage at some convenient spot on the board. > > Measuring VccInt from an I/O pad? ... some trick? > Leave one Vccint ball and one Gnd ball on the FG package disconnected. Use those signals as the feedback circuit of your power supply so that the PSU servos the on die voltage to the correct value. Cheers, Syms. p.s. Sorry for getting your tiny balls mixed up with the package balls earlier. I was plumb lead astray.Article: 96282
Hi I have compiled the GNU tools for microblaze (from the 8.1 source from Xilinx website) the win32 binaries are downloadable http://xilant.com/component/option,com_remository/Itemid,53/func,fileinfo/id,12/ its simple zip of the release folder after build on win32, included are the GCC and related stuff and the uclinux utils genromfs and elft2flt, GDB is not included, compiled with latest cygwin, (cygwin1.dll not included in the zip) the compiled GCC has been tested to compile a simple hello that worked in uclinux simulator at least the genromfs and elft2flt are not tested, at least on previous versions the win32 compiled elft2ftl was broken, with this release I do not know. please dont overload my server the download is 19MB ! AnttiArticle: 96283
Hi, We have several products that use S3's, with a number of fpga pins connected to dipswitches. The dips switch to ground, and we program the fpga's to provide internal resistive pullups. Some small part of the time, at random, one (typically) pin will fail to pull up, and we have to replace the fpga to fix it. Anybody else observe this? JohnArticle: 96284
Raymond wrote: > Hi There. > > Xilinx CPLD XCR3384XL with speed grade -7 have (according to the > datasheet) a maximum clock frequency at 135MHz. How have they found > that number? > > I have some timing problems on a FPGA and that trigged my curiousity. > (I am assuming that they use a likewise method to find the maximum > clock frequency in CPLDs and FPGAs, (but I'm not sure)). That only allies to trivial functionality. Note that as soon as you ahve some synchroneous counters or so, this maximum frequency comes down considerably. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 96285
Symon wrote: > Leave one Vccint ball and one Gnd ball on the FG package disconnected. Use > those signals as the feedback circuit of your power supply so that the PSU > servos the on die voltage to the correct value. Interesting idea. Would help to know a lot more about the power and ground busses on the chip. If there was some significant on chip capacitance for the VccInt power rails that would be tempting. It would take some careful design to keep that servo loop stable given the extremely short transient nature of the power use. > Cheers, Syms. > p.s. Sorry for getting your tiny balls mixed up with the package balls > earlier. I was plumb lead astray. hehehe ... was fun anyway :) When the packaging guide thermal discussion talks about "high end" being 25W, and you are considing a worst case design that might be several times that you really have to wonder what the real design considerations are at this fringe. There clearly isn't enough data up front to do a pencil and paper design, and still feel good about it.Article: 96286
In CPLDs the most usual way to calculate this was taking the output of a flip-flop in one macrocell to the input of a flip-flop in another macrocell running in a simple non-extended p-term mode. Some vendors will give a frequency between macrocells in the same block but more often than not the system figure is between 2 macrocells in effectively different blocks (worst case no extra p-terms). Some of the newer CPLD technologies may blurr this defination if I have not already lost you this defination. FPGAs are not so simple. Some years ago Xilinx talked about a 1GHz counter running but certainly wasn't system frequency. The different vendors do put different biases on their numbers so my personal defination for SRAM type architectures is the speed for an average design with about 3 levels of lut logic average. Very roughly Spartan-3 gets about 150Mhz on my metric a Spartan-2 goes above 100MHz etc. The thing is with FPGAs a lot of factors can vary the frequency reached not least the luck, or maybe it's skill, of the designer. John Adair Enterpoint Ltd. - Home of UAP. Cheaper Boards for Students and Universities. http://www.enterpoint.co.uk "Raymond" <raybakk@yahoo.no> wrote in message news:1138806283.645748.153140@o13g2000cwo.googlegroups.com... > Hi There. > > Xilinx CPLD XCR3384XL with speed grade -7 have (according to the > datasheet) a maximum clock frequency at 135MHz. How have they found > that number? > > I have some timing problems on a FPGA and that trigged my curiousity. > (I am assuming that they use a likewise method to find the maximum > clock frequency in CPLDs and FPGAs, (but I'm not sure)). > > > Raymond >Article: 96287
Symon wrote: > <fpga_toys@yahoo.com> wrote in message > news:1138820483.937142.234800@g43g2000cwa.googlegroups.com... > >>Allan Herriman wrote: >> >>>Is it difficult to measure typical values of the voltage drop on >>>actual hardware though? Just set some outputs to be CMOS highs and >>>lows and measure their voltage at some convenient spot on the board. >> >>Measuring VccInt from an I/O pad? ... some trick? >> > > Leave one Vccint ball and one Gnd ball on the FG package disconnected. Use > those signals as the feedback circuit of your power supply so that the PSU > servos the on die voltage to the correct value. That does sound like a good idea, you probably should probe a package first, to verify the metalization lattice, and so choose a 'representative' pair - also ones that have reasonable adjacent density, so they will not be missed.... Then, you can locally power each FPGA, and I'd also add a thermal sensor on the PCB rear, just to double check what the die thermal diodes are telling you. I'd also route an IO pin, to the 'Smart PSU', that outputs a divided ring oscillator, so you can also track an actual freq-capable point. [ you _will_ want to overclock this, sometimes :) ] Each FPGA can then be Vcc adjusted, and even Clock adjusted, and the FAN (or pumps) cranked up accordingly... -jgArticle: 96288
Paul Johnson wrote: > On 1 Feb 2006 10:15:00 -0800, "Peter Alfke" <peter@xilinx.com> wrote: > >The basic question is: Why do you want (or need) to know? Tell us... > > 1) Nosiness; I'd say Curiosity, to sound more positive > > 2) It tells us how much the die costs you, and whether the chip is > likely to get to a reasonable price in the longer term; As I mentioned, that might not be an accurate measurement. Intel microprocessors are much more expensive per square mm. > > 3) It's a more useful metric than 'gate count' when comparing to ASICs > and other FPGA vendors. I violently disagree! FPGA chip size is inevitably larger than an ASIC of comparable functionality, but the FPGA offers so many advantages that often compensate for its larger size. And FPGAs are made in large volume, and are reconfigurable, ASICs are much smaller volume per design. etc Well-known arguments... Peter AlfkeArticle: 96289
All, More heat is conducted out the bumps, through the substrate, through to the pcb than through the backside heat spreader (without a heatsink). Even with a heatsink, as much as half of the power is going through to the pcb. I know that is hard to believe, but the heat is much closer to the bumps, the bumps are metal (ultra low alpha lead), and they go directly to a copper plane in the substrate (package pcb). FR4 and epoxies are pretty good at conducting heat. The lead balls to the copper pcb completes the (best) heat conduction path. The backside of the die is almost 1 mm of SiO2 away from the area that is hot, and has to then go through a thermal compound to get to the top heat spreader, and then has to be mechanically bonded to a heatsink (if you really want to get power out of the top of the package). Or so I am lead to believe. (I love the puns in this thread). Austin Jim Granville wrote: > Symon wrote: > >> <fpga_toys@yahoo.com> wrote in message >> news:1138820483.937142.234800@g43g2000cwa.googlegroups.com... >> >>> Allan Herriman wrote: >>> >>>> Is it difficult to measure typical values of the voltage drop on >>>> actual hardware though? Just set some outputs to be CMOS highs and >>>> lows and measure their voltage at some convenient spot on the board. >>> >>> >>> Measuring VccInt from an I/O pad? ... some trick? >>> >> >> Leave one Vccint ball and one Gnd ball on the FG package disconnected. >> Use those signals as the feedback circuit of your power supply so that >> the PSU servos the on die voltage to the correct value. > > > That does sound like a good idea, you probably should probe a package > first, to verify the metalization lattice, and so choose a > 'representative' pair - also ones that have reasonable adjacent density, > so they will not be missed.... > > Then, you can locally power each FPGA, and I'd also add a thermal > sensor on the PCB rear, just to double check what the die thermal diodes > are telling you. > > I'd also route an IO pin, to the 'Smart PSU', that outputs a divided > ring oscillator, so you can also track an actual freq-capable point. > [ you _will_ want to overclock this, sometimes :) ] > > Each FPGA can then be Vcc adjusted, and even Clock adjusted, and the > FAN (or pumps) cranked up accordingly... > > -jg >Article: 96290
Jim Granville wrote: > Each FPGA can then be Vcc adjusted, and even Clock adjusted, and the > FAN (or pumps) cranked up accordingly... Still begs the question of where the fuse point is for the package. A 140 VccInt 6 mil 1/2oz traces aren't exactly rated for any serious current without fusing. The solder balls to the die don't have great cross sections either. Plating boundries at the via junctions don't help, as the effective cross section for worst case design lowers due to etching and plating variances. This would leave the VccInt limit for the package something in the area of 15-25A using std tables and assuming a lot about the carrier pcb - or about 18-30W. Probably a LOT less as this isn't free air and one side is up against the hot die under worst case load, and the other side is insulated with the host PCB FR-4 providing little cooling for the IR heating in the traces/vias. Clearly a dense RC design at modest frequencies can easily exceed this in dynamic power. It's hard to even get a ball park without solid design data for the package pcb carrier board. There are additional questions which rapidly pop up, like can the die metalization (probably aluminum) even handle these currents without heating and migration problems. So, lacking real data from Xilinx ... it's probably very fair to say that the UG075 statement showing the high end limit at 25W may well be the limit for power when VccInt and VccIO are combined. The lack of real data really hampers designing safe worst case RC applications. If this is the case, then RC designs can not use any serious fraction of the raw performance in terms of "gate/LUT count" times "clock rate" product you might assume from the data sheet.Article: 96291
Raymond wrote: > Hi There. > > Xilinx CPLD XCR3384XL with speed grade -7 have (according to the > datasheet) a maximum clock frequency at 135MHz. How have they found > that number? > > I have some timing problems on a FPGA and that trigged my curiousity. > (I am assuming that they use a likewise method to find the maximum > clock frequency in CPLDs and FPGAs, (but I'm not sure)). > > > Raymond > This the maximal frequency of a shift-register ! Regards, Laurent www.amontec.comArticle: 96292
Ray, one thought -
I recently had to modify my romgen program (www.fpgaarcade.com) which
produces init strings and generics with a conversion function much as you
suggest.
However the Synplicity tool uses a different attribute style to Mentor's
Precision. I discovered that Synplicity at least will produce the correct
block ram init strings with only the generic set - no synthesis attributes
required.
About time too ....
/Mike
"Ray Andraka" <ray@andraka.com> wrote in message
news:gn4Ef.33686$bF.17923@dukeread07...
> cs_posting@hotmail.com wrote:
>> One thing that can be a bit of a pain is getting the data to be there
>> in both simulation and in the bitsream - often you have to put it in
>> twice. If the table isn't very big, encoding it in the HDL might be
>> simplest?
>>
>
> Yes, that is a pain. The generics for simulation want a bitvector, while
> the attributes for passing to the PAR tools want hex strings. Rather than
> enter the tables twice in different formats (and possibly getting a
> simulation mismatch), I find it easier to use a VHDL function to do the
> conversion of the bit vector to HEX:
>
> function bv2hex (val:bit_vector) return string is
> type hex_lut is array (0 to 15) of character;
> constant hextable:hex_lut :=
> ('0', '1', '2', '3', '4', '5', '6', '7',
> '8', '9', 'A', 'B', 'C', 'D', 'E', 'F'); constant
> str_len:natural:=(val'length+3)/4;
> variable temp:integer;
> variable ret_string: string(str_len downto 1);
> begin temp:=0; for j in 0 to val'length-1 loop if val(j)='1' then
> temp:=temp + 2**(j mod 4);
> end if;
> if (j mod 4)=3 or j=val'length-1 then
> ret_string(j/4+1):= hextable(temp);
> temp:=0;
> end if;
> end loop;
> return ret_string;
> end bv2hex;
Article: 96293I have an evm on order, but is there a place I can download the PPC linux for Virtex-4? I want to make sure I can build it okay. Thanks, ClarkArticle: 96294
Ray Andraka wrote: > Alternatively, you could generate ascii binary in your external > application and past that into an array of bit_vectors directly. This is where I like verilog's include directive... no pasting required.Article: 96295
Hi David, David Brown wrote: > It would be *very* nice to have pass-through parallel port access from > CoLinux. Personally, I'd be looking at it for debugging a ColdFire > running ucLinux rather than any Xilinx work, but I suspect it would be > of interest to a range of embedded developers. I know the CoLinux > developers have been looking at the possibilities of tunnelling serial > ports, parallel ports, and USB, but have had problems with locking > issues. If your "brainy guy" has working code, perhaps it could be > donated to the official CoLinux project? Should be OK - I'll see what I can do. JohnArticle: 96296
Hi, Please let me know - what is the advantage of fully specifying don't care conditions? -SandiArticle: 96297
Jim Granville wrote: > I'd also route an IO pin, to the 'Smart PSU', that outputs a divided > ring oscillator, so you can also track an actual freq-capable point. > [ you _will_ want to overclock this, sometimes :) ] I've been a little gun shy of leaving several fast ring oscillators running on Virtex parts since taking out two consecutive XCV800's that way a couple years ago, my lab desktop board after a client returned a dead board having done the same. It wasn't even that warm at the heat sink. I've never been sure if that was just a freak, or something to worry about. I asked the local FAE about it last year when doing the first XC4VLX200 design and kinda got a shrug and strange look of disbelief. After that I've been more careful to keep toggle rates closer to the chip's stated max clock rate.Article: 96298
fpga_toys@yahoo.com wrote: > Jim Granville wrote: > >> Each FPGA can then be Vcc adjusted, and even Clock adjusted, and the >>FAN (or pumps) cranked up accordingly... > > > Still begs the question of where the fuse point is for the package. A > 140 VccInt 6 mil 1/2oz traces aren't exactly rated for any serious > current without fusing. But you would not use 6 mil, 1.2 oz traces, in something you KNEW was going to the corners, would you ? Via escapes can be much wider than that, and you can always add multiple thermal vias, to your PCB... The solder balls to the die don't have great > cross sections either. Plating boundries at the via junctions don't > help, as the effective cross section for worst case design lowers due > to etching and plating variances. > > This would leave the VccInt limit for the package something in the area > of 15-25A using std tables and assuming a lot about the carrier pcb - > or about 18-30W. Probably a LOT less as this isn't free air and one > side is up against the hot die under worst case load, and the other > side is insulated with the host PCB FR-4 providing little cooling for > the IR heating in the traces/vias. You'll have old/partly dead FPGAs on PCBs ? - wire one backwards, so the substrate diode heats, and do some destructive tests - thermal and fusing.... > > Clearly a dense RC design at modest frequencies can easily exceed this > in dynamic power. OK - So we accept that the extreme case ceiling is going to be 'C detemined ( rather than simple Max_MHz ). That means you design the system with the most aggressive thermal, and current policies you can afford. Then, you test it - and have sensors that mean you can run to the envelope edges ? If you can then prove that the 'C is leaving a lot of MHz behind, in working, real case, designs - then Xilinx will probably be quite interested in finding better thermal package solutions. Intel spends a LOT of money on thermal and current aspects. -jgArticle: 96299
Austin Lesea wrote: > All, > > More heat is conducted out the bumps, through the substrate, through to > the pcb than through the backside heat spreader (without a heatsink). > > Even with a heatsink, as much as half of the power is going through to > the pcb. > > I know that is hard to believe, but the heat is much closer to the > bumps, the bumps are metal (ultra low alpha lead), and they go directly > to a copper plane in the substrate (package pcb). FR4 and epoxies are > pretty good at conducting heat. > > The lead balls to the copper pcb completes the (best) heat conduction path. > > The backside of the die is almost 1 mm of SiO2 away from the area that > is hot, and has to then go through a thermal compound to get to the top > heat spreader, and then has to be mechanically bonded to a heatsink (if > you really want to get power out of the top of the package). > > Or so I am lead to believe. > > (I love the puns in this thread). > > Austin So that mean the top end systems should remove heat from both sides, as well as place the most solid plane (GND?) nearest the package. Perhaps even copper lands, on the rear, to solder the heat pipes to. With stiched thermal vias, of course. -jg
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