Taking A Systematic View Of Design Reuse

June 21, 2007
Electronic Design: What's working well in the realm of design reuse? Chris Lennard: A key to this question is the increased emphasis on configurable IP. With configurable IP, there's tighter integration between the tool and the IP itself. It's n

Electronic Design: What's working well in the realm of design reuse?
Chris Lennard: A key to this question is the increased emphasis on configurable IP. With configurable IP, there's tighter integration between the tool and the IP itself. It's no longer feasible to talk about IP outside of the context of the tool framework. IP has to be delivered through a tool that's able to effectively embed it into a context, by which I mean the user's design flow. Or, it has to be something that's specifically packaged for those design flows.

ED: What isn't working for design reuse?
CL: The idea that you can just deliver a piece of IP and hope it'll work in the end environment. When it comes to certain pieces of IP, like a core, for example, the approach is slightly different. But for peripherals or system IP, which are things that will change significantly on a design-by-design basis, the idea of just delivering a single bundle of IP that will work in any environment is more complex.

ED: So what's the answer?
CL: You need two things. One is a way to specify how the IP itself is delivered. And that cannot rely upon a specific methodology that dictates the naming rules, the directory structure, and other attributes. For the smaller blocks of library IP, tools need to talk to each other as they pass the IP around. That's what we're doing with AMBA Designer, in which we're deploying the SPIRIT Consortium's IP-XACT IP export specification (see the figure). With IP-XACT, flows can be set up to integrate into the downstream environment. They can also be built around standards which help limit the customization work needed to link tools.

ED: Sounds almost like a self-configuring environment.
CL: I wouldn't call it self-configuring. Let's say you're moving IP from AMBA Designer to Mentor Graphics' Platform Express. Now, if AMBA Designer had never seen Platform Express before, IP-XACT will set up the structure of the design IP so the downstream tool can load in these materials. That gets you 90% of the way there. But the last 10% is in the bilateral relationship between tools. In our example, there may be elements that are added to this basic framework that are specific to AMBA Designer and recognized inside of Platform Express. These elements would be handed back and forth between those tools and allow a tighter link between them.

ED: So this is where standards come into the picture?
CL: Yes. Standards provide the base integration level so that tools can be linked in a multilateral environment, in a context that's mutually meaningful. Inside of that context, they recognize what the IP is; they can query one another; they can establish a database of changes; and so forth. That is key in a multilateral sense in that all tools in the industry support the majority of that work. But beyond that, we need an environment that encourages innovation. Standards are not areas in which innovation is encouraged. Rather, standards are about making efficient those things that are inefficient in the industry today.

ED: How do we advance the state of the art? What's the next level?
CL: We need tools that can handle this concept of configurability, whether that configurability is for a piece of design IP, or the configuration of that IP so that it can fit into a different environment. That linking of the tools and the expression of the IP is what the state of the art is becoming. Tools and IP are becoming intimately wedded to each other.

ED: What has to happen to the tools and flows themselves to get to that stage?
CL: That comes down to how the tool interprets what it has received. If a tool is instructed to pick up a piece of IP, how does it know what to do with that IP? The answer goes back to IP-XACT and the Eclipse integrated development environment (IDE; www.eclipse.org). Eclipse provides window management and launching of generators through a coherently, consistently managed front end. To shuttle the IP amongst tools, you also need an API so the tools can query one another about their internal states. Then you need full descriptions of the individual component IP blocks, their integration state, and the constraints associated with the design. All of this is in the metadata that's carried in the IP-XACT specification.

ED: When and from whom can we expect improvements in IP reuse?
CL: As a key provider of core-based IP as well as software tools, ARM feels that it's positioned to help to set some of the standards, or the approaches, for design reuse. Combining these concepts together around our primary value, which is delivering architecture, is establishing a new design reuse model in the linking of tools and IP.

About the Author

David Maliniak | MWRF Executive Editor

In his long career in the B2B electronics-industry media, David Maliniak has held editorial roles as both generalist and specialist. As Components Editor and, later, as Editor in Chief of EE Product News, David gained breadth of experience in covering the industry at large. In serving as EDA/Test and Measurement Technology Editor at Electronic Design, he developed deep insight into those complex areas of technology. Most recently, David worked in technical marketing communications at Teledyne LeCroy. David earned a B.A. in journalism at New York University.

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!