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
Oct 26, 2020
Last week was the Linley Group's Fall Processor Conference. The conference opened, as usual, with Linley Gwenap's overview of the processor market (both silicon and IP). His opening keynote... [[ Click on the title to access the full blog on the Cadence Community s...
Oct 23, 2020
Processing a component onto a PCB used to be fairly straightforward. Through-hole products, or a single or double row surface mount with a larger centerline rarely offer unique challenges obtaining a proper solder joint. However, as electronics continue to get smaller and con...
Oct 23, 2020
[From the last episode: We noted that some inventions, like in-memory compute, aren'€™t intuitive, being driven instead by the math.] We have one more addition to add to our in-memory compute system. Remember that, when we use a regular memory, what goes in is an address '...
Oct 23, 2020
Any suggestions for a 4x4 keypad in which the keys aren'€™t wobbly and you don'€™t have to strike a key dead center for it to make contact?...

featured video

Demo: Low-Power Machine Learning Inference with DesignWare ARC EM9D Processor IP

Sponsored by Synopsys

Applications that require sensing on a continuous basis are always on and often battery operated. In this video, the low-power ARC EM9D Processors run a handwriting character recognition neural network graph to infer the letter that is written.

Click here for more information about DesignWare ARC EM9D / EM11D Processors

featured Paper

New package technology improves EMI and thermal performance with smaller solution size

Sponsored by Texas Instruments

Power supply designers have a new tool in their effort to achieve balance between efficiency, size, and thermal performance with DC/DC power modules. The Enhanced HotRod™ QFN package technology from Texas Instruments enables engineers to address design challenges with an easy-to-use footprint that resembles a standard QFN. This new package type combines the advantages of flip-chip-on-lead with the improved thermal performance presented by a large thermal die attach pad (DAP).

Click here to download the whitepaper

featured chalk talk

Using the Graphical PMSM FOC Component in Harmony3

Sponsored by Microchip and Mouser Electronics

Developing embedded software, and particularly configuring your embedded system can be a major pain for development engineers. Getting all the drivers, middleware, and libraries you need set up and in the right place and working is a constant source of frustration. In this episode of Chak Talk, Amelia Dalton chats with Brett Novak of Microchip about Microchip’s MPLAB Harmony 3, with the MPLAB Harmony Configurator - an embedded development framework with a drag-and-drop GUI that makes configuration a snap.

Click here for more information about Microchip Technology MPLAB® X Integrated Development Environment (IDE)