May 09, 2008
EDA Commandments are Upon Us
By Gabe Moretti

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

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

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.
Comment on this blog entry

April 30, 2008
The Relevance of System Design
By Gabe Moretti

A piece by Patrick Mannion (

It is true that I myself have pointed out that there are applications that are well served with semiconductor technologies that are no longer leading edge. It is true that there is still a place for 8051 architectures built with 180 nm processes. But is also true that we have yet to reach true real time response for many applications, and that markets that require fast correlation of diverse data types are mostly still under served due to limitation in the hardware.

Only looking at either soft or hard components of a products is taking the wrong approach. It is the system that counts, and a leading product is the result of the correct tradeoff between hard and soft components to meet well thought requirements.

A parochial view of the electronics industry that divides software from hardware is counterproductive at a time when hardware/software co-design is the accepted method for product development.

I remember, from my days as a software developers that there are certain undeniable truths guiding software development:

1. there is never enough central memory available,
2. the instruction set is not flexible enough, and
3. the CPU is too slow.

The invention of logic synthesis gave us the ability to develop Application Specific Integrated Circuits (ASIC) relatively cheaply and make some of those points irrelevant by mostly shutting out the software developers. As long as the product market life was over two years, companies could see a good return on their investments, and thus application specific hardware dominated the design and development process. This approach, that lasted well over twenty years, resulted in significant benefits to computer architecture. It gave us Graphic Processors, many types of standard I/O Controllers, and a number of robust format standards.

The advancements in silicon manufacturing did have what ASIC designers might consider a negative side effect: the amount of space on the die that could be dedicated to memory increased significantly, especially since the turn of the century. In addition, processing speed is now such that, with the exception of very few niche applications, this is no longer a problem for consumer products developers. The impressive reduction in market life of electronic products, most do not generate significant revenue for more than nine months, combined with the new-found hardware capabilities has swung the pendulum back toward software as the most efficient implementation tool.

And yet, interactive games, the market sector that generates the largest profits in the electronics sector, still requires dedicated hardware design of the highest quality. Those who say that we have enough transistors on a die, or that ICs have has much computing power as they will ever need, or even that transistors are as good as we will ever need, demonstrate a troubling superficial understanding not only of today's market requirements, but of untapped markets requiring very large storage capabilities, wideband communications, and parallel execution using heterogeneous processors.

It is not us versus them, it is us and them together forging an integration of disciplines that allows superior solutions to known problems and cultivates the ability to develop practical solution to problems we have yet to understand and tackle.

Comment on this blog entry

April 17, 2008
Intellectual Property: Joy and Sorrow
By Gabe Moretti

Attending the Intellectual Property Symposium at the Fairmont in San Jose has been a great experience. It served to provide information that has consolidated intuitions I have had for some time about the world of IP, and also gave me new insights on the industry.

I now have a much better understanding of the reasons behind the debate regarding whether or not IP belongs in EDA. My approach had always been that since IP blocks are a necessary component of ESL design, the development and commerce of the blocks is an EDA activity. But having listened to many speakers explore the legal and financial aspects of the industry, I now understand that both vendors and users of IP must use methods that are different from those in traditional EDA for transacting business. Of course the methods are also very different from those used in the semiconductor industry, so I am now leaning toward the position that IP is its own industry.

In the last two days I have learned more about patents than I thought there was to learn. Speakers in the legal and business track discussed the process required to obtain a patent and more importantly the process to be followed to license the patent to a company. If I had any entrepreneurial dreams of becoming a millionaire by licensing my invention to a big company, I now can kick back and tell myself that given the probability of success, my time is much better spent on the golf course, especially since I do not have the amount of money required to pursue the extremely protracted legal and business negotiations required to achieve the goal.

The technical track also had new information for me. The most important thing every designer must learn is that any change to a third party IP has significant consequences on the project schedule. Peter Hirt, of STMicroelectronics, shared with the audience the fact that internalizing an IP block they had licensed from a third party vendor cost the company six times the amount they had paid for the original license. Most of the cost was incurred in developing a verification environment for the block that was compatible with the one used by the engineers on the team.

In a talk titled "Achieving Maximum Silicon Reuse: Lessons Learned from Benchmarking 1,200+ SoC Projects" Ron Collett showed the impact of changes to third party IP on schedules, using actual performance measurements from real designs that had reached commercial production. A 10% change spread among all of the third party blocks in a given design resulted in more than doubling the development schedule, something that is not intuitive. The same magnitude of impact was also reported by other speakers during the Symposium.

Mark Gisi, of Wind River Systems, talked about the pitfalls of using third party software, especially Open Source software, in developing a proprietary product. Developers are often not aware of the rules surrounding the various licensing mechanisms used in Open Source, and the omission of due diligence can be quite costly, both in financial and in public relations terms, for a company.

I no longer consider a IP block the equivalent of a standard part of old: it is more than that, in technical, financial, and legal terms. Although it may be obvious that companies must educate managers and engineers by providing an understanding of the legal issues regarding reuse of both soft and hard IP, it is also clear that education on the technical uses of IP is required. By attempting to improve an IP block a development team might doom the project to failure because the resulting schedule slip can result in missing the market window for the product.
Comment on this blog entry

April 09, 2008
RF Design on Printed Circuit Boards
By Gabe Moretti

Every once in a while I get one of those "How could I forget that?" moments. I got one a few days ago when I remembered that RF design implemented in integrated circuits is not the same as that implemented in Printed Circuit Boards (PCBs). The cause was the joint announcement by Mentor Graphics and Agilent that they had developed a new integrated design environment for engineers doing RF design on PCB. (See

Cadence, of course is the reason I should have remembered all along. Virtuoso is the graphical environment for IC designers that are Cadence's customers, and they use Spectre, GoldenGate (also from Agilent) or any other RF simulator that is integrated in the Virtuoso Multi-Mode Simulation environment. But for those customers that are designing PCBs, the environment is Allegro. From there they have the choice of a few simulators, including Agilent's ADS, but the simulation environment is not as tightly coupled to Allegro as in the case of the IC design system.

Cadence introduced RF simulation capabilities for PCB design in June of last year, in response to several requests coming from Far East customers, most of them in China.

Just to complete the picture, Eldo RF is the Mentor simulator to use for IC design, while the company has no proprietary RF simulator for PCB design. According to John Isaac, a European customer asked Mentor to provide the RF simulation capability in their PCB design tool two years ago. It has taken this long to find a partner (although I suspect the customer already used ADS), negotiate a deal, and develop the required software. The result is that a designer can enter a circuit in the Mentor environment, simulate it in the Agilent ADS environment, cross probe and debug in either environments, and end up with a verified circuit in the Mentor environment ready to be integrated with the digital portion of the PCB.

I am sure that a few of you are now asking what took so long. After all one only needs common libraries and a package that supports dynamic linking between the two tools. Well it is a bit more complicated than that. You need to pay attention to the semantics of the interface and Mr. Isaac says that one of the weaknesses of prior Mentor PCB offerings was that "we did not understand RF". So one has to factor in the time required to gain the understanding necessary to learn how ADS speaks RF and translate it into as common a language as possible for both Board Station and Expedition tools. Considering that the null project takes nine months, two years is not too bad.
Comment on this blog entry