EDK : FSL macros defined by Xilinx are wrong

[wzab]

I usually use the drawtiming available at http://drawtiming.sourceforge.net
However, when I write documentation or article in LaTeX, I often use
simply
the tikz-timing package.
--
HTH & Regards,
Wojtek

 

[Ed McGettigan]

On Aug 30, 5:38 am, Pratap <pratap.i...@gmail.com> wrote:

Hi,
I am using Virtex II Pro (XC2VP30, package ff896) board to read 8 bit
parallel data from FPGA. The output from the chip is of level 1.2V and
hence I am using SSTL2_II IO standard for the inputs from the chip to
the FPGA. I had designed my board to use the Pins A20 to A27 of the
High speed IO bank J37 for reading the inputs from the chip.
I have shared the ucf files for the not working and working case in
the links below.

not working ucf:https://docs.google.com/leaf?id=0B68lizyh4WNKMGFiYmI4OWQtNTQ3Ny00YzUw...

working ucf:https://docs.google.com/leaf?id=0B68lizyh4WNKYTA0YzFkYzctNGY3Yi00MDFj...

In the working ucf file, the only change I have done is, I have not
used A23 and instead A31 pin of J37(L8 pin of FPGA). I checked with
the Virtex II Pro data sheet and don't see any problem using A23 pin
of J37. In fact, even if I remove all other constraints and just use
the A23 pin also, I get the same error: Below is the link to the .par
file for this failed trial.

https://docs.google.com/leaf?id=0B68lizyh4WNKMzViNDhkOWQtYTE5OS00NGQ2....

ERRORlace:897 - The following IOBs have been locked (LOC constraint)
to the I/O bank 3.
   They require a voltage reference supply from the VREF pin(s) within
the same I/O bank to be available.
   The following VREF pins are currently locked and can't be used to
supply the necessary reference
   IO Standard: Name = SSTL2_II, VREF = 1.25, VCCO = NR, TERM = NONE
   List of locked IOB's:
        DATA_OUT<3
   List of occupied VREF Sites:
   VREF site PAD289 is occupied by comp DATA_OUT<3

Is there something fishy about this A23 pin of J37 bank of the board?
If I use LVTTL IO standard, it works fine, but I can't read 1.2 volts
in that standard. Why is the behavior of this particular pin
dirrefent from all it's adjacent pins? Is there any other IO standard
which can help reading 1.2 Volt as logic high? I have confirmed that
it doesn't work for IO standard= SSTL2_I too.
If there is any document to explain this strange behavior, please
point me to that.

Waiting for some helpful answers.
Thanks and regards,
Pratap

I am using Virtex II Pro (XC2VP30, package ff896) board

You need to explicitly state which board that you are using as there
are many boards, from many vendors. When you reference pins of a
connector (A20 to A27 of J37) there is no context to allow the reader
to understand how this relates to the device.

used A23 and instead A31 pin of J37(L8 pin of FPGA).

If only you had said what J37.A23 was connected to on the FPGA as well
as the working J37.A31 pin...
The L8 pin is in PAD183 (IO_L41N_2) in Bank 2.

List of occupied VREF Sites:
VREF site PAD289 is occupied by comp DATA_OUT<3

PAD289 in a XC2VP30-FF896 is pin AE1 (IO_L39N_3/VREF_3) in Bank 3.
The pin that you have assigned that connected J37.A23 to the FPGA must
be in Bank 3 and this is in conflict with the IOSTANDARD banking
rules.

SSTL (all flavors) is a single-ended referenced IO standard and it
requires an external reference voltage of 1.25V to work. In the
XC2VP30-FF896 Bank 3 these pins are U2, W1, AA1, AB2, AE1, AE3 and AH1
and the 1.25V reference voltage must be applied to all of these pins
and they cannot be used for any other purpose. Your design is
attempting to use one of these pins as an I/O and this is not allowed.

