Abstraction: Necessary But Evil

Abstraction allows aspects of a design to be described in an executable form much earlier in the flow. But some abstractions are breaking down, and an increasing amount of lower-level information has to be brought upstream in order to provide estimates that are close enough to reality so informed decisions can be made.

The value of abstractions in design cannot be overstated. High levels of abstraction enable analysis, which includes functional verification, performance evaluation, and power analysis, and they enable earlier development and integration of software. The latest abstraction comes from using transaction-level modeling and languages such as SystemC. Execution times are often orders of magnitude faster than RTL simulation, and significantly faster and cheaper than emulation. What the model lacks in detail is, for the most part, not important.

Put in perspective, without abstraction the electronics industry would still be pushing polygons around and design size would be limited to just a few thousand transistors. It has enabled digital designs to follow . Without it, digital design would have remained roughly on par with analog design, where designs are still small and require specialists to design them.

The breakdown began creeping in with physical synthesis, and it has grown since then. Today, performance and power are greatly impacted by architectural tradeoffs that cannot be accurately estimated without implementation details, often going all the way down to physical design choices.

The industry always has needed to back-annotate data, according to Bryan Bowyer, director of engineering for Calypto. “The cells in a Liberty file are essentially the back-annotation of data based on low-level measurement and spice simulations. The evil part is when back-annotation is not generalized, and each design needs information about itself later in the flow. Even after we generalize the back-annotation flows we use today, new kinds of data will be needed in the future. I expect this problem will be here to stay.”

Amit Nanda, vice president for global marketing at Silvaco, agrees: “Abstraction has always had to be ‘calibrated’ to actual performance. Breaks in abstraction are not a new or temporary phenomena. It’s just that there will be more cases where the breaks cannot be ignored as we get to sub-10nm process nodes.”

Nanda explains that accuracy has to be used selectively, and where it has the greatest impact is where calibration is more critical. “The trick has been to sacrifice accuracy for functional checks, and get very accurate where it matters most, such as power estimation.”

Still, no one is writing off abstractions just yet.

“We do not have a choice when it comes to looking at software running real-world scenarios,” says Krishna Balachandran, product management director at Cadence. “But that does not provide an accurate picture of what happens in the implementation, which is also important. Considering some of those effects up front is important, so it cannot be an either/or, you have to do both. The level of abstraction is necessary in order to be able to run software and to execute a system, and you have to bring forward as much as possible to get as much accuracy as possible.”

The application of these models must be well defined, as well. “We have defined an abstraction level using TLM 2 loosely timed models, and that is holding up for software development,” points out Tom DeSchutter, senior manager for product marketing at Synopsys. “Most of the industry is now providing models for these and customers are becoming increasingly confident in the creation of models for their own IP. The creation of these virtual prototypes is working well for software development.”

But those models may not be the right ones for other tasks. “For tasks such as architectural exploration, power and performance analysis, you are starting to require more information,” continues DeSchutter. “Assuming that you can reuse the same models for multiple tasks is not possible. There is a dedicated abstraction level and set of information for a specific task. The time to market push is causing everyone to shift left and this is what causes the confusion about the abstraction levels breaking. People are trying to do new things and seeing they cannot use the same models and the same information as in the past.”

Balachandran agrees, saying “power estimation is a perfect example of where both abstraction and detail are needed. You must run real system scenarios and you need information about clock trees and what the implementation will do with sizing of the buffers during place and route. All of that information needs to be brought up-front to estimate power. If one of these things is missing, then you will be grossly inaccurate.”

So how is a power model created? “Power, like a lot of ESL technologies, never got off the ground because of a lack of models,” says Drew Wingard, chief technology officer at Sonics. “It isn’t that power modeling is difficult. It is that abstractions of power are not readily available. There is no straightforward method to pull data from a prior chip into an abstract power model for the next design. Coupling that with the fact that power has not been a first-class design consideration means those who have tried to develop methodologies and tools around that have largely failed.”

Questions remain about the amount of accuracy actually needed. “You cannot do absolute power optimization using transaction-level models,” says DeSchutter. “But customers have successfully done relative power optimization using these models. You have to use the right context and looking at power/performance tradeoffs early in the flow with the notion that there is a defined level of inaccuracy and that the trend appears to be quite accurate. If the power decreases in the transaction level, then you can expect a similar decrease relatively in the final chip.”

