Experts at the table, part 3: Using IP across different markets isn’t so simple; secret sauce versus standards; unexpected uses and problems for finFETs and stacked die.
Semiconductor Engineering sat down to discuss IP and finFETs at advanced nodes with Warren Savage, president and CEO of IPextreme; Aveek Sarkar, vice president of engineering and product support at Ansys-Apache; Randy Smith, vice president of marketing at Sonics, and Bernard Murphy, CTO of Atrenta. What follows are excerpts of that conversation.
SE: It’s harder for a fabless semiconductor company to come up with use cases than an OEM designing its own chip. How will that play out in the stacked die era, where pieces are supposed to snap together like LEGOs.
Savage: That’s correct, and it will be hard for some of the fabless companies. With 3D-ICs, I’m not seeing any convergence at the EDA level on standards. What I do see are a lot of proprietary advances that are closely held.
Sarkar: The big problem is that you understand your IP, but how do you connect these models? With a 3D stack, that should connect to another chip. You have microbumps, but where are the bumps located? We have to define that and other standards.
Savage: When we get into very high volumes in consumer applications, the companies that play in this area will drive what the standards will look like.
Smith: The question is whether they drive to standardization or whether this is part of their secret sauce.
Savage: It’s very much the secret sauce today. There’s a tradeoff between standards making technology cheaper for everyone versus differentiation.
Murphy: I was speaking with the VP of engineering at one large company, and he is pretty heavily involved with 3D. He said it’s chaos right now. They’re trying to figure out standards for TSV locations.
SE: What happens if you run wires around the outside instead of TSVs through the middle of the die?
Murphy: Even then you need standards.
SE: But if you look at 10nm, that’s rather chaotic, too. We also have the IoT on one hand, high-volume consumer markets on the other, and then we have finFETs fitting into all of them in different ways and IP coming in at all different levels. How do we lessen the confusion?
Murphy: The finFET operates very nicely at lower voltages. It’s not typically what it’s used for, but if you can run it at 0.5 volts near threshold, it starts to look pretty attractive for IoT applications.
Sarkar: Cost is going to be the main driver for the IoT, and finFET technology is going to be too expensive. You need a 65nm process with a very cost-optimized package. It’s a different perspective. How do you reduce the cost of the whole thing and design the board, the antenna, and the whole package for 5 cents or 10 cents?
Smith: They’re going to look at the design cost and how quickly you can get it out. That’s critical. It’s a combination of a cost curve and a power curve. It’s the sweet spot where it’s inexpensive to manufacture at different nodes.
Sarkar: This is where we see a lot of focus on power analysis in terms of how you use the power. You put a chip inside the body and it’s going to be there for 10 years.
Murphy: Those are not going to be as price-sensitive, though.
SE: There’s a huge spectrum for how this stuff is going to be used and priced. But finFETs may play a role in different ways. So how do we get to an architecture or modularization where all of this stuff will work?
Smith: What you’ve described is a huge problem, and we solve that with divide and conquer among different companies. But we all have our own specialization, too. We have a hugely connected partnership network across most companies, and that’s how we collectively need to solve this. Several generations back we would have been relying on the large semiconductor companies to tell us what they needed. Instead, what’s happening now, particularly with systems houses becoming more dominant, is they’re going to rely on us to figure it out.
Murphy: That’s happening a lot. They’re expecting answers.
Savage: Yes, more than ever.
Sarkar: If you look at how this comes together from the foundry standpoint, finFET is very similar to 28nm but there are a lot of new metal layers that have been introduced. When you start designing an analog IP or memory, you start to worry about the base layers that use interconnects. There are a lot of complexities you didn’t have to worry about. And what the IP guys traditionally have done doesn’t work. They pretty much start with the design, replicate one piece of that and assume everything would work. Now you need more detailed analysis. And now the models have to provide different kinds of information so at the subsystem level you can validate that this IP will still work. There are going to be some new models people have to start worrying about. How do you model thermal analysis? What do you need to think about there?
Murphy: That’s going to go to peak power. You have to know about peak power to get accurate thermal states, and that’s not easy.
SE: It’s not just peak power, though. It’s peak power over time, right?
Murphy: Yes. We’ve got average power down, but peak power is much more difficult.
SE: We’ve been used to thinking in very vertical worlds. As we get into the Internet of Things we start seeing convergence of markets with different regulations and peak power. Doesn’t context change?
Sarkar: Yes. If you think of Tesla, which is basically a tablet computer, you don’t have to meet any compliance when you’re designing a tablet. When you design something, are you going to design it for a lifetime where you have to worry about electromigration and thermal issues for all applications? Or are you going to do it application-specific?
Savage: We’re seeing the transition across markets like automotive IP moving into aerospace. And we’re seeing the equivalent of the iPhone on wheels. But there are a bunch of other restrictions on automotive in different countries. With automotive IP you have to worry about frequencies and make sure you stay out of the FM band.
Sarkar: One of our customers was designing six different radios and they put into one chip with a DSP. When you talk about a system, they went to their customer and asked, ‘How are you going to use it?’ So they got the software and the chip and the system guys to work together and they optimized that.
Murphy: There are things like ISO 262 in automotive and other standards are going to add layers of complexity. ISO generally doesn’t say anything about what you specifically have to do, but you have to follow a process. As this becomes more defined, though, particularly around safety and security, you’re going to see more things that will have to go into a chip in one application that won’t necessarily have to go into for other applications.
SE: But it’s also hard to nail down because a weakness in any piece can provide a path to something else if they’re all connected, right?
Smith: Yes. Network security and different levels of subsystems have security for totally different reasons. It’s one thing to make sure you have digital ICE (image correction and enhancement) management, and another to make sure this system isn’t going to get hacked at the hardware level. We’re involved in connecting all this stuff. But we’re dealing with all of these connected domains. Systems companies are focused on their area and we have to learn their language. If you’re talking to a guy doing an automotive part, you have to learn different standards you didn’t work on before. We’re all trying to build parts for different domains. You have to learn the terminology and the rules they play by to figure out what to do. Often you need to do more characterization in a different way. On the security side it’s more straightforward for us because it’s on-chip firewalls. But if we get into a different product domain it’s not so simple.
Savage: The other thing from an IP provider side is that the amount of documentation you have to provide is much higher than it’s ever been. If you can deal with automotive and mil/aero, which is the most demanding, you’ve pretty much got everything covered. Consumer is the least demanding.
To view part one of this roundtable, click here.
To view part two, click here.
[…] To view part three, click here. […]
[…] To view part 2 of this roundtable, click here. To view part 3, click here. […]