You cannot fix this problem by reassigning the DATA_OUT<3> to another
location without also modifying your board to provide the required
1.25V to the 7 VREF pins in Bank 3.

Ed McGettigan
--
Xilinx Inc.

 

[Pratap]

On Aug 30, 8:34 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:

On Aug 30, 5:38 am, Pratap <pratap.i...@gmail.com> wrote:









Hi,
I am using Virtex II Pro (XC2VP30, package ff896) board to read 8 bit
parallel data from FPGA. The output from the chip is of level 1.2V and
hence I am using SSTL2_II IO standard for the inputs from the chip to
the FPGA. I had designed my board to use the Pins A20 to A27 of the
High speed IO bank J37 for reading the inputs from the chip.
I have shared the ucf files for the not working and working case in
the links below.

not working ucf:https://docs.google.com/leaf?id=0B68lizyh4WNKMGFiYmI4OWQtNTQ3Ny00YzUw...

working ucf:https://docs.google.com/leaf?id=0B68lizyh4WNKYTA0YzFkYzctNGY3Yi00MDFj...

In the working ucf file, the only change I have done is, I have not
used A23 and instead A31 pin of J37(L8 pin of FPGA). I checked with
the Virtex II Pro data sheet and don't see any problem using A23 pin
of J37. In fact, even if I remove all other constraints and just use
the A23 pin also, I get the same error: Below is the link to the .par
file for this failed trial.

https://docs.google.com/leaf?id=0B68lizyh4WNKMzViNDhkOWQtYTE5OS00NGQ2....

ERRORlace:897 - The following IOBs have been locked (LOC constraint)
to the I/O bank 3.
   They require a voltage reference supply from the VREF pin(s) within
the same I/O bank to be available.
   The following VREF pins are currently locked and can't be used to
supply the necessary reference
   IO Standard: Name = SSTL2_II, VREF = 1.25, VCCO = NR, TERM = NONE
   List of locked IOB's:
        DATA_OUT<3
   List of occupied VREF Sites:
   VREF site PAD289 is occupied by comp DATA_OUT<3

Is there something fishy about this A23 pin of J37 bank of the board?
If I use LVTTL IO standard, it works fine, but I can't read 1.2 volts
in that standard. Why is the behavior of this particular pin
dirrefent from all it's adjacent pins? Is there any other IO standard
which can help reading 1.2 Volt as logic high? I have confirmed that
it doesn't work for IO standard= SSTL2_I too.
If there is any document to explain this strange behavior, please
point me to that.

Waiting for some helpful answers.
Thanks and regards,
Pratap
 I am using Virtex II Pro (XC2VP30, package ff896) board

You need to explicitly state which board that you are using as there
are many boards, from many vendors.  When you reference pins of a
connector (A20 to A27 of J37) there is no context to allow the reader
to understand how this relates to the device.

used A23 and instead A31 pin of J37(L8 pin of FPGA).

If only you had said what J37.A23 was connected to on the FPGA as well
as the working J37.A31 pin...
The L8 pin is in PAD183 (IO_L41N_2) in Bank 2.

   List of occupied VREF Sites:
   VREF site PAD289 is occupied by comp DATA_OUT<3

PAD289 in a XC2VP30-FF896 is pin AE1 (IO_L39N_3/VREF_3)  in Bank 3.
The pin that you have assigned that connected J37.A23 to the FPGA must
be in Bank 3 and this is in conflict with the IOSTANDARD banking
rules.

SSTL (all flavors) is a single-ended referenced IO standard and it
requires an external reference voltage of 1.25V to work.  In the
XC2VP30-FF896 Bank 3 these pins are U2, W1, AA1, AB2, AE1, AE3 and AH1
and the 1.25V reference voltage must be applied to all of these pins
and they cannot be used for any other purpose.  Your design is
attempting to use one of these pins as an I/O and this is not allowed.

You cannot fix this problem by reassigning the DATA_OUT<3> to another
location without also modifying your board to provide the required
1.25V to the 7 VREF pins in Bank 3.

