WP_Term Object
(
    [term_id] => 159
    [name] => Siemens EDA
    [slug] => siemens-eda
    [term_group] => 0
    [term_taxonomy_id] => 159
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 738
    [filter] => raw
    [cat_ID] => 159
    [category_count] => 738
    [category_description] => 
    [cat_name] => Siemens EDA
    [category_nicename] => siemens-eda
    [category_parent] => 157
)
            
Q2FY24TessentAI 800X100
WP_Term Object
(
    [term_id] => 159
    [name] => Siemens EDA
    [slug] => siemens-eda
    [term_group] => 0
    [term_taxonomy_id] => 159
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 738
    [filter] => raw
    [cat_ID] => 159
    [category_count] => 738
    [category_description] => 
    [cat_name] => Siemens EDA
    [category_nicename] => siemens-eda
    [category_parent] => 157
)

IoT chipsets and enterprise emulation tools

IoT chipsets and enterprise emulation tools
by Don Dingee on 10-16-2015 at 12:00 pm

When most people talk about the IoT, it is usually all about wearables-this and low-power-that – because everyone is chasing the next huge consumer post-mobile device market. Mobile devices have provided the model. The smartphone is the on-ramp to the IoT for most consumers, with Bluetooth, Wi-Fi, and LTE, and maybe a dozen or so sensors in a personal cluster at a time.

That model represents just the edge. IoT applications, especially ones designed for the industrial IoT, have two more tiers. In the middle is the multi-protocol gateway, capable of handling streams of incoming data from tens, hundreds, or even thousands of sensors under a wide variety of protocols. These gateways usually smash everything into an IP-compatible blend, in real-time, for further analysis.

Behind both the smartphone and the multi-protocol gateway is some kind of infrastructure, the third IoT tier. Much of the “cloud” application infrastructure is designed for human interaction through a web services protocol, often using a RESTful programming model. A short delay, no more than a second or two, is an acceptable response for most applications.

IoT infrastructure is usually real-time, where a second to respond might as well be never, and unpredictable latency in an IoT network can be an incredibly bad thing. To handle real-time operations, many IoT architectures are moving to a hybrid cloud model, with a converged modular server running multiple cores to handle incoming data and analytics.

We have smaller chips somewhat improving for the edge, but the problem of optimizing bigger chips for the IoT gateway and infrastructure tiers looms very large.

Mentor Graphics dives in to the deeper end of the IoT pool with a brand new white paper discussing how large-scale Veloce emulation systems can help in design and verification of IoT chipsets. They come at the problem from an evolved mobile SoC or network processor (NPU) point of view, which is a valid point of reference. Their discussion of protocols centers on IP-level interconnect, not IoT frameworks such as AllJoyn, MQTT, Thread, and others – I’d like to see them extend their concept to that next level, perhaps with an IoT ecosystem partner.


Nonetheless, Mentor touches on some important issues in IoT chipset design and verification. I’d like to mention two more of their five main points – power consumption, and software.

As Apple is discovering with their A9 chip from its dual sources, system-level power management is becoming a very big deal. Mentor claims Veloce can run the billions of cycles needed to expose power issues, starting early in the design and continuing to full-up verification. Veloce also integrates with third-party tools such as ANSYS for even more advanced power analysis. Power management at remote gateways, or even on a per-core basis in a converged modular server or Spark node in the infrastructure, may prove particularly tricky.

Software for the IoT is another issue entirely. Most co-verification efforts focus on Linux or Android as the platform. IoT operating systems and software may be completely different, running compact RTOS platforms at the edge, OSGi on gateways, and an advanced language such as Lua or Rust on the infrastructure to support data management and analytics. Without getting to the real operating system or language in use for an IoT chip, issues may go entirely unnoticed. Veloce is virtualized, allowing applications to be run over Veloce OS which abstracts emulator and debug details from the application. Again, I’d like to see more IoT software specifics from Mentor in the Veloce environment, but their idea of virtualization is headed in the right direction.

The white paper concludes with a discussion of how Veloce is an emulation data center, rather than just a piece of engineering lab equipment. An Enterprise Server allows job management and scheduling over LSF, relieving a major weakness of earlier hardware emulator implementations. This allows multiple projects to be configured on a single Veloce emulator of sufficient capacity.

To download and discuss the Mentor paper, head here:

SoC Verification for the Internet of Things

I think it is great we are starting to explore these ideas. While the building blocks of the IoT are very similar to those used in mobile chipsets, there are going to be implementation nuances that need addressing in optimized IoT designs. Simulators will not get us where we need to go in terms of understanding behavior of multi-protocol gateway and infrastructure chipsets that must be highly reliable under any real-time traffic scenario. Hardware emulation makes a stronger case for IoT chipset verification, if we can see some actual software and protocols applied.

More articles from Don…

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.