I have always loved a mallard’s iridescent green.

As pin counts of integrated circuits have continued to rise, the difficulties in arranging wire bonds — which connect the “pads” on the chip (die) to the landing zones on the “pins” that connect through the “device” (plastic or ceramic) to the outside world — have likewise continued to rise.  As the connections get closer, simply putting pads around the edge of the die makes them too close, and too small, to accurately bond with a flying piece of semi-molten gold wire.

The article shows micrographs of HP’s technique for radially staggered bonding. This does increase the available size and separation of the pads but it really only defers the problem.  Another problem with device yield is that the “street” which is traditionally cut by a saw requires a significant amount of area.

For a better overall solution, consider the bee’s honeycomb.

A honeycomb is a matrix of hexagons.  Not only is every cell nearly the same, but the amount of material used to construct the honeycomb is minimized.

If a silicon wafer were cut into hexagons, perhaps by a laser, that would reduce the amount of area lost. Further, because a hexagon more closely approximates a circle — which is the end convergence of the radially staggered bonding process.  (The clue is, “radial” — think … circle!)

This whole process could significantly increase both yield and pin count.

Usually blogs attempt to develop a community of readers, all of whom get to discuss each post on the blog site.

Blogs are mostly used to discuss political and social issues. The comments are wide-ranging and often become shouting matches.

If you want to push an issue, to get people excited about something, a blog is great.

If you’re trying to sell something, you’ll either wind up with silence (which is bad) or people shouting and complaining (worse).

A full day of presentations and participation on free software.

More info: http://www.ableconf.com/

Update: A good time and a good place to meet like-minded folks and get up to speed on new technology, and even a few “Aha!” moments on how to do things better. See you next year!

After years of frustration waiting for the Mozilla Thunderbird folks to add the ability to edit LDAP address-books, and years of frustration with the pigheadedness and brain-damagedness of LDAP server software, I decided to write my own little pseudo-LDAP server.

This is a proof of concept only and not meant for production use yet.

Here it is, in Perl: generic-ldap-0.1 It merely reads in

• a Thunderbird address book using a module from CPAN
• or an LDIF file, using another module from CPAN
• or anything else you care to write a plugin for (put it in the Plugins/ subdirectory)… there’s a start on a WordPress module, or you could write one for OSCommerce, or… the sky’s the limit

and shares that out via the LDAP protocol, using the Net::LDAP::Server module. Writing this meant seeing what the various email clients (Thunderbird, Evolution, KMail) actually wanted to see.

The nastiest, most brain-damaged part of LDAP is the non-standard field (attribute) names. None of these programs agree on what to call “home street address” versus “work street address,” for example.  What a nightmare.  My little server tries to remedy this by copying what it can suss out, into every possible field that your email client might be looking for.

What needs to be done yet?

• Better (or any) support for Outlook and Outlook Express, both reading their address-books and talking what they want to hear in terms of LDAP
• Security. Right now there isn’t much, beyond plaintext password authentication for each resource. You probably want to run this behind a firewall until there is support for TLS or SSL or something else. Perhaps another set of Plugins.
• Support for reading IMAP address books, vCards, etc.
• Support for more complex queries. Right now it only understands “OR” queries. Again, possibly as another set of Plugins.

This is written as an extensible system with Plugins. At the moment it fills my internal needs — specifically, sharing a single Thunderbird address-book inside an office.

Please contact me if you would like help adding features or additional development.

William Lindley, wlindley.com, 480.947.6100