Ed McGettigan
--
Xilinx Inc.

Hello McGettigan.
Thanks for the response.
To be specific, I am using the Xirtex II Pro board available from
Digikey.
Here is the snapshot.

http://www.digilentinc.com/Data/Products/XUPV2P/XUPV2P-top.jpg

I now understand the reason why assigning SSTL to J37.A23( AE1) flags
error. But my doubt is, why if I use LVTTL for pin AE1 how does it
work then? I would request for another clarification. If I properly
understand the fix suggested, I need now to connect the pins below to
an external 1.25V. But how to do this. Should this be done in UCF file
or through a physical wire connected to the 1.25V supply on the FPGA
board or an external DC supply? If it has to be done through an
external wire, how can I connect a physical wire to the push button
switch at AH1?
Here is the mapping I found for the pin names corresponding to my
board.
U2: J5-38,
W1: J6-12,
AA1: J6-24,
AB2: J4-47,
AE1: J37-A23,
AE3 : J37-A11,
AH1: PB_LEFT

The question may seem to be novice. But I seriously am not able to get
the clue about these. Can you please suggest any document which I can
follow for getting a real understanding about the IO standard and the
Pin constraints?

Waiting for some more valuable information as always,
Thanks,
Pratap

 

[Ed McGettigan]

On Aug 30, 1:00 pm, Pratap <pratap.i...@gmail.com> wrote:

On Aug 30, 8:34 pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:





On Aug 30, 5:38 am, Pratap <pratap.i...@gmail.com> wrote:

Hi,
I am using Virtex II Pro (XC2VP30, package ff896) board to read 8 bit
parallel data from FPGA. The output from the chip is of level 1.2V and
hence I am using SSTL2_II IO standard for the inputs from the chip to
the FPGA. I had designed my board to use the Pins A20 to A27 of the
High speed IO bank J37 for reading the inputs from the chip.
I have shared the ucf files for the not working and working case in
the links below.

not working ucf:https://docs.google.com/leaf?id=0B68lizyh4WNKMGFiYmI4OWQtNTQ3Ny00YzUw...

working ucf:https://docs.google.com/leaf?id=0B68lizyh4WNKYTA0YzFkYzctNGY3Yi00MDFj...

In the working ucf file, the only change I have done is, I have not
used A23 and instead A31 pin of J37(L8 pin of FPGA). I checked with
the Virtex II Pro data sheet and don't see any problem using A23 pin
of J37. In fact, even if I remove all other constraints and just use
the A23 pin also, I get the same error: Below is the link to the .par
file for this failed trial.

https://docs.google.com/leaf?id=0B68lizyh4WNKMzViNDhkOWQtYTE5OS00NGQ2...

ERRORlace:897 - The following IOBs have been locked (LOC constraint)
to the I/O bank 3.
   They require a voltage reference supply from the VREF pin(s) within
the same I/O bank to be available.
   The following VREF pins are currently locked and can't be used to
supply the necessary reference
   IO Standard: Name = SSTL2_II, VREF = 1.25, VCCO = NR, TERM = NONE
   List of locked IOB's:
        DATA_OUT<3
   List of occupied VREF Sites:
   VREF site PAD289 is occupied by comp DATA_OUT<3

Is there something fishy about this A23 pin of J37 bank of the board?
If I use LVTTL IO standard, it works fine, but I can't read 1.2 volts
in that standard. Why is the behavior of this particular pin
dirrefent from all it's adjacent pins? Is there any other IO standard
which can help reading 1.2 Volt as logic high? I have confirmed that
it doesn't work for IO standard= SSTL2_I too.
If there is any document to explain this strange behavior, please
point me to that.

Waiting for some helpful answers.
Thanks and regards,
Pratap
 I am using Virtex II Pro (XC2VP30, package ff896) board

You need to explicitly state which board that you are using as there
are many boards, from many vendors.  When you reference pins of a
connector (A20 to A27 of J37) there is no context to allow the reader
to understand how this relates to the device.

