share article

Share on facebook
Share on twitter
Share on linkedin

Balancing device performance with costs is proving tough in the age of AIoT


Balancing cost and performance has always been the ultimate engineering challenge. Getting the best of both requires flexible forms of compute and connectivity in a single device, which not only would keep the cost low, but also improve the design flexibility. But, electronics engineers are struggling to increase the processing capabilities of electronic devices without costs spiraling out of control.

In a recent XMOS-undertaken survey of design engineers, 56% said their on-device processing requirements are already high or very high, and another 40% need even more on-device processing. But, 38% claim the goal is to reduce the bill of materials, and of these 48% claim it’s difficult to achieve, because of higher power consumption and greater design complexity.

Artificial intelligence (AI) at the edge is the latest significant demand that is pushing these design boundaries. Market analysis firm Gartner forecasts the AIoT market to reach $3trillion by 2025. In addition to existing compute, the AIoT demands a whole new class of processing across a broad range of applications. The tension is obvious — a solution that does not deliver the required features is irrelevant, if it is too expensive it will fail to be adopted (or the resultant product will fail in the market), if it is too complex it may miss the market window.

If process technology is no longer the answer, then we must address the systems that we build on silicon. Chip vendors should consider how their technology can be re-imagined to deliver on the needs of a new generation of smarter devices. These considerations should include the architecture of their device portfolios, its implication on ease of use and, of course, cost. They should also consider the future — how do their solutions scale with the relentless increase in demand for more capabilities?

All this means is that system architectures must now support four classes of workload — control, signal processing, IO and communications, and AI. Within this in mind, let’s consider some primary factors that drive our choices of architecture:

The development costs of a semiconductor must be amortised over the volume shipped in its lifetime. It follows that, all other things being equal, a semiconductor that can target a large market will be cheaper than one that can target a smaller market. Accordingly, as customer requirements diversify and the market for a specific set of features decreases, the cost of a chip delivering that fixed set of features must increase.

Conversely, a flexible device that can address a broad set of applications can maximise the return on R&D investment and those savings can be passed on to the customer, reducing cost. As diversity increases, it becomes better to spend R&D dollars on optimising flexible technology than increasing the number of application-specific devices.

Homogeneous or heterogeneous?

The right approach is homogeneous for as long as it is possible to deliver on required performance and cost. To make an analogy, if I have a two-seater sports car and an SUV, I can deliver on speed or luggage space, but I cannot deliver on both at the same time. A homogeneous solution would be to have two fast SUVs. Obvious, but what of efficiency? Well, both fast SUVs could probably be smaller, maybe not individually as quick — dealing with peak demands by working together.

It is only when we cannot otherwise accommodate the performance or cost demands of the application that we should consider heterogeneous approaches — they are inflexible and more complex to program.

One development method or four?

As we enter into the new age of AIoT because it is likely that different techniques will be used by the embedded programmer, the DSP engineer and the data scientist. However, the guiding principal should be to support industry standard approaches that are common in the customer and partner ecosystems, and that those approaches should ultimately be consolidated into a single tool flow.

The more homogeneous the target device, the easier this is to achieve. Homogeneous devices also scale elegantly. If you need more resource, more of the same resource is added. Done correctly, the design complexity impact of scaling a homogeneous architecture should be negligible. In the end, an easier to use architecture gets designs into the market faster.

Share this article

Share on facebook
Share on twitter
Share on linkedin

Member Login