EDK : FSL macros defined by Xilinx are wrong

[Symon]

"colin" <colin_toogood@yahoo.com> wrote in message
news:1138876017.581870.242570@g43g2000cwa.googlegroups.com...

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.

We leave out an occasional via to squeeze in 0805 caps in this centre

region. Works well on our FG676 parts with, IIRC, a 6x6 centre. The 0805s
are 2mm long so they fit nicely into the via matrix. The 0805 pads are
directly aligned with the FPGA GND pads, so the via fit into the gaps.
HTH, Syms.

 

[austin]

dp,

As I said, you do not believe me.

Go run the simulation for a 6X6 array.

The outer wall of 6 is + (6+6+3+4, the perimeter), and all the inner 5X5
(25 conductors) are -.

Then look at the distribution of current at DC.

I did find one article on furnaces, which showed the proximity effect on
carbon electrodes, but it also made mention of frequency effects, and
seemed unclear on what they saw. They clearly saw what I describe in
the plots of current. But, they also attributed it to the 50 Hz AC
field (which is pretty absurd....skin effect at 50 Hz is negligable!).

As I said, well misunderstood. Even after looking at the answer, they
explained it wrongly.

Austin

dp wrote:

austin wrote:

dp,

I know you do not belive me. And you haven't ever solved Maxwells
equations for this case (or else you would see it).



Austin,
I also think it is some kind of misunderstanding, of course.

Perhaps (if you refer to the railroad story) the motion came
from the train moving, or something else they just did
not take into account initially, things like that do happen.

However, for the case of the BGA socket, this cannot
apply. If there is no DC current through the central pads
it can only be because of higher active resistance or,
more likely, because there is little if any (leakage only,
I guess) DC current to talk about. Come to think of it,
it should be that last one.

BTW, my (1.27 mm pitched) BGA designs all have a
via hole in the center of each pad, this is OK if you run
small quantities.
The most important drawback is the necessity to once
fry the BGA chips belly up with some flux, before you use
them on the board, lest some of the balls get detached
(come coldly soldered from chip vendor) and flow through
the board forming a bubble .... (I had this several times until
I figured out how to deal with the problem).
The most important advantage is obviously having access
to all the BGA pads with the scope etc.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

 

[dp]

Jim Granville wrote:

austin wrote:
dp,

I know you do not belive me. And you haven't ever solved Maxwells
equations for this case (or else you would see it).

I am not going to convince you, so I will not try, but it is a real
effect, and it really happens.

I also admit that it is greatly misunderstood (after all, Westinghouse
believed as you do, util they made a million dollar mistake by building
it, and experiencing it first hand).

Take a magnet near the front of a Shadow mask CRT, and you can
clearly see the effect a magnet has on moving (dc) electrons.
DC current requires electrons to move, even if the ammeter does not.

-jg

High school physics is sufficient to know you can deflect the beam of
electrons because of the two interacting magnetic fields, the one the
electrons produce when moving with the one you apply with your
magnet.
The DC current value remains unchanged, I hope you are aware of
that.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------

 

[Jeff Shafer]

Thanks Joey, I'll definitely keep everybody up to date if I get this
working. Xilinx support keeps sidestepping the issue. I already have
shared memory across the PLB working with no problems, but it's kinda slow.
I'd much rather use the 3-cycle OCM instead. It just seems like such an
obvious way to connect the two processors. Of course, if I have to implement
a lock in the PLB BRAM to get the OCM BRAM to share properly, that might
negate much of the performance advantage of using the OCM in the first
place.

Jeff



"Joseph" <joeylrios@gmail.com> wrote in message
news:1138951712.444434.71790@g14g2000cwa.googlegroups.com...

Jeff,

I experienced some of this same quirkiness with a shared DSOCM BRAM and
could'nt pin down the cause. This non-determinism led me to use a
shared PLB BRAM, where I experienced no such problems. If your system
requirements will allow it, I would switch to using the PLB bus since
there isn't much documentation out there on using cooperating PPCs, let
alone via sharing a DSOCM BRAM. On the other hand, if you figure out
what is going on, I'd love to hear about it!

Good luck,
Joey

 

[al82]

dp ha escrito:

I am pretty sure you don't just assume there is little,
if any DC current flowing through the central BGA pads,
you know it is so. It just cannot be explained by any
static magnetic field, that's all. My assumption
is that there just is no DC current, it can be measured
as DC once it has been summed up in the power/ground
plane capacitance, decoupling capacitors etc. With CMOS
chips, you actually have only leakage DC current, which
is orders of magnitude lower than what I believe we are
talking about. The rest is only AC.

I think that you are calling AC current to what actually is Switching
current, but CMOS transistors switching current is DC.

Try to add a DC ammeter in the VCCAUX and you will see several hundreds
of mA. That's why you need a large DC voltage regulator.

The result is that there is a large DC current flowing through the
central BGA pads as well as some AC current (that originates from
changes in the DC current value).

 

[colin]

All

It seems to me that when I learnt Kirchoffs there should have been a
caveat that these laws are almost completely pointless (even at DC!)

Any decent pointers as to where to start reading would be appreciated.

Colin

 

[Paul Johnson]

On 2 Feb 2006 17:07:42 -0800, "dp" <dp@tgi-sci.com> wrote:

Austin Lesea wrote:
.....
The static magnetic field will force the static electric field to be
confined to the area adjacent to the current flow in the opposite direction.

.....

Austin,

sure you did not really mean that? Static magnetic fields do not
affect electric field(s) according to physics.

I think the confusion is in the use of the word 'static'. A DC current
produces a magnetic field (Ampere's law, and Maxwell's 4th eqn). Line
up two conductors next to each other, run a current through them, and
the two resultant magnetic fields will interact. An electron in bar A
will move in the component of the magnetic field produced by bar B,
and so will feel a force due to it. This is the proximity effect.
Perhaps not all 'static', but all DC.

 

[Uwe Bonnes]

austin <austin@xilinx.com> wrote:

Further,

Anyone who can point to a clear and simple explanation, please do.

When I first mentioned this to our packaging group, the lead engineer
said "oh yes, I see this in the EM simulations..."

So, I know I am not imagining it!

Perhaps put some simulation results online, with an explanation of the
input data. With simulation GIGO (garbage in, garbage out) easily comes
into play.
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Paul Johnson]

So, what's the answer? Either

a) The central balls "carry no current at all", are isolated from the
die GND, and are just for thermal conduction, or

b) They are connected to the die GND, they do carry some return
current, although less than the GND pins at the edge, and their
decoupling is still important, but not very important?

 

[Nju Njoroge]

Hello,

Please refer to this thread:
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/4373c26ee4c38328/aebfcf5e6f06f52c?lnk=st&q=PLB+Master&rnum=1&hl=en#aebfcf5e6f06f52c

(Google "PLB Master" in Googe Groups and this will be your first hit).

Properly using the IP2IP_Addr in the IPIF is what allowed my master to
work properly.

Good luck,

NN


agou wrote:

Hi, group

I generated a IPIC interface by the Create and Import Peripheral Wizard

to access PLB_DDR blockon the PLB bus.

I chose the DMA, user logic Master Support mode. And then try to
develop my own logic based on the generated files. Here, I have one
problem:

To write to an address on PLB bus, I need to provide two addresses:
IP2IP_Addr which stores the source data and IP2Bus_Addr
to which writes the data. Do I need to instantiate a BRAM in the FPGA
to provide the source address?

What I am not clear is whether the BRAM is compatible the IPIC logic.
Or do I have to instantiate another PLB_Bram and then hook it up to the
PLB? Are there any other simple method?

Thank you for the help.
Roger

 

[Marc Randolph]

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

Howdy Austin,

Could you provide a bit more detail on this? UG112 seems to say that
theta JB varies too much from situation to situation to be worth
publishing. If it has even more impact on cooling the device than the
theta JC, it seems like more information should be provided.

Furthermore, how much closer to 0 degC/W could the thermal resistance
be, compared to the ~0.6 degC/W of the flip-chip packages? Or were you
referring to everything except flip-chip?

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.

Isn't the heat spreader on the flip-chips also copper? It seems like
going through one tiny layer of thermal grease and one layer of
heatspreader would have less thermal resistance than bumps + epoxy +
substrate + ball + pad + via + ground plane. I don't see mention that
the substrate has a substantal amount of copper in it, but that doesn't
mean it isn't there and just not well documented.

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