used A23 and instead A31 pin of J37(L8 pin of FPGA).

If only you had said what J37.A23 was connected to on the FPGA as well
as the working J37.A31 pin...
The L8 pin is in PAD183 (IO_L41N_2) in Bank 2.

   List of occupied VREF Sites:
   VREF site PAD289 is occupied by comp DATA_OUT<3

PAD289 in a XC2VP30-FF896 is pin AE1 (IO_L39N_3/VREF_3)  in Bank 3.
The pin that you have assigned that connected J37.A23 to the FPGA must
be in Bank 3 and this is in conflict with the IOSTANDARD banking
rules.

SSTL (all flavors) is a single-ended referenced IO standard and it
requires an external reference voltage of 1.25V to work.  In the
XC2VP30-FF896 Bank 3 these pins are U2, W1, AA1, AB2, AE1, AE3 and AH1
and the 1.25V reference voltage must be applied to all of these pins
and they cannot be used for any other purpose.  Your design is
attempting to use one of these pins as an I/O and this is not allowed.

You cannot fix this problem by reassigning the DATA_OUT<3> to another
location without also modifying your board to provide the required
1.25V to the 7 VREF pins in Bank 3.

Ed McGettigan
--
Xilinx Inc.

Hello McGettigan.
Thanks for the response.
To be specific, I am using the Xirtex II Pro board available from
Digikey.
Here is the snapshot.

http://www.digilentinc.com/Data/Products/XUPV2P/XUPV2P-top.jpg

I now understand the reason why assigning SSTL to J37.A23( AE1) flags
error. But my doubt is, why if I use LVTTL for pin AE1 how does it
work then? I would request for another clarification. If I properly
understand the fix suggested, I need now to connect the pins below to
an external 1.25V. But how to do this. Should this be done in UCF file
or through a physical wire connected to the 1.25V supply on the FPGA
board or an external DC supply? If it has to be done through an
external wire, how can I connect a physical wire to the push button
switch at AH1?
Here is the mapping I found for the pin names corresponding to my
board.
U2: J5-38,
W1: J6-12,
AA1: J6-24,
AB2: J4-47,
AE1: J37-A23,
AE3 : J37-A11,
AH1: PB_LEFT

The question may seem to be novice. But I seriously am not able to get
the clue about these. Can you please suggest any document which I can
follow for getting a real understanding about the IO standard and the
Pin constraints?

Waiting for some more valuable information as always,
Thanks,
Pratap- Hide quoted text -

- Show quoted text -

But my doubt is

This is off topic, but I've never understood why so many non-native
english writers use the word "doubt" when the correct word is
"question". Did this originate from a single original [language]-to-
English translation dictionary and then was propogate to every other
[language]-to-English translation dictionary?

why if I use LVTTL for pin AE1 how does it work then?

LVTTL is not a single-ended voltage reference IO standard and does not
require an external VREF.

The LVTTL standard relies on the switching levels of the transistors
that make up the input buffer. This circuit has a much wider range
for detecting a valid logic low (0.8V) or valid logic high (2.0V) and
thus does not offer the same level of precision and speed that is
possible with the other type (VREF +/- 0.15V).

I need now to connect the pins below to an external
1.25V. But how to do this?

This must be done physically on the board with a soldering iron,
wires, voltage source, and capacitors for noise decoupling.

If this board was intended to support these types of IO standards then
it would have been designed this way. Since the board was not
designed this way any use of this IO standard will not be very
reliable even with the rework to the board. The IO standard will
likely required external termination resistors to a VTT supply that
will also need to be added further complicating the rework needed
(this may have been added to the module that was designed).

Can you please suggest any document which I can
follow for getting a real understanding about the IO
standard and the Pin constraints?

Every FPGA family includes documentation on the supported IO standards
for that family. For the Virtex-II Pro device that you are using this
information is included in the Virtex-II Pro data sheet DS083 in the
Input/Output Block section. The current generation of FPGA families
has this information in a separate user guide, for instance Virtex-6
SelectIO User Guide, UG361.

