Experts At The Table: Changing Design
By Ed Sperling
System-Level Design sat down to discuss the changing design landscape with Juan Rey, senior director of engineering for Calibre in Mentor Graphics’ Design to Silicon Division; Michael McNamara, vice president and general manager of Cadence’s System-Level Division; Yervant Zorian, chief architect at Synopsys; Prasad Subramaniam, vice president of design technology at eSilicon; and Ravi Varadarajan, an Atrenta fellow. What follows are excerpts of that conversation.
SLD: What’s changing in design?
McNamara: Software is a component that can’t be ignored anymore. It can’t be done later in the design cycle. The hardware-software co-design is a real problem—and a real opportunity. When you look at battery life, often it’s the software that has to be fixed. It isn’t the hardware. The software is now smarter and does more.
Subramaniam: As you go into smaller geometries you have more choices in terms of technology and complexity. There are more variables in the technology, different libraries that are available, more choices in terms of transistor Vt and channel length. If you look at the combination of what’s available to do a design, finding the optimal point in your design optimization is key. How do you optimize for power, performance and area all at the same time. Many people only see a small portion of the design space that’s available to them, but while it may be good enough for them it may not be the optimal solution.
Varadarajan: What’s changed is the increasing commonality between SoCs today. You see an ARM core, a GPU from ARM or Imagination, and DDRs. The challenge is how to improve the turnaround time for closure. These designs undergo a lot of derivatives over their lifespan, which are incremental changes. The real challenge is how you can close on a new derivative in 10% to 15% of the time it took to do the original design. What can you capture to achieve closure at the front end so every single design is not a complex back-end-to-front-end netlist handoff process? There are some customers going down that path already, putting in methodologies and mechanisms to ease that process.
Rey: There are a lot of tendencies and trends that require the tools to be faster and have new functionality, and the designers need to be aware of that to get an edge over their competition. In addition to that, there is also a need for portability. People don’t want to be tied to a single semiconductor manufacturer. They want more than one source. Designers need to be aware of that and be able to port their design to different places, and the tools need to be able to play in more than one place at the same level.
Zorian: There are two things going on. One is that complexity is going up, and the other is that shrinkage continues. On the complexity side IP usage is going up. It’s now 70% to 90% of a chip. But if you look at vertical markets, IP is not enough. These need to be grouped together into subsystems to improve re-use and reduce design time. On the shrinkage side, maintaining the health of the chip is a problem. The more we shrink, the more important our yields, quality, reliability and testability. We need to ensure those capabilities are available early on in our IP and our subsystems. You have placeholders, so as you move down you can shrink while maintaining the health of the chip.
SLD: How do we deal with all of this complexity? Is it a matter of raising the abstraction or do we need to deal with the problem differently?
Varadarajan: Abstraction is the key message. If you look at all the advancement over 20 years, physical synthesis still closes timing at the cell level. It places and routes standard cells and finally signs off on timing at the standard-cell level. That’s what designers trust, and it has to go down to that level today. Being able to have enough confidence at a higher level of abstraction and having global design closure with confidence is essential. Being able to predictably create subsystems and validate timing closure at that level, before you descend into the detailed implementation is essential.
Subramaniam: Abstraction alone is not enough. What you need in addition to that is an actual implementation of that abstraction. One of the reasons IP re-use has been successful, particularly in the analog and mixed-signal area, is that you have the abstraction and the actual implementation. You know that when you implement something it’s going to work. We need to extend that to the subsystem level. Today we have it at the individual IP block level. We don’t have it at the level of the subsystem. We need to create hardened or quasi-hardened models, so you can have an abstract view of that subsystem and also know how it will behave. You know its performance characteristics, its power characteristics and all the other critical characteristics. In 3D ICs, you might have pre-implemented version of subsystems that you can simply drop in. That makes derivatives simple. You have a common subsystem with a standard interface. It allows the designer to focus on one portion of a design, no matter what the technology node.
Zorian: I agree that having abstraction isn’t sufficient. You also need the ability to explore the different options and optimize between them. You need automation capabilities to explore those options and see what the best choices are. It may be 2D or it may be 3D. But with designs today you have so many ways of optimizing them. To explore that is very important.
Rey: On the implementation side, historically there were not robust methods to keep the abstraction level all the way down to the implementation. That is changing. You come up with IP, you know where you can stretch the limits of implementation, and you need to get those details down to the implementation. The foundries are jumping into that. It’s becoming mainstream. Think about keeping several different power domains. You need to make sure information moves all the way from the system level to GDS II to ensure you are not crossing from one power domain to another without the proper protection. That’s happening now.
McNamara: At each design level we need some way of modeling the design. Then we need a way of verifying the design is behaving the way we think it should behave, whether it’s functional or electrical. There’s a transformation stage, which we call synthesis, where you take that abstraction level and push it down to the next level, whether that’s RTL to gates to polygons. And then you have an analysis or extraction phase that takes information from that level and projects it up to a higher level of abstraction. We’ve all built tools that do pieces of that. But if we want to raise it to a higher level of abstraction we need to have a modeling language and a way of transforming it to the lower levels and abstracting information up. There is a system above every design node that just considers us as a component. That plays all the way from the transistor to the macro cell and up. As we look at increasing complexity, we have to tame this. We need a way of bounding these things and putting rules around them so the higher levels can abstract away that detail but also take advantage of the power. If you have too firm a rule that doesn’t let you take advantage of what the power can do, then you’re leaving performance, area or power on the table. It helps to think of this in four boxes. Do we have a modeling language? Do we have a way of verifying it’s correct. Do we have a way of projecting it to the lower level? And do we have a way of abstracting things up to a higher level?
Subramaniam: The modeling language should be able to address all the key attributes of the design. You need to be able to define a set of metrics for every design, and then you need to be able to look at all the different alternatives that are available for that design and translate each of those implementations into the metrics. Now, when you’re in the exploration phase, you can take a particular design and if you use this combination of transistors or this process from this foundry, what does it look like? That’s really critical as part of the exploration phase. Both tools and language are required for this exploration phase.
SLD: Is there a language that does this?
Zorian: We are going up in abstraction. TLM is a high-level description. That same IP has multiple levels of description. But what is being shared for exploration purposes is a transaction-level model. Once you decide to use it, you go down to the detailed models. But there’s a good exchange of information at that level.
Tags: Atrenta, eSilicon, Mentor Graphics, Synopsys Cadence