I think you are referring to non-flip-chip here?

Thank you!

Marc

 

[Brian Drummond]

On 2 Feb 2006 18:25:17 -0800, "dp" <dp@tgi-sci.com> wrote:

austin wrote:
Further,

Anyone who can point to a clear and simple explanation, please do.

When I first mentioned this to our packaging group, the lead engineer
said "oh yes, I see this in the EM simulations..."

So, I know I am not imagining it!

Austin

Austin,

the only way a simulator can see DC current
resulting from a static magnetic field is a software bug
or, worse, misconcepted basics behind the software.

I don't think he's talking about the magnetic field generating a DC
current; but modifying the path of one that exists from other causes
(the PSU).

Think about those moving electrons (beta particles) in a particle
detector; a static magnetic field certainly modifies their path.
(Thus you can determine their velocity from its radius)

Also think about the force on two busbars carrying a _DC_ current; on
what does the force act? On the electrons, i.e. on the current, which
(in modifying their path) apply force to the busbar.

The same will apply in a BGA package; it will not generate any current,
but it may redistribute it between conductors.

- Brian


- Brian

 

Michael Hennebry wrote:

I've recently read some articles stating
that a realy fast place and route algorithm
for fpgas would be a good thing.
In this case, "really fast" means sub-second
or even sub-millisecond.
For what kind of applications would one
need such fast "compile" times?