Ed McGettigan
--
Xilinx Inc.

 

[Jon Elson]

I think I mentioned this problem a year or so ago, but have new data.
We previously had problems with whiskers shorting adjacent pins on some
boards that
have a Xilinx XC9572-15TQG100C part. These whiskers were laying flat on
the board, so their origin was not completely clear.

Now, I have some boards that were reflow soldered some months ago, and
were only finished now. On inspection of the CPLD, clear evidence of
Tin whisker growth is obvious. I think EVERY chip has whisker growth
on at least one pin! This is quite a concern, as this equipment may
have a 20 year operating life.

There are 12 other fine-pitch parts on this board, and none of those
show signs of the whiskers.

I reported the first occurrence to Xilinx at the time, including
microphotographs,
and they basically blew me off, saying it was obviously my process.
We are using tin-lead solder paste on tin-lead plated boards.

Does anyone have any idea why we are experiencing this, or what can be
done to prevent these chips from developing shorts over time?

Thanks,

Jon

 

[Stefan Monnier]

If you follow such conferences, you necessarily get far-out ideas.
But if you look at the actual processors in use today, they
are not so different from 40 years ago. Bigger and faster, yes,
but otherwise not that different.

Actually, if you look back at "far out research" from years ago, I think
that even though the machines we use are "like the ones from back then"
from a programming point of view, they are also in some ways "like the
far-out ideas from back then".

E.g. the "Processor In Memory" still hasn't happened, but current CPUs
have a boat load of on-chip memory. So I think the way to predict the
future is to take those far-out ideas and try to see "how will future
engineers manage to use such techniques while still running x86/ARM
code". After all, experience shows that the part that's harder to
change is the software, despite its name.


Stefan

 

[Jon Elson]

On 09/14/2011 04:54 PM, Uwe Bonnes wrote:

Jon Elson<jmelson@wustl.edu> wrote:
...
I reported the first occurrence to Xilinx at the time, including
microphotographs,

Please put the pictures on the web
...
They are really crummy, and show the "old" problem, some whisker-like

strands thay lay across the board. This new condition is different, and
shows REALLY typical-looking tin whiskers that are growing out of the
bends of the gull-wing leads on these Xilinx QFP parts. The last time
I tried photographing this, I got very mediocre results, the stereo
zoom microscope setup we have is optimized for hand rework of parts,
and the light level decreases as you increase magnification. So,
although I can see what is going on quite clearly, I doubt the pictures
would be very definitive. But, I have NO doubt, whatsoever, that what I
am seeing NOW matches the published tin whisker photos that are
ubiquitous on the web.

What has me worried is these are essentially new boards, just going
through testing before sending out to researchers who will be using them
for a number of years. If I saw this amount of whisker growth in the
six months these boards have been in storage after reflow, it may
indicate a LOT of problems in the future. It has definitely gotten me
worried!

(As for posting this as a reply to another thread, my first post as a new
thread was rejected by some news server, but I could not discern the
reason for the rejection.)

Jon

 

[glen herrmannsfeldt]

In comp.arch.fpga Steve Richfield <steve.richfield.spam@gmail.com> wrote:

At every computer conference I attend, I see numerous papers that show
how to incrementally increase the capabilities of present products,
plus a paper or two about some aspect of distant future processors.
There is a sort of consistency among these papers that, taken
together, creates an image of the manifest destiny of processors that
are VERY different from present-day processors and networks. I am
interested in that image, and I suspect that others here may also be
interested.

I am reading in comp.arch.fgpa, but comp.arch readers may have
different ideas.

Here is the sort of image that I see emerging. Perhaps you have your
own very different vision?

