The Problem With EDA Standards

In the EDA industry, does standard mean the same as it does in most industries? The Free Dictionary defines it as: Something, such as a practice or a product, that is widely recognized or employed, especially because of its excellence. In the EDA industry, a standards body is the place where EDA companies and customers come together to try and bring about convergence, often in a new or emerging area. It generally is based on a strawman supplied by one of the major EDA companies, and in most cases it will be populated by interested parties whose tools or flows are dependent on it. Those strawmen often have been worked out with a select group of customers and gone through a proof of concept implementation before being offered up for standardization.

Design houses often look for something to replace an internal methodology so they no longer have to support internal tools or scripts and instead can have the role and responsibility taken over by the EDA company. The work in the standards group attempts to bring about convergence between similarly minded people and results in a document that we call a standard.

The problem is that multiple EDA companies may be competing in a similar area of technology or coming at the problem from a different perspective. For each company the solution is the path of least disruption for their existing tools or methodologies. When multiple companies want to standardize a strawman, the industry has more than one standards group that can host competing ideas and each can produce a ‘standard’ at the end of the process. In some cases a standards group will make a request for donations and then select the one they believe is the best base on which to build a standard. However, this sometimes creates a sore loser.

But at this stage, none of them is a true industry standard; they are merely working documents along the path to discovering the final solution. The industry has another standards body that it uses to finalize a standard, namely the IEEE. This provides a much more rigorous review of the work and draws in a larger group of people to hash out the finer points of the standard.

How does this compare to the rest of the electronics industry? Think about Betamax and VHS, or Blu-ray versus HD DVD? The difference is that in other industries they tend to duke it out in the market until a single winner is found, whereas in the EDA industry we grind away to bring about some kind of convergence. This has the opportunity to create something better than any of the original strawmen.
There have been examples of one solution being overwhelmed by another (SystemVerilog versus e), there have been cases where two standards were left standing (VHDL and Verilog, although nobody agrees that this was good thing) and there have been cases where a third solution was defined to replace all of the other candidates (VMM, OVM, UVM).

An ongoing battlefield
Each and every time one of these battles emerges, politics comes to the fore. If we examine the case of the power format struggles we can see this in action although this one has been uglier than most.
Power has become a major design and optimization criteria, both in the mobile and server markets. Unlike other optimization parameters, power is a system-level issue and optimization is spread throughout the implementation processes. Before the development of the power formats, various pieces of the flow started to include power information in a piecemeal manner. Power intent cannot be described in the design file. And even if it could, that would inhibit one design being implemented in several different ways, each with a different power/performance tradeoff. So an independent file is used to describe the power intent and this information is made accessible to all of the tools in the flow. The aim of the Common Power Format (CPF) and Unified Power Format (UPF) is to centralize information related to power into a single description.

Power intent drives all tools in flow. Source: Cadence Design Systems

There are two major camps in this debate. The first was created by Cadence, the Common Power Format (CPF). They worked with several customers and some EDA companies to craft CPF, but Cadence kept control of the specification. It is what we call an “open standard” in this industry—open in the fact that select people can access and use it for incorporation into their own tools, thus enabling a flow to be created within the industry, but not truly open in that everyone could use it. Because of this restriction, Mentor and Synopsys banded together to construct a second format from scratch called the Unified Power Format (UPF). Accellera was the place used for their discussions. Because Accellera was driving toward a truly open standard, Cadence needed to open up CPF and chose Si2 as their forum, even though they believed that the technology was not yet stable enough to become a standard. The Accellera committee managed to reach consensus quicker and released their first standard in early 2007 ahead of the Si2 release a month later. Cadence and Si2 continued to develop the standard and came up with version 1.1 in 2008. The CPF updates were based on continuing donations from systems companies and merged into the base that had been in use for some time.

In the meantime, UPF 1.0 was handed over to the IEEE for a higher level of ratification. Steve Schulz, President of Si2, says “The simulation semantics were better and more thought through than what we had in CPF, but many other parts of it had never been tested or used.” The IEEE did a lot of work to tidy up the standard and fixed several problems with the original contribution. But as Qi Wang, technical marketing group director at Cadence recalls, “In the last minute, UPF 1.0 was included 100% into the standard to preserve backward compatibility. This created a lot of confusion since there are methodology differences in the true 1801-2009 and UPF 1.0.” Schulz concurs: “The industry now had competing semantics in the same standard and when it came time to update the standard, some of the original constructs had to be removed.”
A senior person in a system design company, who asked not to be named, said that “pushing it through the IEEE was a political attempt to get a leg up on CPF and was done in a rush. Now everything is being re-envisioned and because of this support in EDA tools is going slowly. EDA companies are waiting for their customers to tell them which commands they need to be supported. This means that implementation is being done piecemeal. When we ask for features we find that some vendors tell us that they cannot support them. It shouldn’t be this way around.”

The competing standards started with some large differences in methodology and the ground that each covered. While there was a significant overlap, they each had unique capabilities and different approaches to similar problems. Venki Venkatesh, senior director of engineering at Atrenta, says “There has been an earnest attempt at bringing about convergence [between the two standards]. The UPF committees have been borrowing from CPF, and the CPF community is gladly lending.”

Two standards create extra work for EDA companies attempting to fit into both flows. “We have to understand both of the standards and the areas in which the concepts are different,” Venkatesh notes. “It is a fair amount of work trying to keep up with both standards. Many companies are using the two standards at different places in the flow and this requires making sure that power intent is correctly expressed in both. For example a company may use UPF in the front-end and CPF during implementation. This may force them to use a subset that is supported in both.”

Politics and money got in the way of the process because nobody wants to concede the advantage to another EDA company. Is this messy battle almost concluded? Not really. Si2 is continuing their work on both the modeling and the format side. They are working on extending into other problem domains. “Power is too important to give up on,” Schulz says. “We are adding information about static timing analysis and how this relates to power states. We are also working on system-level modeling (top-down refinement versus bottom-up composition), bridging the gap to the embedded software world, analog power, thermal concerns, electrostatic discharge issues and many other areas. We believe that we can offer unique value in this area if we can pull it off. We have pledged to continue making contributions to the IEEE 1801 working group.”

The message in all of this is clear. If the industry believes it can sit back and relax while important issues, such as power-intent formats, are being hashed out in the standards groups and that they can just enjoy the fruits of the standards group’s labor, then they may be in for a surprise. The solution created may not be in their best interest. Get involved, because your future success may depend on it.