Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 96275

Article: 96275
Subject: Strange problem with sysace + linux + Ace on SanDisk.
From: "tony.p.lee@gmail.com" <tony.p.lee@gmail.com>
Date: 1 Feb 2006 09:50:47 -0800
Links: << >>  << T >>  << A >>

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?


-Tony


Article: 96276
Subject: Re: Back to max thermal and power for XC4VLX200's
From: fpga_toys@yahoo.com
Date: 1 Feb 2006 10:01:47 -0800
Links: << >>  << T >>  << A >>

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'd


Article: 96277
Subject: Re: Back to max thermal and power for XC4VLX200's
From: Allan Herriman <allanherriman@hotmail.com>
Date: Thu, 02 Feb 2006 05:12:51 +1100
Links: << >>  << T >>  << A >>
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,
Allan

Article: 96278
Subject: Re: Die Area
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Feb 2006 10:15:00 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Die Area
From: Paul Johnson <abuse@127.0.0.1>
Date: Wed, 01 Feb 2006 18:45:24 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Back to max thermal and power for XC4VLX200's
From: fpga_toys@yahoo.com
Date: 1 Feb 2006 11:01:23 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: Back to max thermal and power for XC4VLX200's
From: "Symon" <symon_brewer@hotmail.com>
Date: Wed, 1 Feb 2006 19:10:01 -0000
Links: << >>  << T >>  << A >>
<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
Subject: microblaze GNU tools for win32 binaries (from 8.1 build) for download
From: "Antti Lukats" <antti@openchip.org>
Date: Wed, 1 Feb 2006 20:16:02 +0100
Links: << >>  << T >>  << A >>
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 !

Antti 



Article: 96283
Subject: Spartan3 pullups
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Wed, 01 Feb 2006 11:27:40 -0800
Links: << >>  << T >>  << A >>
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?


John



Article: 96284
Subject: Re: Maximum system frequency on FPGA/CPLD
From: Rene Tschaggelar <none@none.net>
Date: Wed, 01 Feb 2006 20:31:49 +0100
Links: << >>  << T >>  << A >>
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.net

Article: 96285
Subject: Re: Back to max thermal and power for XC4VLX200's
From: fpga_toys@yahoo.com
Date: 1 Feb 2006 11:50:53 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: Maximum system frequency on FPGA/CPLD
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Wed, 1 Feb 2006 20:15:04 -0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Back to max thermal and power for XC4VLX200's
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 02 Feb 2006 09:31:35 +1300
Links: << >>  << T >>  << A >>
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: 96288
Subject: Re: Die Area
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Feb 2006 13:27:32 -0800
Links: << >>  << T >>  << A >>
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 Alfke


Article: 96289
Subject: Re: Back to max thermal and power for XC4VLX200's
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 01 Feb 2006 13:36:01 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Back to max thermal and power for XC4VLX200's
From: fpga_toys@yahoo.com
Date: 1 Feb 2006 13:38:52 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: Maximum system frequency on FPGA/CPLD
From: Larry <laurent.gauch@amontec.com>
Date: Wed, 01 Feb 2006 22:44:19 +0100
Links: << >>  << T >>  << A >>
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.com

Article: 96292
Subject: Re: BPSK modulation on Xilinx FPGA
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Wed, 01 Feb 2006 22:23:48 GMT
Links: << >>  << T >>  << A >>
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: 96293
Subject: xilinx linux source?
From: "Anonymous" <someone@microsoft.com>
Date: Wed, 01 Feb 2006 22:29:07 GMT
Links: << >>  << T >>  << A >>
I 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,
Clark



Article: 96294
Subject: Re: BPSK modulation on Xilinx FPGA
From: cs_posting@hotmail.com
Date: 1 Feb 2006 14:30:14 -0800
Links: << >>  << T >>  << A >>
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
Subject: Re: Impact 8.1 problems=> uClinux rules on MicroBlaze !!!
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 02 Feb 2006 08:30:30 +1000
Links: << >>  << T >>  << A >>
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.

John



Article: 96296
Subject: don't care condition
From: "sandi" <sandipon.basu@gmail.com>
Date: 1 Feb 2006 14:32:24 -0800
Links: << >>  << T >>  << A >>
Hi,
Please let me know - what is the advantage of fully specifying don't
care conditions?
-Sandi


Article: 96297
Subject: Re: Back to max thermal and power for XC4VLX200's
From: fpga_toys@yahoo.com
Date: 1 Feb 2006 14:40:46 -0800
Links: << >>  << T >>  << A >>

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
Subject: Re: Back to max thermal and power for XC4VLX200's
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 02 Feb 2006 11:49:19 +1300
Links: << >>  << T >>  << A >>
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.

-jg


Article: 96299
Subject: Re: Back to max thermal and power for XC4VLX200's
From: Jim Granville <no.spam@designtools.co.nz>
Date: Thu, 02 Feb 2006 11:58:14 +1300
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search