Let’s say you form a group in the United States with the purpose of setting up “offices” or camps in various impoverished foreign countries for the purposes of helping the local denizens. You know, an NGO kind of thing.

If you’re gathering a team of typical Americans (well, typical except for their willingness to go live in harsh foreign conditions), then it’s unlikely that you’ll be blessed with large numbers of people speaking obscure Amazonian or Khoisan or Altaic languages. So if you all just hop on a plane one day and go set up shop, you’re going to have a hard time getting things done.

If you really want to work hand-in-hand with the community of interest, not simply declare, “Here’s how things ought to be done, so go do that, kthxbai,” things will be rough. What, are you going to guess at what’s needed (since you can’t understand them when they explain their real problems)? And then make policy and… well… stop people in the street until you find someone who has watched enough Dallas reruns to have picked up some American English?

That’s not going to work. The only way you can be effective is to incorporate into each group one or more people who understand the local language and culture and can communicate in a manner meaningful to someone with an American background, and vice versa. An interlocutor or two become important to bridging the divide between two very different cultures with two very different sets of aspirations that can mutually benefit by interoperating.

Which is sort of how IC and MEMS design work. You’ve got these two domains that are wildly different from each other, and yet, when you need the mechanical machinations of a MEMS device to deliver an electrical result for further computation, they need to work together – and work together well – for it to be worth the effort.

The most typical scenario is the co-design of a MEMS chip and its associated ASIC, which will typically take the raw output of a transducer of some sort and “condition” the signals, filtering out noise and compensating for environmental variations and otherwise transforming a rough output into something robust and reliable, upon which decisions can be made.

The role of interlocutor between these domains is one that a company called SoftMEMS plays. Designers of the electronics need to involve the mechanical origins of the electrical signals; meanwhile, the mechanical designers still need to be able to simulate their creations using typical mechanical design tools. And, some chameleonic newer HDL tendencies notwithstanding, each side is foreign to the other. So SoftMEMS allows designers to make models that can work on both sides of the aisle. (Something US legislators could stand doing a bit – no, a lot – more… but let’s not go there.)

You might not necessarily go out and explicitly buy a SoftMEMS tool, however. That’s because, in many cases, the SoftMEMS capabilities are added into other tools. A designer using Tanner’s tools, for example, can get access to extra menus and capabilities that come from SoftMEMS.

This isn’t quite as simple, however, as bolting on, say, mechanical IP or standard mechanical cells. While IC design – digital in particular – has benefited from standardization and abstraction, MEMS has not. There are no PDKs; each foundry may work in a different way. There are design rules, but there is far more variation in the geometries used for MEMS; rounded features are not unusual. And materials vary dramatically.

In fact, even just restricting ourselves to the electrical/mechanical interface is too limiting. SoftMEMS also bridges to thermal, magnetic, optical, and fluidic domains, combinations of which may interplay in any given device. So building a model that reflects the idiosyncrasies of a particular juxtaposition of domains and materials means going back to basics and spelling everything out.

 That means you need to define your process. Which means you need to define your process steps. Which means you need to define your materials. Which means you need to define explicitly the properties of those materials. Little is left to assumption. SoftMEMS does, in fact, provide some IP that either works as is or is subject to parameterization or at least provides a starting point, but many designs will need to start from the bottom and work up.

Actually, you may start from the top and work down. The flow allows a top-down approach, where you start with abstract models and refine to a specific layout and process, or a bottom-up approach, where you start with the process. But the point is, the “bottom” here can be really far down.

If you are starting from scratch at the bottom, you build your process step by step. When a material is going to be laid down, for example, then there is a step for that, with various parameters indicating things like amount of material and whether it’s a conformal coating. The mechanical or other properties of the material also need to be called out. For etch steps, you can pull in a mask that you’ve defined in, for example, Tanner’s L-Edit tool.  You work your way to the top, and, when you’re done, you can “play” the process and see a 3D view of the layers building up, with mask-defined features materializing before your eyes.

This may sound similar to what we saw in Coventor’s SEMulator 3D, but in this case it’s more approximate. If you needed a higher level of accuracy, you could move from SoftMEMS to SEMulator 3D for sign-off analysis. But for everyday planning and work and meetings, remote or in-person, you can demonstrate what’s being built or specific issues or whatever through the tool rather than doing a separate drawing in PowerPoint.

At the circuit level, you can define devices that have a combination of ports from all of the different domains that SoftMEMS supports. And then you can simulate the whole thing. “But,” you might wonder, “how do you simulate all of those domains together with one engine?” Easy, silly: with a simulator that can do that. Which is more common than you might think: SoftMEMS’s Mary Ann Maher has specifically used or is aware of:

• Tanner (SPICE, Verilog-A; Verilog-AMS coming this fall),
• Cadence (SPICE, Verilog-A, Verilog-AMS, VHDL-AMS),
• Synopsys (SPICE, MAST),
•  Mentor (SPICE, HDL-A, Verilog-A, Verilog-AMS, VHDL-AMS), and
• Matlab (M).

Now… some of these languages are designed to handle multiple domains, but… SPICE? Isn’t that only for circuits? And the answer is, “Yes and no.” As Ms. Maher reminds us, SPICE is simply a solver of differential equations in matrix form that happens to have targeted electronics. In theory, it can handle other domains as well; it’s just that the input format or language is geared towards circuits. So these non-electronic models can be converted to “fake out” SPICE so that it can simulate both mechanical and electronic systems without realizing it’s been duped. Of course, the tools accepting the SPICE output must also be aware of the charade so that they can present the true nature of the results.

This multicultural awareness is what makes SoftMEMS a viable go-between that can allow various domains to work together rather than working near each other separately. By speaking multiple languages, it can communicate to either side (or all sides) in culturally-relevant terms, reducing the chances of misunderstandings and misjudgments that might add delays to project schedules.

More info:

SoftMEMS