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 96400

Article: 96400
Subject: Re: BGA central ground matrix
From: "colin" <colin_toogood@yahoo.com>
Date: 3 Feb 2006 01:31:23 -0800
Links: << >>  << T >>  << A >>
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


Article: 96401
Subject: Re: BGA central ground matrix
From: Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de>
Date: Fri, 3 Feb 2006 09:39:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
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 ----------

Article: 96402
Subject: FPGA ogg Vorbis/Theora player
From: "urielka" <uriel.katz@gmail.com>
Date: 3 Feb 2006 01:57:24 -0800
Links: << >>  << T >>  << A >>
i am quite a newbie in FPGA development.
my idea is build a SoC(System on Chip) which will be a Video/Audio
player based on FPGA(Xilinx Spartan 3E 1M gate count).
the video and audio decoders are Vorbis for audio and Theora for video
and will be almost hardware based as posible.
the desgin will have a Soft CPU for directing data from CF,reading the
fs and then output a bitstream to decoders.
the audio decoder will output all the data to a DAC(20bit or 24 bit for
better quality).
the video decoder will write to a RAM which will be the LCD
framebuffer.
the cpu also can write to the framebuffer but it will write over
decoder data so i will have some kind of osd when the decoder is
playing(like for remaining time,volume and other stuff).

from what i understand,doing a full ogg decoder on chip is madness so
what i have to do i build coproccessors that will do most of
clock-expensive and the software will use those coprocessors,right?

the storage will be a CF card which are damn cheap and can work as
IDEs.
the part i want to know if this is posible to be done in a FPGA.

i saw a guy that made a full Theora camera which use a encoder for
super-high resolutions(1024x768@30FPS-->1280x1024@15FPS) on a Spartan
2E which have a 300K gates.(that desgin is 96% of the FPGA,the article
is in linuxdevices)
so i guess a decoder that can decode 160x120-->640x480 @25FPS streams
will be alot smaller and could fit into a FPGA.

i could move all the ogg vorbis decoder to a ASIC vorbis decoder(they
exsist :) ) so saving the time about implenting the ogg vorbis format.

what you think,it is posible? which soft cpu(s) should i use,which
things the cpu need to preform real fast? is it posible on a
Spartan(development boards for spartan are damn cheap).
if it is important to someone the desgin(the final one) will be powered
with a LiPo battery :)

thx in advance


Article: 96403
Subject: Re: Die Area
From: David R Brooks <davebXXX@iinet.net.au>
Date: Fri, 03 Feb 2006 02:22:27 -0800
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> Yes, and the first computers used two triode vaccuum tubes to store a
> bit, with a supply voltage around 150 V.
> 60 years of Progress !
> Peter Alfke
> 
Colossus used (afair) 4 pentodes: 2 for the flipflop, and 2 more to 
switch it, essentially wire-ANDed to each of the F/F tube anodes. They 
made each of the switch tubes act as a 2-input AND gate, using the 
control & screen grids independently (& at different voltage levels).
Why pentodes? They were already being produced in vast numbers, for 
radio & radar. Triodes had much less use in that sector.

An anecdote has it that when the truck driver went to requisition yet 
another truckload of EF36 tubes (but didn't know what they were for), 
the storeman asked him "what are you doing with those things? Shooting 
them at the Jerries?" :-)

Article: 96404
Subject: Re: Die Area
From: David R Brooks <davebXXX@iinet.net.au>
Date: Fri, 03 Feb 2006 02:24:42 -0800
Links: << >>  << T >>  << A >>
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!
> 
Quick answer: find a friendly dentist, & have him X-ray the package in 
question.
That's what we did at work many years ago (I no longer work at that 
company), when we wanted to examine (non-destructively) a competitor's 
product.


Article: 96405
Subject: Re: BGA central ground matrix
From: Paul Johnson <abuse@127.0.0.1>
Date: Fri, 03 Feb 2006 10:26:54 +0000
Links: << >>  << T >>  << A >>
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.

Article: 96406
Subject: Re: BGA central ground matrix
From: Paul Johnson <abuse@127.0.0.1>
Date: Fri, 03 Feb 2006 10:44:17 +0000
Links: << >>  << T >>  << A >>
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?

Article: 96407
Subject: Re: FPGA growth vs. ASIC growth
From: Paul Johnson <abuse@127.0.0.1>
Date: Fri, 03 Feb 2006 10:59:34 +0000
Links: << >>  << T >>  << A >>
On Fri, 03 Feb 2006 00:52:20 -0800, Caleb Leak <dornif@gmail.com>
wrote:

> I am trying to show the gap 
>narrowing between these two over time. 

