Mar 12, 2013

Tools vs IP

posted by Bryon Moyer

All of the major EDA companies have had IP. Synopsys started with DesignWare before IP was a real concept; Mentor had IP associated with consulting for several years; Cadence has made a couple of acquisitions – notably memory – to bolster its internal IP efforts.

But the early products of these groups were typically lower-level IP – particularly I/O protocols. Not having to plough through hundreds of pages of a complex protocol spec was an attractive thing – assuming you were willing to trust your vendor to get it right or you had some way of verifying it without having to learn it yourself. And assuming you were willing to pay for IP (not a given in the early days).

Meanwhile, increasingly sophisticated IP from IP companies increasingly requires an accompanying tool to help configure the IP and integrate it with the rest of the design.

So we’ve had tools companies making IP; IP companies making tools.

And the IP part of the EDA play has become far more visible, almost holding its own against the tools themselves. And more and more, a robust IP portfolio is seen as including a processor. Intel/AMD and ARM obviously have their own well-established franchises (of which only ARM is an IP play), but there have been a few other notable players. MIPS was a recognizable contender, even if it never managed to outpace its archrival ARM; it was recently gobbled up by Imagination Technologies.

There has remained another processor company still duking it out with its own unique story. Tensilica promised a configurable processor. In essence, you told the tools what you wanted to do, and, in the end, you got a processor tailored for your application. And the software tools to compile to it.

Well, Tensilica is now betrothed to Cadence. My colleague Jim Turley noted the parallel to Synopsys’s purchase of ARC. Didn’t notice that one? Yeah, that’s because Synopsys bought Virage bought ARC*. And ARC also boasted configurability, and had a focus on the audio business – a space that Tensilica has participated in.

So we have the continued agglomeration of IP and EDA together. Dominated by ARM, followed by Two of the Big Three EDA guys. And Imagination.

Now we have more tools guys making IP; fewer IP guys making tools.

Some discussion today with Cadence reveals a bit more nuance. There’s debate as to whether a Tensilica core really competes with an ARM core. The customizability of the Tensilica core for very specific vertical applications means it gets more deeply embedded, often running with no OS at all. In fact, it is marketed as a data plane, suggesting the need for an accompanying control plane host. Some even say it’s an alternative to RTL, not an alternative to ARM.

Meanwhile, Cadence is promoting a theme of “next-generation IP” that, at first blush, sounds just like what IP has always been. The concept is that you can’t really count on shrink-wrapped IP that’s reusable by all comers. Each customer is going to want specific changes and adaptations that no one else may want (or that they want to keep to themselves).

This has always been the case – to the point where the on-the-shelf IP has historically been a teaser to engage in a consulting contract to give the customer what they actually want. So why is this suddenly a “next generation” thing?

The difference is that this customization is intended to be automated. In other words, the IP base is built with numerous knobs, and a tool accomplishes the customization per the knobs that the customer wants tuned. In fact, it intentionally starts to look more like a tool – a circuit generator – than a piece of circuitry. This has obviously been happening already here and there; it was central to what Tensilica was doing.

So we’ll have a tool guy making IP that looks like a tool.

You can see more about the merger in their release

 

 

 

*And ARC bought Teja Technologies, an event that rendered This Then-Intrepid-Marketing-Exec to explore an opportunity to be This Intrepid Reporter…

Tags :    1 comment  
Mar 07, 2013

A Hardened Hub

posted by Bryon Moyer

There’s a new 9-axis motion sensor hub in town. Called SENtral, it’s a collaboration between PNI Sensors, known for geomagnetic sensors and fusion, and EM Microelectronics, a division of Swatch, whose focus is on ultra-low-power circuits. And it has its own twist.

Given EM’s focus, it should come as no surprise that this hub’s claim to fame is low power: they say it uses a small fraction of the power of the next competing microcontroller-based sensor hub solution. The exact value of that fraction is still being finalized; the press release quotes a conservative 10%. Some actual numbers are looking more like 1% (depending on which processor you compare it to), so they’re settling more on a preliminary value of 5%. That’s 5% of the competition, not 5% less than the comp.

So you might wonder, how did they get their microcontroller to draw so much less power? And the answer is, because it’s not a microcontroller running fusion software: they’ve hard-coded the fusion algorithms as an ASIC. So that answers one question: you’re not going to get source code to tweak if you want to adjust the fusion algorithms.

Since the focus here is on motion, you might understand this as meaning that motion algorithms are pretty much set; do the math and deliver quaternions. But it’s not all about pure math. You may want to tweak how magnetic anomalies are rejected, for example.

So they’ve built in some knobs – register values – that can be adjusted when you configure the device. There’s a bitstream that loads on start-up, and this configures the device for the sensors you’ve chosen (all of which are a bit different); you can also use this to tweak some of the algorithms (although, to be clear, you do this via a graphic interface, not by manually tweaking a bitstream, just in case that sounded scary).

You can find out more about what’s going on with their release.

 

Tags :    0 comments  
Mar 06, 2013

One + One > Two

posted by Bryon Moyer

The latest, greatest mobile standards appear to be beastly affairs. Added to the old ones, and the number of algorithms that a poor cellphone – even a smart one – has to manage becomes pretty daunting.

And features like MIMO – various permutations and combinations of multiple antennae on the sending and receiving sides – make for an array of possible algorithms that CEVA says can only be managed through a software approach. That is, you load the software you need for the algorithm required at the moment rather than hard-code every possible variant, which would simply take too much silicon.

CEVA attacks this market with their XC architecture, and they recently beefed it up by announcing a multicore version. “OK, big deal,” you might say. “I had one core, now I can have more than one. I could do that before by instantiating more than one.”

Yes and no. Going truly multicore means one more huge addition to the architecture, most of which operates in the background: cache coherency. So even if that was all they had done, that’s a lot of work in its own right.

But they appear to have gone beyond that, adding packet management and scheduling hardware, along with design tools that understands higher-level concepts like queues and buffers. And frankly, at least conceptually, this starts to look a lot like a Cavium OCTEON chip, only with DSPs instead of RISC CPUs.

But, of course, this is IP, not hard silicon (although they have emulation boards). So you can configure things any way you want – including homogeneous and heterogeneous architectures, the latter blending DSPs and CPUs if desired.

They’ve also added floating point support; they point to the MIMO algorithms as a particularly compelling reason to move beyond fixed-point.

So it’s a larger leap than just adding another core or two. You can see more of the speeds and feeds in their release.

Tags :    0 comments  
Get this feed  

Login Required

In order to view this resource, you must log in to our site. Please sign in now.

If you don't already have an acount with us, registering is free and quick. Register now.

Sign In    Register