| |
|
|
 |
| |
 | |  | | | | | Interview: Logic Designers Get Physical
Matt Rardon
Cadence Design Systems | |
| |  | |  |
Interview with Matt Rardon, Cadence: Logic Designers Get Physical
Cdnusers interviewed Matt Rardon, Sr. Member of Consulting Staff, Cadence. Prior to joining Cadence seven years ago, Matt was an ASIC logic designer for several large electronics companies. Throughout his career, he has focused on physical synthesis.
cdnusers: Matt, why is physical predictability important for logic designers?
Matt: It’s important because without physical predictability logic designers and chip implementers spend a huge amount of time iterating on a design. Using a traditional silo design approach, these designers sit on different sides of the design “wall” without a lot of communication.
cdnusers: Give us an example.
Matt: For one, after a logic designer completes synthesis using wireload models—or some other form of estimation—he/she passes the design “over the wall” to an implementation engineer. Then, the logic designer waits for the physical information to be lobbed back over the wall before he/she gets to see how the design will perform once placed and routed. Unfortunately, the results that come back are often quite different than the design performance that the logic designer saw when using wireloads so, now, he/she has to do some incremental optimization.
cdnusers: You said the designers involved spend a “huge amount of time iterating on a design.” Can you talk more about why?
Matt : Using the example I just gave, the logic designer is going to try to optimize the design with limited physical information, knowing that limited information is static—it is really only valid for one snapshot of the design and once changed, it is stale. But, it’s all the designer has to work with. Then, after design performance goals are met the designer will again pass the design back to the chip engineer and let he/she update it. This iterative process continues until the performance goals are achieved—a huge time sink.
In the real world, of course, many logic designers try to overcome this iterative process by building more margin into their design constraints. However well intended, this is a blind approach since not every path will be affected in the same way once the physical effects are considered. It’s really a heavy-handed approach and results in an unnecessarily large area and unnecessarily high power consumption.
cdnusers: True, but this problem has been around for a number of years, how is the challenge different today than in the past?
Matt: While the fundamental challenge is really the same—the logic designer is still wondering how the design is going to perform in the physical domain—today’s designs are far more complex, creating new problems. First, wire delay has become more and more important. It can’t be ignored and it must be accurately modeled to be of any use. A bad model can be just as bad as no model at all. Second, physical effects are more challenging to model because the processes have shrunk and manufacturing concerns have become much more important. Third, consumer demand for portable products has made power critically important. And, as designers are well aware, power, like physical effects, must be accounted for throughout the logic design process—concurrently with the physical effects.
cdnusers: What’s the answer?
Matt : The answer goes back to the question: Why is physical predictability important for logic designers? Because, if logic designers had physical predictability, they would have a peek at the design performance considering physical processes such as placement and routing without the need to pass the design over the wall. They would have an early look at the design before they had to involve the implementation engineer.
This “sneak peek” would allow the logic designer to generate the best netlist for physical implementation before passing the design to the chip engineer the first time. The result is less iterations and faster time to closure.
cdnusers: For RTL designers, what is the significance of being able to design with physical predictability in mind?
Matt : Let’s look at the process. Most approaches to physical predictability start with a synthesized netlist. In truth, this is really already too late. Waiting until the gates are available to consider physical effects isn’t the best approach because fundamental architecture mapping decisions have already been made. Everything is pretty much set. You can only make incremental changes—big changes can be only made from the RTL starting point.
Ideally, you want to consider physical effects when you start the RTL—when comparing different architectures and mapping them to the technology library. This would be especially beneficial when generating initial constraints. By having an estimation of physical effects available when logic designers are laying out a design and exploring the avenues that may actually be committed to the design, they could see how those different approaches would turn out in the physical domain as opposed to having to generate the true netlist before they can get any idea of that.
cdnusers: This all makes sense. How is Cadence addressing the problem of physical predictability?
Matt : Cadence is taking what we think is a novel approach. While we are using proven technologies, everything is being used in a new way. This is important because logic designers have unique work flows and unique approaches to tool use. Synthesis is considered to be an iterative batch process; in order to be successful, any approach to physical predictability must be a primarily hands-off process, and it must be fast.
When logic designers are working to generate an RTL, they are exploring different avenues. They want fast turnaround times so they can evaluate their options. The Cadence approach addresses this by using various levels of abstraction of the physical data and only considers the physical data necessary at a given stage. Stated in a different way, more abstract information is used early in the synthesis flow when run time and iterations are an important concern. More detailed information is used later in the synthesis flow when final closure is an important concern.
This is a tricky balance, of course, since abstraction must be done in such a way that the information remains as representative of the physical effects as possible—you can’t abstract it so much that it’s not useful or it’s misleading. Also, data presentation is important for logic designers because they don’t need to be concerned with the full scope of information that is available during the physical information process. They don’t want, or need, a back end tool. The beauty of the Cadence solution is that it only presents the information that is useful and helpful to the logic designer.
Key technologies in the solution are the physical layout estimator (PLE) and QoS Prediction. PLE is used to abstract the placement and routing process to generate a high quality netlist. It can be used with the RTL; it does not require gates. QoS prediction uses a lesser degree of abstraction to present the logic designer with a view of the design that considers detailed physical effects. This can be thought of as a logic-design-focused silicon virtual prototype.
cdnusers: Silicon virtual prototype?
Matt: The silicon virtual prototype that we use leverages existing Encounter silicon virtual prototyping technology. We just present the results in a different way so they are easier for logic designers to use. Designers don’t have to get bogged down with all of the physical implementation tasks just to generate a silicon virtual prototype..
cdnusers: How easy, or difficult, are the PLE and QoS Prediction technologies you mentioned to run?
Matt : They are really very simple. You just add a few more things to your existing scripts. For example, you include the physical libraries that are available from your foundries. Just load them in with your timing libraries. Then, you load the floor plan to help direct the process. Synthesize as you normally would. This uses the PLE to full advantage.
Once you are happy with the initial synthesis results, use QoS Prediction to see how the results look in the physical domain. Then, you can do analysis, or you can do more optimization until you get the design into the shape that you want it to be in to go into full physical implementation.
cdnusers: One final question: What can a logic designer do with the results of QoS Prediction?
Matt : He/she can use the analysis capabilities that are available inside RTL compiler to figure out what the cause of a problem is—is it a path that has a really long net on it? If so, maybe he/she can work with the physical implementation engineer to make changes to the floor plan. Or, if it is a path that has a lot of logic on it, he/she can go back and take a look at the RTL and see if it can be recoded differently to get a tighter logical path.
It depends on what the individual problems are, but since logic designers are in their synthesis environment, they can get to the bottom of it and make the necessary changes without having to pass things back and forth “over the wall” numerous times to isolate what the root cause of a problem really is.
cdnusers:Thank you, Matt.
| 
About the author
Matt Rardon has worked at Cadence since 2000 as Application Engineer, Core Comp Engineer, Product Engineer and currently as Senior Member of Consulting Staff. Matt is a Hoosier, graduating from Purdue University with a BSEE in 1996. Prior to coming to Cadence, Matt worked at Texas Instruments as an ASIC designer, at Alcatel as an ASIC designer, and at Intrinsix as a consultant. Matt is married with a 16 month old daughter and enjoys photography. |
| |
This content has not yet been rated by other users |
|
|
|
|
|
|
|
|
|
|
| |
|
|
|