Why would it narrow? At first sight, it should stay constant. For a
given FPGA technology, the differences are simply due to the extra die
resources required to implement a programmable feature as opposed to a
fixed feature. This difference should stay constant as both the FPGA
and ASIC move to new processes. 

The obvious differential is that the larger FPGA companies will be
able to take advantage of a new process earlier than most ASIC
customers. However, as process lifetimes increase (about 5 years now?)
this differential decreases, rather than increasing. Besides, it's not
in the interest of the fabs to only have a handful of customers on a
new process; they want everybody on it.

Another factor to take into account is that the FPGA vendor's
cutting-edge devices - the first ones on 90nm, for example - are
invariably large, expensive, and low yield, and so probably not useful
to most customers. So, it could even be argued that the ability to
take advantage of new processes isn't actually that useful anyway.

Article: 96408
Subject: Re: IP2IP_Addr in IPIF
From: "Nju Njoroge" <njoroge@stanford.edu>
Date: 3 Feb 2006 03:38:05 -0800
Links: << >>  << T >>  << A >>
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


Article: 96409
Subject: Re: xilinx linux source?
From: "Thomas Gebauer" <th.gebauer@gmx.de>
Date: Fri, 3 Feb 2006 13:06:25 +0100
Links: << >>  << T >>  << A >>
Try

make ARCH=ppc CROSS_COMPILE=<cross-compile toolchain prefix>

"Anonymous" <someone@microsoft.com> schrieb im Newsbeitrag 
news:KitEf.959$no3.741@tornado.southeast.rr.com...
> So the process is really:
>
> 1. get PPC cross compiler
> 2. get kernel source from kernel.org
> 3. generate board support packages from fpga design
> 4. build kernel
> 5. build ace file and boot
>
> So the magic is all in the BSP stuff which I assume is basically the BIOS
> code in a regular PC and the libraries/memory spaces for the various
> peripherals? Monte Vista is just making it easier for folks by packaging
> everything in one place?
>
> How does the kernel source know that I'm building for a PPC target?
>
> Thanks,
> Clark
>
> <tony.p.lee@gmail.com> wrote in message
> news:1138904088.604673.26180@g47g2000cwa.googlegroups.com...
>>
>> mvista is rsync site is just mirror of the public linux kernel site.
>> You don't need to pay monte vista to use it.
>>
>> It is not the only place to get it.
>>
>> -Tony
>>
>
> 



Article: 96410
Subject: Re: BGA central ground matrix
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 3 Feb 2006 12:09:46 +0000 (UTC)
Links: << >>  << T >>  << A >>
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

Article: 96411
Subject: Re: How will synthesizers handle these statements?
From: moogyd@yahoo.co.uk
Date: 3 Feb 2006 04:26:26 -0800
Links: << >>  << T >>  << A >>
In general, I don't think that a synthesis tool will share resources
between always blocks.

I find it best to "help" the synthesys tool where possible.

I would re-write the above code (verilog is a bit rusty)

parameter FinalCount := 8'h25 ;
wire AtFinalCount <= (process == FinalCount) ? '1' : '0' ;   // or
always block

always @(clk)
begin
   if (pop0 && FinalCount) || kick0
      whatever <= asdf0 ;
   else if
      etc etc
end // always


Article: 96412
Subject: Xilinx: generic tristates and multiplexers
From: "JL" <kasty.jose@gmail.com>
Date: 3 Feb 2006 04:46:39 -0800
Links: << >>  << T >>  << A >>
Hello all,

I have a problem with internal tristates in Xilinx Virtex-2. They
basically don't exist, although are widely used in the documentation.
Imagine you have N dual port rams with the enable inputs attached to
the output of a tristate like this:

g_loop: for x in 0 to N-1 generate
     nEnable(x) <= something(x) when (connect(x) = '1') else 'Z';
end generate;

As you know, the high impedance 'Z' state doesn't really exist inside
Xilinx Virtex-2 FPGAs, and will in fact appear as a '1'. When we
perform a pre-synthesis simulation, the simulator sees the signal as a
'Z', which is not the actual behaviour. After synthesis and
translation, the signal is properly seen as '1' instead of 'Z'.

A possible solution to make pre-synthesis and post-translate
simulations behave the same would be to use multiplexers instead of
tristates. But how can we build them in VHDL with a generic number of
inputs?

Other solution would be to make the pre-synthesis simulator see a 'Z'
as a '1'. We could achieve this with a pullup component, although I
never got it to work in the past. I wonder if there is another way to
make the simulator understand a 'Z' as a '1'.

Any hints?

Regards.
Jose.


Article: 96413
Subject: Re: Back to max thermal and power for XC4VLX200's
From: "Marc Randolph" <mrand@my-deja.com>
Date: 3 Feb 2006 04:55:16 -0800
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).

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


