Semiconductor Engineering sat down to discuss what’s changing on the leading edge of design, and what’s needed to support those changes, with Bari Biswas, senior vice president for the Silicon Realization Group at Synopsys; Michael Jackson, corporate vice president for R&D at Cadence; Prashant Varshney, head of product for Microsoft Azure; Rob Aitken (Arm fellow at the time of this panel, now distinguished architect at Synopsys); and Mohamed Elmalaki senior principal engineer at Intel.
SE: Most of the gains are coming from architectures in terms of PPA. Packaging is really important, and so are materials. We are seeing fundamental changes in chip design. What’s needed from the EDA tool side to make this work, and how is that different from today?
Biswas: The future of chips is heterogeneous. Along with the customization done by product teams and design houses, many of the designs are going down to a few nanometers, and that’s an extremely costly proposition. The IC design itself is becoming multi-dimensional — multi-die, multi-process technology nodes, assembled together. Some of them are new, some of them are re-used from previous generations. In addition to the traditional IC designers, we are seeing more people from a system background doing these types of heterogeneous chips. For the EDA companies, this is both a challenge and an opportunity. It’s a challenge because you need to think of a solution from the ground up, making sure all the needs of a system designer will be there. The design environment should be seamless, going from 2D to 3D. It should share some of the infrastructure and data models we have developed in the 2D space with 2.5D and 3D stacks. And it should allow architectural exploration at the system level and address the scalability. Right now, we might be talking about 5 or 10 dies together. We need to build a system that will allow scalability up to hundreds of dies, and then deal with the connections that are between the systems. We are seeing some of these protocols or standards for those connections emerging very recently. These are the key challenges and requirements. In addition, and very important, analysis is being done as part of the EDA solution cycle. This is necessary for a comprehensive, ground-up type of design.
Jackson: Today, designs already are being done for 2.5D and 3D-ICs. In the future, we will be designing ones that will be even more complex. For an EDA solution, you need a burst of capabilities that span all the way through the physical implementation of 2.5D and 3D-IC systems. There are different types of analysis that will be needed, along with connections with packaging and co-design. You also need to be able to do design planning for these systems — and they are systems because you’re bringing together different dies or chiplets. You need to be able to do multi-design planning, dealing with things like die placement and bump planning. And you need a single database. Many of these systems will be heterogeneous, not only in terms of the type of fabric — they may have RF sensors and digital — but also in terms of the process technologies that are represented. These systems are going to be big. They’re going to push the complexity envelope. There are needs for high-capacity analysis for power, thermal, 3D static timing, cross-domain ECO, and then there is the whole functional verification side. Much of this is an evolution of existing capabilities, adding dimensions and being able to deal with the complexities. Today, these designs primarily are being done by IDMs. There are initiatives in the industry today to support the reuse of chiplets, which will require some level of standardization. This is similar to the standardization efforts for single dies, but with extensions to multi-die configurations. That will open the door for companies to supply chiplets for others to integrate. But in addition, there’s always a role for custom silicon.
Fig. 1: Chiplet concept using heterogeneous dies in a package. Source: Cadence
Lee: There are continuing challenges with new process nodes — particularly with a reticle-sized die, like an AI chip, that uses the full extent of a single die. Now, as we look at integrating multiple die using interposers, or stacking die, the problems become much larger. These are early days for this approach. We have customers doing 2.5D and 3D, but it’s just at the beginning of this shift. The tooling and methodologies are new. It requires close cooperation between EDA companies and the end customers. The lines between systems and silicon have blurred. Before, you had the heterogeneous capability through multiple chips and multiple packages on a PCB. Now, we’re able to integrate those all into a single package. So before, you had a system designer looking at electromagnetics, or system or thermal integrity. All those analyses now need to be done in the context of multiple die. The challenge is that you have traditional chip designers, who are used to EDA workflows, but now we need to bring in a thermal analysis team and a magnetics analysis team. New methods, tools and physics need to be brought into this 3D-IC workflow. It’s a challenge as well as an opportunity. When we look back in three years, we will be able to say, ‘Now we have a better understanding of how this should be done.’
SE: Where does the cloud fit into this picture?
Varshney: If you just rewind a few years, back in 2018 TSMC announced a cloud alliance. At the time, they said they were moving their 5nm simulation to the cloud. That was proof for the industry that the security and performance the cloud offers are there, and it spurred a lot of momentum and interest in cloud. In 2020 and 2021, people were trying things out. They said, ‘It sounds interesting and looks promising. Let’s see if the security audits and the performance are in line with what we need.’ They’re done with that now, and as we look from mid-2021 until now, they’re starting to make decisions about how to migrate to the cloud. The change is happening. At the moment, many customers are looking at a three- to five-year plan for how they can move everything into the cloud. If you’re looking at 5nm simulation, or any SoC in general, it takes 5X to 10X the hardware resources to be able to do that versus a 16/14nm chip. There are huge resource requirements, and getting down to these new nodes, everyone is struggling to figure out how to augment their capacity in data centers. But that’s not possible. You have to create a new data center. You cannot add capacity anymore. So people have to decide, if the cloud performance and security work, is that a viable solution? The industry is at the cusp of making that decision. Right now, cloud for the EDA industry is in the low single digits. But it is seeing rapid adoption. There will be some on-premises data, which has to be on-prem, but a large set of work will be moving into the cloud.
SE: What’s need in the toolchain that isn’t there today?
Aitken: There’s a need for tools that operate across multi-die solutions, and not just take them into account to say, ‘I have this here and that there.’ You need to be able to co-optimize things. ‘How should I partition my design? What level of this should go here? What should go there? Other than using an Excel spreadsheet or PowerPoint, how do I figure out what is an optimal way of doing this?’ That’s a chicken-and-egg thing, from a supplier and a company standpoint. How do we know what the partitions will look like? Well, we don’t because we’re not entirely sure what the 3D technology is supposed to be, and we don’t know what the boundary is. How do we create an abstraction of a chiplet that’s stable across design in the same way as a SPICE model or a standard cell library. It’s an abstraction that you can literally go to the bank with and say, ‘If the silicon meets this, it’s good. If it doesn’t, then it’s a problem for the manufacturer of the silicon.’ If the design doesn’t work, and the SPICE model says it shouldn’t work, that’s the designer’s problem. If the SPICE model says it should work, that’s the foundry’s problem. There isn’t that level of a boundary yet, which is why so far we’ve seen the same company on both sides of the interface. That’s the only way you can manage it. But if you’re going to have a chiplet ecosystem where there are multiple companies — somebody supplies a chiplet that does this, somebody else supplies a chiplet that does that — what is the level of abstraction that allows you to work with that and create a system? The tools that define that abstraction, and then to be able to use it, are missing at the moment.
Elmalaki: We’re not seeing a specific tool missing. Some of the modeling has been an issue, and that can be improved. We have designs where we have chips from TSMC or Samsung and Intel all going into the same package. Different companies have different packaging solutions for chiplet assembly, and interfacing between chiplets, which creates a challenge. We need innovation in terms of compression and how we transfer data. And things like clocking and DFx for chiplets would be very helpful. The CXL standard is promising. It’s being used a lot. But there’s a need for abstraction above the chiplet connection. The EDA part is not the most challenging. The software that runs across heterogeneous chips is one of the most challenging areas for the industry as a whole. We’ve come a long way over the past two or three years for how we assemble chiplets in a package. We haven’t seen the same improvements on the software side.
SE: So what do these heterogeneous packages look like in the future? Are they collections of standard IP, semi-standard hard IP, or is everything custom?
Elmalaki: At a high level, there’s a regular cycle. A workload comes in, and we build very custom accelerators for that. Then it goes from very custom, purpose-built to general-purpose. The best example involves AI. We have a lot of small, custom accelerators for AI workloads. We are building custom chips for it, but we could see a shift toward general-purpose CPUs and GPUs as our code stabilizes and people rely less on fixed functions. You’ll always have purpose-built and general-purpose chips. The question is how much of one do you need versus the other. In the future there will be a mix.
Aitkin: If you look at the history of IP 20 years ago, there was a question of whether we should have hard IP blocks, which are effectively GDS that you drop into a chip, or whether we should we have soft IP that is synthesized into a fabric. Those evolved over time into soft IP that was built according to a recipe, because that was the most economically sensible way to get things into large chips. When you switch to multi-die, that decision might change. It might make more sense to shift to hard IP, which is essentially what a chiplet would be. You would lose the flexibility. Say you had a multi-processor, where you could dial in that you want 4 cores, 16 cores, or 32 cores, and you want them on a little block that will plug into your system. The challenge is defining what that block is, and how it connects to the rest of the system. If we could come up with a standardized way of building such things for them to communicate and connect to broad-based systems, that would simplify a lot of the design effort. Today you have huge amounts of effort going into verification. If that chiplet is pre-defined, pre-characterized, and pre-verified, you don’t need to do that anymore. But you do lose the flexibility of, ‘Oh, I changed my mind. Sixteen cores isn’t enough. I wanted 24.’ Or, maybe if the boundaries are defined on the edge, maybe you could swap that in later. If you can get all of the standards and solve all of the packaging constraints, thermal constraints, and die ownership issues, then that opens up a path for a chiplet ecosystem. But getting it to work involves giving up a certain amount of flexibility in return for predictability, and hopefully some cost savings. There’s definitely a possibility for that to exist, but there are a few problems to solve first.
