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

A Bigger Pie : Value Addition In the ASIC Ecosystem

There were a couple of press releases this week in which companies attempted to add value to their primary products in an interesting way.

#1 DFT + IP

Virage Logic's bid for LogicVision might seem puzzling at first. Why would an IP company want to take over a DFT EDA vendor? My take is that Virage Logic intends to provide customers with the IP and the means to test them. The only problem bigger than IP integration is IP test! Poor documentation, absence of proper test-friendly structures and long verification cycles are commonplace when IP vendors provide just their IP and a test document of questionable quality. Using LogicVision's test and diagnosis technology, it's not hard to envision Virage's IP coming with fully integrated self-test structures that require just a little glue logic from the IP integrator for complete testability.

#2 Open Source + ASIC Products

How can an ASIC/System vendor increase the demand for its products? Realizing that the software built upon the hardware is the real driver for demand, XMOS is using open source to nurture an ecosystem around its hardware platform (programmable event-driven processor arrays). It doesn't hurt that it also allows XMOS to demonstrate the flexibility of its platform when it comes to applications. Xlinkers is a user-driven open-source community for software utilizing the XMOS platform. An open source community hosting a variety of (constantly maturing) applications is a huge vote of confidence for users considering XMOS products. Not only do customers get to appreciate the flexibility of the platform but they also get a head start by reusing the developed open-source components as building blocks for their own products.



Tags : ASIC, VLSI