Article: 96414
Subject: [map error] unable to pack a IBUF into the IOB
From: "Pasacco" <pasacco@gmail.com>
Date: 3 Feb 2006 05:02:10 -0800
Links: << >>  << T >>  << A >>
hi

When exercising xapp290.pdf example, I met following error message
during MAP stage.

----------------------------------------------------
ERROR:Pack:1107 - Unable to combine the following symbols into a single
IOB
   component:
        PAD symbol "clock" (Pad Signal = clock)
        BUF symbol "clock_IBUF" (Output Signal = clock_IBUF)
   Each of the following constraints specifies an illegal physical site
for a
   component of type IOB:
        Symbol "clock_IBUF" (LOC=BUFGMUX4S)
   Please correct the constraints accordingly.
----------------------------------------------------

Meanwhile, I found following Answer in Xilinx Answer browser
---------------------------------------------------
The GCLK IOs can only use IBUFGs, so the tool is unable to pack a IBUF
into the IOB. To work around this issue, specify that the net use an
IBUFG. This can be done by instantiating it in your code or adding a
BUFFER_TYPE constraint to your code with the value set to IBUFG. The
syntax for these can be found in the Software Manuals.
--------------------------------------------------

However, when I put the following attribute, still same error message
appeared.

  // synthesis attribute BUFFER_TYPE clock "ibufg";

Does anyone have any suggestion? Thankyou in advance.


Article: 96415
Subject: Re: [map error] unable to pack a IBUF into the IOB
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Fri, 03 Feb 2006 14:59:45 +0100
Links: << >>  << T >>  << A >>
Pasacco schrieb:
> 
> Meanwhile, I found following Answer in Xilinx Answer browser
> ---------------------------------------------------
> The GCLK IOs can only use IBUFGs, so the tool is unable to pack a IBUF
> into the IOB. To work around this issue, specify that the net use an
> IBUFG. This can be done by instantiating it in your code or adding a
> BUFFER_TYPE constraint to your code with the value set to IBUFG. The
> syntax for these can be found in the Software Manuals.
> --------------------------------------------------

You are on the right path. It 'clock' is ffed into a GCLK pin, it must 
use a IBUFG!

> However, when I put the following attribute, still same error message
> appeared.
> 
>   // synthesis attribute BUFFER_TYPE clock "ibufg";
> 
> Does anyone have any suggestion? Thankyou in advance.

Those damm attributes are case sensitive, even in VHDL (which is usually 
NOT case sensitive) use

// synthesis attribute BUFFER_TYPE clock "IBUFG";

instead. But if 'clock' is used a s a clock inside your code, the 
compiler will detect this automatically and insert an IBUFG. So no need 
for explicitly using the attribute.

Regards
Falk

Article: 96416
Subject: Re: BGA central ground matrix
From: "dp" <dp@tgi-sci.com>
Date: 3 Feb 2006 06:33:45 -0800
Links: << >>  << T >>  << A >>
Brian Drummond wrote:
> ...
> >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)

I really regret I have to go back to this thread. I suggest everyone
posting more on this nonsense makes sure to consult at least
some high-school physics books first.
 The electrons (or beta particles, the origin does not matter)
can be moved in vacuum or in a gas because they, when moving,
produce a magnetic field, which interacts with the static
magnetic field, exactly in the same way as two magnet pieces
interact with each other (i.e. results in a force applied to the
freely moving electron).
 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.

> 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

No. It cannot. I am tired of this thread, I would have hoped all
electronics engineers would have at least some fundamental
understanding of physics. Apparently there are some who don't.
Anybody who has doubts please consider taking some basic
course of physics.

Dimiter

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

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


Article: 96417
Subject: Re: BGA central ground matrix
From: Phil Hays <Spampostmaster@comcast.net>
Date: Fri, 03 Feb 2006 06:52:27 -0800
Links: << >>  << T >>  << A >>
"dp" wrote:

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

Hall effect.

http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html


--
Phil Hays
 

Article: 96418
Subject: question for the EDK users out there...
From: me_2003@walla.co.il
Date: 3 Feb 2006 06:52:37 -0800
Links: << >>  << T >>  << A >>
Hi ,
I would realy appreciate it if someone could explain the possible usage
of a DCR bus (with PPC or MB).
Thanks in advance, Mordehay.


