Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
you can safely use their lead-free parts in standard Sn/Pb solderUsing pure Sn lead finishes in standard Pb soldering profiles is a no-
no.
You need to run your profile at the higher, Pb-free process
temperatures. Make sure all of your materials (board, other
components, flux, paste, etc.) can handle the higher temperatures. If
you do not get up to the Pb-free process temperatures, the Sn finish
is not annealed properly, and thus stresses between plating and base
metal are not relieved properly, thus causing an increase in Sn-
whisker growth rate.
Xilinx has knowledge base articles where they specifically say that
Using pure Sn lead finishes in standard Pb soldering profiles is a no-Nico Coesel wrote:
My guess is that you'll need to look at the temperature profile of the
soldering process. I'd get some lead-free soldering experts to look at
the problem.
My feeling on this is that the whiskers have been growing over the
6 months of storage, and that whisker growth is not possible during
the reflow. I believe all the other parts on the board are ALSO lead-free,
and the whiskers are ONLY showing up on this ONE part. And, we use
other Xilinx parts where it is NOT showing up. ONLY on the 100-lead
QFP, but not on 44- or 144-lead parts.
Searching the literature, I have NOT found anyone who says temperature
profile has ANY effect on whisker growth. Alloys, stresses in the tin
plating, thickness of the tin plating, purity (or lack of) in the Tin,
storage conditions (humidity and thermal cycling) have all been implicated
in affecting the rate or prevalence of the whisker growth. But, I
have never seen a paper that mentions the reflow temp profile. If you
have a reference, I'd like to read it.
Thanks,
Jon
Ah. Do your power gaming while waiting for supper to be ready. ButQuadibloc wrote:
So, just as larger caches are the present-day form of memory on the
chip, coarse-grained configurability will be the way to increase
yields, if not the way to progress to that old idea of wafer-scale
integration. (That was, of course, back in the days of three-inch
wafers. Fitting an eight-inch wafer into a convenient consumer
package, let alone dealing with its heat dissipation, hardly bears
thinking about.)
Oh, sure it does. Just have four of them on the top
of the box, put it in the kitchen, and call it a stove.
Green Array are already selling processor arrays with the biggest beingVery few problems divide up that way. For those that do, static
reconfiguration is usually the best choice. Dynamic reconfiguration
is fun, but most often doesn't seem to work well with real problems.
ACM killed off SIGAPL about 5-6 years ago. Sorry to see it go.6. A new language with APL-like semantics would allow programmers to
state their wishes at a high enough level for compilers to determine
the low-level method of execution that best matches the particular
hardware that is available to execute it.
APL hasn't been popular over the years, and it could have done
most of this for a long time. On the other hand, you might look
at the ZPL language. Not as high-level, but maybe more practical.
No, they aren't. Sorry. They raise the level above that of theOn Sep 14, 2:06 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
6. A new language with APL-like semantics would allow programmers to
state their wishes at a high enough level for compilers to determine
the low-level method of execution that best matches the particular
hardware that is available to execute it.
APL hasn't been popular over the years, and it could have done
most of this for a long time. On the other hand, you might look
at the ZPL language. Not as high-level, but maybe more practical.
ACM killed off SIGAPL about 5-6 years ago. Sorry to see it go.
Have a look at the DARPA HPCS languages, notably, Chapel, Fortress and
X10. Not entirely sure about their respective statuses, but they were
an attempt in the HPC arena to raise the level of abstraction.
Please don't associate what I say with the auto-eroticism of those+---------------
| For example, there are people starting to think about genuinely
| unreliable computation, of the sort where you just have to live
| with ALL parths being unreliable. After all, we all use such a
| computer every day ....
+---------------
Yes, there are such people, those in the Computational Complexity
branch of Theoretical Computer Science who are working on bounded-error
probabilistic classes, both classical & in quantum computing:
The fundamental mathematical defects of that formulation are left ashttp://en.wikipedia.org/wiki/Bounded-error_probabilistic_polynomial
Bounded-error probabilistic polynomial
In computational complexity theory, bounded-error probabilistic
polynomial time (BPP) is the class of decision problems solvable
by a probabilistic Turing machine in polynomial time, with an error
probability of at most 1/3 for all instances.
And the mathematics is itself singularly unimpressive.http://en.wikipedia.org/wiki/BQP
BQP
In computational complexity theory BQP (bounded error quantum
polynomial time) is the class of decision problems solvable by
a quantum computer in polynomial time, with an error probability
of at most 1/3 for all instances. It is the quantum analogue of
the complexity class BPP.
Though the math seems to be way ahead of the hardware currently... ;-}
CSP?In article<270b4f6b-a8e8-4af0-bf4a-c36da1864692@u19g2000vbm.googlegroups.com>,
Despite a lot of effort over the years, nobody has ever thought of
a good way of abstracting parallelism in programming languages.
I have not seen anything as elegant as CSP & Dijkstra'sIn article<4E74E439.4000107@bitblocks.com>,
Bakul Shah<usenet@bitblocks.com> wrote:
Despite a lot of effort over the years, nobody has ever thought of
a good way of abstracting parallelism in programming languages.
CSP?
That is a model for describing parallelism of the message-passing
variety (including the use of Von Neumann shared data), and is in
no reasonable sense an abstraction for use in programming languages.
That is a model for describing parallelism of the message-passingDespite a lot of effort over the years, nobody has ever thought of
a good way of abstracting parallelism in programming languages.
CSP?
Well, measure theory is also extremely elegant, and has been aroundDespite a lot of effort over the years, nobody has ever thought of
a good way of abstracting parallelism in programming languages.
CSP?
That is a model for describing parallelism of the message-passing
variety (including the use of Von Neumann shared data), and is in
no reasonable sense an abstraction for use in programming languages.
I have not seen anything as elegant as CSP & Dijkstra's
Guarded commands and they have been around for 35+ years.
But perhaps we mean different things? I am talking about
naturally parallel problems. Here is an example (the first
such problem I was given in an OS class ages ago): S students,
each has to read B books in any order, the school library has
C copies of the ith book. Model this with S student
processes and a librarian process! As you can see this is
an allegory of a resource allocation problem.
IMHO this is the wrong solution. Actually it is not a solution at all.Jon Elson wrote:
Hmmm, one additional tidbit. Some boards reflowed at the
same time have been stored in a lab environment. These boards
in question were stored in my basement for six months. The lab env. boards
show no sign of the whiskers. Conditions in my basement are
not bad at all, but it is likely more humid down there than
in the lab. So, I guess this means don't store lead-free
boards in humid conditions.
That's not really all that surprising though, is it? Hardware thatDespite a lot of effort over the years, nobody has ever thought of a
good way of abstracting parallelism in programming languages.
Your original statement wasIn article<4E74F69C.5080009@bitblocks.com>,
Bakul Shah<usenet@bitblocks.com> wrote:
I have not seen anything as elegant as CSP& Dijkstra's
Guarded commands and they have been around for 35+ years.
Well, measure theory is also extremely elegant, and has been around
for longer, but is not a usable abstraction for programming.
I gave some counter examples but instead of responding to that,Despite a lot of effort over the years, nobody has ever thought of
a good way of abstracting parallelism in programming languages.
old Philips pick & place machine in my basement, and reflow the boardsIMHO this is the wrong solution. Actually it is not a solution at all.
You really should get in touch with someone who has experience in this
field in order to solve the problem at the root.
You have to understand this is a REALLY small business. I have an
Yes, but programs tend to follow the mathematics of matrix algebra.On Sat, 17 Sep 2011 09:44:35 +0100, nmm1 wrote:
Despite a lot of effort over the years, nobody has ever thought of a
good way of abstracting parallelism in programming languages.
That's not really all that surprising though, is it? Hardware that
exhibits programmable parallelism has taken many different forms over the
years, especially with many different scales of granularity of the
parallelisable sequential operations and inter-processor communications,
Well, part of it is that we aren't so good at thinking of problemsThe entire issue of parallelism is essentially orthogonal to the
sequential Turing/von-Neuman model of computation that is at the heart of
most programming languages. It's not obvious (to me) that a single
language could reasonably describe a problem and have it map efficiently
across "classical" cross-bar shared memory systems (including barrel
processors), NuMA shared memory, distributed shared memory, clusters, and
clouds (the latter just an example of the dynamic resource count vs known-
at-compile-time axis) all of which incorporate both sequential and vector
(and GPU-style) resources.
In nuclear physics there is a constant describing the number of yearsWhich is not to say that such a thing can't exist. My expectation is
that it will wind up being something very functional in shape that
relaxes as many restrictions on order-of-execution as possible (including
order of argument evaluation), sitting on top of a dynamic execution
environment that can compile and re-compile code and shift it around in
the system to match the data that is observed at run-time.
That is: the language can't assume a Turing model, but rather a more
mathematical or declarative one. The compiler has to choose where
sequential execution can be applied, and where that isn't appropriate.
Needless to say, we're not there yet, but I expect to see it in the next
dozen or so years.
Spoken like someone who would know the difference between covariant andIn comp.arch.fpga Andrew Reilly<areilly---@bigpond.net.au> wrote:
On Sat, 17 Sep 2011 09:44:35 +0100, nmm1 wrote:
Despite a lot of effort over the years, nobody has ever thought of a
good way of abstracting parallelism in programming languages.
That's not really all that surprising though, is it? Hardware that
exhibits programmable parallelism has taken many different forms over the
years, especially with many different scales of granularity of the
parallelisable sequential operations and inter-processor communications,
Yes, but programs tend to follow the mathematics of matrix algebra.
I wonder if this dozen years is also a constant. People have been
working on parallel programming for years, yet usable programming
languages are always in the future.
I've read the language descriptions of Erlang and Go and think that bothOn 9/18/11 12:38 AM, nmm1@cam.ac.uk wrote:
In article<4E74F69C.5080009@bitblocks.com>,
Bakul Shah<usenet@bitblocks.com> wrote:
I have not seen anything as elegant as CSP& Dijkstra's Guarded
commands and they have been around for 35+ years.
Well, measure theory is also extremely elegant, and has been around for
longer, but is not a usable abstraction for programming.
Your original statement was
Despite a lot of effort over the years, nobody has ever thought of a
good way of abstracting parallelism in programming languages.
I gave some counter examples but instead of responding to that, your
bring in some random assertion. If you'd used Erlang or Go and had
actual criticisms that would at least make this discussion interesting.
Ah well.