Apr 10, 2014

On the Scene: EELive 2014 Wrap Up

posted by Amelia Dalton

We stormed the gates. We took no prisoners. But, we did take home a lot of pens. Most importantly, we learned some stuff. Welcome to my new video blog called “On the Scene.” You can expect some jokes. You can expect some insight about this year’s Embedded Systems Conference (or whatever they’re calling it this week). And you can expect to see my smiling face. Think of it like a funny tech snack - if you will.

Tags :    0 comments  
Apr 09, 2014

Moving Back to Software

posted by Bryon Moyer

We’ve seen it before: the debate between hardware and software for implementing electronic functions. An oft-cited approach is to keep as much as possible in software for flexibility. But things tend to go hardware under two circumstances: when raw speed is needed and when a function becomes so common and stable that no changes are expected.

Especially in that latter case, the normal trajectory is that you have a software solution for a long time and, as things mature, at some point you can reduce it to hardware. It may go to FPGA if speed is a concern even before maturing in order to maintain some flexibility. But if it’s available in ASIC form, then you know it’s pretty long in the tooth. And, in general, once cast in hardware, it’s less common to see something back out into software again.

And yet that’s exactly what TI is proposing with their collaboration with Triangle MicroWorks: together they provide a smart-grid substation solution on TI’s Sitara (and other) processors – taking that role back from current FPGA and ASIC solutions.

Given that this is rather less common, I inquired as to what the dynamics were. That’s really two questions: (a) what drove it to hardware in the first place, and (b) what’s the benefit of making the effort to go back to software?

Turns out there were two factors in the hardware implementation. One was classic: performance. Some functions (they specifically mentioned Generic Object-Oriented Substation Event, or GOOSE, messages and Sampled Measured Values (SMV) data) require timing that hardware could achieve. In addition, these functions can require anywhere from 2 to 5 Ethernet ports – not typically available on your average processor chip.

FPGAs have the flexibility and performance to do this. And, of course, ASICs do too. And so that has been a common solution, according to TI.

But now, with clock speeds hitting the gigahertz level, coupled with RTOSes to support the real-time requirements, the speed needs have moved back within the realm of the possible in software. Additionally, TI added a huge acronym communications subsystem to their processor platform. Called the Industry Communication Subsystem Programmable Real-Time Unit (ICSS-PRU), it allows configuration of multiple ports of a variety of different protocols, including Ethernet. So this now meets the requirements that, in the past, only hardware could provide.

Of course, it’s work to do this. Why make a change if the current solutions are working? Well, for one thing, if you’re a vendor of the software solution and not the hardware one, then you’ve got business to steal. That’s from the vendor’s standpoint. What about the customer? TI claims two things: development time and cost.

It would seem that both of those would apply more to the FPGA than the ASIC solution (since there’s no development required for the ASIC). And if the functions are mature enough to go into an ASIC, then hopefully the required software code is available as IP for a software solution – having to rewrite from scratch wouldn’t be a savings.

And then there’s cost… and money talks.

And so we have an example of a reverse trajectory: starting in hardware and eventually moving to software. At least that’s the proposal that TI is making. (And they say that customers are biting… but then again, I’ve never heard someone say on the record that their solution wasn’t getting traction…)

You can learn more from their announcement.

Tags :    0 comments  
Apr 08, 2014

Metal Oxide Photoresists Lower Roughness

posted by Bryon Moyer

One of the huge challenges of advanced-node patterning is roughness. There are actually two flavors of this: line-edge roughness (LER) and line-width roughness (LWR). Almost the same, but not quite.

The first is visible by looking at one edge of a line, and it’s hard to use any other word besides “rough” to describe what this means. It’s not long meanders in the line (which you might not expect from a mask, but might get with something like directed self-assembly (DSA); it’s the really small granular stuff. If you were to extract the frequency content of the edge, you’d be looking for the high-frequency mode, not the low end.

LWR is similar, but takes into account both sides of a line. Each edge has its own roughness, but, if by some effect, the two sides managed to track exactly, each jogging right or left when the other did, then the width of the line would be exactly constant. So even though the edges might be rough, in this idealized case, there would be no LWR (and no changes in impedance, although the constant impedance would be impacted by scattering at the rough edges).

In practice, the left side might jog left while the right side jogs right, creating a wide spot (lower impedance) in the line. Or vice versa, pinching the line down (higher impedance). This gives roughness to the line. You can think of LER as common mode and LWR as differential mode if you want. Yes, there’s a mathematical definition; we don’t need it for our purposes here.

So, obviously, the thinner your lines become, the more that roughness – if it remains constant – becomes a problem, because the deviations from perfection become an increasing percentage of the line width. And I used the word “granular” above on purpose, since it is the granularity of the resist that contributes to the roughness.

Standard resists are polymers – chains of monomers of some substance. The smallest unit available here is the monomer itself – break that and you end up with a different chemical substance. And, according to Inpria, a startup offering new resists, these monomers are in the range of 4 to 6 nm in length. That’s a non-trivial percentage of the feature size at a 10-nm node (even though we shouldn’t take that 10 too literally).

In order to smooth out the resist, a smaller grain is needed. And this is what Inpria is proposing to bring to the table: metal oxide-based resists. They’re delivered in an organic medium, but that organic nature gasses away, leaving only something that resembles a ceramic more than a plastic. And the grain size is on the order of 1 nm. Inpria claims the smallest, smoothest sub-10-nm lines yet.

Its hardness is another benefit. Many times “hard masks” are created by filming the wafer with a “hard” material and then patterning that with resist. These metallic oxide resists are hard enough to act as their own hard masks, eliminating those extra steps.

Challenges remain. Dose sensitivity is still being optimized, although it’s apparently better than conventional resists, which Inpria says require a high dose. Anything reducing the needed dose goes directly to improving exposure throughput, which we know is the biggest remaining EUV hurdle. (At this point, I have no information as to whether the double-exposure trick reported earlier applies here… no reason to think it would, since the chemistry is different.)

More challenging, perhaps, is reducing defectivity. This is where much of Inpria’s activity is focused now.

I suppose it’s too early to declare victory – new materials and new vendors of something so fundamental will be viewed cautiously by fab managers. You can imagine metals and their oxides that might play havoc if set loose in a cleanroom, so there’s something of a convincing job. But hafnium and tin are top of the list at this point, with good performance and good fab compatibility.

We’ll be able to watch progress even as EUV results are demonstrated. You may notice in the numbers that companies like ASML present, in some cases they’ll show results both for conventional and for Inpria resists. If you’ve ever wondered what that means, well, now you know.

Tags :    0 comments  
Get this feed  

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register