posted by Bryon Moyer
Some time back, we took a look at the library of mechanical elements in Coventor’s MEMS+ tool for building MEMS device models. In the “be careful what you wish for” category, making it easier to connect elements into models meant that engineers started connecting more elements into models, and the models got bigger.
Big models can stress a tool out, resulting in slow results and resource starvation.
Well, they’ve just released version 4 of MEMS+, which at the very start, addresses those concerns, enabling quicker handling of more complex models.
But there’s a much more subtle way that they’ve addressed the needs of ASIC designers. Each MEMS element will need an accompanying ASIC to clean up the signals and abstract away a lot of the mechanicalness of the element so that electrical types – or, more likely, digital types – can understand the sensor outputs in their own language.
And, of course, you’re going to want to get started on that ASIC design as soon as possible. But the whole purpose of the ASIC is to turn messy sense element behavior into clean outputs, and in order to do that, you need to know exactly what messy signals you’re going to start with. And you don’t want to wait until the device is finished to do that; you want to model the behavior ahead of time.
The thing is, mechanical folks use finite element analysis and other such schemes for simulation; the ASIC designers will be using Verilog-A. MEMS+ is integrated into Cadence’s Virtuoso tool, so Virtuoso users can actually do their modeling using MEMS+ via a proprietary scheme. But Verilog-A can be used anywhere, and not everyone uses Virtuoso.
What that’s meant in the past is that the MEMS designers have had to hand-craft early Verilog-A models for the ASIC guys to get started on. Those models are tedious to create, and in their effort to keep the task reasonable, things would get left out of the model. And sometimes those left-out things would matter. Which meant that you wouldn’t find out about them until silicon came out, and you’d have to take another turn at the ASIC.
The next step was that MEMS+ could create a full Verilog-A model automatically. This would include all of the non-linearities and such, but it was a huge model, with thousands of “degrees of freedom” (i.e., knobs and variables) and would realistically take far too long to simulate.
So with this release, MEMS+ will let you create a simplified model by selecting specific behaviors and ranges to focus on. These could reflect particular modes or non-linearities of interest. MEMS+ can then fix the other parts, reducing the degrees of freedom from thousands to tens. Which results in a dramatic speedup – like 100X.
This approach can be used on a wide range of sensors – when the movement of the element is a fraction of the surrounding air gap. There’s actually a behavior that is not supported by this model, and it affects some sensors and typically applies to all actuators: it’s called “pull-in.”
The idea is that, when you apply an electrostatic field that pulls on a mechanical element, the element will resist thanks to the mechanical restoring force – essentially, it’s a spring pulling back against the field. But at some point, the field overwhelms the restoring force, and the behavior is no longer linear – the element gets “pulled in” to close the gap.
I sort of picture it this way (if you’re squeamish, you might skip this bit): picture standing some distance in front of an operating airplane jet engine, facing away from it. With earplugs. Good ones. You feel the pull behind you, but you can lean forward and stand your ground like a boss. Feeling brave, you step back a bit. The pull gets stronger, but you man up and show the universe who’s in charge: you are. Yeah, baby. You repeat this, working harder and harder against the engine’s suction, until suddenly, “whoosh.” Um… yeah. Say no more. Non-linear to say the least.
That discontinuity is pull-in. And it’s not included in these simplified models. It’s probably not a good thing to have in a sensor (although you’d want to know if it’s going to be an issue); it’s actually a useful feature for actuators since it gives you a good, positive contact.
One bit of good news with these simplified models: they run independently of MEMS+. So, unlike the Virtuoso-integrated approach, which requires MEMS+ in the background, you don’t need a MEMS+ license to use the simplified model. Obviously a MEMS guy needs a license to create the model, but the ASIC designer doesn’t need a separate license to run it.
You can find out more about MEMS+ 4 in their release.
posted by Bryon Moyer
It almost sounds too good to be true. You plug in your new connectable gadget, and not only do you get power, but you’re also connected to high-speed data with no further wires.
People have talked about using home electrical wiring for communicating for a long time, but it doesn’t seem to have gotten much traction – at least not in the US. (Ok, not that I’ve noticed, anyway.) Given the big clunky unshielded wiring, I’ve more or less assumed (without really thinking about it) that they weren’t up to the high-data-rate tasks that we all count on now.
Wrong. Or so say the folks at Qualcomm. Yes, Qualcomm. I know, we think phones and wireless and unplugged with those guys, but their Atheros group has apparently been paying attention to things both wired and plugged. They’ve announced an SoC that supports HomePlug AV2, supplementing existing chips already available. This new QCA7500 gets them above gigabit speeds.
What’s unique about HomePlug is that it can support both narrowband (for Internet of Things) and wideband (for HD video or high-speed internet). The Qualcomm chip supports gigabit data throughout the house; no Cat 5 needed.
What really caught my attention was MIMO. MIMO? Really?? Like, beamforming WiFi sort of thing, with multiple antennae? On… a wire?? O_o
Well, it’s true. But it works only on three-plug systems. Both the live and neutral are used as channels; 2x2 is the only possible configuration. (And it ain’t going to work if your contractor or builder faked out the three-plug thing for the inspector without actually grounding it throughout the house…) SISO is, of course, also supported.
If you have a really big house, you can even use repeaters. Which, of course, would inject a repeated signal in all directions, slightly delayed from the original. Apparently that latency is very low, and doesn’t create an issue for receiving devices trying to capture a clean signal.
When I think of the equipment needed to deploy this technology, I think of stuff that you can go buy at Fry’s to install. And for new construction with clean, grounded wiring, in particular in the US, that’s a possible model. Just like we do with WiFi in our houses.
But there’s another model: the managed one. In this case, your high-speed data carrier actually does the installation and manages the network remotely. This has been done in old houses in Europe (where I would guess the after-the-fact wiring might be sketchier). Qualcomm actually seems more highly focused on this model.
To be clear, they don’t think this will supplant wireless; they see the two working in concert. In fact, it just occurs to me… for folks like me using a cable connection, the wireless router (which is wired to the cable modem, if not outright integrated with it) has to be near the cable connection, which may not be near where you want the signal. So you could run the signals on the power line and have the WiFi router pick it up elsewhere in the house for a stronger signal where you need it. (Why use WiFi when you have HomePlug? Well, for smartphones, for example… they’re not plugged in.)
As to the cost of this technology, they don’t see it as being a huge issue – unless we end up with too much proliferation of interfaces and protocols. If the industry can rally around a few, it should be OK.
You can learn more about Qualcomm’s chip in their release.
posted by Bryon Moyer
Mobile communications have been one of CEVA’s focus areas (others being audio and images). If you’re new to CEVA, they do DSP cores for SoCs, focusing on low power as a critical feature. (They have lots of hardware features, but at the end of the day, whether it’s a hardware accelerator or an optimized instruction set, it all leads to lower power and longer battery life.)
We’ve covered them before (albeit getting distracted by the incredible alphabet soup that characterizes this market). As complexity has grown, they’ve seen the need for multiple DSP cores, so they put together a multicore platform.
But most of their mobile effort was going into DSPs that would reside in a handset. And yes, handsets have being going multicore for lots of reasons. And with the proliferation of smartphones, they have to be the most abundant example of heterogeneous multicore. In other words, different cores for different purposes – applications, baseband, graphics, etc. This requires an asymmetric model, with every core having its own OS and memory image (possibly sharing some memory for message passing and such).
But now they’re going for more than just the handset: they’ve just introduced a new XC4500 family that focuses on mobile infrastructure – and, specifically, base stations. You might think this would just be a bigger version of what they use in the handset, which is the XC4000 family. But it’s not, because what happens in a base station is very different from what happens in a phone.
A handset is all about taking a single call or session or whatever and breaking it down to extract the content and send that content to the appropriate places in the phone. That’s not at all what a base station does; it manages traffic. It doesn’t care, for the most part, what’s happening with any particular call or session; it’s just making sure everything gets to the right place. This is, basically, packet processing.
So while the phone needs all these different processors to handle the different aspects of the content, the base station simply needs to be able to scale what it does to accommodate the amount of traffic it has to handle. Which means that, unlike the phone, it can benefit from a homogeneous multicore architecture using a symmetric approach (SMP). If one core can process x calls, then n cores can process n*x calls. More or less (yeah, I know it’s not quite that simple…).
Which makes the XC4500 look different from the XC4000, even though they’re on opposite ends of the same airwave. It’s much more like a router than it is like a phone. Because it is a router of sorts. Traffic management features allow multiple independent queues and provide built-in dynamic scheduling. Data for a specific task is stored in shared memory, so assigning it to a specific core merely involves sending a pointer rather than a time-consuming data copy. They have cache coherency infrastructure to keep all of the cores’ caches in synch as well.
You might wonder, by the way, what the opportunity is for new base stations. And, apparently, there’s not a lot of movement in the traditional fiber/cable-backhaul market, where your wireless call gets sent to the mothership over a wire. But new installations are starting to favor wireless backhaul over microwaves. That’s where they see things looking up.
You can find out more in their release.