Archive for the '6. The 10 Commandments' Category

Two of my (many) passions are Twitter and standards. Recently, I completed a fun project that combined both. But in an old-fashioned way. The publisher of the THINKaha book series encouraged me to write a book for their “#XYZ tweet” collection. Each of these short books contain 140 bite-sized ideas on a topic that lets the reader get a quick taste of the subject and/or the author.

I agreed, and the” #STANDARDS tweet” book was born. Tweets in print are rather odd, but it was a fun experience. Thanks again to Rick Jamison (@rickjamison), there are some clever cartoons that adorn the text. Also, thanks to JL Gray (@jlgray) for writing the Foreword and supplying the funniest headshot I’ve ever seen. Too bad I couldn’t bring myself to use it – instead, the book has JL’s officially nice face in the front matter.

If you’d like a free copy of this little book, post a comment, send me an email, connect with me on LinkedIn, message me on  Facebook, or tweet an @mention or DM, and I’ll put one in the mail for you.

Happy Tweeting and Happy Standardization!

@karenbartleson

The quite successful 2011 Design and Verification Conference was held last week. The most prominent topic at the conference was the Universal Verification Methodology, UVM, which is the latest standard ratified by Accellera. Instead of telling you about UVM myself, I decided to get information straight from one of the participants in the UVM effort, my colleague Yatin Trivedi.

Yatin told me, “The design verification community is rejoicing over the release of UVM 1.0. At DVCon 2011, the exuberance was quite visible. Let me just cite a few data points for any skeptic who might rush to call it “irrational exuberance” of Alan Greenspan fame –

- record number of attendees (more than 200) packed the all-day UVM tutorial

- standing room audience at Town Hall lunch meeting to talk about UVM and SystemC interactions

- full-house UVM panel that had six of the leading contributors answer Cliff Cummings’ tough questions

- 12 of the 37 papers were about UVM

- best paper awarded to Adam Erickson on “evil” UVM macros!

- more than half the exhibitors showed their support for UVM

- “Meet the Experts” in Accellera’s booth was a great place for attendees to interact with, who else?, the UVM Experts

- numerous tweets with the hashtag #uvm, and a number of blog posts about UVM

- … and who can forget the rousing applause as each contributor was recognized for their dedication?

“Yes, UVM was the biggest story at DVCon 2011. So, naturally, the question arises – what is UVM?

“UVM stands for Universal Verification Methodology. It is a verification methodology, based on a class library defined using syntax and semantics of IEEE Standard 1800, also known as the SystemVerilog hardware description language. Thus it is a SystemVerilog-based verification methodology, not a new language. The standard is defined by the UVM 1.0 Class Reference document approved by the Accellera Board of Directors.

“UVM is a fine example of ‘a standard developed by committee’. Accellera’s VIP-TSC not only worked on the standard – the Class Reference Guide document – but it went one step beyond to provide a Reference Implementation for the documented classes.”

I asked Yatin if the UVM effort followed any of The Ten Commandments for Effective Standards. He told me, “This industry-wide effort under Accellera demonstrates several commandments from the Ten Commandments of the Effective Standards:

- Collaborate on Standards, Compete on Products: Not only major EDA vendors participated in this effort, but several users from competing companies collaborated too (notably, AMD, Cisco, Freescale, and Intel). Clearly, everyone was working towards the same goal.

- Start with Contributions, not from Scratch: UVM is built on top of the Base Class Library (BCL) of OVM, widely-used contributed technology such as VMM’s Register Abstraction Layer (RAL) and phasing mechanism, support for Open SystemC Initiative’s (OSCI) Transaction Level Modeling-2.0 (TLM-2.0), and the committee-developed Command Line Interface and Resource Manager.

- Be Truly Open: All Accellera standards are open to anyone who wants to develop and use them. They are also free. In case of UVM, the Reference Implementation is also open and available at no cost. Many leading EDA vendors have verified that the reference implementation is usable on their tools. The reference implementation is an Open Source project, so the support is provided by the community.”

