Newsletter

EDA DesignLine  >  Blog

EDA Commandments are Upon Us





EDA DesignLine

It is not every month that one gets a new set of Ten Commandments, so when Karen Bartleson announced that she had received from unspecified, but one must suspect a source of Higher nature, the Ten Commandments for Effective Standards, I paid attention. You know, just in case. When dealing with deity, or the EDA Standards' Iron Lady, it is better to be informed. Just like getting a ticket, pleading ignorance will not get you out of trouble. By the way, in case you would like to be electronically present at the unveiling of the next seven imperatives, please visit Karen's blog page.

Unfortunately, unless I have already committed a sin of omission (in Catholic terms), it is going to take ten trips to the mountain to accumulate the entire set. But we have the first three:

  1. Cooperate on Standards, Compete on Tools
  2. Do Not Mix Patents and Standards
  3. Know when to stop
Few on this planet think of me as a prophet, so it is with humility that I dare suggest some small modifications to the wording of number 2 and 3. But I do so because I believe the error was in the translation, not in the intent.

Number 2 should state: Do Not Mix Patents and Copyrights with Standards.
Obviously software code, which is at times incorporated in standards, may be covered by copyrights when it is offered to a standard making working group (WG), not a patent. The WG should then be free to use the code in every opportunities, whether it is to develop, publicize, or distribute a standard. The code should be usable as a development tool or as an integral part of the standard, and be available in source code form to the users of the standard. Any restriction of the type: "You can see it but they cannot" is not only a hurdle to the WG, it also directly contradicts the First Commandment.

And speaking of the First, I would urge all consortia, you know who you are, do stop the silly practice of requiring a company to pay a fee or sign a non-disclosure in order for its employees to work on a standard. The practice make no sense given that the fact that one donates IP to a WG indicates the intent to have the IP a public domain item as part of the standard.

Number 3 should state: Know when to begin and when to stop.
In her commentary to this commandment, prophet Karen tells that although beginning new work on a standard is exciting, we should have the maturity and fortitude to stop working on it once we can prove that the standard is redundant, or useless. I would think it would be much wiser to foresee such negative outcomes before we waste a lot of technical, political, and yes emotional time on an effort doomed to failure. Unfortunately, the mountain fog must still have engulfed the prophet as she wrote her commentary, because the examples given to support the thesis are weak, to use a charitable term.

Her example of VHDL Waves is taken out of temporal context. At that time, an era that most verification engineers are only familiar with by studying ancient EDA history, Verilog was still controlled by Cadence, VCD was not open, VHDL vendors were few and very competitive, and each had its own wave display mechanism. Of course we found a way to use VCD for VHDL waveform display and VHDL debuggers got much more sophisticated, and thus VHDL Waves became redundant. But all this does not mean that it was not a good standard at the time.

Karen also states that: " If there is a well-adopted standard that is available to everyone, it is not effective to create a competing or overlapping one." She talks about libraries, as an example. The de-facto standard for libraries, and the one I suspect she is referring to, is of course .lib from Synopsys. But .lib was not open, and it took the formation of a WG to convince Synopsys, not to join the group, that would have been too democratic, but to open the .lib format so that other companies could use it.

The Accellera VIP Task Force
Karen Bartleson has been instrumental, in fact indispensable, in the formation and approval of the Verification Intellectual Property Technical SubCommittee. Is she violating the Third Commandment by her own actions? There is already an open standard in existence, the Open Verification Methodology (OVM) developed by Cadence and Mentor, and the Verification Methodology Manual (VMM) developed by Synopsys is not open but it has standard aspirations. That those companies should work to harmonize the two approaches is desirable, but do we really need the use of a neutral third party like Accellera to be the mediator? There are still some deals that are better struck is private, smoke filled rooms. And knowing the players those would be expensive Cubans providing the smoke! It would be a shame for a consortium with a spectacular record of standard development like Accellera to be caught in violation of the Third Commandment.

 






Accellera
Cadence Design Systems
Mentor Graphics
Synopsys
Related Content

WEBINAR
1. Webinar 1: Verification of Complex Analog Designs

WEBINAR
2. Accurate Verification of Next-Generation Custom Digital SoC and Memories in 65/45nm Technologies

WEBINAR
3. Verification of Next-Generation Mixed-Signal Communication SoC In 65/45nm Technologies

WEBINAR
4. Webinar 3: Verification of Next-Generation Wireless SoC and Systems in Package

 

 Featured Jobs
T-Mobile seeking Senior Facilities Engineer in Bellevue, WA

Protingent Staffing seeking Quality Engineer in Irvine, CA

Broadcom seeking Principal Packaging Engineer in Irvine, CA

ITT Corporation seeking Systems Engineer in Thousand Oaks, CA

Comverge, Inc. seeking Senior Firmware Engineer in Norcross, GA

More jobs on EETimesCareers
 Sponsor
 CAREER CENTER
Ready to take that job and shove it?
SEARCH JOBS:

 SPONSOR

 RECENT JOB POSTINGS
For more great jobs, career related news, features and services, please visit EETimes' Career Center.