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.