1. Processors would be able to automatically reconfigure around their
defects with such great facility that reject components will be nearly
eliminated. This would make it possible to build processors without
any practical limits to complexity. Several papers have been presented
explaining how this could be done with Genetic Algorithm (GA)
approaches. Initial reconfiguring would be done at manufacture, but
power-on reconfiguring would adapt to on-shelf and in-service
failures. Processors with large numbers of defects would be sold as
lesser performing processors.

Reminds me of stories about Russian processors that came with
a 'bad instruction' list the way disk drives (used to) come with
a bad blocks list.

If you follow such conferences, you necessarily get far-out ideas.
But if you look at the actual processors in use today, they
are not so different from 40 years ago. Bigger and faster, yes,
but otherwise not that different.

2. An operating system would distribute the work as tasks, with each
task having input and output vectors. Any task that fails to
successfully complete would be re-executed on other sections of the
processor while diagnostics identify the problem in the failed
section, which would then be reconfigured around the new defect. This
would allow systems to keep running and continue producing correct
results, despite run-time failures.

I suppose there are some problems that could work that way.
A web browser updating multiple windows on a page could farm out
each to a different task. But many computational problems don't
divide up that way.

3. Memory would be integral to the CPU, and would be in the form of
thousands (or millions) of small memory banks that would eliminate the
memory bus bottleneck. Switched memory buses could quickly move blocks
of data around.

4. The processor would be organized as a small (2-4) number of CPUs,
each having a large number of sub-processors capable of dynamic
reconfiguration to specialize in the computation at hand. That
reconfiguration would be capable of the extensive data-chaining needed
to execute complex loops as single instructions, and do so in just a
few machine cycles, after suitable setup. Sub-processors would
probably be reconfigurable for either SIMD or MIMD operation.

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

5. The system would probably use asynchronous logic extensively, not
only for its asynchronous capabilities, but also for its inherent
ability to automatically recognize its own malfunctions and trigger
reconfiguration.

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.

7. There are other items on this list, but they aren???t as easy to
explain, and they may not be essential to achieve the manifest destiny
of processors.

Note that the Billions of dollars now spent on developing GPU-based
and large network-based processors, along with the software to run on
them will have been WASTED as soon as Manifest Destiny processors
become available. Further, the personnel who fail to quickly make the
transition to Manifest Destiny processors will probably become
permanently unemployed, as has happened at various past points of
major architectural inflection.

Consider that direct decendant of the 35 year old Z80 are still
very popular, among others in many calculators and controllers.
New developments might be used for certain problems, but the old
problems can be handled just fine with older processors.

For many years now, the economy of scale of people buying
faster processors to browse the web or run spreadsheets has
supplied computational sciences (computational physics, computational
chemistry, and computational biology) with cheap, fast machines.
Machines that wouldn't have had sufficient economy of scale
without those other uses. The whole idea behind GPU processors
is that the economy of scale of building graphics engines for
gamers can also be used for computational science.

Apparently the only conference around with a sufficiently broad
interest and attendance to host discussions at this level is
WORLDCOMP. This would provide a peer reviewed avenue of legitimation
for Manifest Destiny research. I have talked with Hamid, the General
Chairman, about hosting these discussions, and he is OK with it,
providing that I can drum up enough interest. So, I need to determine
the level of interest out there in a more distant future of computing
that lies beyond just the next product.

Consider the latest deviation from traditional processor design,
the VLIW Itanium. VLIW has been around for years, and never did
very well. Some thought its time had come, but it is sinking just
like the similarly named boat.

Conferences aside, please email me or post your level of interest, and
please pass this on to any others you know who might be interested.

-- glen

 

[Uwe Bonnes]

Jon Elson <jmelson@wustl.edu> wrote:
....

I reported the first occurrence to Xilinx at the time, including
microphotographs,

Please put the pictures on the web
....
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

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

 

[Quadibloc]

On Sep 14, 4:08 pm, Stefan Monnier <monn...@iro.umontreal.ca> wrote:

E.g. the "Processor In Memory" still hasn't happened, but current CPUs
have a boat load of on-chip memory.  So I think the way to predict the
future is to take those far-out ideas and try to see "how will future
engineers manage to use such techniques while still running x86/ARM
code".  After all, experience shows that the part that's harder to
change is the software, despite its name.

