feature article
Subscribe Now

The Spirit of Standardization

IP Re-use Takes Center Stage

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.

Leave a Reply

featured blogs
Jul 3, 2020
[From the last episode: We looked at CNNs for vision as well as other neural networks for other applications.] We'€™re going to take a quick detour into math today. For those of you that have done advanced math, this may be a review, or it might even seem to be talking down...
Jul 2, 2020
Using the bitwise operators in general -- and employing them to perform masking, bit testing, and bit setting/clearing operations in particular -- can be extremely efficacious....
Jul 2, 2020
In June, we continued to upgrade several key pieces of content across the website, including more interactive product explorers on several pages and a homepage refresh. We also made a significant update to our product pages which allows logged-in users to see customer-specifi...

Featured Video

Product Update: Advances in DesignWare Die-to-Die PHY IP

Sponsored by Synopsys

Hear the latest about Synopsys' DesignWare Die-to-Die PHY IP for SerDes-based 112G USR/XSR and parallel-based HBI interfaces. The IP, available in advanced FinFET processes, addresses the power, bandwidth, and latency requirements of high-performance computing SoCs targeting hyperscale data center, AI, and networking applications.

Click here for more information about DesignWare Die-to-Die PHY IP Solutions

Featured Paper

Cryptography: A Closer Look at the Algorithms

Sponsored by Maxim Integrated

Get more details about how cryptographic algorithms are implemented and how an asymmetric key algorithm can be used to exchange a shared private key.

Click here to download the whitepaper

Featured Chalk Talk

Cloud Computing for Electronic Design (Are We There Yet?)

Sponsored by Cadence Design Systems

When your project is at crunch time, a shortage of server capacity can bring your schedule to a crawl. But, the rest of the year, having a bunch of extra servers sitting around idle can be extremely expensive. Cloud-based EDA lets you have exactly the compute resources you need, when you need them. In this episode of Chalk Talk, Amelia Dalton chats with Craig Johnson of Cadence Design Systems about Cadence’s cloud-based EDA solutions.

More information about the Cadence Cloud Portfolio