Collaborative Advantage

Of course EDA is a tool industry… or is it? Perhaps our assumptions are out of step with the times – let’s explore this idea further.

We start with the fundamental value proposition of commercial EDA, which is rooted in expertise to improve the efficiency and predictability of designing electronics (I focus on chip design). Of course, expertise in software and algorithms is critical, along with human interface design to support deeply intricate technical decision-making and analysis. So, software is a critical delivery vehicle, no doubt. But is the industry’s value really in the software, or the expertise that created the software? Here is some evidence that points in the other direction.

First, consider the “partner” model of EDA tool development. New software is developed through lots of close interaction with customers, learning the details of their flow, their data, and their methodologies, to incorporate into supporting tools, which are then rolled out in layers of beta sites and evaluations until the customer is willing to use it in a production context. This is arguably a consulting model, highly dependent upon knowledgeable EDA expertise to capture, implement, and adapt to specific and time-varying needs. Very little in EDA is shrink-wrap anymore.

Anyone care to guess the value of EDA software devoid of the development team (such as after an acquisition has gone poorly)? It’s never been just about code.

Next, look at current design technology trends – continually increasing use of commercial IP blocks, created by the vendor and delivered along with domain experts to assist in successful integration. Most of the more complex IP usage is as much “re-do” as “re-use” for at least later portions of the flow – selective alterations to manage die size and power consumption at the front end, and more context-based variations (and DFM concerns) requiring custom re-work in the back-end.