My main question concerning the original poster's projection of the
logical future for processors is that reconfigurability comes with a
large amount of overhead. So if leaving reconfigurability out improves
speed by a factor of 3, say, it won't be popular.

However, that's only true if the reconfigurability is fine-grained, as
on an FPGA. On something like IBM's recent PowerPC chip with 18 CPUs,
where one of them can be marked as bad, so that it uses one for
supervision and 16 for work, there is almost no overhead.

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

John Savard

 

[Jim Granville]

On Sep 15, 10:11 am, Jon Elson <jmel...@wustl.edu> wrote:

 This new condition is different, and
shows REALLY typical-looking tin whiskers that are growing out of the
bends of the gull-wing leads on these Xilinx QFP parts.  

Interesting location, suggests stress helps ?

Are these on both bends, & on the compression, or tension part of
each ?

Were these manually or reflow soldered ?
At Lead-based, or Lead-free temperatures ? Post cleaned or not ?

-jg

 

[Mark Thorson]

Steve Richfield wrote:

1. Processors would be able to automatically reconfigure around their
defects with such great facility that reject components will be nearly
eliminated. This would make it possible to build processors without
any practical limits to complexity. Several papers have been presented
explaining how this could be done with Genetic Algorithm (GA)
approaches. Initial reconfiguring would be done at manufacture, but
power-on reconfiguring would adapt to on-shelf and in-service
failures. Processors with large numbers of defects would be sold as
lesser performing processors.

Defect density is hardly a limiting factor. Thermal
and I/O are, both also being packaging and substrate
issues. Also, it would introduce pain if different
chips with the same part number, revision level, and
date code had different performance. Probably no fun
for the guys in the testing department, either.

I'm reminded of a friend of mine that worked on
binary code rehosting tools for Clipper. He'd rant
and rave about all the hardware bugs being hidden
by the assembler. When I told him that I learned
from this newsgroup that yield was being enhanced
by zapping individual bad cache lines to make them
permanently invalid, he just laughed.

 

[Mark Thorson]

glen herrmannsfeldt wrote:

In comp.arch.fpga Steve Richfield <steve.richfield.spam@gmail.com> wrote:

Note that the Billions of dollars now spent on developing GPU-based
and large network-based processors, along with the software to run on
them will have been WASTED as soon as Manifest Destiny processors
become available. Further, the personnel who fail to quickly make the
transition to Manifest Destiny processors will probably become
permanently unemployed, as has happened at various past points of
major architectural inflection.

Consider that direct decendant of the 35 year old Z80 are still
very popular, among others in many calculators and controllers.
New developments might be used for certain problems, but the old
problems can be handled just fine with older processors.

8051 and PIC architecture hardware and software engineers
are still gainfully employed, perhaps more now than ever
before. Maybe he was referring to the 6502?

 

[Mark Thorson]

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

 

[Nico Coesel]

Jon Elson <jmelson@wustl.edu> wrote:

I think I mentioned this problem a year or so ago, but have new data.
We previously had problems with whiskers shorting adjacent pins on some
boards that
have a Xilinx XC9572-15TQG100C part. These whiskers were laying flat on
the board, so their origin was not completely clear.

Now, I have some boards that were reflow soldered some months ago, and
were only finished now. On inspection of the CPLD, clear evidence of
Tin whisker growth is obvious. I think EVERY chip has whisker growth
on at least one pin! This is quite a concern, as this equipment may
have a 20 year operating life.

There are 12 other fine-pitch parts on this board, and none of those
show signs of the whiskers.

I reported the first occurrence to Xilinx at the time, including
microphotographs,
and they basically blew me off, saying it was obviously my process.
We are using tin-lead solder paste on tin-lead plated boards.

Does anyone have any idea why we are experiencing this, or what can be
done to prevent these chips from developing shorts over time?

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.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

