Come Together Right Now (Over Me) : EDA Standards That I'd Love to See

It's great to see the EDA industry going pursuing interoperability via standardization. I think I'll keep the rants about there being two competing standards for almost everything (Verilog vs. VHDL, ECSM vs CCS, UPF vs. CPF) for another post. The industry has done a great job on two fronts: libraries (Liberty, GDSII, LEF) and design intent (UPF, CPF, SDF). Two areas that are conspicuously devoid of standards are implementation and sign-off. The items on my wishlist below fall into one of the two categories.

#1 Physical Design Verification

This seems to be one of the low-hanging fruits ripe for standarization. The manufacturing rules for GDSII, regardless of the implementation tool, are the same. Yet, EDA vendors or foundries spend translating the same rules into a multitude of languages. Wouldn't it be great if every physical design verification tool supported the same rule format?

#2 Parasitic Extraction

There are only so many things one expects to be present in an RC Deck. These values, much like in DRC decks, are constant for a given process. It can't be hard to develop a common extraction rules format. Vendors can still add value via the speed and accuracy of their RC estimation algorithms.

#3 Crosstalk (Delay and Noise)

Standard delay calculation is, in essence, interpolation of a LUT. Thus, tools from different vendors usually correlate very well for non-SI timing. Timing with SI is the real problem now. A standard for crosstalk impact estimation would go a long way in addressing one of the greatest pain points in ASIC design: A scenario where the implementation tool and sign-off tool do not agree with respect to the timing or noise impact of crosstalk. If buying the implementation tool and sign-off tool from the same vendor is not an option, ASIC design companies are left with the unenviable prospect of multiple iterations to close SI-aware timing. There are two issues here. One, each vendor is convinced that their approach to crosstalk is the right one. Two, vendors don't publish their delay calculation methodology so that customers can examine the merits of the competing approaches. It's hard to say if vendors view their delay calculation methodology as the core of their tool and are unwilling to publish it for fear of competing implementations. If that is the case, good luck to ASIC design companies. They're going to need it.


#4 Implementation

This is a tough one to get consensus on. It's also interoperability cranked up to the max. Imagine of every design tool spoke the same language. Imagine no more tool-specific scripts. Tool scripts that work in one tool environment will work seamlessly in another regardless of the flow. You only need one set of scripts regardless of the vendor. The problem getting this to work is two-fold. One, tool languages are a certain way because of the tool architecture. It's not going to be easy supporting the same language on different architectures. It shouldn't be impossible either. A common implementation language seems to be the same as a common design intent language (such as SDC) except for the increased scope. Two, different vendors have features that competitors might not possess and so require different commands to exercise these features. For example, if one vendor has technology for sequential scan-compression logic while another has a combinational scan-compression technology, it's going to be hard to get them to agree on a common set of commands.




Tags : ASIC, VLSI