posted by Bryon Moyer
This is something of a more off-the-beaten path story that I ran into at Semicon West. I talked with a German company called DAS that focuses on environmental remediation. In other words, cleaning up after the rest of you.
Fabs have always needed scrubbers to clean up the wide variety of rather questionable substances that really shouldn’t be out wandering the streets without supervision. Typically, that’s been done in one place: all of the various waste gasses from the different processes would be directed to the Mother of All Gas Confabs to mix and mingle and then – in the ultimate betrayal – to be scrubbed. Sort of like inviting folks with outstanding warrants to pick up their winning lottery tickets and then arresting them when they get there.
But that takes lots of piping and, not inconsequentially, creates some level of risk as the various gasses are allowed to consort with each other. The trend is away from centralized scrubbing and towards point-of-use abatement, meaning that each process or machine has its gasses neutralized at the machine rather than all in one place.
It turns out that there are very different treatments for different waste gas streams – especially when you look beyond just the semiconductor business. Techniques include “burn/wet” treatment (where water scrubs the burn products); electrostatic treatment for dust; “thermal/wet” treatments; oxidation/pyrolysis for LEDs (hydrogen and ammonia); and a new “wet” treatment for lab bench waste.
At Semicon West, they focused on two systems – an existing one and that new one. The Styrax system is a burn/wet unit used for waste gasses from etch, CVD, metal organic CVD (MOCVD), transparent conductive oxide (TCO) deposition, and epitaxy. It’s a water-intensive process (many of these seem to be), but they’ve gotten water usage down to 1 l/min through the use of lye; without it they would need more like 20 l/min.
Then they announced a new system called Salix for single-wafer clean wet bench processes. This is for water-soluble waste gasses, and it has two stages – one for acids, one for alkalis. It doesn’t handle organics (presumably not an issue for this application). It can handle up to 3 x4 inlets, so, I guess in that regard, there’s still some mixage going on… just not at the building level.
You can check out more detail in their Salix release.
posted by Bryon Moyer
In a recent piece on antenna tuning, I addressed circuit and MEMS approaches, and one of the advantages of circuits was said to be better yield. So I contacted the MEMS folks in that space for their comments on yield, and I received a carefully-worded comment from Cavendish Kinetics (and none from WiSpry).
I interpreted the Cavendish comment as basically acknowledging that yields weren’t great but were on a typical learning curve. Well, it turns out that interpreting the comments as saying yield is good or bad depends on what standard you hold for “good” yield.
I had a follow-up conversation with Cavendish Kinetics’ Larry Morrell, who had provided the yield comment. The purpose of the conversation was to address their technology more generally (which we’ll cover in the future), but the yield topic cropped up. Apparently my interpretation of Larry’s comments had caused some… heartburn.
So, while this was spurred by this particular exchange, it raises a more general question: What should “typical” expected yields be? If you’re talking about MEMS, according to Larry, you might expect in the 40-60% range. So being on a typical learning curve that tops out at such numbers would suggest yields at or below the 40% range.
But not all MEMS suppliers are in that range. For instance, InvenSense does wafer-level bonding between a MEMS wafer and an ASIC wafer. Because they don’t rely on known-good dice, their overall yield will be a product of the MEMS and ASIC yields. They’ll be throwing away any good ASICs that happen to mate up with a faulty MEMS die and vice versa. So such a strategy works only if yields are high for both the MEMS and the ASIC. And a quick conversation with an InvenSense representative at a show last year suggested their yields are in the 90%+ ranges.
Cavendish Kinetics also says their yields are in the 90% range. So why the cautious words? Because they’re not using “typical” MEMS yields as their standard; they’re using CMOS yields as their standard, and those should be well into the 90s. So having around 90% yield isn’t good enough; they’re still working up the curve. In fact, looking back at Larry’s words, he does say “…normal yield learning curve for a CMOS process.” I just interpreted that to mean the shape, not necessarily the absolute values.
Going forward, it suggests that standards could be changing. Companies scoring in the 90s will increasingly put pressure on lower-yielding companies if they meet in the market. That last qualifier is important, since there are many MEMS companies that address very specific niche markets where there is little competition and where pricing isn’t so deadly. As long as no 90%ers dive in to compete, they’re OK. But they should certainly have their radar out…
posted by Bryon Moyer
Not long ago, coincident with Sensors Expo, Freescale announced their new Intelligent Sensing Framework, or ISF. From the initial descriptions I saw, I was frankly a bit confused as to how this is different from a driver and from other sensor fusion solutions. A conversation with Freescale’s Jim McGlasson helped add some color to what’s going on.
As a starting point, we can remind ourselves that a driver is a piece of code running on a host (or AP or whatever) that lets that host access a resource. In the case of a sensor, the driver can poke and prod at the sensor to configure it or retrieve data. The API and other hooks are typically defined by the operating system; this lets the sensor behave in a way that the OS is expecting, and it abstracts the sensor details from the upper layers.
While the ISF is described as providing sensor abstraction, it does not behave like a driver. By definition, the ISF isn’t intended to run on the host: it runs on the sensor.
“How,” you ask, “can code run on a sensor??” The short answer is, “It can’t.” Unless there’s a microcontroller in there. Which there is in Freescale’s “intelligent” sensor line.
Originally, the existence of that microcontroller wasn’t made evident to users, and, even if they knew about it, it wasn’t there for them to program. Its role was to give Freescale a way to take a single sensor and configure it into different products. A classic way of managing different OPNs (ordering part numbers) that can be handled with a single chip.
But, at some point, they opened up the microcontroller, and so this is where the ISF runs. It is particularly intended for systems where there may not be a host and OS; the ISF provides an API and hooks for working with the sensors and other data inputs.
Microcontrollers are increasingly being used as sensor hubs, whether integrated with a sensor or external, both for providing a low-power way of managing sensors without involving the host and as a place to execute sensor and data fusion algorithms. And that’s the ISF’s goal: provide a platform to simplify the creation of systems involving multiple sensors that require some sort of fusion.
If the system also has a host and OS, then a driver would still be needed to access the ISF.
So, details aside, the main point is that the ISF and drivers are separate entities, and you might have one or the other or both. The ISF provides a framework for sensor fusion that’s done below the level of the host. You can find out more in Freescale’s release.