IoT engineering challenges drive IC, system-design trade-offs

IoT engineering challenges drive IC, system-design trade-offs

Feature articles |
Besides the obvious challenges of keeping costs low for IoT devices, there area a number of design and verification challenges that are primarily driven by finding the balance between functionality and the limitations of the hardware and software. EDN’s Janine Love spoke to ARM, Micrium and The PTR Group.
By eeNews Europe


Moving beyond the hype of the potential for the IoT, there are some real engineering challenges that must be overcome in order to satisfy the intoxicating market predictions of IoT uptake across industrial and commercial markets. ABI Research estimates that the volume of data captured by IoT-connected devices exceeded 200 exabytes in 2014, and its annual total is forecast to grow seven-fold by the decade’s end, surpassing 1,600 exabytes—or 1.6 zettabytes—in 2020. So, how do we successfully create the devices that will handle all of this data?

Qian Yu, technical marketing manager at ARM says that from the physical implementation perspective, the design and production challenges come about due to functionality requirements, the limitations of flash technology, and economics.

In terms of functionality, one of the things that makes IoT SoC designs unique is their low power requirements, even as compared to mobile devices. And, their sleep-to-wake ratio is much higher. They still have similar frequency requirements, though, in order to ensure functionality. “As a result,” Yu says, designers need to focus on peak power and sleep leakage power optimisation without sacrificing too much performance.”

Christian Légaré, CTO and EVP, Micrium, notes that connectivity issues are also significant for IoT, as communication stacks may require their own processor. Légaré also emphasises the importance of defining an identity in hardware for security purposes, adding “It’s the only place where it can’t be modified or hacked.” Other security concerns for the IoT include maintaining privacy, anti-tampering, secure boot, and remote upgrades.

Obviously, small, single purpose, low-power IoT devices cannot handle all of these power management, connectivity, and security requirements, so what is the way forward? Légaré suggests an overall IoT approach that incorporates edge nodes (hubs or gateways). He says in this type of deployment, designers must answer questions such as: Where do you put the required computing resources in the system? How do you design the system so that it is future-proof? To be successful here, Légaré believes that embedded engineers need to work more closely with their colleagues further down the line, in IT. “This is not simple,” he says, “because both fields have their own set of technologies and vocabulary. However, for the IoT to be successful, embedded and IT engineers must come to understand each other.”

Moving into the realm of performance, Yu notes that some of the implementation and verification challenges include noise isolation, analogue to digital timing closure, and mixed-signal modelling. Also, he points out that the existing embedded flash technologies do not scale well below the 40 nm process. They require higher voltage than other types of logic blocks, so they consume more power.

How to Pick a Platform

Perhaps one of the biggest early challenges in IoT design is to pick an implementation platform. Mike Anderson, CTO and Chief Scientist for The PTR Group, Inc., notes that the choices between the ARM Cortex M0/M0+/M3/M4 (and soon M7) are plentiful. As with all design projects, engineers weigh which platform gives them the most features for their design constraints. But, more frequently, they tend to make their selections based on the availability of the prototyping platform. Anderson points to the TI MSP432, Freescale Kinetis series, and the ST Micro ST32 as some examples. He also suggests that compatibility with the Arduino platform offers advantages of inexpensive sensor modules, numerous communications options, and an easy to use, open-source development environment.

Another concern with platform selection is the debugging environment. Anderson offers this advice, “The commercial development platforms like Keil and IAR do a great job at integrating the development/debug features into a common IDE — for a price. If you’re a start-up or one of the DIY/maker crowd, then there are open-source tools that, with a little bit of integration on your part, can serve yeoman’s duty without the initial “sticker shock” [purchase price] of the commercial products. Additionally, many of the FPGA vendors have embeddable Cortex-M cores with verification tools included if you feel the need for some custom hardware.”

Anderson adds that while you can look at specifications to determine the platform of choice, he has found that lately selection is more likely based on anecdotal evidence. For example, someone’s friend at another company had a good experience with application support, so that’s the product other people are choosing.


How to Balance Power, Functionality, and Reliability

First, define the system architecture and put the computing resources where they make the most sense, advises Légaré. So, that’s the reasonably simple part, then what?