Accellera’s VIP-TSC working group will continue to seek ways to improve the UVM standard and enhance the reference implementation. If you wish to contribute, please join the VIP-TSC.

There’s been a shift in what’s needed in modeling standards for IC design. The focus has moved from timing to power consumption. Timing modeling, which dominated much of the effort from the early to mid 00’s, has sorted itself out. The Liberty format (.lib) has been successfully extended for demanding nanometer timing accuracy by customers and EDA suppliers via collaboration in the Liberty Technical Advisory Board (LTAB). Other groups such as OMC that had sprung up to tackle timing modeling, among other things, have completed their missions and provided direction to the LTAB so that Liberty (.lib) consolidates all the market needs.

Power management of ICs is now the growing challenge, as power modeling and optimization has replaced timing as a critical need for standard modeling during the past couple of years.

Power consumption has to be modeled at both the gate level and the system level. A lot of good work has gone into power modeling at the gate level in Liberty, and this work is ongoing. Several years ago, the LTAB ramped up its efforts in the area of power modeling, in conjunction with the rise of UPF and CPF power formats. Both the IEEE 1801 Low Power Working Group and the Si2 Low Power Coalition (LPC) have been guiding critical extensions to Liberty with respect to gate-level and macro-level power and implementation modeling. The LTAB accepts input from all sources – one doesn’t have to be a member to contribute.

This cooperation with IEEE 1801 and LPC is a good example of the First Commandment for Effective Standards: Cooperate on Standards, Compete on Products. The concept is that it’s most effective and efficient for companies to cooperate on creating standards. The corollary is that, just as for companies, it’s better for standards organizations to cooperate. IEEE 1801 and LPC contributing to the LTAB is the model of cooperation among standards organizations that we can always use more of.

What’s coming next for power modeling? The challenges are moving into the system-level space – ESL if you like. As in moving from transistor-level to gate-level modeling, moving from gate-level to system-level means new and/or enhanced standards are needed. Taking power modeling up a level of abstraction, to the transaction-level, will require a lot of system-level expertise that needs to come, not from the gate-level world, but from another space – the system-level space. Power modeling efforts from the system-level experts will be essential to produce effective standards. The system-level guys will certainly need to play a substantial role.

Just where are the system-level guys? In OSCI, of course. The Open SystemC Initiative has been the center point for system level modeling since 1999. It only makes sense for system-level power modeling standards to come from OSCI. In the same spirit as the LPC cooperates with the LTAB for gate-level power modeling, it will be great to have IEEE 1801 and LPC contribute valuable ideas to OSCI as they generate new system level modeling needs.

I have a new friend in the standards game. His name is Keith Boone, and he works on standards in the medical industry for GE’s Healthcare division. Keith’s recent blog post, “Tactics for standards setting: lead, follow, or get out of the way”, gives insights that pertain to challenges anyone in any industry faces while creating standards.

The 5 tactics Keith writes about are: ignore, monitor, contribute, lead, and kill. He adds an interesting dimension to playing the standards game – that of budgeting. For each of the 5 tactics he describes, he provides the relative costs (in time and travel). Leading costs more than monitoring, for instance.

As in the medical industry, these tactics are also used in the electronic design automation industry. I’d like to highlight a couple of points in Keith’s post and add some insights from EDA.

Ignoring a standards effort in EDA is appropriate when the proposed standard brings no value to our products and services. It’s my Seventh Commandment for Effective Standards – Think Relevance. The standard may not go away completely (especially if there are a few players who think the standard is cool), but most parties will not incur unnecessary, wasted costs.

Monitoring happens a lot in EDA standards. It seems that it’s usually the big companies and a handful (at most) of smaller ones are the major contributors to our standards. The rest simply sit back and watch for the right time to capitalize on the standard by supporting it in their products. Case in point: look at all the companies that support SystemVerilog and compare it to the names of the participants in its development.

