With DAC approaching, it is a good time for both EDA companies and their customers to take a deeper look at the evaluation process of EDA tools, and how EDA companies position their tools. I hope this is useful for customers and vendors alike.
When it comes to positioning EDA tools in the marketplace there are really only three meaningful measurement scales. Products will primarily be categorized as: (1) Better; (2) Faster; or (3) Cheaper. Of course, Faster could be used as better performance and Cheaper could be viewed as better price. However, I break it down this way because, on the equivalent of the Mazlow Scale of EDA, a Better product is usually more highly valued (e.g., optimization) than a Faster product (e.g., simulation technology treadmill) or a Cheaper one. While this method is taught in one way or another at most business schools, it is relentlessly drummed into the heads of the executives and marketers at all companies mentored by EDA icon, Jim Hogan (who says he actually borrowed it from Isadore Katz). So, for now, I will refer to this as the Hogan Scale.
What makes a product better? Generally we look at two broad categories – quality of result (QoR) and ease-of-use. The method to measure QoR will vary based on the product category. For example, you might measure QoR for a IC place and route product by result chip performance, power, and area (PPA). For a circuit simulator QoR may be primarily measured on accuracy or debugging support. Each customer needs to list and rank the criteria that matters to them. Do not include vendor-touted features unless they matter to you over the time period of the license you are considering buying.
Most benchmarks focus on QoR, leaving ease-of-use as a part of the Better measurement that is often undervalued. However, sometimes ease-of-use is measured in total clock time (set up time and difficulty; and run time). If a tool only gives good results when run by the vendor’s application engineers then you have a potential problem for several reasons: (1) you will always be dependent on support from the vendor just to get good results from the tool; (2) you may end up competing with other companies over who gets the better support from vendor; (3) if you cannot get the support you need, or perhaps cannot afford it, the tool will go underutilized; and (4) your development team may not be able to express their expertise since they cannot adequately drive the tool. To summarize, if ease-of-use is low either you won’t see the QoR you saw in the benchmark when you use the tool yourself, or you will need to rely on the vendors AEs which may be quite expensive. Perhaps more disturbing, the availability of the vendors AEs is not typically under the customer’s control.
Measuring Faster is pretty straight forward and simply requires that you give the tools you are measuring a similar amount of resources. You may need to be a bit flexible with that at times. If one vendor supports parallel processing and another does not you simply need to consider what speed you require or how much more you are willing to pay for the higher speed. Faster will often lead to better. In the classic trade-off, if you can run simulation fast, then you can do more verification by running more simulations to get better quality results from verification.
Cheaper is often a pejorative term. In this context we simply mean less expensive. If two tools are essentially similar in QoR, ease-of-use, and speed, then price will make the difference. Where there are clear differences between the tools customers should consider if saving on license cost is actually worth it. EDA tools should be a multiplier of value for customers, not a necessary evil or cost. Good engineers will produce noticeably better results with good tools than they will with bad ones.
Finally, I have been asked by small companies and other bloggers how small EDA companies can, or should, compete with the major EDA vendors. It starts by knowing where you are on the Hogan Scale. If your Better is enough, then promote that. If not, are you Faster? Cheaper simply never works for a start-up. Competing on price with the big vendors is a bad place to be.
lang: en_US
Next Generation of Systems Design at Siemens