How the Internet of Things Drives More Diverse Design Considerations

Last week I was in Taiwan, presenting at and attending CDNLive. It is always great to see the local progress. MediaTek presented on their adoption of Perspec System Verifier, highlighting how they increased throughput of test generation from 1 to 100 test cases per hour. Realtek reported on their use of JasperGold technology, as well as on their Palladium adoption, achieving between 30x to 50x speedup for verification acceleration and 2000x when embedding the testbench in the Palladium platform. ARM discussed connections to the Fast Models and Cycle Models. Details will be posted here. For me personally the most eye-opening keynote was Dr. Shih-Arn (SA) Hwang, General Manager, Design Technology at MediaTek. He gave a great talk outlining the design requirements for IoT, and they are not just about performance, power and cost!

SA started with outlining the universal IoT drivers, from wearables connected to mobile devices, through smart homes connected to set-top boxes, the connected car including driver assistance and car-to-car connections, all the way to enterprise automation for smarter industrial, healthcare, city, and energy management.

Just like I did in a previous blog post (How Health And Auto Requirements Drive IoT Design) about my Beddit and Waze usage, SA talked about what he has personally already done – from getting a smart watch that caused him to eventually upgrade his wireless router at home and to add more storage. In the future he will bring in lights that can be remote operated, home automation components, an electric and connected car and, eventually, a robot like Pepper.

Talking about requirements, SA made development of mobile applications almost sound “easy” as they are driven by power first, speed second and cost third. For IoT, not only the design considerations themselves need to be extended, but they also become more diverse depending on which areas of the IoT are actually targeted.

First, power, performance and cost are joined by security, connectivity and maintainability. So instead of three design considerations, design teams need to balance six considerations. And just to make life more interesting for design teams, the priorities change depending on the end application. SA cited, as examples, fitness tracking, health implants, ADAS/robotics and traffic infrastructure.

• For the edge nodes in a fitness tracker, cost comes first, followed by power and connectivity. These are the edge nodes in the IoT that are, after all, rolled out in large volume and need to be awake – powered on – for reasonable time frames.
• Priorities vastly change when considering health implants like a Dardioverter Defilibrator. Now security comes first, followed by maintainability and power. Nothing can go wrong in a device like this, so security trumps everything else. As there is a surgical impact, maintainability comes second. And the lifetime of the implemented electronic is heavily impacted by power consumption, again crucial to avoid a new surgical procedure to change a battery.
• For reactive applications like automated driver assistance and robotics, speed comes first, followed by connectivity and maintainability. If the warning of a driver assistance system in a car lags with its response, human life can be at stake. So the reaction time comes first here.
• Finally, for large infrastructure projects – SA used a traffic light example – maintainability comes first due to their volume and distribution in the field, followed by security (as in … don’t mess with traffic lights causing mayhem as shown in 2007’s blockbuster “Live Free or Die Hard”, which this site here claims is not possible due to mechanical stops preventing an “all green”) and cost.

Linking back to EDA and design requirements, SA called for validation and verification to extend from single chip methodologies to multiple chips as outlined in the flow graph below. This may actually cause new applications for platform ESL simulation at the transaction level with traffic generation and early access to applications, allowing assessment of the IoT dataflow and partitioning of the IoT architecture.

In closing, SA pointed out that the momentum of IoT applications is definitely confirmed, but emphasized that smartphones are an important enabler as they serve as an IoT gateway. And the diversity of architecture and design considerations, as described above, is definitely much broader compared to smartphones.

For me all of this is great – IoT continues to drive interesting development challenges for EDA to solve.