Is IP reuse, rather that an ESL, the next level of abstraction for SoC design?

The opening-night Design Automation Conference reception last night featured a panel discussion that faced-off senior design managers against senior marketing folks from the technology infrastructure. (Fair disclosure: the event was sponsored in part by EDN, and I was involved with it.) In the course of the ensuing conversation, the issue of Intellectual Property (IP) reuse came up repeatedly. And that leads me to a speculation.

It has been clear for some time that we need a higher level of abstraction in order to deal with the complexity of modern SoCs. Many in the industry have interpreted this as the need for an Electronic Systems Level (ESL) language—a textual representation of the behavior and structure of an SoC that could both capture the design intent and direct the implementation process. But that ESL has proved hard to find.

It seems to me, based on last night’s conversation, that there are at least two reasons for this. One is novelty. Engineers—always frantically busy–are famous for ignoring a valuable advance that would require them to learn something new. This leads to a paradox: a familiar language will inevitably end up describing either an assembly-language software implementation (if it’s C-like) or an RTL implementation (if it’s Verilog-like) of the design intent, not the design intent itself. A language that would actually describe the intent, or the requirements, would require abstractions with which engineers are not familiar, and syntax so general as to be foreign to non-mathematicians.

The second problem is one of applicability. Both the C-like and Verilog-like attempts at ESLs have proved useful for behavioral or transaction-level (respectively) simulations of an SoC and its functional blocks. But while the facility the higher-level models bring for architectural exploration and functional verification is useful, both approaches have proved impossible to translate into useful RTL netlists for any but a narrow range of architectures. So the system models created at these levels of abstraction remain stranded there. The only way to produce more detailed models for verification or to derive an implementation is to manually redesign based on the high-level code.

So how do design teams increase their level of abstraction during the implementation process? The answer, at least as it emerged last night, is the reuse of IP. System designs are not implemented using textual representations, they are implemented using block diagrams comprising blocks of reusable IP, explored via behavioral views of the IP, and then stitched together using familiar RTL tools. This is the emerging methodology.

It is fraught with problems. As is widely discussed and was discussed again last night, there are all kinds of issues that force design teams to treat IP not as an abstraction but as the packaging around just another RTL or physical block. This undoes most of the benefit gained by the abstraction. Yet the focus of the industry, through organizations such as SPIRIT, the VSIA and the FSA, and through close collaborations between IP vendors and users, is to make the encapsulation of IP as thorough as possible. In effect, we are trying to make IP into a black box from which we can extract whatever view we need for a particular stage in the design process—behavior, transaction, netlist, physical or whatever—when we need it, without opening the box.

The panelists last night warned that encapsulation is a continuing process. Don’t expect it if you are the first to use a new piece of IP—in that case, you are entering a joint development, not an IP reuse. But as IP is more often reused, it gets more completely encapsulated, until for a commodity IP block it is reasonable to expect that you’ll never have to see the code. Perhaps this will be part of the new level of abstraction we’ve been looking for. The next step will be design management tools that can similarly encapsulate the work that goes on in a joint development.

Continues with "Searching for a new SoC abstraction, part 2: verification" >>