The industry is fairly unified in the need for virtual prototypes. “How do you get feedback to the architects early enough that they could change the design?” asks Wingard. “How can you feed data into the architectural design process? That is when the design is most fluid and the fewest aspects fixed. The ability for the architect to improve is the highest.”

Having the models is only one piece of a necessary methodology. Those models have to be exercised, and that requires a different model.

A new flow emerges
One technology that is often talked about when considering software verification, performance analysis and power optimization is use-cases or scenarios. The Accellera has been working on standardizing the way in which these are described, but this is only the first step towards defining a methodology.

Consider the virtual prototype. “It is really a methodology for trying to find issues earlier on, but it is not something that provides an automated feedback loop that would help a designer with the design task,” says DeSchutter. “It provides a structure to do simulation, to do analysis and optimization. In the end, it is up to the architect to find the important scenarios that should be focused on to find the worst case conditions.”

But performance optimization is just one task. “Performance is typically driven from a set of worst-case scenarios, not typical use cases,” points out Wingard. “Power is about averages across a set of use cases. With performance, I don’t have to optimize in all modes, only in the top performance modes.”

This is where the holes in the methodology start to become apparent. “If you do not know the scenarios, then you will not find the worst cases,” says Balachandran. “There is no magic to this. There are no tools that can help you find the scenario where the maximum power will be consumed. That has to come from user input. The person designing the chip or system has to anticipate this. This lies on the shoulders of the system designer.”

Even if worst-case scenarios are found, this may not be the ideal input set. “It takes some experience and you need an architect who understands what kind of traffic profiles and what kind of scenarios will run on the end product,” explains DeSchutter. “You have to look at it in the context of the software, but it becomes harder to find the critical use cases. A key piece is to abstract away the software because software makes it hard to isolate the bottlenecks. As an architect you need to focus on the specific traffic patterns that come together in a worst-case scenario. By focusing on the worst case, capturing those scenarios and controlling them individually, you can create the non-ideal environment and look at how that influences power and performance. While you may not optimize for that, you can make sure that the design can handle it.”

So a complete methodology requires the right abstractions for the hardware models, for the input scenarios and for the software.

In block-level verification, the industry developed and promoted pseudo random test pattern generation because it was felt that it was too difficult to come up with all of the right test cases. Automatically creating tests enabled the holes to be filled and more bugs to be found before tape-out. However, when it comes to performance and power, the system designer is still on the hook. There is nothing to help them find the worst-case power, or the energy that will be taken by a certain task, or the highest temperature that any part of the design will reach.

Change makes things worse
As much as the industry likes to concentrate on the new aspects of methodologies, other changes are aggravating the problem.

“Designers are very good at repeating what they did for the last chip, but may not realize the implications of a technology change until something breaks,” says Bowyer. “I have heard some finFET designs run hotter than expected because designers didn’t account for the change in dynamic power consumption. But finFET power consumption is predictable, and these types of problems are at least as much about engineering culture as they are about tool flows.”

Part of the challenge is that these are new technologies with little silicon history. “Heuristics based on prior silicon history for shrinking planar devices helped alleviate fears of migrating to new nodes,” says Nanda. “A whole new 3D device structure with more uncertain MEOL parasitics and no historical data has made the problem scarier. Larger-scale devices, such as SRAMs, have pushed the yield targets for bit cells to the seven sigma levels at sub-16nm nodes. So the problem has become worse. And when a designer does not know where the cliff edge is, it is hard to push design performance. If you have a blindfold on and are feeling your way forward toward a cliff edge, you will take very carefully calibrated steps.”

So while attempts are being made to optimize the architecture, power is still being wasted throughout the flow. “Designers routinely guard-band designs and that is just the way things are done,” says Balachandran. “Nobody has time to tweak the RTL to any great extent. Product cycles are shrinking and this is not an option. There is also a lot of IP reuse, so they take a piece of IP that may not be the best optimized for power. When a new block is added to the design, it can be made power efficient, so the message is that there is hope.”

How much is being left on the table? “Most designs are using about 5% more area and 10% more power than they need to be,” Bowyer estimates. “This cost is closer to 20% area and power for IP that was designed on an older process and is being re-used on a finFET technology. Many designers even expect increase with finFETs, but don’t have time to go back and re-optimize their RTL.”