Edgar was seldom in the office – even before the current trends in telecommuting and working from home exploded. He’d waltz through the cube aisles looking important at least once or twice per week – tossing a gigantic notebook with DRAFT stamped on the top onto the desk of some unsuspecting victim. The target would immediately activate his defenses – talking about how he was behind on his part of the project and was almost critical path right now. Edgar wasn’t fazed. Sure, reviewing this draft of the spec might impact this one project at this one company – but Edgar was in this for the Greater Good. Edgar was a big picture guy – no, more than that. Edgar was a chronic career committee member.
Every engineering organization has at least one Edgar – the engineer that volunteers for every consortium and “working group” that comes along. Most of these efforts will go nowhere – and that’s just the way Edgar likes it. Specifications will be reviewed and modified in perpetuity. Power struggles will ensue amongst idealistically opposing factions debating semantics of corner cases that no real-world scenario will ever see, and corporate one-upsmen will work to be sure that nothing happens that will compromise competitive advantage or benefit a rival. However, the boondoggle bonanzas that are associated with most of these ill-fated standardization efforts keep the Edgars of the world coming back for more – perhaps even dragging their feet a bit in order to maximize the meals, airfares, and hotel stays consumed on expense account, all while conveniently avoiding most of the real work back at the ranch.
Occasionally, however, we need some of these efforts to accomplish something that will actually benefit the industry. When it comes to SoC design, nothing is more important in enabling productivity, reducing risk, and simplifying verification than the use of standardized, pre-engineered, proven IP blocks and subsystems. Unfortunately, with IP coming from a wide variety of sources – many of whom are highly competitive and proprietary, the idea of standardization hasn’t caught on too quickly. Events like the recent demise of even well-conceived operations like the VSI Alliance (VSIA) take hope down another notch still. Last July, VSIA announced it was closing down, making provisions for its existing standards to be taken over and consolidated by other industry organizations.
There are, however, a couple of stand-out efforts that apparently our dear Edgar missed out on. These bodies have actually produced standards that companies are adopting and that engineering teams are using productively in SoC design. IP-XACT is a standard from The SPIRIT Consortium that enables complex IP from disparate sources to be easily incorporated into a wide variety of SoC designs and design tool flows. In order for IP to be realistically used and re-used, it needs to be compatible with a variety of design tools and design flows from the major EDA vendors. The key to the success of IP-XACT may be its generator-centric architecture. Because of this architecture, tool vendors can extract and optimize the information needed by their particular applications without re-architecting their tools to support a new standard natively.
The founding companies realized that they would never be likely to share the level of proprietary data needed to make their tools support common native data models, and they didn’t like the idea of giving up the flexibility to add differentiating capabilities that might affect their data model itself. By adopting a meta-data/generator approach, they built a competitive firewall through which they apparently believed IP could pass but their proprietary tool technologies could not. Recently, The SPIRIT Consortium released version 1.4 of their specification, which includes additional capability to support transaction-level modeling.
IP-XACT is centered on an XML meta-data description called a “component.” It contains a structural description, the interfaces, and references to all of the IP views. To create a nested hierarchy, components are collected into a “design,” the design is configured via a configuration object, and that design itself can then be instantiated or referenced as a component.
Interconnects are specified by bus definitions. Bus definitions contain wire-level and bundle-level specifications that determine what components can be interconnected. Bus definitions include classifications like master, slave, system-level, and monitor, and bus definitions can be derived from other bus definitions. Commonality in bus definitions determines whether and how two components are legal to interconnect.
In the 1.4 release, abstraction definitions were added to facilitate ESL or transaction-level design. Transactional interfaces support function calls across the interface. An abstractor in each object handles the mapping between wire models and function call models to allow mixing of objects at various levels of abstraction in a single design.
All these models can be assembled and configured in an IP-XACT compliant design environment. Such an environment is the hub where the top-level model of your system is defined before it is passed on to your automated EDA tool chain. This is where the generator-based architecture of IP-XACT kicks in. IP-XACT includes two levels of API that allow compliant tools to integrate – a loose generator interface (LGI) and a tight generator interface (TGI). The LGI simply allows meta-data to be dumped for consumption by compliant tools. The TGI allows direct database query and modification for tools that need, like the name says, a tighter connection.
For any particular tool or flow, a generator is developed based on the TGI. The generator talks across the TGI in an environment, language, and location-independent manner. Location independence allows data that is remotely located to be accessed by a link to an executable via URL so a remote server can supply deliverables such as licensed content. Generators can be clustered into chains so that multiple generators can be singly invoked.
IP-XACT is a boon for IP providers, particularly those creating IP for commercial sale and use, because it gives a neutral framework for IP development that’s independent of the vagaries and specifics of proprietary EDA tools. It enables development of IP that can be used across various mixed-vendor tool chains and with various source design languages. It also allows aggregation of IP into larger, pre-verified, subsystem-level blocks, facilitating design at a much higher level of abstraction, where the productivity benefits of IP-based design are greatest, and where the potential differentiated value of commercial IP can best be realized.
As Edgar could probably tell you, standards are never any good until an ecosystem of companies willing to support them grows around them. This is where SPIRIT shines. With a firm foundation of the “big three” EDA companies – Mentor, Synopsys, and Cadence, plus an A-list of IP, semiconductor, and systems houses like ARM, Freescale, LSI, NXP, ST, and TI as board members, there is sufficient industry mass to actually make things happen.
If your organization wants to get started with IP-XACT without having to sequester your team for weeks while they consume and absorb the entire 350-page standard, there is even a Quick Start available that walks through the major concepts and use cases with a fairly simple step-by-step how-to approach for the most common tasks.
While IP-XACT may not please the Edgar on your team, it may help you get a lot more work done in a shorter amount of time, particularly with the new 1.4 transaction-level support. IP-XACT is a standard that is conceived (refreshingly) in a way that closely reflects the way many teams actually do design work and protects the way that EDA and IP companies need to operate to be competitive and protect their proprietary technologies. We could use a few more standards like this.
