posted by Bryon Moyer
This was originally going to be simply an update on something we discussed before. But it may be slightly more than that.
You may recall that, when it comes to local wireless for the Internet of Things (IoT), it’s largely a battle between WiFi, Bluetooth, and Zigbee (not counting proprietary networks). And that WiFi and Bluetooth have an edge, being in phones.
But Zigbee, despite its detractors (which seem legion), has one feature that can be useful for extending the range of a network: meshing. It’s something rival Bluetooth can’t do.
That is, until CSR introduced CSRmesh to lay a meshing capability over Bluetooth.
So this was largely going to be an update to say that CSR has also introduced an enablement kit to make it easier to get going. It includes dev boards, a USB programmer, and a software development kit (SDK) that initially targets the lighting market, with others coming later in the year.
Image courtesy CSR
But then came news of a more unusual sort: Microchip is in talks that may result in Microchip’s acquiring CSR. Not that an acquisition like this would be unusual, but, ordinarily, you would hear about it when the deal is done; not when talks start. Heck, you’re practically inviting your competitors to come help drive the price up!
Slightly closer review (OK, not that much closer – just reading boilerplate at the bottom of the release that would ordinarily be ignored) provide clues as to what’s up: we’re not in Kansas anymore. In the gray print at the bottom of their website you’ll find that, “CSR Plc is a company registered in England and Wales.” And the UK has a “Takeover Code” that requires more disclosure than what we’re used to this side of the pond.
So… if you’re engaging with CSR’s technology, it might someday come with a Microchip logo. Then again, it might not.
You can get more info on CSR’s enablement kit in their announcement, [Editos note: updated to fix a press release issue.]
posted by Bryon Moyer
While multicore took a while to take root in the embedded world, it’s now relatively commonplace. But the most accessible style of multicore is homogeneous: all cores the same. Combine that with a shared memory configuration, and this becomes easy because you can use a symmetric multiprocessing (SMP) solution out of the box from your favorite OS. It treats the multiple processors as a group as if they were a single processor. It can do so because the processors are all the same and they all have the same view of memory.
But that’s not how all systems work. Increasingly, folks are wrestling with heterogeneous systems, which have different processors, each of which might have its own OS instance running (or perhaps even no OS at all, so-called “bare metal”). While there might be some shared memory, it would typically be for message passing between processors. For the most part, each processor would have its own memory (or portion of memory) privately allocated.
(Just to clear up some potentially confusing terminology here, homo-/heterogeneous refers to the hardware architecture; SMP and its counterpart asynchronous multiprocessing (AMP) refer more to the software architecture, including the OS. SMP has a single OS instance managing the entire bunch of processors, and, as such, requires a homogeneous configuration. But a homogeneous configuration can be run as AMP if some of the processors have their own independent OS instances running. AMP systems can also include SMP components. At least, that’s how I see it…)
AMP/heterogeneous systems are harder to manage because each processor is aware only of itself. For the most part, no OS instance has system-wide scope (unlike SMP). So things that are easy with SMP become hard with AMP.
An easy example is bring-up: who’s in charge to make sure that all processors are synchronized in their operation? Typically, each processor comes up and holds at a so-called “barrier,” but which processor looks around, deems the system stable and ready for launch, and releases the barrier?
Much of that is system design work to assign that “master” processor, but then you need a programmatic way of implementing the decision. And the catch is that, because each processor is out of scope for any other processor, there’s no obvious logical way for one processor to control the others. There’s no “super-process” that has everything in scope.
This is what Mentor Graphics is trying to address with their recent multicore announcement. Now, to be clear, Mentor makes a lot of tools for a lot of things, including both silicon implementation and embedded systems. This announcement was not about how to create a multicore SoC; it was about how to implement software on an existing heterogeneous architecture.
There were three fundamental components to their announcement, addressing several different AMP challenges:
- remoteProc: this is a set of functions that allows one processor to control another. In particular, it allows for a well-coordinated system-wide boot sequence, with one processor controlling the life cycles of others.
- rpmsg: this allows intercommunication between processors (so-called inter-process(or) communication, or IPC). The figure below shows this interacting through the hypervisor, although no hypervisor is required. They’ve also optimized an MCAPI implementation, which can be layered over this.
- Improvements to their CodeSourcery tools to allow visualization of the different processes/processors in a clear and synchronized fashion (a challenge if you just run something like gdb on each core and then try to make sense out of the independent results).
Image courtesy Mentor Graphics
They did a cleanroom implementation of these functions to ensure that they could be used with proprietary software without exposing that proprietary software to GPL license restrictions (which would otherwise require making source code for that proprietary stuff public).
They have it integrated into their tools for ARM processors and available as libraries for bare-metal setups. They don’t have an integrated version for non-ARM processors; the libraries could be used, although they haven’t been validated on anything but ARM. It’s not that they think it won’t work on non-ARM; they just seem to feel that ARM is all that matters, so it’s where they’ve spent their energy. (I’m assuming that if something else blew up huge, they’d invest more energy there…)
You can find out more in their announcement.
posted by Bryon Moyer
Cadence recently announced new extraction tools, claiming both greater speed (5x) and best-in-class accuracy for full-chip extraction. And what is it that lets them speed up without sacrificing results?
The answer is the same thing that has benefited so many EDA tools over the last few years: parallelism. Both within a box (multi-threading) and using multiple boxes (distributed computing). The tools can scale up to hundreds of CPUs, although they’re remaining mum on the details of how they did this…
They have two new tools: a new random-walk field solver (Quantus FS) and the full-chip extraction tool (Quantus QRC). They say that the field solver is actually running around 20 times faster than their old one.
The field solver is much more detailed and accurate than the full-chip extraction tool. It’s intended for small circuits and high precision; its results are abstracted for use on a larger scale by the full-chip tool. That said, they claim good correlation between QRC and FS, so not much is lost in the abstraction.
They’ve also simplified the FinFET model, cutting the size of the circuit in half and increasing analysis speed by 2.5x.
While QRC is intended for the entire chip, it can also be used incrementally – in which case it can be three times again as fast. Both the Encounter digital implementation tool and their Tempus timing analysis tool can take advantage of this incremental capability to do real-time extraction as the tools make decisions. It’s also integrated into the Virtuoso analog/custom tool.
As to accuracy, they say they meet all of TSMC’s golden FinFET data, that they achieve consistent results with single- and multi-corner analysis, and that they’ve been certified by TSMC for the 16-nm node.
Their fundamental capabilities are summarized in the following figure, although this coverage is consistent with the prior tools.
Image courtesy Cadence
You can read more in their announcement.