EDK : FSL macros defined by Xilinx are wrong

<fpga_toys@yahoo.com> wrote in message
news:1138808303.733536.253170@g44g2000cwa.googlegroups.com...
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.
 
fpga_toys@yahoo.com wrote:
Symon wrote:
See how crazy this gets without enough data to work on?
Cheers, Syms.

No, only the heat spreader is at 0K, the die is at max temp, and the
FR-4 to my pcb would have to assume chip temp less free air heat
losses.

Shall we review your calcs assuming the die was at commerical temp
limits
See how crazy this gets without enough data to work on?

You do not have a clue what the voltage drop between the host pcb and
the die is at any current, much less your 870A example.

Show me in the data sheet please :)
 
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
 
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
 
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.
 
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
 
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
 
Jim Granville wrote:
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...
My PCB's yes ... the question is just what is the construction and
limits of Xilinx's package pcb that acts as the carrier for the die.

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.
Do we? There have been some pretty strong statements here it's only a
thermal limit.

Then, you test it - and have sensors that mean you can run to the
envelope edges ?
So you test it with 10 lots of chips that all happen to have process
variences to support a higher current profile. Then start building with
a lot of chips that are at the other extreme ... say etching took the
traces 20% under at spots due to photomasking failures ... but well
inside the PCB mfg's stated tollerances for the build quote. I've
always been uncomfortable with doing designs that way. Trail and error
is not s substitute for engineering.

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.
I'm not sure that's the case, but there are nagging questions pointing
that way with some experience, the current lack of hard data and trying
to make conservative design assessments.

It may simply come down to their using the old rules of thumb that only
15-25% of the design will be active, and scaling needed resources to
that number. When I was doing the XC4VLX200 design last year the local
FAE was dead sure that I only needed to use power estimator numbers in
that range. A number of demonstration programs hit older XCV2000e's
and XC2V6000's a lot harder ... like packing them with RC5 cracking
engines, or distributed arithmetic engines. I was off by a factor or
3-5 on power estimates.

RC may tend to push the active design portion of the chip to numbers
near 100%, and with it much higher toggle rates than a typical hardware
controller design.
 
Austin Lesea wrote:
Our FPGAs will do a lot: you need to know how best to use them if you
want to squeeze this kind of power out of them. I think it would
require a liquid cooling solution.
My cooling solution has been water or phase change on high density
designs for a couple years, with heat exchangers directly
attached/integral to 1/4" or 3/8" milled copper plate heat sinks
spaning 16 to 64 parts per board. Air just can not carry enough heat
away in dense designs.

Thanks for the specific data on the per pad currents. Did I misscount
the VccInt pads? I only get 140 on the 1513 package listed as the only
option for the LX200. That would lower the dynamic power limit from 50W
to about 44W by your numbers.
 
actually a bit lower than 44W if the worst case design current is fixed
at 250ma/pad during clock current peaks, and the average current is
lower.
 
fpga_toys@yahoo.com wrote:
Jim Granville wrote:

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...


My PCB's yes ... the question is just what is the construction and
limits of Xilinx's package pcb that acts as the carrier for the die.
I thought these top end FPGA's, were flip-chip, no bondwires stuff ?

-jg
 
fpga_toys@yahoo.com wrote:

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.
Interesting - plausible, if they were 'several'.
The type of ring Osc I expected was not "many of the fastest", but one,
designed to be longer and slower - you are trying to get a physical
verify of the silicon/process/temp/vcc ability, and you want to avoid
local heating.
-jg
 
Austin Lesea wrote:
With that much stuff switching, I doubt seriously you would see any real
narrow peaks.

The clock is spread out over 2 ns of distance/speed of light on chip,
and the switching is as well.
Yeah ... for LX200's certainly true.

With just the Tckskew for the LX200 being 1.2ns, 500Mhz/2ns would yield
a fairly smooth distribution. Small parts don't have that problem, and
would
tend to cluster around clocks more, as the skew is about the same as a
LUT
delay. But likewise, because of the skew, a large RC design with a
single
clock would be forced down below 200Mhz on an LX200, and the clustering
is likely to reappear in the first 1.5ns of the clock period.

