Experts at the table, part 1: Decisions about whether to customize vary by market, the size of companies, and in some cases whether off-the-shelf parts are even available.
Semiconductor Engineering sat down to discuss custom designs with Yong Pang, head of North American operations for Imec; Phil Burr, director of portfolio product management for Arm’s embedded and automotive groups; Ambar Sarkar, chief technologist at eInfochips; and John Tinson, vice president of sales at Sondrel. What follows are excerpts of that conversation.
SE: There is a lot more customization and heterogeneity being added into chips than in the past. What’s driving this and what’s changed?
Burr: One of the big drivers here is simply that now you can do this. There’s also a potential cost reduction. We have partners who have seen a 75% reduction in area, a 90% reduction in their bill of materials, and much lower power. And with devices, you have analog right alongside of digital, so custom makes sense there.
Tinson: Cost and size are important and they both have been there for awhile. Power is very important, too. We’re also now dealing with latency. There are other drivers that are arriving as applications evolve, as well. All of that requires a bigger investment, and differentiation is a major justification for that.
Pang: I agree that part of the reason this is happening now is because you can do custom silicon. But the other side is you have to do this. It’s not a good fit for many devices to use off-the-shelf components. You have to customize and optimize for cost, power, and maybe for security.
Sarkar: You could always customize a design, and I agree that it’s easier now. What’s different is there is a better understanding of how to customize in a given time-to-market window. That has improved tremendously. The motivation has stayed the same in terms of power, but now you have no choice. If you didn’t have to, why customize? For the most part, this is still about power and cost.
SE: We are seeing new markets where performance is required, such as artificial intelligence and machine learning. But we also are seeing tightening power budgets, concerns about leakage and more noise with thinner dielectrics. Does custom design solve these issues?
Burr: At much larger geometries like 90nm, the issues we’re dealing today around scaling were not there. Some of these devices are so small and low power that they require dark silicon just because there is no other way. But if you look at our core devices, there are over 3,000 cataloged parts. If there isn’t isn’t a device there that’s pretty close to your requirements, then something is wrong. Custom silicon is much more about adding new features and integrating them into a device.
Tinson: If you don’t want a lot of dark silicon, that puts the onus on the architect to pick the right IPs. And if you want to get better performance, it means they have to be assembled correctly. This is part of the job for the architect.
SE: It’s not just the chip anymore. It’s everything in between, from bandwidth to memory and I/O to how it works in a bigger system. It’s not just one component that’s being customized. It’s lots of different things, right?
Sarkar: Just by controlling this dark silicon you’re adding a lot of value, and you can do with this things like big.LITTLE. But that notion of heterogeneity has been going on for a long time in terms of the libraries you select, the NAND that you use. So there’s this whole notion of being able to scale based on the blocks that you’re targeting. This is a chance for architects to show off their ability to control all of these factors.
Pang: And what we can do today is different from what we could do two years ago. Scaling brought us more choices. That’s a good thing. We can use different processes for different things. That also bring some challenges. This is where system in package or some other advanced packaging can provide different options and different ways forward.
SE: So will dark silicon ever completely disappear?
Sarkar: That’s the goal with custom silicon. You run a CPU or a GPU or an MPU when it’s needed, and they stay silent when they’re not. There’s a big bonus on the software side with power gating, where you can have the software guys turn things on and off. But dark silicon isn’t going away completely. It’s just that you’re not seeing as much of it.
Burr: Dark silicon isn’t something that comes up very often anymore.
SE: One of the problems with custom designs is that in the past they were considered a much more expensive option. Is that changing?
Pang: It depends on what you’re trying to do. Some customization is easy to do. If you move to 16/14/10, the cost goes up big time. There has to be a very good reason for customization at 10nm because there are going to be a lot of tradeoffs.
Tinson: If you’re in cash-flow mode in a startup, you may want to get to market quicker. In that case, you may want to choose a design where a lot of the work already has been done for you. You get to market quicker and you turn that money into a profit. The alternative is to go slower if the goal is less clear and you’re not sure you’re going to be able to make a profit.
Burr: If you have a PCB and you’re spending $2 million a year on an MCU, then you should consider a custom chip. The idea is that if you can put some of these components together, then you can save some costs.
SE: So let’s go back a couple notches here. Is it more expensive to do a custom chip at the same node as a non-custom chip?
Sarkar: It depends how you define expense. NRE is going up. But if look at the business model, it has to work for you. So the short answer is, not really.
Tinson: A lot of that depends upon volume and the IP. You may have savings on a piece part, and that could provide savings. And if you volume is high enough, that will offset your labor.
SE: So you’re looking at total cost of design versus the individual parts that make up that cost, right?
Pang: If a custom design enables you to win a market, or extend a market, or if enables you to cut the cost down because it’s volume-dependent, that makes a difference. If you can reduce the cost of a cell phone by a couple pennies and there are hundreds of millions of these devices sold, that’s a lot of pennies.
SE: Is this market-specific? For example, is it happening in established markets versus new markets where there is nothing out there yet? In IoT, some of this stuff is brand new.
Burr: If you look at mobile and the cost of integration, it wouldn’t happen without custom design. It’s going to be the same with industrial. With IoT, it will almost certainly happen, but people aren’t going to do that with the first iteration of the product. You’d make something using off-the-shelf components like PCBs. You get to market and get some volume, and then you can start to refine it.
Tinson: In automotive we’re seeing a real need for customization. Platforms need to be differentiated. Instructions are being given to the platform providers that they need to customize their silicon for ADAS. Electronics is what differentiates it.
Sarkar: There are some products in the medical field that are being deployed, as well. That’s really where you need customization.
Pang: With newer markets like that there are no off-the-shelf components even available. You have to customize.
There seems to be a wide gap between MCU based and full custom design.
The success of the GPU and heterogeneous implies that a non MCU programmable design would have considerable value.
Intel FPGAs clock at about 1GHz which is respectable, but design at the RTL level is tedious and time consuming.
I am an old logic designer that still considers HDLs to be just description languages. Worse yet synthesis is needed to create netlists before any simulation can be done. And then only a waveform is generated(no functional simulation or debug until a test bench is run against a complete design.
Hardware/system design has always been about connecting functional blocks.
OOP software design is about connecting functional blocks.
AND THERE ARE COMPILERS AND DEBUGGERS FOR OOP.
It is straightforward to define classes that correspond to hardware functional blocks. There is incremental compilation, the compiler resolves the interconnections, and breakpoints so the very basic functions can be observed with minimum effort.