So, back to the question of worst case designs for supporting RC.
What are the worst case VccInt currents that various packages will handle? How does that relate to what is necessary for balancing the design across multi phase clocks to spread the current spikes following clock edges in time?
Is there any means to get a handle on the current time spread profile by knowing the distribution of routing lengths and logic depths for each clock?
I assume ground pads are shared between VccInt and I/O? If so, how would one combine worst case VccInt ground currents with the worst case I/O ground switching currents for a worst case package level design spec?
Hi John, OK, let's work through this. First I'll pick a package, say FG672. Now, I'll choose a part, say FX20. From UG075 ThetaC = 0.4 and ThetaB = 3.8. So, best case thermal resistance from junction to case = 0.4 // 3.8 = 0.36 K/W
OK, say we've selected a commercial grade part. That means our junction temperature can't exceed 85degC or 358K (from DS112). The minimum Vccint voltage is 1.14V (from DS302).
Right, you asked for worst case Vccint current, which I assume means 'what's the maximum current' the package can handle.
Assuming best case heatsinking, we can keep the case at c.0K with a perfect liquid Helium cooled heatsink. Therefore we can dissapate 358/0.36 = 1000W. Vccint can be 1.14V, so that's a maximum current of about 870A.
Now do you see why you're asking the wrong question? ;-) Of course my example is a ridululous exaggeration, but your posting provided little to go on. You need to do a proper analysis with thermal simulation tools to get a meaningful answer, and even when you get that answer it'll be wrong!
Try this bloke's book:-
formatting link
There's a brief review of the book by an FPGA expert on Cambrian Design's website
formatting link
HTH, Syms.
p.s. I hereby release the copyright on this post to avoid any legal ramifications. ;-)
You won't be limited by the current carrying capabilities of the wires. It's the thermal that will limit you. Flip-chip packages can deal with a lot more heat and they can deal with a lot more current. You're probably concerned about the wire bond packages but those have higher thermal resistance, limiting the amount of power.
To keep working under high speed *or* low speed conditions, the current effects from a single clock edges *must* be mitigated in the first few hundred picoseconds by distributed capacitance on the FPGA silicon and package. The "high frequency" capacitance needed externally is typically for the Gigahertz and below frequency range. The nice thing here is that the huge super-short current spikes don't need much capacitance to keep the voltage up. Proper decoupling needs an understanding of what the biggest current steps are in the applicable frequency range. We don't need to know the current "surge" at each clock edge in these devices; the worst case condition for this worry of yours is one single clock distributed across the chip. Single clock synchronous designs make up a large number of FPGA designs. There aren't problems. It's when you go from nearly no activity to massive activity (or back) that the external decoupling and power regulation needs to handle the massive change in current. This is design.
Again, stop thinking that the wires will cause you problems. Your balls won't vaporize and your wires bonds won't fuse because the quantity and distribution of power in the FPGAs accommodates some nasty design corners. If you can remove the heat, you can source the current. If this wasn't the case there would be a significantly larger population than you freaking over the power.
Symon was going over some thermal resistance values in another response. It's that level of engineering needed for proper heat sing desing. I did a quick look at the Aavid embedded fan heat sink for a XIlinx part when you were first blowing the design issues out of proportion. The junction-to-case, thermal interface material, and heat sink had thermal resistance values of 0.1 C/W, 0.2 C/W, and 1.38C/W (I think that's "respectively"). If you were designing for 40W in 45C ambient with 125C die temperature, everything's fine with that simple "active" heat sink. The 125C is the temperature you mentioned in an earlier post but the commercial and industrial *operating* die temps are lower than the "absolute maximum" junction temperature value you referenced, at 85C and
100C for the Virtex-4 series, respectively. See the ordering information for the junction temperature ranges.
So in the example above you'd need a better solution than that convenient small embedded-fan heat sink. The processor heat sinks demonstrate thermal resistance values far below the 1.38C/W for this one heat sink. Proper selection - or design - of the heat sinks are required to meet your maximum operating power and maximum operating ambient temperature.
If we were talking about mounting bare die to my pcb your answer would be close.
Now, what is the voltage drop from my pcb pads to the die at 870A for both the ground and VccInt paths?
Those little tiny balls, via's and traces on the chip carrier PCB have just enough cross sectional area to be called fuses. And not enough cross sectional area to avoid a voltage drop.
You're forgetting that the liquid helium cooling we've designed in has made your tiny balls into super-conductors. Both Lead and Tin are Type 1 superconductors. (Not sure about the solder alloy though, maybe you need RoHS parts?) You now only need to find the current that causes the critical magnetic field strength above which the superconductivity stops. Sadly, gold and copper don't superconduct; their lattice vibrations are too small. (Hint :- Think Cooper pairs.) However, the liquid helium should stop them vaporizing. All we need to do is turn up the external Vccint a little to compensate for the voltage drop in the traces and bond wires thus keeping the Vccint on the die in spec. :-) See how crazy this gets without enough data to work on? Cheers, Syms.
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? :-) Syms.
p.s. For commercial temperature rated parts the current rating goes up by a factor of (125 + 273.13) / (85 + 273.13) . I guess.
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.
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.
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.
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.
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...
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).
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.
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.
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
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....
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.