Article: 96419
Subject: Re: BGA central ground matrix
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 3 Feb 2006 14:55:01 -0000
Links: << >>  << T >>  << A >>
"dp" <dp@tgi-sci.com> wrote in message 
news:1138977225.228637.248310@z14g2000cwz.googlegroups.com...
> Brian Drummond 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.
>
<snip>
> No. It cannot. I am tired of this thread, I would have hoped all
> electronics engineers would have at least some fundamental
> understanding of physics. Apparently there are some who don't.
> Anybody who has doubts please consider taking some basic
> course of physics.
>
> Dimiter
>
> ------------------------------------------------------
> Dimiter Popoff               Transgalactic Instruments
>
> http://www.tgi-sci.com
> ------------------------------------------------------
>
Hi Dimiter,
Did you ever learn about the Hall Effect in your physics classes? Check 
out:-
http://en.wikipedia.org/wiki/Hall_effect
There's even a nice picture for you! ;-)
HTH, Syms. 



Article: 96420
Subject: Re: BGA central ground matrix
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 3 Feb 2006 14:56:10 -0000
Links: << >>  << T >>  << A >>
"Phil Hays" <Spampostmaster@comcast.net> wrote in message 
news:q8r6u1h32albkt9oqkq0vkatko9uudniiu@4ax.com...
>
> Hall effect.
>
>
> --
> Phil Hays
>
Phil, you beat me by 3 minutes. Dammit!
Cheers, Syms. 



Article: 96421
Subject: Re: BGA central ground matrix
From: "dp" <dp@tgi-sci.com>
Date: 3 Feb 2006 07:03:00 -0800
Links: << >>  << T >>  << A >>

Phil Hays wrote:
> "dp" wrote:
>
> > 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.
>
> Hall effect.
>
> http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html
>
>
> --
> Phil Hays

Hall effect has negligible values in conductors. On the other hand,
it may take place somewhere on the die, that might well be.
If the current does not flow out of the chip into the wires there
is no need to redistribute it.  I hope everyone is happy now.

Dimiter


Article: 96422
Subject: Re: BGA central ground matrix
From: Phil Hays <Spampostmaster@comcast.net>
Date: Fri, 03 Feb 2006 07:16:12 -0800
Links: << >>  << T >>  << A >>
"dp" wrote:

>Phil Hays wrote:
>> "dp" wrote:
>>
>> > 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.
>>
>> Hall effect.
>>
>> http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html
>>
>>
>> --
>> Phil Hays
>
>Hall effect has negligible values in conductors.

Not always.  Same as with skin effect, it isn't always negligible at
power line frequencies.  Best to do the calculations before, rather
than after.


--
Caution: Contents may contain sarcasm.
 

Article: 96423
Subject: Re: BGA central ground matrix
From: "dp" <dp@tgi-sci.com>
Date: 3 Feb 2006 07:22:34 -0800
Links: << >>  << T >>  << A >>
Phil Hays wrote:
> "dp" wrote:
>
> >Phil Hays wrote:
> >> "dp" wrote:
> >>
> >> > 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.
> >>
> >> Hall effect.
> >>
> >> http://hyperphysics.phy-astr.gsu.edu/hbase/magnetic/hall.html
> >>
> >>
> >> --
> >> Phil Hays
> >
> >Hall effect has negligible values in conductors.
>
> Not always.  Same as with skin effect, it isn't always negligible at
> power line frequencies.  Best to do the calculations before, rather
> than after.
>
>
> --
> Caution: Contents may contain sarcasm.

It has nothing to do with frequencies, and we are talking
DC. And yes, it is negligible inside the conductors
in the context ot the thread, this is why I did not
mention it at all. If you want to pursue this further,
you are welcome to do the maths and prove me wrong,
with all the sarcasm included. I shall not do it,
I have more practical things to do.

Dimiter


Article: 96424
Subject: Re: xilinx linux source?
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Fri, 03 Feb 2006 07:28:36 -0800
Links: << >>  << T >>  << A >>
Clark,

we have released the source code for the Linux port to Virtex-II Pro to 
the linuxppc open source repository at http://penguinppc.org . Click on 
the "Kernel Source" link on the left side to find out what the different 
ways are to get access to that source code. linuxppc-2.4 is the correct 
tree.

Various distributions have picked up that source code. To get started, 
though, you will need cross-compiler, kernel, and root filesystem. The 
MontaVista Preview Kit contains all these things and combined with 
XAPP765 that should get you started.

- Peter


Anonymous wrote:
> I'm confused. I thought the xilinx linux was open source? Is monte vista the
> only place to get the source?
> 
> "Peter Ryser" <peter.ryser@xilinx.com> wrote in message
> news:drteng$8a31@cliff.xsj.xilinx.com...
> 
>>Have a look at XAPP765
>>(http://www.xilinx.com/bvdocs/appnotes/xapp765.pdf). It is written for
>>an older EDK version but the principles of operation are still the same.
>>
>>- Peter
>>
>>
>>Anonymous wrote:
>>
>>>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
>>>
>>>
>>
> 
> 




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