In article <j4r508$rgl$1@speranza.aioe.org>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

In comp.arch.fpga Steve Richfield <steve.richfield.spam@gmail.com> wrote:

5. The system would probably use asynchronous logic extensively, not
only for its asynchronous capabilities, but also for its inherent
ability to automatically recognize its own malfunctions and trigger
reconfiguration.

This is a meaning of the term "asynchronous" with which I was
previously unfamiliar.

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.

Its status as the leading write-only language has been taken
over by Perl; despite the claims of its proponents, it never was
exceptionally useful for scientific calculations or anything else.
Also, its model is a fair match to the computers that were being
fantastised about in the 1980s, rather than the 2000s.


I am very much in favour of people doing serious future thinking,
but it would have to be a lot better-informed and hard-headed,
and preferably more radical, than this.

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


Regards,
Nick Maclaren.

 

[glen herrmannsfeldt]

In comp.arch.fpga nmm1@cam.ac.uk wrote:

(snip)

In comp.arch.fpga Steve Richfield <steve.richfield.spam@gmail.com> wrote:

5. The system would probably use asynchronous logic extensively, not
only for its asynchronous capabilities, but also for its inherent
ability to automatically recognize its own malfunctions and trigger
reconfiguration.

This is a meaning of the term "asynchronous" with which I was
previously unfamiliar.

It does seem a little unusual. Asynchronous logic, sometimes also
known as self-timed logic, has been around for years. Some is
described in: http://en.wikipedia.org/wiki/Asynchronous_logic

I suppose I believe that some failure modes could be detected
and a corrective action initiated.

-- glen

 

[Jon Elson]

Jim Granville wrote:

On Sep 15, 10:11 am, Jon Elson <jmel...@wustl.edu> wrote:
This new condition is different, and
shows REALLY typical-looking tin whiskers that are growing out of the
bends of the gull-wing leads on these Xilinx QFP parts.

Interesting location, suggests stress helps ?

This is a known part of the whisker problem, if you read the literature.

Compressive stress will produce the whiskers, tensile stress suppresses
the whisker growth. Funny, these sort of look like they are coming from
the outer side of the bend, but there may be initial tensile stress
there that then becomes compressive when the reflow relaxes strains
in the lead.

Are these on both bends, & on the compression, or tension part of
each ?
It SEEMS that these are mostly showing up on the back of the

first bend up from the PC board, that would be the second bend
out from the package body, and facing toward the package.

Were these manually or reflow soldered ?
At Lead-based, or Lead-free temperatures ? Post cleaned or not ?
These are lead-free parts, soldered with 63/37 Tin/Lead solder

paste (Shenmao solder paste distributed by Manncorp), and reflowed
onto Tin/Lead plated 6-layer PC boards with a peak reflow temp
actually measured on the board of about 235 C. (My batch reflow oven
has a thermocouple that I poke into a through-hole on one of the boards
near the center to monitor actual substrate temperature.)
But, then as I am still getting my solder stencil technology
figured out, I had to do a bunch of rework to remove solder
shorts.)

THEN, the boards were stored for about 6 months, and now when I inspected
them, I see the whisker growth. The boards were not cleaned after reflow,
but were cleaned just before this inspection.

Thanks for the comments and questions!

Jon

 

[Jon Elson]

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

 

[Nico Coesel]

Jon Elson <elson@pico-systems.com> wrote:

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.

Simply use common sense and knowledge: the whiskers grow because of
stresses in the crystal structure of tin. If you (nearly) melt a metal
you'll alter the crystal structure*. Humidity and temperature may
accellerate growth of whiskers, but only if the initial stress is in
the crystal structure. Thats why I'm pointing to the temperature
profile of the soldering process as the source of the problem.

You should check whether the whiskers also grow on parts which have
not been soldered yet. I bet they don't otherwise Xilinx would have a
really big problem on their hands.

* think about hardening steel by cooling it very fast after it has
been heated close to the melting point.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------