Now, since you have just learned (from Xilinx) how we do all the deep
sub micron engineering so you do not have to, I will submit my bill and
we can move on to more interesting topics?
Hmm ... I missed that full lesson ... shucks :(

Anyway yes ... you have been far more helpful than others I've asked.
And while it's not at the detail I would like, I can live with the
general
validations for today.
 
Jim Granville wrote:
I thought these top end FPGA's, were flip-chip, no bondwires stuff ?
They are. but instead of mounting the chip on the pad side of the pcb
carrier, they are solder bump (AKA very small balls) mounted to the
other side of the pcb carrier and use vias to get to the BGA pads on
the
other side. The bump pitch is much tighter than the BGA pitch, and it
allows them to have more pwr/gnd bumps/pads than are on the other
side for the pcb BGA. And as Austin pointed out, it allows them to
use a multilayer pcb carrier to have pwr/ground planes in the carrier
pcb to spread out the current more evenly, and probably act better
as a bonding side heat sink.

This also means that the "trick" of issolating a VccInt and Ground pair
doesn't actually measure the die voltage, but the pwr/gnd plane of
the carrier, and there will still be a voltage drop from the via,
traces
and pads to the bumps.
 
Tim,,

That is so last year.

Howard Johnson showed that the loops need to be made small.

As it turns out all ranks of connections inside the square carry no
current at all. Solve Maxwell's equations, and surprise!

So, alternative power and ground is the best.

That is what our SparseChevron(tm) is all about.

Austin

Tim wrote:
Typically FPGA BGAs have a central square of balls which are all connected
to ground. What is the current wisdom on how to hookup the PCB tracking for
the central ground matrix.

The simplest, and lowest inductance, seems to be to put down a solid square
of copper covering the central ground ball pads, and pepper the square with
ground vias. But that looks like the dreaded 'Solder Mask Defined' pads. Is
it better to go with individual NSMD pads, tracking, and vias?

Thanks.
 
There doesn't seem to be a fix for this. As a work around, I scrapped
the PLB_DDR controller and DDR sim module. In its place, I used
Create/Import wizard to make a PLB slave pcore that supports bursts.
This pcore instantiates a large memory array and I'm now using this in
simulation. It seems to work well. This solution only took a few hours
to implement...I wish I done this in the first place :)

NN
Nju Njoroge wrote:
Hello,

Sometime back there was a question on the comp.arch.fpga about
interfacing a PLB master pcore with the PLB DDR controller (see below
for thread or check this out:
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/72bc1bce10a2a4ac/adc03dda153a66c8?lnk=st&q=Sl_rearbitrate&rnum=1&hl=en#adc03dda153a66c8).
Recently, I have set-up a simulation environment in which my master
pcore talks a PLB DDR controller (instead of a PLB BRAM). My master
pcore issues 384 writes to the PLB DDR controller, then it reads from
the locations it wrote. My master pcore successfully completes all 384
writes, then it starts the reads. On the 109th read, it encounters the
exact same problem as described in the posting. Anyone encountered this
issue and fixed it? I have been avoiding using PLB_DDR in simulation,
but I have some apps that use too much memory and cannot fit in the
conventional PLB BRAMs.

Thanks,

NN
 
Antti Lukats schrieb:
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/

the toolchain as compiled and made available is now also tested to
compile working uClinix flat images so it is possible to cross compile
"Out-Of-Tree" for uClinux !!

really nice you type make on Windows machine, you get the binary and
that will actually work on microblaze - uClinux !!

so no need for CoLinux or full linux box if you are only writing
userland applications for uClinux on winPC

Antti
 
I am working on project, where I am using CPLD operating at 5V supply.
Can we direcly give the high inut voltage i.e. +5V to its input pin?
that depends on the chip you use ...
usually they support 1-2 higher voltage standards as input than they
deliver as output but you can only find out about that by looking to the
data-sheet of *your* CPLD ...


the newer parts run on lower voltage and at least recent FPGAs would not
even support 5V - that is why we use some of the old FPGAs as well ...
Looks like you can still buy them but recent Xilinx ISE tools do not
support them any more so we have a few machines still running ISE 4!


bye,
Michael
 
"Gabor" <gabor@alacron.com> wrote

an excellent post! We use a criss-cross pattern of smaller traces going
between the pads and vias, four narrower traces per gnd pad and per via.
Makes it look nicer around the edges of the central cluster, but works much
the same as yours!
Cheers, Syms.
 
Austin

This all suggests that I can have an outer ring of vias in the center
of a device (next to every "outer" gnd ball) and a copper pour on the
top layer connecting the rest of the gnd balls with a few vias. I can
then easily put some bulk decoupling right in the center of the bga as
it is no longer peppered with vias. If this is the case then you have
my thanks for pointing this out.

By the way, you say no current flows on the inner balls but surely they
carry their share of the DC current?

Regards

Colin
 

Welcome to EDABoard.com

Sponsor

Back
Top