Beyond the world of language and format standards for electronic design automation tools is a whole universe of other technical standards. One area that I haven’t written much about is standards that affect IP products. (By IP, I don’t mean Internet Protocol or Intellectual Property as ideas or inventions. In my industry, IP refers to the building blocks that are used in computer chip design.)

My colleague, John Swanson, recently wrote a good article about new standards for audio/video bridging, or AVB. He describes the advancements in entertainment and home networking which bring us more amazing electronic products every year. More products mean more opportunity – or need – for interoperability. More need for interoperability means more standards.

The venerable IEEE Standards Association is addressing the need for these AVB standards. They will affect the entire supply chain, starting with IP such as Synopsys’ DesignWare® Ethernet QoS IP core. While you might never see the standards, you’ll certainly see the benefits.

While writing “The Ten Commandments for Effective Standards”, I stumbled across the University of New Hampshire’s InterOperability Lab. It’s quite an undertaking, and we’re all benefiting from their efforts. I wanted to learn more about what goes on at the InterOperability Lab and if it might pertain to EDA software. Today I had the pleasure of talking with Jon Beckwith and Bob Noseworthy, senior and chief engineers at the Lab. They gave me enough information to write another book, but for now I’ll just summarize our conversation.

The UNH InterOperability Lab was founded in 1988 and has grown into a major operation with around 120 people (100 are students) working in a 32,000 sq. ft. facility on some 26 programs in data networking and storage technology. The Lab is funded willfully by industry: companies pay fees (very reasonable amounts, IMHO, to cover expenses) and provide their latest products for inclusion in test beds.

Pretty much anything that has to do with networking can be tested for interoperability – i.e., compliance to standards – at the Lab. (Standards are the beginning of interoperability, but it’s conformance testing of products which implement a standard that uncovers limits, ambiguities, or missing parts in the standard.) The Lab delivers confidential reports to participating companies which tell them whether their products are robustly interoperable – or not. Product performance, price, features, and the like are not analyzed; that’s left up to the companies as they go about running their businesses.

For students working at the InterOperability Lab, it’s doubly beneficial. Not only are they paid for their apprenticeships, but they also gain real world experience that augments their studies. They work on a team which must produce real results for companies whose businesses depend on them. The students build professionalism and learn how to communicate because the reports they issue to companies could imply product cost and delay. Plus, having their hands on the newest products gives them an appreciation of how theories they learn are actually applied.

What has made the InterOperability Lab a success? Three things, certainly. The lab provides a high quality service, at an affordable price, from a trustworthy source (earned over time). Additionally, engineers from the InterOperability Lab do something special to ensure that their compliance testing is the best it can be. They actually participate in the development of standards. Their contributions during the creation of a standard center around the question, “Why standardize something if you can’t test it?” As the standard’s specification is constructed, the Lab guys ask, “How are you going to test this?” This additional dimension makes for a better standard and ultimately, better products that implement it.

Every once in a while, the concept of standards compliance testing for EDA products comes up. It’s been quite a few years since our industry attempted it for Verilog simulators at a third party interoperability lab. Would an interoperability lab for EDA fly today? It would be a complicated process to put together the countless design flows and tests that would cover the bulk of EDA tools and standards in the market today. Security would be a necessity before EDA companies and customers would feel comfortable contributing their tools and design test cases. It could be expensive, too, unless many companies were willing to chip in.

Another question should be asked, “Is independent compliance testing needed for EDA?” If EDA tools were seriously noncompliant and not interoperable, customers would likely scream (the way they did when they needed a standard for low-power design), wouldn’t they? Or perhaps the cost of nonconformance to standards in EDA isn’t significant enough to warrant an independent compliance lab. Or maybe EDA vendors are doing an acceptable job of preventing and correcting interoperability problems? (I can feel eyes rolling.) It could be that customers have learned to live with a measure of non-interoperability in favor of getting new products faster. It would be interesting to learn if an interoperability lab like that of the University of New Hampshire would bring a big benefit to EDA.

One thing I didn’t learn about the University of New Hampshire’s InterOperability Lab is why the “O” is capitalized. I’ll have to call Jon and Bob.

Want to listen to Conversation Central shows on your computer? Want to comment on a show? Need to find the links that a guest talked about? Visit our new Conversation Central Show Notes site.

Prefer to listen to Conversation Central podcasts on your iPod? Go to the iTunes store and search for “Conversation Central”. All our shows are there, and they’re free.

From either location, you can subscribe to Conversation Central so you won’t miss a show. Unless you want to, of course. We welcome your suggestions and comments.

There’s an interesting article in the July 2010 edition of Wired magazine (yes, it’s the print publication I subscribe to, but only because the FAA won’t let us read electronically during takeoff and landing – one of the best times to read). The article is about Sergey Brin, the co-founder of Google. Brin estimates that he has a 50/50 chance of contracting Parkinson’s, and he is helping fund research to find a cure – hopefully, before he develops the debilitating disease.

The entire article is intriguing – what Parkinson’s is, its possible genetic links, and the personal story of an intelligent, highly successful man. Yet, what fascinated me most was an underlying theme that the standard scientific method as we’ve known it could become extinct in the future.

You remember the scientific method: propose a hypothesis, design tests, analyze results, repeat until convinced. This standard method for gaining knowledge – for seeking the truth – has been used for a thousand years and has led to countless discoveries and breakthroughs.

The internet, or I should probably say the Information Age, could bring about the demise of the standard scientific method. How? By virtue of the massive amount of data that continues to be produced – prior to any hypotheses. The new scientific method, as talked about in the Wired article, could look like this: scan the data, look for patterns, draw conclusions, find truth. No more would a scientist have a sudden thought and seek to prove it. Instead, “regular” people would contribute data that, when aggregated, would reveal the secrets of science.

With an estimated 2 billion users of the internet today, the amount of data they can provide about a given problem is enormous. In the case of disease, for instance, people who report on their health and living conditions could reveal commonalities that today’s monster search engines could uncover: things that a limited set of tests, no matter how carefully thought out, could not. Disclosure would be voluntary – I don’t want to get into privacy issues here – and I suspect people who become ill or have loved ones in danger would be more than willing to contribute information to finding a cure, and even better, prevention.

The standards that I deal with every day are miniscule and fleeting compared to the scientific method. When a standard as ingrained as the scientific method is abandoned, I’m in awe.