Abstractions: The Good, Bad And Ugly

Moving to a higher level saves time in most cases, but the pieces don’t always go together as planned.


Raising the level of abstraction has become almost a mantra among chipmakers and tools developers. By moving the vantage point up a couple rungs on the ladder, it’s easier to see how the individual parts of a design go together, to identify problems in the design as well as fixes to problems, and it all can happen much more quickly.

That’s the theory, at least. And in most cases, it’s borne out by the highly history of EDA, which is built on the ability to abstract out problems and automate the results. But as complexity increases inside of SoCs, not all of those abstraction levels connect so easily with each other. The result is that instead of being able to consistently benefit from abstractions, chipmakers are frequently forced down to the least common denominator—sometimes with less than optimal results.

“Right now we have a checklist for signoff and transfer from the customer to the supplier that involves everything from DRC to whether simulation is resolved and clean and we’ve done all the tests, and further upstream there is an even more rigid handoff,” said Mike Gianfagna, vice president of marketing at eSilicon. “The reason is risk reduction, but there’s a big opportunity being left on the table for doing it that way. We answer the question the customer asked us. But what if we answered the question they meant to ask? That would require a well-defined abstraction layer where rather than just constraining the problem we get the customer to help us define it. We’re lacking a good interaction method.”

Where abstractions work
Where higher levels of abstraction do exist—and notably, where engineers use them—they offer enormous savings in time and effort. Electronic-system-level tools are the most obvious example, and ESL springs to mind for many engineers when the subject of raising the abstraction level in design is broached. But abstractions also can be much more basic than that.

Consider, for example, moving a tool from one core to multiple cores. Cadence’s move this week to shift its verification platform from a single core to an SQL database layer that can parse out the different operations and allow multiple users to share information is a less obvious example of abstraction. “For each layer of abstraction you go up, you can increase productivity by 10 times,” said John Brennan, Cadence’s MDV product management director. “In this case, we’ve taken a 13-month verification cycle and reduced it to 5 months.”

Quantifying this, it costs about $38 million to verify an SoC at 40nm. At 20nm, the number is closer to $110 million, said Brennan. Raising the abstraction level in that case has an almost immediate payback for chipmakers.

While verification consumes the lion’s share of time in a design, abstractions are being raised across the design chain, from the initial architecture to the manufacturing and even at the PCB level. In fact, abstractions have become critical at the PCB level, which mirrors the rising complexity of SoCs. PCBs may look rather roomy compared to SoCs, but lines and spaces have decreased from about 250 micron to 50 microns. That makes density, and all the related considerations—signal performance, power distribution, thermal effects and manufacturability—as well as the tradeoffs now critical to the design, according to David Wiens, product manager for the Systems Design Division of Mentor Graphics.

“This used to be a draftsman’s role,” said Wiens. “Now you need to automate a number of tasks and do full system design. You need to optimize the silicon on packages on the board or multiple boards, for cost, performance and size, and you need to understand power and where it is deployed.”

The fusing together of system-level board tools, rather than point tools, is a big shift in this part of the market. In part, it also builds a bridge between layout designers and board engineers, each of which has functioned in different silos. Abstractions can effectively overcome this kind of silo behavior in some cases—but not all. Moreover, they they can be used to make sense of complexity when it becomes too overwhelming, which is one of the big problems in integration of SoCs these days.

“An important obstacle for the integration of application-specific processors is system complexity,” said Eran Briman, vice president of marketing at CEVA. “This includes both integration with multi-level memory hierarchies, as well as integration with CPUs, GPUs and other hardware acceleration blocks. The more specialized processors you have in the system, the more complex is your SoC, and the harder it is to program it. There are multiple industry initiatives that try to standardize and simplify this, such as HSA (Heterogeneous System Architecture). In addition, automatic software offloading tools must be able to take into account such system complexities and completely hide it from developers.”

Where abstractions don’t work
Abstractions help with this complexity. But abstracted tools and code don’t always connect seamlessly with other abstracted tools or code.

“The design verification world has its own approaches to abstraction that don’t always mirror the design world,” said Drew Wingard, CTO at Sonics. “The verification folks have abstractions like UVM methodology and EDA companies love that because they run lots of simulations and sell lots of licenses. But by and large, it’s not design people doing the chip integration. This is like a U-shaped curve, where you have the architects and verification people at the higher levels of abstraction, and everyone else down below. So we start with the architects using TLM and models for automation, but they’re not paying attention to the cores and transactors. Then you go through the core of the design where people do not work at that level. And there is not a flow to describe the design at a high level of abstraction.”

SystemVerilog was supposed to act as a higher-abstraction bridge, but the reality is that more design engineers still work in Verilog than SystemVerilog. So while the abstraction level can work, the reality is that it frequently doesn’t. The same is true with RTL and SystemC.

“We would love to have working industry-level flows to mix and match models,” said Wingard. “But it’s too much work to make SystemC and RTL work in an an open environment. And the requirement in ESL that every has to reach the same level of abstraction is a huge problem. At this point, the only common point is Verilog.”

Even on the verification side things don’t always work as planned. Charlie Kahle, CTO at Synapse Design, said differences in abstractions and translations frequently make it difficult to verify designs. “More and more people are doing their golden reference model using SystemC, but there is a lot of manually intensive verification involved because there are holes in how you verify that. We’re seeing some tools mature, but there are holes in how you verify that.”

Looking to the future
Standards are one way to close some of these gaps. Benoit de Lescure, director of applications engineers at Arteris, said that one of the big problems his company faces is the abstraction level for IP. While standards such as IP-XACT describe the interface, they don’t do anything to abstract out the characterization of that IP.

“The industry needs to go beyond just describing the interfaces at the wire level,” de Lescure said. “There may be three modes of operating for a video card. We need a way to describe how much bandwidth it will need, what the traffic will look like and get the tooling and automation to the next level.”

But even beyond that, most experts agree that the design and IP industry needs to start using tools more consistently. Even if abstraction levels did mesh, the adoption curve for engineers using these tools needs to move forward more quickly than in the past. That will provide the economies of scale and the impetus to develop new standards, new levels of abstraction, and to smooth the transition between all of them. Until then, things are likely to remain in different states of development and abstractions, and a long way from delivering on their full potential.

Leave a Reply

(Note: This name will be displayed publicly)