Archive for the '6. The 10 Commandments' Category

It’s time for the next installment in “The 10 Commandments for Effective Standards”. The 7th Commandment for Effective Standards is:

Think Relevance.

In order for a standard to be effective, it has to fill an industry need. Formal standards are expensive and time-consuming to produce, so it’s important that they give real value back to customers and suppliers. Pet projects are not appropriate for standardization because they don’t serve the market at large. It may be fun or intellectually stimulating to standardize an arcane piece of technology, but it doesn’t help the community to use resources on efforts that aren’t really needed. I experienced this firsthand in my first couple of years as a standards participant. To protect the certainly innocent, I won’t mention names, but there was a small simulator company that desperately tried to create an IEEE standard based on their own unique algorithm. No one else thought their stuff was cool, so the effort was ultimately fruitless and resources were wasted.

There’s also a timeliness factor to consider for relevant standards. Standardizing an unproven or not-adopted technology is not effective. We could have standardized aspects of bubble memory technology, but I doubt it would have been worthwhile because the technology didn’t catch on. Cycle-based simulation for electronic design automation is another good example. A decade ago, I sat through an attempt to create a standard around it, but it also failed because the technology was just too new at the time.

So, the next time you, your company, your standards organization, or your industry considers developing a standard, be sure to ask first, “Will it be relevant?”

Warning: if a standard is produced that isn’t relevant, it could become a laugh. (If you haven’t seen this week’s Dilbert series, it’s about the standards game. And I think it’s really funny. All hail, Scott Adams!) 

In my continuing series, “The 10 Commandments for Effective Standards”, the 6th commandment is:

Leverage Existing Organizations and Proven Processes

Standards begin in a variety of ways (a topic for a different post). Regardless of what motivates a standards effort, it’s important that a process is followed to ensure a successful outcome. When I say “process”, I actually mean all the ingredients required to produce a useful standard. These include: bylaws, policies, procedures, guidelines, rules of conduct, committee and governance structure, administration, websites, information management tools, PR, market acceptance, and formal accreditation. (Whew!)

Developing a new standardization environment is a monumental task. I’ve seen standards groups take 6 months or more just to get the basics in place. The best approach you can take to launching a new standards initiative is by doing so under an existing standards body – if possible – instead of creating an entirely new organization. Taking advantage of what an existing group has learned and refined over the years is a smart way to start. Existing standards bodies can offer you administrative, technical, marketing, and financial resources to expedite the standards process.

In my industry, and I’m sure that in other industries as well, there are several standards-setting and standards-development organizations to choose from. The criteria I suggest for selecting an organization to work with is finding one that you trust. Not just the one with the most money, or the biggest staff, or the fanciest website, but one that resonates with your goals. One that has a proven track record of delivering standards that are in use today by your customers. And one that has a positive reputation in your industry.

If, for whatever reasons, you can’t find an appropriate organization and decide to start your own, it’s still a good idea to leverage existing organizations. Some are quite willing to share their bylaws and policy documents that you can use as a template, if not adopting them completely. Accellera and the IEEE Standards Association, for instance, have shared their policies with other groups to help them get started or improve their existing policies. Using existing principles lowers the risk of something going wrong during the process and certainly shortens the time for your standard to be completed.

Observing the 6th Commandment for Effective Standards can save you significant time and money – both of which we could all use a little more of.

It’s time for the next Commandment for Effective Standards.

Number 5 is: Realize There Is No Neutral Party.

For anyone involved in the standards game, this knowledge is crucial. Everyone participating in standards has a mission to accomplish, be it for business, law, safety, technology, or personal reasons. No one would spend a valuable minute or a precious penny on a standards activity for which they didn’t care about a specific outcome.

People can be surprised when they come to understand how not-neutral standards participants are. An engineer who is new to a committee can be horrified to discover that another committee member has been purposely delaying progress by throwing up smokescreens that sound like policy discussions. An EDA vendor can be perplexed when another vendor who has participated in developing a standard for years suddenly announces an alleged essential patent. And a customer can be shocked upon discovering shenanigans that feel like vandalism when attempting to survey the industry about which of two standards is preferred.

I’ve always chuckled when an organization claims to be a “neutral third party”. It happens usually in the midst of a standards struggle, and on the surface it seems to be an answer to a settlement. In truth, the NTP (how’s that for a new acronym?) has something to gain. In the case of one famous – I should say infamous – standards battle (see the last paragraph of the article), the NTP stood to increase membership and bring in additional funding.

Keeping the 5th Commandment for Effective Standards in mind before jumping into a standards activity can help you gain a broader perspective and quell some of the emotions associated with any skirmishes that might erupt.

If anyone can find a truly neutral party in the standards game, I’d be fascinated to learn about it.

EDA standards blog The Standards Game
10 Commandments effective standards
power standards UPF Unified Power Format CPF Common Power Format
verification standards VMM Verification Methodology Manual OVM Open Verification Methodology
patents essential patents SystemVerilog P1800

 

EDA standards blog The Standards Game
10 commandments
open open standards

As a mere mortal, I’ve decided that my 10 Commandments for Effective Standards can have “dot” commandments.  I’m introducing the 3rd.1 commandment: Know when to start.  I want to give credit to Gabe Moretti for the 3rd.1 commandment as he recently commented on my first 3 commandments in his blog.  My version of “Know when to start” adds an additional concept. 

There is a proper time to start a standardization effort for a technology (or format, API, database, …).  Before standardizing, it has to have reached a certain level of maturity.  Parents don’t send an ovum to school, instead they wait until the child has developed enough to get along with others, pay attention, and follow instructions. 

