posted by Bryon Moyer
MEMS oscillators are making a serious challenge to quartz these days. We looked at Sand 9’s approach recently, but as I thumbed back through other recent announcements, I came back across one that, in retrospect, had some relevant bits to discuss.
Silicon Labs’ earlier announcement focused on the CMOS+MEMS aspect of their work. At the time, I didn’t see anything I could add to the discussion, so I let the announcement stand on its own. But in light of some of the issues I covered in Sand 9’s release, I thought there were some things to come back to on the Silicon Labs story – some of which weren’t immediately apparent in their release.
This relates to temperature compensation, which seems to be the number one concern with these devices. Yes, everyone tries to compensate with circuitry, but if you can minimize the raw temperature effects, then the compensation is easier.
We looked at the stack that Sand 9 built to do this – silicon and oxide having opposing temperature coefficients and therefore physically compensating for each other. Well, Silicon Labs does something similar but not identical.
They use SiGe as the active material for the resonator, but they back it with SiO2, which again opposes the temperature characteristics of the SiGe.
The other subtlety here relates to the CMOS processing aspect, although again, it seems to be two different ways of accomplishing the same thing. Sand 9 discussed how having the compensation ASIC in the same package was important so that the ASIC was experiencing the same temperature as the sensor it was compensating.
With the Silicon Labs approach, this happens as a direct result of combining MEMS and CMOS on the same die: The compensation circuitry isn’t just next to the sensor; it’s on the same die as the sensor. So again, it experiences the same temperatures as the sensor. It’s probably even closer, although at some point, if you start arguing about hot spots on the actual die, you could question whether mere monolithic integration guarantees better compensation. It depends on where things are on the die and how “hot” the circuits are. So it remains to be proven whether monolithic compensation is practically any more effective than a well-engineered die-by-die solution.
You can find more on Silicon Labs’ process here.
posted by Bryon Moyer
A new device available in a plastic package. Big news! Wow, no one has ever done that before, right?
In so many other cases, this might be a reasonable reaction to a press release announcing a new plastic package. Except when the topic is MEMS. You can never take anything for granted with MEMS, it would seem. Least of all packaging.
So why is this news? It was a pressure sensor from STMicroelectronics. And here’s the deal: pressure sensors have to be open to the environment. That’s how they access the pressure, through a hole or port. If you take such a device, with its delicate diaphragm, and you subject it to the plastic molding process –which occurs under high pressure – you’re very likely to damage the pressure sensor itself.
Some folks have apparently addressed this issue by encasing the inner workings with a gel that can absorb the strain – in some cases even covering the sensor, meaning the pressure measurement has to act through the gel.
What ST did was to make a rather substantial change on the sensor die itself: they’ve decoupled the sensing element from the rest of the die, suspending the sense element by silicon springs. The springs handle the molding pressure without interfering with the sensed pressure. (Well, it would seem that the springs would have to be calibrated into the measurement, but they’re not blocking in the way a gel would.)
Rather a lot of work to accommodate something as silly as a simple plastic package. Which, of course, is neither silly nor simple… You can find out more in their announcement.
posted by Bryon Moyer
Cadence has announced its latest upgrade to their Palladium emulator family. It has many of the usual improvements you might expect – faster execution, higher capacity, better debug, and such. But there are two other new features that are more than incremental.
The first hybridizes verification between a virtual platform and the emulator. This is not the same as, say, simulation acceleration, where a simulator is running a cycle-accurate model and using the emulator to speed up the particularly intensive bits. In that model, the emulator is “slave” to the simulator.
In the hybrid model they’ve announced, it’s almost the inverse of that: the emulator is doing the real verification; a virtual platform is employed to speed up non-critical elements.
An obvious example of that is OS bring-up. If you’re actually testing the OS loading process to see if it works and to find bugs, then doing that on the emulator is necessary to model the true hardware cycle by cycle.
But once you have that done, then re-running the OS load each time you want to test something after that is not a good use of time. So the virtual platform can do that and then establish the state from which the emulator can continue. It’s more versatile than simple save-and-restore because you can instruct the virtual platform to do things differently each time if you want.
In this model, the overall SoC (or whatever) and its state are distributed between the virtual platform and the emulator. But it’s key to remember that the virtual platform is running abstracted models while the emulator is running the actual circuits. So anything that’s truly being verified needs to be in the emulator: the stuff in the virtual platform is assumed to be correct (at least for the purposes of the test being run – you could always swap it later).
Typically, the processor would be in the virtual platform and things like graphics and other accelerators would be in the emulator. (Unless you’re actually testing out the processor…)
Cadence says that the tricky part was achieving synchronization between the virtual platform and the emulator to make sure that they can each do their own thing when that makes sense – but that they check in and synchronize with each other where needed. This is essential for ensuring that, at any given time, the combined emulator/virtual platform entity is in a valid state.
Using this model, parts of the execution that don’t matter except to establish a correct state for some other test can be hurried along, slowing down only when the block-under-test is being exercised. The result they claim is 10X faster hardware/software verification and 60X faster OS bring-up.
The other new element is the ability to download virtual testbench elements like data generators into the Palladium for software-based execution. This may sound a bit like the VirtuaLAB thing we discussed last year, but there’s a critical difference. While they’re both intended to get rid of the rate matchers necessary to interface real data sources to the emulator, the VirtuaLAB approach is via pizza-box hardware as an accessory to the emulator. Cadence’s approach involves no new hardware because it’s simply software executed in the existing Palladium hardware.
You can get more details in their release.