Compile time is a completely different issue. In using an FPGA as
a processor (for netlists) the practice of dynamic linking becomes
just as useful for FPGA's as it is for processors. Consider that your
operating system is loaded with hundreds/thousands of dll's and .so
objects for libraries and small modules. It's actually more useful, as
the amount of "memory" (AKA LUT's) in an FPGA is smaller, a LOT
smaller, so the practice of swapping/paging in smaller netlist seqments
will be a necessary tool to avoid completely reloading an entire FPGA
image in the form of a freash bitstream.

Once one has done the compiling,
How fast can one program
an fpga anyway?

How many times do you compile a program? ... How many times do
you execute/dynamically link an object to run it? Link and go times
are much more important than compile times, except maybe for
very large programs that a programmer is debugging.

Loading an entire bit stream is very time intensive ... loading a few
collums is a LOT faster.

 

[Jim Granville]

dp wrote:

When the electrons move inside a conductor (metal), this effect
is seen as a mechanical force applied to the _conductor_. It takes
electric rather than magnetic field to move electrons inside the
conductor. This is how electric motors work. You _cannot_ affect
the path of the electrons inside the conductor by a static magnetic
field, just as you cannot force them to exit the conductor.

If true, then why do superconductors have a critical magnetic field level.
Moving electrons are influenced by magentic fields, the key
question, is how much ?
-jg

 

Austin Lesea wrote:

As I already said, I will post some results (when I find them).

I've given seminar talks for the last 20 years pressing designers to
constantly reevalutate the underlying assumptions in a design, as they
frequently change, and with small invalidations in the foundation, the
whole design can, and does, fail. Actually to document them, and well.

As a consultant tackling failed projects, one reoccuring theme when
I started probing the design/architecture was asking questions about
the assumptions and getting the "everybody knows ..." answer. The
"we have always done it that way, and it works ..." answer. Well, why
is it now broke?

This is another case of "everybody knows", that will be fun to add to
my
on going talk, "It's not what you know that will hurt you, it's what
you
think you know" as a case study

 

fpga_toys@yahoo.com wrote:

Michael Hennebry wrote:
I've recently read some articles stating
that a realy fast place and route algorithm
for fpgas would be a good thing.

A VERY GOOD P&R is necessary to optimize a hardware
design.

A VERY FAST P&R that is pretty good, is necessary to use
an FPGA as a netlist processor.

 

[Jim Granville]

Austin Lesea wrote:

Paul,

The latter (b).

They do carry current, but it is falling off as 1/r or 1/r^2 (I just
can't remember which).

The BART rails had 2/3 nearest the power rail, and 1/3 in the rail
furthest. Which makes me think it was 1/r, not 1/r^2.

Also, BART has shorting links every X meters that ties the two rails
together (now) to lessen the return resistance (improve efficiency).

Hmmm....

I think I was told that the inner 2X2 balls had 1/8 to 1/16 the
current...but it may have been more (or less).

Hmmmm....

As I already said, I will post some results (when I find them).

Please do, we can agree there is an effect, my antennae just question
how much of an effect at DC ?.

You still have to satisfy ohms law, so any push effects that favour
flow, have to model somehow as mV(uV) generators....
To skew Ball DC currents 7/8 or 15/16, frankly sounds implausible, and
maybe the models there forgot to include resistance balancing effects ?
[ ie do not believe everything you are 'told' ]

-jg

 

[Symon]

<fpga_toys@yahoo.com> wrote in message
news:1138992533.556317.212590@g49g2000cwa.googlegroups.com...

As a consultant tackling failed projects, one reoccuring theme when
I started probing the design/architecture was asking questions about
the assumptions and getting the "everybody knows ..." answer. The
"we have always done it that way, and it works ..." answer. Well, why
is it now broke?

That's the monkey story.

http://www.wowzone.com/5monkeys.htm
Monkeys are funny.
Cheers, Syms.

 

[Sylvain Munaut]

Hi Jeff

Jeff Shafer wrote:

Question summary: Can I successfully share a Xilinx dual-port BRAM between
two PowerPC data-OCM's where it is possible to write and read the same
location at the same time without corrupting the data? (by different
processors from different ports of the BRAM) I don't care if the read
returns the old data or the new data from the write, but I want the read
results to be deterministic and repeatable without corrupting the write.

As I understand, you use 1 port always for read and another always for
write.

So you could clock the write port on the negative edge even while
keeping the two processors and their plb bus on the same clock. Let's
says clk is your main clock. Instead of feeding di,dip and wren directly
to the BRAM, register them in the clk domain, then connect the output of
these registers to the respective port of the BRAM and feed "not clk" to
the wrclk ping of the BRAM.


Sylvain

 

[agou]

Hi, Nju

Thank you for the reply. I don't know whether your code in last thread
derived from the user_logic.v generated by the Create and Import
Peripheral Wizard. And I am currently reading this code.

In this code, there is a port named IP2IP_Addr, and in your last
thread, you first connected with the IP2Bus_Addr and then you revised
it to your local target memory. What I am not clear is that how to
instantiate the "local target memory" which is compatible to the IPIF?
Should I instantiate a PLB_BRAM block?

Besides the above, in the user_logic.v, there is a 16 bytes flattened
registers(mst_reg(0:15) in the sample code) which are used for the
control from the software side. Meanwhile, in the sample code, each of
this address is assigned a specific address, e.g. IP2IP register is
located at C_BASEADDR+0x104. And I saw another reference design in
which software could read these register directly by the address. So I
just wonder whether I could allocate some other registers in my
hardware and specify the address myself. If it could be done, then for
writing, I could just store my data in these registers first and then
assign these registers' addresses to the IP2IP_Addr. But I don't find
anything on how to specify the registers' addresses in the sample code.

So now, could you tell me how did you do to use a "local target
memory"? And do you know whether the second method would work or not?

Thank you
Roger

Nju Njoroge wrote:

Hello,

Please refer to this thread:
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/4373c26ee4c38328/aebfcf5e6f06f52c?lnk=st&q=PLB+Master&rnum=1&hl=en#aebfcf5e6f06f52c

(Google "PLB Master" in Googe Groups and this will be your first hit).

Properly using the IP2IP_Addr in the IPIF is what allowed my master to
work properly.

Good luck,

NN


agou wrote:
Hi, group

I generated a IPIC interface by the Create and Import Peripheral Wizard

to access PLB_DDR blockon the PLB bus.

I chose the DMA, user logic Master Support mode. And then try to
develop my own logic based on the generated files. Here, I have one
problem:

To write to an address on PLB bus, I need to provide two addresses:
IP2IP_Addr which stores the source data and IP2Bus_Addr
to which writes the data. Do I need to instantiate a BRAM in the FPGA
to provide the source address?

What I am not clear is whether the BRAM is compatible the IPIC logic.
Or do I have to instantiate another PLB_Bram and then hook it up to the
PLB? Are there any other simple method?

Thank you for the help.
Roger