posted by Dick Selwood
Today (November 2nd) the International Telecommunication Union’s World Radiocommunication Conference meets in Geneva. It will run until the 27th and, apparently, during much of that time, there will be bitter arguments about the leap second. As we discussed in Just a Second http://www.eejournal.com/archives/articles/20150924-justasecond/ a few weeks ago, now that we measure the second using atomic frequencies, it is clear that the earth doesn't rotate evenly, so, at relatively unpredictable times, a leap second is declared. This requires the administrators of a range of systems to tell the system to add the extra second. The first time a leap second was declared, there were serious problems. Supporters of the leap second claim that the problem is well understood and manageable, but opponents argue that now we don't rely on the sun and stars for navigation, and use artificial satellites and the internet to share time signals, there is no need to take any risks. The arguments are summarised in IEEE Spectrum. http://spectrum.ieee.org/tech-talk/computing/networks/leap-second-heads-into-fierce-debate
posted by Bryon Moyer
You may recall a discussion about Golgi’s role in the Internet of Things (IoT) this last summer. In effect, it served to enable device makers to leverage phones as remote controls, providing the cloud-based go-between that completed the connection.
While that might seem like limited functionality, what it reinforced for me is that, despite all the easy drawings about what the IoT should look like, actual implementation was coming rather more slowly – step by step. So getting devices connected by phone was one step.
Well, Golgi is now back with another step. This time it’s for device makers that want to connect to various web services. Examples they list include analytics by Initial State), SMS via Twilio, push notifications through Pusher, a cloud database via Parse, email through SendGrid, and IFTTT for automating activities. That said, they say they provide an extensible API framework, so you’re not limited to this.
The way they do this is by creating device code based on the device API you design. That’s implemented over a complete stack, using MQTT for messaging. That then connects to their cloud-based connection point, which offers two portals.
(Click to enlarge; image courtesy Golgi)
One is an API portal that allows you to get in and control your device; the other is the connections portal through which you can push your device messages to the various cloud-based services. So, in the same way that the earlier offering provided a cloud-based midpoint and device code for connecting to the phone, this announcement has a similar cloud-based midpoint, but for connecting to other web-based services rather than the phone.
You can read more in their announcement.
posted by Bryon Moyer
Coventor recently announced the latest release of MEMS+, their MEMS EDA/CAD tool, and the timing was tough because it came just after I had an article involving process design kits (PDKs). And amongst the things that the latest MEMS+ release brings is movement towards MEMS PDKs (MPDKs).
MEMS devices are, of course, notorious for evading any attempts to rope in process and design options through standardization of any kind. Efforts continue, but it remains a challenge.
This means that any MEMS design involves a collaboration between a particular fab (captive or foundry) and the design folks to come up with a physical design that meets the requirements for a particular new sensor or actuator. And what’s done for some new design may have nothing to do with what has been done in the past. Materials may change, dimensions and shapes may change, and circuits and packages may change. Everything’s negotiable.
With the latest release of MEMS+, Coventor says that they’re enabling the use of PDKs for well-established sensors – IMUs, devices built on Leti’s MnNEMS process, and piezoelectric devices. The MPDK isn’t standardized, but then again, silicon circuit PDKs have also taken a long time to move towards standardization.
So Coventor is working, initially, with one fab and EDA company at a time, starting with XFAB and Cadence. You may recall from the silicon side that the first step away from incompatible PDKs for each tool/foundry combination was for a single foundry to unify its PDKs for all tools. So initially, for example, TSMC PDKs were different for Cadence, Synopsys, and Mentor tools, and then TSMC worked to unify the format.
But the result worked only at TSMC; GlobalFoundries and other fabs would have their own formats, even if unified across tools. This is the issue that the OpenPDK project has tackled since 2010.
This is the path that MPDKs are likely to take, according to Coventor. It would be nice if the lessons of the past allowed us to bypass some of the effort replication. For instance, if XFAB gets something going, it sure would be nice to use that as the basis for someone else, layering on change and generalizing rather than starting from scratch or even turning the XFAB-only MPDK into a similar-but-incompatible someone-else-only MPDK.
You can read more about this and the other new features in MEMS+ 6.0 in Coventor’s announcement.