IoT Demands Correct By Construction Assembly

Three months for an IoT design may not be aggressive enough. Think one and two months.

popularity

The article Limiters To The Internet Of Things outlined several factors that are slowing the rate of deployment for the IoT. Those limiters are cost, power delivery and storage, standards, security, and the limits of your imagination. This article picks up on a comment made by Chris Rowen, fellow at Cadence, related to cost.

Rowen laid down a challenge “You want to be able to create a design for $500,000 and three months of effort. This is a highly optimized chip for my application. It is one or two orders of magnitude less from a cost point than what we are seeing today.”

With the challenge laid down, Semiconductor Engineering talked to the industry to find out what it would take to make this a reality.

“Many of the EDA tools today have too much overhead for IoT edge type of designs,” points out Simon Rance, product manager at ARM. “Three months is not an aggressive enough goal. It needs to be in the one- to two-month range. The back end must become push button.”

Aveek Sarkar vice president for ANSYS, only partially agrees with this statement. “You definitely don’t need the cutting-edge place and route and other optimization methods,” he said. But he does believe that that we may be looking in the wrong place for the savings “EDA is likely to enable costs savings rather than a cost addition.”

Others agree with the last part of the statement. Ron Lowman, strategic marketing manager for IoT at Synopsys says, “I don’t think we need to compromise on optimization. I do believe that we need to develop easier to use tools.”

Others are simply not impressed by the goal. Frank Schirrmeister, senior director at Cadence points out, “We do a factor of 2 to 3 [improvement in productivity] every couple of years, so you come to a factor of 10 quite easily of the next 3 to 5 years.”

But these two trains of thought are not necessarily at odds with each other. Being able to deliver a product at a lower cost has several components to it. Sarkar says “we have to look at cost from multiple angles: (a) reduce the overall system cost, not just the chip area or the package, (b) minimize the field failures that result in returns and support costs, and (c) reduce the development time and cost.”

There seems to be little doubt in the industry that significant progress can be made in the reduction of development time and the industry appears to be concentrating on two aspects of this. The first is curtailing the increasing verification costs, and ways in which this can be done are examined in the article “How To Cut Verification Costs For IoT”. The second is a desire to move toward correct-by-construction assembly of systems given the amount of Intellectual Property reuse and adoption of standard infrastructures likely to be used for many IoT devices.

“One way to achieve that is to use standard components,” Rance says. “It helps to bring down cost and bring in the timescale. This is driven from the both the hardware and software sides. The hardware is not changing much from design to design. It is just small tweaks depending on requirements from a different customer. It is really the software that changes.”

Synopsys is a firm believer in IP sub-systems. Lowman says that “sub-systems include all the necessary processing, hardware accelerators, and closely coupled peripherals and memories, to build very innovative applications. The market will need to continue to drive in this direction. Platforms provide mature, validated basic functionality yet enable customization via both software and hardware.”

Rowen agrees that correct-by-construction assembly is a reasonable expectation. “To some extent it does happen today when people connect up to standardized bus platforms. You have verified separately that each component meets the specification and you know that the interconnect generator meets the specification so that you don’t need to verify the logical correctness of plugging that component into the network. That is a form of correct by construction.”

But this may not be as simple as it sounds. “The interconnect is so complex and has so many configurations of options and parameters that it is impossible to abstract,” says Schirrmeister. “You almost have to use the RTL.”

Michael Sanie, senior director of verification marketing for Synopsys agrees. “The interconnect is so complex that this always has to be modeled at the RT level. There is some architectural exploration that happens above that.”

The industry has been looking for a while to find mechanisms that enable automation of this type of assembly work. “In-house automation based on spreadsheets and scripts has been around for many years,” points out Bernard Murphy, chief technology officer Atrenta, “but is running out of gas for multiple reasons—adapting legacy or 3rd-party RTL for power, performance, area and compatibility with in-house standards, dealing with parameterized IP which defeats spreadsheets and optimizing RTL hierarchy for power and area. All of these are beyond in-house scripts.”

The industry tried to devise a method to capture metadata related to assembly. IP-XACT was first standardized by the SPIRIT Consortium in 2004 and later ratified by the IEEE as IEEE 1685. “In theory IP-XACT should streamline assembly,” says Murphy, “but reality does not support that view. The standard always seems to be behind practical needs, investment to align internal development logistics with IP-XACT is significant, and commercial efforts to support the standard have mostly disappeared.”

While IP-XACT may not have been a glowing success, the industry is not ready to give up on metadata. “The secret sauce behind making [automated assembly] work is metadata,” explains Rance. “This can add information to the IP that solves the mystery about where this IP had been, what it has gone through, a way to tell if the IP has been truly tested and how many times and with what conditions, so that I know I don’t have to re-verify it.”

Sarkar summarizes the challenge for the EDA industry. “Design houses will require tool flows that are cost effective for them. For EDA to benefit, the business model has to tune itself to meet the needs of these smaller design houses, a lot of which will be in India and China.”