First Time Success And Cost Control

First time success has been the ultimate goal for semiconductor companies due to escalating mask costs, as well as a guiding objective for the development of EDA tools, especially in the systems and verification space. These pressures are magnified for the (IoT), especially the edge devices. Have system-level tools been able to contribute to first time success and control costs or are they an additional investment for which the impact is still being debated? Semiconductor Engineering sat down with Frank Schirrmeister, group director, product marketing for System Development Suite at Cadence; Eshel Haritan, vice president of engineering at Synopsys; Jon McDonald, strategic program manager in the design creation business unit of Mentor Graphics; Grant Pierce, chief executive officer at Sonics and Alex Starr, AMD Fellow and pre-silicon solutions architect at AMD. What follows are excerpts of that conversation.

SE: The IoT edge devices are small, focused, cost sensitive devices. Do we need to look at the design of these devices differently than other systems?

Haritan: We have to remember that ultimately there is an application that sits on top of it. The system needs to have sensors collecting data. The application may be on the hub or your cellphone and this may be analyzing the data or sending it to the cloud for analysis. Maybe we can stay at 65nm or older nodes, but when you put the whole thing together and introduce software it become complex pretty fast.

McDonald: How do we justify the cost of the investment in up-front analysis? It doesn’t matter if it is the IoT or other devices; it doesn’t matter if we are reusing old nodes. At the system level a lot of the ROI and justification is based on insurance that you will get it right, or closer to right, the first time. The biggest problem is when you consider someone who thinks, ‘Yes, I know what I want to build and will just go ahead and do it quickly.’ Sometimes they are successful, and for them there is no ROI.

Pierce: We talk a lot about the chips that succeed. Success is necessary to get any return for the cost. For the IoT, companies will have to move very quickly because the opportunity to respond is going to demand a design cycle that is out of proportion with the lifecycle of the product created. If we could get the chip done in negative time, that would be really helpful. That will not happen, but if you invest a year or two years and the chip is successful, but only lives a year in the marketplace, then it starts to look like a risky venture. Throw on top that the IoT is such a broad statement of possibilities that we will have a lot of companies come in that simply experiment, get it wrong, and then have to eat the entire cost and throw it away. So now when we talk about system-level design being done correctly, up front, with perhaps an Agile software approach, it also begs for an Agile hardware approach that enables us to take what we like from a given chip and re-use it. But the reuse paradigm isn’t about the individual cores, it is about the compute system perhaps with new sensors or peripherals. This means I need to look at things not just from the standpoint of the individual chips but what I can invest in and re-use – a platform. We have to play the game with a book that is anticipating a lot of different plays, and we have to be prepared to make those plays in advance of entering into the game. I don’t think startups are the right companies to go after IoT. They are fundamentally compounding the risk.

Haritan: First let’s define success, then we can figure out the risks. Success is getting the design right and getting to volume as fast as possible. Companies may define this in different ways, such as how long does it take me to get to 10 million units? If this is success, then what are the risks? The first risk is to get the architecture wrong. People build families of chips, they don’t build a chip. They build a platform and many derivatives. You need to get the architecture right for power, for performance, for costs. If you get it wrong you either don’t make money or you fail in the market. The second part is you have to compress the design cycle. Given that software content is increasing, this is all about the shift left methodologies (see Who Pays For EDA Shift Left?) we are hearing about, doing software in parallel with hardware. If you don’t do that, the risk is that you will be late or spend too much time or money on the design. The only way to tell if it really works is to have it work in the environment. Full system validation includes hardware, software and the environment. There may be bugs in the hardware but it doesn’t matter if the software doesn’t see them.

McDonald: The biggest risk is that you have a specification, you build exactly what the spec said and it doesn’t sell. It does not do what it needs to do to be successful. Most companies can build something when given a spec. The processes are good, the methodologies are good—the problem is that you don’t know if that is really useful or what needs to get built. That is where system-level ROI comes in. You cannot look at the ROI just on the chips that are successful. We have to look at all of the chips that failed and what it would have taken to make them right. You have to see how many that failed devices could have been successful.

Starr: With shift left, there is a relentless drive toward improved time to market for huge SoCs. Everything has to work within the environment that it is intended for. All of the investment in these larger devices can be applied to smaller, cheaper designs and get it out of the door much faster. This is what will get the cost down.

Schirrmeister: For designs on the sensor side of the wrist band, there is a different type of shift left compared to the application processor side. For the application processor side, they are probably using ARM mbed or something similar. There may also be open-source processors coming for this. When I look at where my tools are involved, system-level tools, shift left is about getting software early, getting emulation involved. The sensor side is a small microcontroller and it is about mixed-signal, about predefined software but in a much different way than the software we build for complex virtual platforms for. It is not hardware/software early bring up on a platform.

Haritan: We need to look at different vertical markets. For IoT and the sensor sub-system, the software content will be small and will be done by the semiconductor team as part of the functionality. It is just an ASIC block. It is not exposed to the end user who is developing application software. All of these sensors will communicate through Bluetooth or ZigBee and send information to a base station where an application will run. This application will be complex.

Schirrmeister: Agreed. Shift left also exists for the small microcontrollers, but it is digital/analog. What I need to bring together is analog mixed-signal components with digital portions and a small ARM core and yes, software becomes important. It is software plus digital plus analog, but at a different level of complexity.

Part two can be found here.