Business trends are also significant. The fabless / foundry model has led to many design houses relying more on their EDA vendors to prove out how the tools work with the foundries. Add to that EDA’s new interest to scope in embedded software (see: http://www.si2.org/?page=1077), which also means more of a service orientation to support domain-specific verification and modeling to complement the tools. Let’s also not forget the new “software as a service” growth area for EDA.

Finally, there’s the financial point of view. Already, almost 30% of EDA revenue comes from IP and services today — not counting the “embedded services” we discussed supporting EDA tool revenue.

I see these trends expanding. EDA serves a very diverse and changing marketplace, with many diverse requirements, and a growing dependency upon customers and foundries to complete the product cycle. Would managing EDA primarily as a service industry better serve it’s future growth? I’d be interested to hear your comments.

Over the last 5 weeks, I have spanned nine countries visiting with Si2’s members across Europe and Asia, returning on Wednesday. Cities included London, Cambridge, Brussels, Eindhoven, Leuven, Paris, Grenoble, Tokyo, Yokohama, Hsinchu, and Seoul. Calling it a “world tour” may be a bit of a stretch, but this is about as close as I’ll ever get (unless my local Austin band suddenly becomes famous and lands a global tour gig, but I’m not holding my breath).

Hectic though they may be, I truly enjoy these annual “tours” – to sit down face-to-face with so many industry leaders in their own work environment, meeting with their engineering teams, and connecting on a much more personal level. These trips offer an opportunity to gain deeper understanding of the needs and priorities of so many companies that are setting the pace for our industry’s growth and innovation. Naturally, there are numerous large corporate heavyweights on our itinerary, but we also visit startups, some working from within “technology incubators” that wow us with amazing levels of innovation, passion, and efficiency. While funding ability within this economic climate varies widely, this creative spirit is alive and well across the globe, just as much as it is within Silicon Valley. By listening to each organization’s unique circumstances, we can then better understand how to architect and phase standards efforts that satisfy the greatest possible set of shared priorities, while avoiding areas of ambiguity or conflict.

While extended economic malaise has left us with permanent tectonic shifts across the industry, I heard loud and clear that standards matter every bit as much today as ever before. In fact, the need to find efficiencies has forced new ways to automate and new ways to collaborate. Most of the time this requires supporting standards as the lifeblood of technical data exchange for enabling effective business commerce. This is true in established areas that need better efficiencies, and even more so for new growth niches that are being held back by confusion and fragmentation.

The topic area that seemed the most timely on this trip was OpenPDK, which took center stage. I should have expected this, because nearly every company touches PDKs in some way, and the data is getting more complex. Achieving commonality is made much more complex because today’s production environments are using a variety of formats and languages that are difficult to replace, yet all know we can and must find ways to do better. There is clearly an increased emphasis on differentiated analog and custom design out there.

OpenAccess is always a primary topic of engagement. I am gratified to hear that many companies are either expanding their use of OpenAccess this year, or planning first production deployment. A large majority are quite pleased with it’s current state; some are glad to hear about recent new features or the in-work enhancements to better scale our operational model. Many have delayed their production deployments for up to several years, to sync with vendor tool upgrade decisions.

I also found that more companies than I had realized have been feeling increased pain in the area of DRC rule decks, and are eagerly awaiting the release of OpenDFM out of the DFM Coalition. The pain levels are primarily associated with managing QA across multiple DRC formats, complications arising from increasing variability and new DFM rules, and complexities due to industrial partnerships requiring sharing of PDKs and libraries.

Low-power is an ever-present priority, but companies are still struggling to fully incorporate low-power intent across their design flows. Part of this is the multi-format issue (this includes some who remain using in-house formats, and are telling their vendors to translate into either CPF or UPF). The general case seems to be starting out with basic low-power intent using UPF for synthesis, then using CPF for the implementation flow. Users of CPF seem very pleased with it and it’s direction. Still, interoperability remains a problem (there was appreciation for the LPC’s recently-released Interoperability Guide that maps between CPF and IEEE-1801).

While many companies care about continued device and feature integration, fewer plan to rely on advanced process nodes to do it. There is good long-term potential for 3D stacked die to fulfill some of that need – but only after a host of technical and business issues can be resolved first. I am not sensing urgency here, but in general solid interest.

In summary, I found that business activity has restored to near-previous levels, with renewed enthusiasm but with fewer staff and a cautious revenue outlook for years to come. The value of standards has not declined, even though the ability to support them with staff resources has become more tightly managed and focused on direct areas of pain and need.

Last month, I wrote a blog describing the “Top Ten Guidelines for Successful Collaboration”, and received some very supportive email responses suggesting that I continue the topic but explore it further. In particular, I was asked to expand on “why collaboration in EDA standards seems to be non-existent”. So, I’d like to discuss the specific challenges that impact the EDA world (this idea from an EDA CEO, mind you), though it really spans our entire design enablement eco-system.

Here is the symptom: EDA has two primary competitors upon which the rest of the eco-system seems to routinely divide, split into two “camps” that cause sustained pain for users, partners, and even EDA’s own eco-system. Examples of this are not hard to find: library formats, design rule formats, high-level HDLs, verification libraries, low-power formats, etc. My email associate cited an ever-present duopoly even where a single standard would seem a clear logical choice. Critics state that this is a sign of an immature industry that fails to grow its market; others note that at least two is far better than five, ten (or none).

So, why does EDA repeat this bad habit, arguably to its own detriment? First of all, the market for EDA tools is in fact highly inelastic, i.e. it is very difficult to create more designers by lowering prices or increasing features, especially in the high-stakes silicon arena. EDA competes in a largely saturated market (with the exception of emerging technology niches). Second, much EDA software has a low barrier to entry by new entrants, or by large EDA customers. This low barrier caps its selling price point, which is the alternative of large customers returning to in-house development (which has higher NRE but lower RE). Third, EDA has developed some “bad habits” in the handling of its business model, often losing what little leverage it has in negotiations just to close a deal in a given quarter. Fourth, EDA has continued to lose clout to more powerful and concentrated market forces – those who actually create the silicon, for example. All of these forces put EDA into a defensive posture, using anything in its arsenal to defend against a transition to a competitor – and that includes formats and standards. This is a natural reaction to these circumstances.

In EDA’s defense, there are times when multiple simultaneous, proprietary approaches are the right business decision, in spite of the lofty goals of collaboration. This can occur when a format becomes tightly linked to a (proprietary) tool algorithm or internal data structure, or when a new tool needs to blaze its own trail with a new (unstable) format.

The real problem for EDA, and for EDA’s customers, is that boundary lines are poorly defined. We hear phrases like “collaborate on standards, compete on tools”, but for EDA formats, languages, and libraries that are at times tightly intertwined with their algorithms (and thus value proposition), this is easier said than done. The fact that everyone in the supply chain may “lose” more shared market opportunity as a result of divergent formats is rarely considered.

I think we can and should do better, but it’s unrealistic to expect EDA to define clear boundaries for itself. Customers must share a large part of the burden here, because for all the talk of common standards, they do not consistently prioritize collaborative results and common standards, for the good of the larger industry, over other immediate needs. The main reason EDA appears worse at collaboration than other industries is due to a perfect storm of reinforcing market forces. The only solution to this is a new, stronger market force – consistent purchasing priorities of EDA’s customer base.

“Customers want openness – suppliers don’t”. That adage is as old as the hills, and has been applied universally regardless of industry. Of course, reality is more complex and nuanced, so I believe this is a flawed paradigm. A more accurate saying might be, “people are motivated for choice when purchasing, and motivated for stability when selling”. This better underscores the common human motivations that we all share in business. Besides, the same company that is a customer in one market may simultaneously be a supplier in another market!

Openness is a key enabler as a business issue, as well as serving it’s critical enabling technical role, which is why standards are central to business whenever specific elements of information (data) or elements of physical products must interact in the ecosystem of commerce. But what exactly defines openness? I now offer a proper taxonomy to help everyone with a thorough understanding of the salient dimensions, and why each dimension should matter to you.

I assert that openness can be measured by three dimensions: access, usage rights, and control. Access (or availability) defines what technology you can get, and when you can get it. Usage rights (as in licensing) defines what you are allowed to do with the technology that you get. Control defines who has the power to determine the evolution of that technology over time, once the industry becomes dependent upon it.

Let’s look a little deeper into each of these three aspects of openness.

Access Rights. Openness in access rights do NOT define a standard! For example, anyone can access source code from SourceForge.net, but that does not make the code a standard. Similarly, the ability to download a specification as defined by a single company that may own it does not define a “standard” or its openness.

Usage Rights. “Open source” licenses (e.g. GPL, GPLv2, Apache, Mozilla, etc) are very popular at Si2, for example, when distributing collaborative technology. When ensuring a common industry standard that cannot diverge, however (such as OpenAccess), open source licenses need a little extra help. The divergence problem can be solved by requiring that all redistributed changes are contributed back to the standards group so that a consensus-driven process can fairly determine the next revision. Alternatively, a single company of sufficient market clout can force a single path, as defined through their product support (though this violates the control aspect of openness).

Control. The most important aspect that defines “openness” is who controls the technology’s evolution, because this can directly affect winners and losers in the marketplace. Licenses are about usage rights, not control of future versions, so this critical aspect is undefined in “open source” licenses. Most standards development organizations (SDO’s) use a “one-company, one-vote” rule for evolving a standard, coupled with required non-discriminatory membership processes so that no one can “game the system”. A formal, managed (supervised), trusted open process is critical to establish trust, especially when market competitors are actively engaged.

So, openness – in standards or other collaborative technology – is defined by the three aspects described above. It is critically important to properly assess what aspects of openness are important to your business for any given situation, and make the appropriate trade-offs.

The name for this blog, Collaborative Advantage, is but a complementary antonym of the oft-used phrase “competitive advantage”. It underscores the point that collaborating on technology for mutual benefit, if done properly, can deliver certain unique benefits not possible with alternative approaches. There are also unique advantages to proprietary approaches – but we note that the street is littered with failed companies that competed poorly and lost all. So, too, are the risks of collaborating “poorly”. This week, I delve into what makes for a successful collaboration. I’ll use standards as the driving example below, but the logic applies to nearly any multi-entity business engagement.

The fundamental assumption here is that all participating companies share a business (usually economic) benefit by pooling time and resources toward a new (shared) technical capability. However, there are many ways this naive concept can fail. Just some of the issues to consider:
1. Do the companies really share a common paradigm, or does it fall apart once specifics are introduced? For example, different companies may use the same terms to mean very different things – this needs to be aligned up front because basic assumptions may not be valid.
2. Are the right technical leaders at the table to enable sufficiently broad engineering success, and do they have sufficient supply chain representation for market credibility and clout for adoption?
3. Is there alignment and ongoing active management of between the technical participants and the business unit owners? To often, individual participants act out of their own pure interest, but are not making wise investment trade-offs from their own company’s business perspective.
4. How will the technology be injected into the competitive marketplace, and how will it coexist with current technologies? It must enable a smooth migration in the market over time, because even big changes happen incrementally.
5. What is the education / training plan for the collaborative technology? It will not be successful if it is not understood or inconsistently used.
6. Once initially developed and released, how will it evolve after the companies commit their businesses to it? As needs and priorities shift to adapt to a changing market, the architecture of the standard must allow for flexibility for enhancements and “coopetition”.
7. What other inter-related or co-dependent technologies must work alongside it to have value? Most standards, for example, exchange data working alongside or on top of other standards (which also evolve over time).
8. How will the collaborative technology be tested and verified? Who takes responsibility for that? There needs to be a plan for ongoing enhancements and support.
9. Is there a roadmap for how the technology will advance and be released, and who defines that roadmap? It is essential to have a change process that all competitors can trust equally.
10. Have logistical issues been addressed up-front (e.g., meetings across timezones, funding / budgeting, intellectual property rights and IP portfolio protection, etc)? It is a good idea to define specific expectations and test the return-on-investment value to a priority need of each company.
When investing in any collaboration, an up-front success-oriented plan means thinking through all the barriers that can arise and identifying means to overcome them by design. This approach works when collaborating on technical standards, but is also just as effective for other forms of shared engineering development.

Your additions and comments, as always, are welcomed!!

Si2 Home Page: www.si2.org

Because so much industry attention has been placed on bringing about improved interoperability for Process Design Kits (PDKs) used to precisely describe manufacturing process details to designers and design tools, my last few blogs have addressed the importance of the topic and rationale for how we are developing standards to address this complex, multi-faceted landscape.  This week I’ll finish up by summarizing what the new OpenPDK Coalition is planning to actually develop and deliver in 2010 — just in time for 22nm requirements (but applicable to all foundry processes).

Let’s begin by clarifying the scope and purpose – which supports
digital as well as custom / analog design.  Why?  All digital libraries assemble circuitry that was custom-designed for a given PDK.  The purpose of OpenPDK is to reduce the time and cost to develop, deploy, and maintain PDKs, by defining open standards to capture PDK information in a portable way that enables generation of multiple format-specific file sets required in the marketplace.  The Coalition is about defining open interfaces, languages, parameters, constraints, and formats that can efficiently work together.

There are seven PDK standardization deliverables currently defined for 2010.  Starting with Si2’s existing OpenAccess symbol set, enhancements are expected to focus on consistent handling of parameters and possibly an augmented symbol set.  The OpenAcess extensibility feature will make this a straightforward task.  Second, an open solution to hold PDK parameters will be standardized, with potential technology contributions aiding this goal.  A new Design Parameter Database (DPD) structure (in XML or equivalent) will permit plug-ins to read / write to multiple file formats, and delivery to members will include a common software implementation of the DPD and plug-in structures.

Closely coupled to the above two standards is a new standard callback specification that enables automatic callbacks to a PDK scripting function whenever a design parameter has changed, supporting multiple languages as identified by coalition members.  Standardized parameter types will ensure consistency in data objects and semantics, regardless of language, for lossless generation.

Pcells are a fourth standardization requirement. Given that multiple Pcell languages and evaluators exist (some proprietary), the approach within OpenPDK is to architect a plug-in standard for OpenAccess for Pcell evaluation, define an API standard through which the required parameters may be passed, and possibly enhance OpenAccess with higher-level constructs to broaden the parameter dictionary.

The fifth need identified by foundries is a standard SPICE socket (API) specifically targeting consistent netlisting, parameterization, elaboration, and evaluation (simulation).  This will be done in cooperation and partnership with the Compact Modeling Council (CMC) to ensure a converged reference for all SPICE standards.

The sixth area is to enhance the OpenAccess technology file to better support DFM-aware routing, new analog / mixed-signal and digital constraints, and add consistent PDK constraint definitions into OpenAccess.  The work will include updates to LEF/DEF and related translators.

Finally, the OpenPDK Coalition will address a major need in rule deck verification.  Si2 will seed this work with an upcoming standard out of the DFM Coalition to address what foundries refer to as “targeting”.  This is essentially a more efficient and modular approach to revising a PDK for specific foundry process variations. Extensions are planned to recognize various device structures, and the result will be tested with vendor tools to ensure quality results and commercial tool support.  OpenDFM will also utilize a plug-in architecture to enable vendor-specific DRC formats.

If you have read this far (whew!), then you are likely a good candidate to help us achieve this important industry goal.  Please contact Si2 for more details.

For more information about the OpenPDK Coalition, please visit: http://www.si2.org/?page=1118.

For Parts 1 and 2 of this discussion, as well as previous blogs, visit:http://www.si2.org/?page=1067

Last week, I explained why PDKs are so fundamentally important to our semiconductor business, and why the need for PDK interoperability has dramatically increased in recent times. In that blog, I also noted that current industry practice spans a variety of languages and formats, primarily rooted in proprietary offerings that have not simplified the goal of achieving broad interoperability objectives. This week, I will give readers a 10,000-foot summary of how Si2’s members are tackling this issue in the new OpenPDK Coalition. I believe it is very important to understand the reasoning behind the OpenPDK approach, so I will dedicate today’s blog to this understanding .

Incidentally, last week several of Si2’s members (TSMC and Springsoft) wrote a summary of some of the pieces that go into a PDK and how they interact – you can read it here on the EE Times website: http://i.cmpnet.com/eetimes/news/online/2010/03/TSMC_SpringSoftWPMarch4.pdf.

So, given that we live in a complicated, multi-lingual PDK world, where roughly 95% of the market uses proprietary technologies, how can anyone deliver on the promise of broad-based interoperability? What practical value could open standards have in such an environment, and how can standards enable a better world given these complexities?

First, we must recognize that there are multiple components within PDKs, in which some have more near-term convergence potential than others, and some offer greater practical cost and efficiency savings that offer solid return-on-investment value. In such cases, we can all quickly benefit by direct alignment to a (possibly enhanced) existing format that meets all needs and can gain wide acceptance just by gaining trust in its ability to meet the technical requirements for relevant process nodes, and by securing the confidence of an open and non-discriminatory standardization process.

Second, for remaining component pieces where near-term convergence would be less likely or impractical, the intelligent approach would be to somehow architect standard interfaces at a higher level of abstraction that can automatically generate any of the existing variations, targeting assured lossless translations for optimal efficiency. While proprietary technologies may or may not be converted into standards, having access to knowledge that permits this interoperability “bridge” architecture toward open standards allows the relative value, and speed of migration, to be determined by the marketplace. In this way, we do not ignore current practice, yet we deliver strong value to all players and simultaneously increase the pace toward market-determined open standards migration.

The OpenPDK Coalition, driven by major foundry requirements and guidance, is taking on the need for broad-based market interoperability through open standards. This includes an architectural approach that supports plug-ins for generation of specific delivery formats, of course centered on technologies suitable as open standards, but also seeking interoperability with current practice to co-exist and migrate. This is a business and market-friendly approach to enable broad-based industry adoption. In addition to new standards work focused on this plug-in architecture for multi-format PDK generation, there are also a set of seven component areas of focus for delivered PDK contents. More on those seven areas will be explained in next week’s blog.

Members of the OpenPDK Coalition are meeting next week (hosted by Mentor Graphics), and they will be including an open session for interested visitors who may wish to consider participation. Please visit Si2’s website or contact Sumit DasGupta at Si2 for more details. For more information about the OpenPDK Coalition, please visit: http://www.si2.org/?page=1118.

For Part 1 of this discussion, as well as previous blogs, visit: http://www.si2.org/?page=1067