In our industry, the maturity of an EDA technology comes through customer usage in real IC design projects.  Subsequently, donations of proven technology to an experienced standards development organization (SDO) is quite effective as evidenced by Verilog, VHDL, SystemVerilog, Liberty, SystemC, UPF, and many others.  The final step is when the SDO transfers the completed standard to the venerable IEEE Standards Association for its formal ratification and moniker. 

Overall, the quality and merit of a standard relies on it having been deployed in the “real world” with a good measure of acceptance before sending it off to the graduate school known as the IEEE-SA.

It’s always exciting when a new standard activity launches.  There’s hope and expectations for a solution that will greatly help improve productivity for customers and suppliers alike.  I don’t have statistics on how many new standards are ultimately successful.  That would be some interesting data.

I do know that not every standard that starts becomes completed and adopted.  Completion – the official ratification by an organization or managing entity – is important, of course.  Yet it’s adoption that indicates the true measure of success for a standard.  The number of customers using it and the number of tools that support it are the best indicators of a viable standard.

There are dozens of EDA standards sitting on the shelf unused.  (Remember VHDL Waves?)  Resources consumed by these standards could certainly have been better spent. Working on a standard that isn’t going anywhere is a senseless waste.  If there is a well-adopted standard that is available to everyone, it is not effective to create a competing or overlapping one.

Hence, my 3^rd Commandment for Effective Standards is: Know when to stop.

No one likes to admit defeat, but shutting down an ineffective standards activity is only right.  If an already-accepted standard is made available to everyone, it’s important to stop working on an alternative. 

The EDA industry has done this at least three times in standards for libraries, constraint languages, and physical description languages. Let’s hope this commandment continues to be honored for many years to come.

EDA standards blog
The Standards Game

In a recent comment, John Blyler asked if I had any thoughts on company employees in standards-setting bodies.  The context is the Broadcom-Qualcomm lawsuit in which Broadcom alleged that a Qualcomm employee sat on a standards committee.  The whole story is interesting in and of itself – and it’s not finished yet. 

For me, the story hit home.  Participating in standards committees can have implications on your company’s patent portfolio.  This is the underlying reason for my “2nd Commandment for Effective Standards”. 

Commandment #2: Do Not Mix Patents and Standards

Before I go any further, I must solemnly swear: I Am Not A Lawyer and I Am Not Giving Anyone Legal Advice.  OK, now I am free to give my opinion. 

If there is a mortal sin in standards, mixing patent rights with standards is it.  It is cheating if you help develop a standard, don’t reveal that you have associated patents, and then assert your patent rights against others who use the standard.  Famous lawsuits have shown that companies cannot introduce patents into the standards arena and expect to retain rights to their patents. 

The term often used for patents that have standards implications is “essential patent”.  This means that in order to make use of the standard, the patent would necessarily be infringed upon.  If your company owns an essential patent and you participate in a related standards committee, you risk your company’s right to enforce the patent.  Effectively, your company can lose its intellectual property (IP) rights provided by the patent.

Patents that have to do with a company’s product which complies with a standard can be a different animal, though.  Product implementations that use the standard belong to the developer, and if the implementations are copied, the developer can be entitled to assert IP rights.

I have experienced occasions when EDA companies attempted to preserve their essential patent’s IP rights while contributing to a standard.  Complicated proposals to license and require cross-licensing were made, but these only caused confusion and derailed progress.  Worse, I witnessed instances of companies attempting to pressure or fool their competitors into relinquishing their IP rights.

On the positive side, I have known EDA companies to properly withdraw from standards committees to preserve their IP rights.  They have also made conscious decisions to forgo IP rights in favor of a much-needed standard. 

What should you do if you are participating on a standards committee and represent a company that has a patent portfolio?  Ask your company’s lawyer right away for direction.  Standards organizations usually have policies to address patents, and some won’t accept donations of patented technology.  Your lawyer can interpret these policies and help your company determine how it wants you to proceed.  At one end of the spectrum, your company might choose for you to not participate at all.  At the other end, your company may decide to contribute its essential patents to the standards efforts. 

The ideal situation in EDA is for all standards (which include formats, languages, databases, and APIs) to be free of IP and patent issues.  Either there are no essential patents to begin with, or essential patent owners are willing offer them up if they want to participate in standards creation.  Fortunately, the EDA industry hasn’t experienced patent-standard lawsuits to my knowledge, and we should strive to keep it so.

EDA standards blog
patents standards essential patents

Experienced standards people know there are certain aspects of standardization that just plain work.  When they’re not followed, trouble often ensues.  Progress can be delayed, valuable resources can be wasted, or a standard might be produced that no one ever uses.

Based on real activities I’ve been involved in that were either quite successful or dismal failures, I put together what I like to call my “10 Commandments for Effective Standards”.  I didn’t receive them from the god of standards, but instead learned them from the schools of hard knocks and good fortune.  This is the first installment. 

Commandment #1: Cooperate on Standards, Compete on Tools

This is the “golden rule” of standardization.  It is the essence of effective standards.  When the need for a standard arises, usually after a new technology has been in use for a while and customers begin to feel the pain of different (or similar) formats that serve the same purpose, it’s time for vendors to cooperate. 

Lack of cooperation to create a customer-demanded standard can result in two (or more) standards for which the whole industry pays a price.  Customers and vendors alike must either choose one standard over another, restricting their ability to sell into a broader market, or they must support two standards, which is just plain costly.

Yes, cooperation means give-and-take for the vendors.  Some engineering investment likely needs to be made if formats are modified during the standardization process.  Yet this investment is surely less than having to support two separate standards.

When the next appeal comes from EDA customers for a standard, let’s hope we can cooperate to satisfy them.  Then, we can compete like crazy by offering the best products that capitalize on our cooperation.

EDA standards blog
cooperate compete