When it comes to EDA, contributions are the key to success of our standards. Starting from scratch is rarely a good way to begin a standards effort. When we say “contributions”, we mean – as Keith states – commenting on email reflectors, participation in discussions and conference calls, attending meetings, providing feedback during voting / balloting, and providing text. We take it one step further and contribute technology as well.

Leadership is an absolute requirement for a successful EDA standard. No matter what other tactics may be in play, it’s leadership that will ensure a viable standard is the result. I’m not sure that 80% of the contributions are uncontested in EDA (that would be nice). We’ve certainly been through some big battles. However, I could probably find some cases that match the 80% figure, and I’d bet it was leadership that made them that way.

There’s no doubt that “kill” is a tactic that is repeated in EDA. The element that Keith describes which seems to be missing too often, though, is transparency. If we were to follow his advice, it’s possible that there would be a lot less positioning and posturing – especially in the media. (I’d like to point out that IEEE-SA has similar balloting rules as ANSI and ISO that help enable the delaying tactic.)

I thoroughly enjoy reading Keith’s blog (and following him on Twitter) and seeing how similar industries are when it comes to producing standards.

I’ve decided to create a new series in my blog that gives real world, real time examples of “The Ten Commandments for Effective Standards” in action. As I see activities, successes, and challenges in the standards game that pertain to one of the “commandments”, I’ll point them out. If you come across any good examples, be sure to let me know and I’ll be glad to write about them (and give you credit, of course).

A few weeks ago, an instance of the second commandment – Use Caution When Mixing Patents and Standards – arose as Microsoft filed a lawsuit against Motorola. Microsoft is claiming that Motorola broke its promises to the IEEE-SA and ITU to offer a Reasonable And Non-Discriminatory (RAND) license to Motorola’s patents that Motorola identified as being related to WLAN and H.264 video compression. Motorola denies the claim and says it licensing is reasonable.

For countless reasons, I won’t make any judgments on which company is right or wrong or the shades of gray in between. However, I do want to emphasize that this suit (among so many others) is the reason why a standards organization’s intellectual property policy is so important. The IP policies of the IEEE-SA and ITU will likely play a key role as this dispute is resolved. As Yatin Trivedi said when he sent me the link to an article about the lawsuit, “Maybe this suit (and its settlement) will give new understanding of the IP policy in standards organizations.”

There are surely high stakes to be won or lost in the Microsoft vs. Motorola suit because the consumer electronic products industry is massive. And the big question is who’s to decide what RAND really is? The answer will be up to the courts.

I’m excited to tell everyone that my book is now available! It comes in hardcover, paperback, Kindle, and eBook through Amazon.com, Synopsys Press, and other book outlets. Rick Jamison, who created amusing cartoons for the book, and I are blatantly proud of our accomplishment. If you’ll be at the Design Automation Conference, stop by The Standards Booth for a complimentary copy.

“The Ten Commandments for Effective Standards” is a short book that expands upon my blog posts of the same name. I also wove in ideas from my blog readers’ comments on those posts. I included chapters on why I believe standards are important and what I think effective standards are. The book summarizes what I learned over many years (how did that happen?) of participating in creating EDA standards.

I’m quite sure that the challenges we face in the EDA industry when we standardize are similar to those in other technical fields. I found countless examples of challenges in other standardization efforts and included some interesting ones in the book. I hope my book will be of value to people involved in standards everywhere.

As I say in the Introduction, I realized that writing a book about how to create effective standards is like writing a book on parenting. There’s no single right way to do it and opinions abound. I look forward to lively discussions about my book.

In writing my short book, “The Ten Commandments for Effective Standards”, which will be published in a few months, I received much feedback with a variety of perspectives. A lot of it centered around the 2nd commandment: don’t mix patents and standards.

