Don’t Underestimate the Challenges of IoT

Adhering to ISO 26262…avoiding repairs to IoT devices in hard-to-reach factory floor locations…dealing with the complexities of server-class chips with as many as eight CPU cores—developers will find no shortage of IoT hurdles to overcome


After several years of hype about the potential for the Internet of Things (IoT), some sense of reality is emerging. Perhaps no one needs an Internet-enabled toaster, but there are plenty of other applications in the home, vehicles, and factories that do make sense. Many observers envision IoT devices as being incredibly cheap as well as ubiquitous, easily tossed away and replaced when they fail or become outdated.

This leads some engineers to believe that IoT designs can be done quickly and easily, with less rigor than goes into today’s smartphones and other complex consumer devices. They may look to bypass some aspects of verification, perhaps settling for lower coverage goals or an informal test plan that does not correlate intended functionality and coverage. In many cases, there seems to be little concern about long-term safety and reliability.

Is an IoT device really the ultimate disposable product? Can designers and verification engineers really cut corners?

The situation is much more complicated than it might at first appear. For a start, IoT devices may contain highly sophisticated electronics. The Intel Atom family of processors, sometimes cited as ideal for IoT applications because of its lower power requirements, has grown to include server-class chips with as many as eight CPU cores. System-on-chip (SoC) devices built with these processors can be as complex as one can possibly imagine.

Verification of complex electronic designs, of course, remains a major challenge. It costs millions of dollars to turn a chip, so a bug that escapes to silicon can be costly to fix. A missed market window may cost hundreds of millions. IoT chips must be verified as thoroughly as designs for any other application. The high volumes expected for many types of IoT devices mean that any campaign to replace defective chips would be enormously expensive.

Figure 1: Not all devices connected by the IoT will be simple to design or verify. (Source: Fotolia)

Further, many IoT devices will be in locations that are not easily accessible, making repair even more difficult. Such devices in the home or office include security cameras, environmental sensors, and heating and cooling controllers. On the factory floor, every second that production is halted costs money, so IoT repairs must be avoided. Even if a hardware bug can be fixed by an over-the-Internet software patch, some percentage of chips are likely not to update properly without manual intervention.

Some observers maintain that the majority of IoT devices will be built using field programmable gate arrays (FPGAs) rather than custom chips. This avoids the long delay and expense of fabrication for both the initial build and subsequent bug fixes. But repairs are just as difficult regardless of the chip technology used, and leading-edge FPGA design and verification engineers generally follow a flow much like their application-specific integrated circuit (ASIC) and custom chip counterparts. Choosing a complex FPGA, which may very well qualify as an SoC, offers no shortcuts for verification.

As if all this isn’t enough, some categories of IoT chips must follow rigorous verification and safety standards, such as ISO 26262 for automotive electronics. These standards typically require high coverage metrics, with coverage points mapped back to the functional requirements for the product. The design must be bug-free before chips are fabricated. In the field, manufactured devices must be “safe” and robust in the presence of random errors such as a wire breaking or an alpha particle flipping a memory bit.

Figure 2: Robust verification of IoT devices requires a flow that maps requirements to features and uses appropriate coverage metrics to measure the contribution from multiple verification engines. (Source: OneSpin)

Tool vendors, chip suppliers, and systems houses must undergo a long process of certification to these standards. As knowledge of safety standards grows, consumers are likely to demand that all manufacturers be certified. In truth, verifying some classes of IoT devices may be harder than verifying a smartphone or tablet, not easier.

What is an IoT Verification Team to Do?
Many of the answers lie in formal verification technologies. Formal tools such as property checkers have the ability not just to find bugs, but to prove mathematically that there are no longer any bugs to be found. This provides a measure of certainty impossible to obtain with simulation or emulation alone. Formal tools operate on assertions about how the design should (and should not) operate. With standardized assertion formats and tools that can determine how much of a design is covered by assertions, many of the traditional barriers to the use of formal have been shattered.

This is especially true for formal applications (“apps”) that verify specific aspects of the design with little or no manual effort. Some apps can extract certain kinds of design intent from the hardware description language (HDL) model or setup files and auto-generate assertions for formal analysis. Other apps include pre-packaged assertions. Many formal users rarely, if ever, write their own assertions, relying instead on apps to check for such issues as improper block connectivity, propagation of unknown values, and interface protocol violations.

The team must establish a robust verification flow, starting with requirements and mapping these to features that represent every aspect of desired behavior. The verification plan must specify which engines (simulation, emulation, and formal) will be used for each feature. Appropriate coverage metrics must be selected and monitored to ensure that every aspect of the design has been verified. Robust coverage metrics are now available from formal tools and these can be combined with results from simulation and emulation for a comprehensive view of verification completeness.

The verification team must also employ formal equivalence checking between the HDL model of the design and its gate-level implementation. Modern logic synthesis tools apply a wide range of transformations and optimizations to the design. Equivalence checking flags any mismatches due to synthesis tool errors, improper synthesis setup, or optimizations inappropriate for a particular design. Formal equivalence checking must be applied for FPGA designs as well as for ASICs and other custom chips.

Finally, where standards or consumer demand require long-term reliability, the team must verify that random faults during operation can be detected by hardware safety mechanisms. These faults must either be corrected or used to trigger an alarm of improper operation. This stage of verification is also performed primarily using formal techniques, including random fault injection, fault propagation analysis, and safety coverage metrics. If a fault simulator is used, the work can be cleverly split with the formal tools and the results can be combined.

In summary, IoT development teams do not get a pass on using the most advanced design and verification methodologies. They must verify their chips and devices thoroughly and, where appropriate, guard against random events that can compromise operation. The good news is that there are proven tools available today to meet all these challenges.

Tom Anderson is technical marketing consultant at OneSpin Solutions. His previous roles have included vice president of marketing at Breker Verification Systems, vice president of applications engineering at 0-In Design Automation, vice president of engineering at IP pioneer Virtual Chips, group director of product management at Cadence, and director of technical marketing at Synopsys. He holds a Master of Science degree in Computer Science and Electrical Engineering from M.I.T. and a Bachelor of Science degree in Computer Systems Engineering from the University of Massachusetts at Amherst.

Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google
  • TwitThis