The next step varies. If an endpoint needs to be optimised for power, it often starts with a design step and then using a JTAG probe with power measurement capabilities to find the right balance. If a communication stack will run on the endpoint or on a module connected to the endpoint, a real-time kernel is often used to optimise CPU usage.

Of course, IoT applications have different requirements. For example, IoT endpoint applications have a smaller power envelope and a lower performance target than wearables. From the physical implementation perspective, Qian Yu offers designers the following check list to balance power, functionality and reliability:

Foundry process selections: By selecting the process node, designers anchor the window of PPAC (performance, power, area, cost) based on the application and design budget. They then engage in trade-offs using various design techniques

Operating voltage: Lower operation voltage has a big impact in power saving, so applying low-voltage design techniques can have a big pay-off.

Sleep leakage optimisation: Many IoT devices will sleep most of the time, so leakage optimisation for the sleep mode is critical. Designers can optimise the memory retention and power down mode using thick gate oxide (TGO) devices for non-sleep blocks, considering a trade-off between area with power by applying more long channel devices.

IoT SoC subsystem: Although the notion of an IoT subsystem SoC is relatively new, those components are actually using mature technologies. Designers can exploit IP blocks, reference designs, and integration tools to add functionality and improve reliability. (For instance, designers use ARM’s IoT subsystem reference design to speed up the design and prototype of IoT subsystems.)


What’s New?

There are a number of other new products, tools, and techniques to help with the balance of power. Légaré points out that the latest real-time kernels provide a new system-tick mode that allows the processor to slow down or stop when there is nothing to execute, thereby saving power.

For instance, multicore processors can be used to add more performance while keeping power low. In his experience, Légaré has found that many embedded engineers are not yet comfortable with multiple cores. “Here again,” he says, “new microcontrollers, new designs and new development tools for asymmetric and symmetric multiprocessing (AMP and SMP) will be required.”

In terms of new products, Anderson believes that the ARM Cortex-M has significantly changed the playing field. “We no longer have to use ancient tools to produce the code, and the development platforms are plentiful.” He concedes, though, that power consumption measurement is still a bit of a black art. He notes an important distinction that some manufacturers, such as Ambiq Micro in its Apollo Development boards, wire the power measurement leads out on the development board, while others “leave you to your own devices to figure out power consumption.“


What are engineers wondering about the IoT?

Anderson, Légaré, and Yu all agree that the most common questions from their customers centre on low power and security.

Some common questions Yu reports regarding power consumption include:

How does the power management of your logic and memory IP work?

What is the leakage ratio between normal operation, light sleep, and deep sleep modes?

What is the minimum voltage can you memory IP operate at and retain data at?

Can your IP support implementation of “A” frequency but within “B” power budget? We can live with A% of area increase but we are looking or B% of power saving, do you have a solution?

In the end, there is still room for improvement in the hardware offerings for IoT, and we are just at the beginning of the developments there. According to Légaré, hardware advancements are still needed in order to achieve more performance and keep power consumption low, while continuing to meet all of the emerging requirements. “The challenges are not only technical, they are also commercial,” he says, “The industry needs to address all these issues in a way that it is cost-effective so that the IoT can happen.”

In Anderson’s experience, most of the “burning questions” are about security for IoT devices. The major success will be found by finding the balance between security and cost. He notes that past experience suggests that the more secure something in, the less user friendly it tends to be. So this remains a challenge for IoT.

To help with security, Légaré notes that the Trusted Computing Group recently released v. 2.0 of its Trusted Platform Module, which calls for integration of the initial root of trust in the hardware. He says, “The industry now understands this is what needs to be done if we don’t want to repeat the mistakes we made when first connecting computers to the Internet in the 90s. So, we are looking at the silicon vendors and asking them to implement this standard.”

Looking Ahead

Arguably, the potential for IoT devices is enormous, and many use cases have yet to be imagined. And, each of those use cases will have different requirements, resulting in a spectrum of IoT devices and deployment types. But, at the heart of it all, we need to find ways to maximise functionality while minimising power as never before. As we embark on the great IoT adventure before us, engineers need to leverage every low-power technique and trick they learned from mobile designs, and develop many more. From the hardware side, vendors need to respond with flexible, inexpensive platforms that can take advantage of all of the best practices of design and integrate security.

Linked Articles
eeNews Analog