When I first wrote about patents and standards, my experience was that they simply don’t mix. There was too much risk for holders of (potentially) essential patents to participate in related standardization activities. Crazy cross-licensing schemes served only to delay progress on completing standards – no one in my industry had figured out how to make them work. Everyone wanted to play junior lawyer, citing all kinds of things that may or may not have been law.

Today, there is still much scrutiny on essential patents and standards. (An “essential” patent is one that will necessarily be infringed upon by anyone implementing the standard.) Possibly, there is even more focus now. As several of my book’s reviewers pointed out, however, there are some workable solutions in place that address the challenge of implementing a standard that has an essential patent associated with it.

One such effective solution is known as a “patent pool”. Essentially, all the holders of essential patents throw them into the ring, allowing others to license the patents. With a patent license in hand, implementers are free to create products that support the standard – without fear of lawsuits from the patent holders.The basic requirement is that the licenses must adhere to RAND (Reasonable And Non-Discriminatory) terms. It’s not acceptable to charge exorbitant fees nor refuse licenses to competitors.

A good example of a standard that employs a patent pool is USB. Adopters and promoters of the USB standard sign an agreement to license their patents to each other under RAND (Reasonable and Non-Discriminatory) terms and without royalties. Further, they agree to not assert their patent rights against others who have signed the agreement. The well-adopted and widely-used USB standard has taken advantage of the patent pool concept to successfully (so far) mix patents and standards.

Thus, I have changed the 2nd commandment to: use caution when mixing patents and standards. While I still think it’s safer to avoid producing standards that read on essential patents, diving into a patent pool can be the right approach. Just be careful, please.

I’m starting the new year by finishing a project, and it feels great. I posted the first of my “10 Commandments for Effective Standards” way back in February of 2008. Today, I’m completing the series with a concept that summarizes what I’ve learned about the standards game.

The 10th Commandment for Effective Standards is: Know That Standards Have Technical and Business Aspects.

When you think about a standard, the first thing that might come to mind is its technical nature. How can a standard’s working group piece together formats donated from several companies into a single, cohesive standard? How will the standard be implemented into existing algorithms and code? How will customers be able to plug together products that support the standard from different vendors? Which features of the standard must be included in the first version and which can be saved for future revisions?

These are vital questions to be answered, of course. But addressing only the technical aspects of a standard does not ensure that an effective standard will be produced. The business elements have to be considered as well.

Practical questions should be settled during the standardization process – if  not by the working group members, at least within the participants’ own organizations. For instance, how much will modifications to current products cost in order to support the proposed standard? Can new products be developed quickly enough to make use of the standard? Will it be economically feasible for customers to switch to a new standard?

To create an effective standard, not just a technically elegant one, the people working on a standardization effort need to realize – and be able to address – business concerns equally as much as technical concerns. I can think of four ways to meet this requirement.

First, a company can find an employee who has both technical expertise and business savvy to represent the company in the standard’s working group. This person is someone who can navigate his or her way through challenging technical issues as well as complex commercial constraints. It’s true, I know, that individuals who are skilled in two clearly different areas can be hard to find.

A second way to address both technical and business elements of a standard is through “on the job training”. A person working on a standards project can gain expertise in the area that’s not their specialty by watching and learning from others who are part of the project. I admit I learned a lot about the business side of standards by watching my competitors’ behavior.

A third approach is for companies to consciously and actively train their employees who are destined to work on standards projects before they start participating in standards development. This sounds like common sense, of course, but it does require forethought and investment in a training program.

A fourth way to balance technological and business considerations is for companies to send more than one representative to the standard’s working committee. This does mean additional resources must be invested, but it can certainly pay off.

Realizing the technical and business aspects of the standards game will help you be as effective as you can in the standards game. Happy New Year!

P.S. Watch for my upcoming book, “The 10 Commandments for Effective Standards”, from Synopsys Press. I hope it will be published in a few months.

I’m nearing the end of my series, “The 10 Commandments for Effective Standards”. Here is the 9th installment. It looks at how the standardization process can be accelerated and how standards can have a better chance of being adopted by industry.

