HomeChipsetsSix steps to build a custom IoT chip – as directed by Arm (Pt 2)

Six steps to build a custom IoT chip – as directed by Arm (Pt 2)

The sense to design and build a custom system-on-chip (SoC) is plain, we understand from an earlier companion piece. As we also understand, from the first part of this post, the process of IoT chip design is logical, much like constructing a printed circuit board – or a cabinet, indeed, where the design is drafted, the materials and fixtures are selected, and the thing is bolted together.

Here, we consider the final stage, as described by UK chip design house Arm, and voiced by the firm’s ‘developer advocate’ Alessandor Grande, in a seminar room at Electronica 2018 in Munich earlier this month. This build phase is broken into three: the configuration, the validation, and the fabrication.

There are subtleties, too, of course – and just like with carpentry and fitted kitchens, there are design tools available to pre-empt the uneven floors, the sloping plaster, the difficult corners. But, as Grande explains, just as the value for getting the design right is considerable, the cost of getting it wrong is high.


The fourth step is to configure the hardware and connect the peripherals. Developers can choose to do this from scratch, or lift from a template. Arm has a bunch of these; other chip designers will offer the same.

In the Munich tutorial, however, Grande majors on Arm’s CoreLink SSE-050 as an entry-level subsystem for designers using Cortex M3 processors to quickly configure the parts of embedded systems.

As with the rest of its support offer, its subsystems are part of its DesignStart programme. “Again, this is all free of charge,” comments Grande.

In particular, the M3 / SSE-050 combination are made for this middle ground of IoT devices, between rich embedded systems and highly constrained sensor units, well-suited to every field, from automotive and industrial to healthcare and home.

The SSE-050 is built around a single core, and an AHB interconnect protocol – based on Arm’s own open-source ‘advanced micro-controller bus architecture’ (AMBA), a standard for connecting blocks in SoC designs.

It also layers in four banks of configurable S-RAM, an APB bridge to connect peripherals, and Flash Cache and Flash Controller for better performance. Arm also provides a real-time clock and true random number generator for higher-grade security, and radio designs for connectivity.

Whether you go with the Arm template, in the end, these are standard considerations.


Unlike with building a cabinet, say, digital construction allows for the virtualisation and verification of designs, before anything is nailed down. This saves money and time, and produces better chips and higher returns.

These days, silicon is more about verification than it is about design, in terms of staffing at least. When Grande joined Arm, five years ago, he assumed different.

“I thought most of the work was about designing the chip,” he says. “Actually, if you look at a company like Arm, you’ve probably got one design engineer for every 10 validation engineers.”

It is anecdotal, but it makes clear the pressure on designers to deliver first time. “Validating a complex system is really hard – for a lot of reasons, but mainly because of cost,” he says.

Fixing a system with a bug takes a couple of engineers in the design stage; the effort multiplies when the design is in silicon, and in market. More likely, the recourse for an imperfect SoC is to disable some functionality and reduce the performance of the system.

“It is a big loss, if you don’t consider verification from the get-go,” says Grande. There are two ways to minimise risk: to use and re-use pre-verified parts, or else run your own tests. In the second instance, the key is to verify at every turn, he says, so each block is checked before the system is stitched together.

Again, Arm promises access to verification tools and support as part of DesignStart, and advice on external verification partners if preferred. But there is no telling, until the crystal is set. “You can never be sure, by the way – you have to implement the design to find out.”


Nevertheless, with the checks in order, the SoC can go into fabrication. “You have to build it,” says Grande. “This means transforming your high-level description of the chip into silicon – and that means gates and transistors.”

In other words, the design gets real, at last – which requires certain other tools and know-how. Again, there are elephant traps for rookie IoT designers – and, again, Arm is offering support via its DesignStart programme.

“One thing we do provide is physical IP, optimised for specific process nodes and values,” says Grande. A trick with fabrication, he notes, is to choose a suitable foundry for the IP in the design – or else choose suitable IP for the foundry.

“Each foundry has its own way of building things. And if you want to build in an optimised chip for a specific foundry, you need to make sure to use the right IP for that.”

Five reasons for developers to build a custom IoT chip – as signed by Arm
Six steps for developers to build a custom IoT chip – as signed by Arm (Pt 1)
Six steps for developers to build a custom IoT chip – as signed by Arm (Pt 2)

Industrial IoT manufacturing
Previous post
Industrial IoT product round-up, featuring u-blox, Analog Devices, Altair, Eurotech
Vodafone ioT
Next post
Vodafone simultaneously launches NB-IoT and LTE-M networks in New Zealand