Get In The Spirit Of IP Reuse

April 14, 2005
Anyone embarking on an SoC design knows that the job involves stitching together relatively large blocks of IP. That may sound like a relatively easy task, but anyone in-the-know will tell you it's not. Integrating IP unleashes a host of difficulties, n

Anyone embarking on an SoC design knows that the job involves stitching together relatively large blocks of IP. That may sound like a relatively easy task, but anyone in-the-know will tell you it's not. Integrating IP unleashes a host of difficulties, not the least of which is coercing any given design methodology to seamlessly handle any given piece of IP. But an industry consortium, formed just two years ago, is making headway toward solving this difficult problem.

Despite its unwieldy moniker, "Structure for Packaging, Integrating and Re-using IP within Tool-flows," or Spirit, the group was assembled to address a specific technical issue. "The key reason for the formation of Spirit was a sense of frustration in the industry about how to use the advanced system-level tools to the best advantage," says Chris Lennard, technical chair of the Spirit Consortium and a technical marketing manager at ARM.

"In the late 1990s, we began seeing system-level tools emerge with a lot of capabilities," says Lennard. The big problem for ARM, as an IP provider, was that any given piece of IP had to be personalized to work with these tools. Lennard and collaborators at Philips realized that rather than make the IP fit each design-flow scenario, it's best to standardize all IP in terms of how it fits into flows. Spirit was formed to develop a standard method of packaging IP.

"What we based our approach on is eXtensible Markup Language (XML) metadata that's packaged with the IP to express design intent," says Lennard. "The metadata is a machine-interpretable way to relate a design specification to a design implementation. For example, the metadata might describe how the Verilog signal list of a piece of design IP describes a bus interface."

These metadata descriptions are applicable to both new and legacy IP. They don't impose or enforce any design style on the IP authors. The descriptions themselves are created while IP blocks are imported into Spirit-compliant SoC design tools. "The largest contribution to the foundations of Spirit was Mentor Graphics' donation of their IP schema," says Lennard.

Spirit-compliant IP actually makes quite a profound impact on an SoC design flow (see the figure). "Previously, these SystemC-based ESL tools existed effectively in isolation," says Lennard. But at this year's DATE, ARM showed how its MaxSim ESL tool could execute handoff of Spirit-compliant IP to Synopsys' CoreAssembler tool.

"We're trying to build an SoC infrastructure in which you build up the configuration for your IP," says Lennard. "And then you can hand that IP over to an RTL tool that recognizes the IP, recognizes its configuration, and can stitch it together for you in the same fashion in which you played with it in your SystemC exploration environment."

The ability for Spirit-compliant IP to move from a SystemC exploration environment into hardware/software co-verification and synthesis is crucial. But just as crucial, if not more so, is the ability for Spirit-compliant EDA tools to both import and export full Spirit descriptions.

SCARING UP SUPPORT Support for Spirit is growing within the industry. Besides ARM and Philips, the consortium's key members include Cadence, Mentor Graphics, and Synopsys. In terms of available Spirit-compliant IP, ARM itself has yet to officially announce compliant products. But according to Lennard, ARM encapsulated the full PrimeXsys 926 platform with Spirit metadata, as well as the PrimeXsys 1176 platform.

Synopsys announced support for the Spirit 1.0 specification in its CoreAssembler tool. Mentor's Platform Express also can handle Spirit-based IP. At DATE, a number of vendors, including ARM, Beach Solutions, Cadence/CoWare, Design and Reuse, Mentor Graphics, Prosilog, and Synopsys, demonstrated Spirit-compliant IP and tools in practical application.

At DAC, the consortium will announce version 1.1 of the specification, which will add timing constraints for synthesis, as well as the alpha version of the Spirit 2.0 specification. The 2.0 release will add extensions to address the concepts of verification and transactional IP that's becoming more popular in the ESL world.

On top of that, by the time DAC rolls around, the consortium will announce its plans of taking the Spirit specification through one of the existing standards bodies, such as the IEEE.

Sponsored Recommendations

Design AI / ML Applications the Easy Way

March 29, 2024
The AI engineering team provides an overview and project examples of the complete reference solutions based on RA MCUs that are designed for easy integration of AI/ML technology...

Ultra-low Power 48 MHz MCU with Renesas RISC-V CPU Core

March 29, 2024
The industrys first general purpose 32-bit RISC-V MCUs are built with an internally developed CPU core and let embedded system designers develop a wide range of power-conscious...

Asset Management Recognition Demo AI / ML Kit

March 29, 2024
See how to use the scalable Renesas AI Kits to evaluate and test the application examples and develop your own solutions using Reality AI Tools or other available ecosystem and...

RISC-V Unleashes Your Imagination

March 29, 2024
Learn how the R9A02G021 general-purpose MCU with a RISC-V CPU core is designed to address a broad spectrum of energy-efficient, mixed-signal applications.

Comments

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