The 9th Commandment for Effective Standards is: Start With Donations, Not From Scratch.

In the fast-paced EDA industry, spending too many years producing a standard can cause the standard to be pretty much obsolete by the time it’s finished. A sure way to speed up the standards process is to start with donations of already-proven formats, technology, and methods. Creating a foundation for a standard with techniques that have been shown to be useful gives a working committee a big head start. It also means that bugs or limitations may have already been addressed, lightening the load for the committee.

It’s important for the working committee – and its parent organization –  to allow donations to come from more than one source. Limiting contributions to a single company can be met with skepticism. It can also make committee members suspicious that a single company’s agenda is being pushed or that the standardization process isn’t open.

Of course, if a single solution is so elegant and welcomed by the committee that it’s not interested in other donations, it’s fine to proceed. However, this sense should be widely accepted, and committee members shouldn’t be blocked from making donations if they wish to.

On the other hand, if only one donation is made and no other donations are forthcoming, it could indicate that there’s no real need for a standard. In this case, even if much time and effort are put into producing the standard, it could end up sitting on a shelf, unadopted.

Donations can be made in a variety of ways, and established standards-setting and standards-development organizations have policies governing them. At times, owners can contribute their solutions through licensing schemes, but it’s critical that the terms be reasonable and non-discriminatory. Also known as RAND terms, this insures that all interested parties will have access to the standard for use in their products and services.

I know that some industries have to create standards from scratch before products can be developed. Yet, in my industry I’ve found that donations of proven technology result in highly effective standards.

This is the 8th installment in my series, “The 10 Commandments for Effective Standards”. If you’ve missed the previous entries, have no fear. There’s no god of standards to whom you’ll have to pay penance. And if you’re interested, the first 7 commandments are in the archives.

Commandment #8: Recognize there is more than one way to a standard

In the early days of the electronic design automation industry, EDA standards were primarily produced by the IEEE’s Design Automation Standards Committee (DASC) or by the Electronics Industry Association. These formal standards organizations sponsored the ratification of two of EDA’s most well-known standards, VHDL and EDIF, respectively.

Over time, however, the process of creating EDA standards became protracted and inefficient. As technology advancements sped up, EDA standards fell behind, and by the time they were ratified, they were practically obsolete. Lore had it that EDA standards took 3 – 6 years to complete. With new semiconductor technology nodes coming along every 3 years or so, standards were clearly not keeping pace.

When the collective EDA industry “we” realized this, new models for standardization were developed. Plus, the venerable IEEE introduced its corporate standards program, and some important EDA standards were produced in record time.

I’ve grouped the standardization models into 4 categories: closed proprietary, company open proprietary, formal committee, and open source. All of these are in play, with each having different strengths and weaknesses. Here are their characteristics and an example of each:

Closed Proprietary

Characteristics

• owned by a single company
• available only to that company’s customers
• fast to evolve and well-supported
• other vendors are not allowed to use them
• greatly reduces tool interoperability

Example

• Cadence’s Physical Design Kit format (PDK)

Company Open Proprietary

Characteristics

• ensures access to everyone
• immediate availability, timely releases
• well-established, well-maintained standards
• significant resources applied by owner

Example

• MAP-in (Milkyway Access Program)

Formal Committee

Characteristics

• consensus-based processes
• membership open to all
• members sincerely want standard to succeed
• can be slow or fast to evolve depending on process

Example

• Unified Power Format (UPF) / IEEE Std. 1801

Open Source

Characteristics

• open to everyone
• members want the standard to succeed
• single person, entity, or company manages enhancements from and to a community
• fast to adoption and fast to evolve
• “forking” can occur without management and commitment

Example

• Open SystemC

Which model is selected for an EDA standard to follow depends on several factors including: maturity of the technology, rate-of-change requirements, industry demands, and business climate. Each has its place in today’s standards game.