The User Perspective on Electronic Design Automation

Hugo:

First, you have to know the IC architecture that will be used—custom, standard cell, FPGA, etc. That narrows down the tool choices. Then there are five key issues to consider when buying tools. They are cost/performance, training/support, make or buy, compatibility, and transition. Let's look at them one at a time.

Hugo:

How will the tool perform compared to similar tools? Tool demonstrations at the vendor's site, at our site, or at a conference are worthwhile. They can answer a lot of questions and raise some more. Of course, vendor demonstrations always show off the tool well (no surprise). They usually are done using small examples or to show just a few features.

Demonstrations also help to show up features from one vendor that are missing from the other. It's also good to ask each vendor why they are better than the competition.

Then you have to decide which features are most important to you. There are often several tools for a specific problem area, such as power estimation. Therefore, comparing the tools can take a lot of homework and engineering time.

Following up references is another way to gain insight on the tool performance. User groups are independent reference sources. For example, on the Synopsys User Group (SNUG) website, users describe tool problems and solutions. These include both Synopsys tools and others as well.

Unfortunately, some tool license agreements restrict dissemination of benchmark results. Vendors claim that results taken out of context do not provide a valid measurement. Therefore, users need to get comparative information informally.

What is the total cost for the tool? (Prices have varied from free university tools to over $750,000.) Tools may be bought outright, or licensed in several different ways. To compare different vendor tools you need to look at the total costs and the ROI to the user company.

What are the tool licensing options? These may be on a per engineering “seat” or per use basis or a floating license (any “seat” can use the tool). They also vary on a per month, quarter, year, or perpetual basis, and may be site-specific, company-wide, or worldwide. Table 3.1 shows some licensing options.

Hugo:

Different vendors offer different variations—and new options emerge all the time. The table gives some examples of the variables possible. The costs may vary widely. For instance, a perpetual license may cost four to five times more than a subscription license.

A design manager needs to have as much flexibility as possible. Workstations fail or become obsolete, people come and go in projects and companies. Design managers need to be able to assign a temporary license to anyone they choose, as required. This may be anywhere, on any project, for whatever time they need. EDA licensing agreements can be a substantial burden for design managers.

The user should get a free trial period and automatic warnings before a license expires. The design manager needs easy license renewal, without either user or vendor bureaucractic delays. There have been cases where a license expired at a critical time without warning and took days to renew.

Some vendors charge for the right to use the tool, whether or not you are actually using it. It is obviously preferable to be charged only when the tool is actually being used.

The total cost involves the initial cost, the technical support cost, bug fixes, and upgrades. Yearly support cost often runs 15% or more of the initial cost. (All these things are usually negotiable...) In addition, there is your own in-house support cost to install upgrades and check bug fixes.

What is the cost/performance lifetime ROI? Will this tool create a better ratio of revenue improvement than a similar tool?

Nora:

I see you need to take into account many cost factors.

Hugo:

Yes, these are expensive tools, and there are a lot of them. If they make basic cost/performance sense, then we look at the support issues.

Nora:

What kind of support issues?

LOCATION

Department, site, multisite, division, city, country, worldwide

WHO

Named person, fixed seat (machine), floating seat, # of seats, employee, consultant, subsidiary, customer, etc.

DURATION

Free trial period, month, year, perpetual, subscription (quarterly)

PORTABILITY

Fixed seat, registered persons, dynamic person assignment, anywhere, anytime

CHARGE BY

Seat, minute, hour, monthly, yearly, usage, tool run, project, location, etc.

Hugo:

EDA tools are complex, with many options and parameters to set or enter. There is a huge amount of data to be entered in specific (often proprietary) data formats. Graphical User Interfaces (GUIs) help somewhat, but they differ from tool to tool.

Therefore, engineers need training on how to use the EDA tools. There is a substantial learning curve to become skilled in using each tool. Furthermore, each (frequent) upgrade of the tool may require a refresher course.

Therefore, an important question is: what training is available? Are both initial and follow-on training included? Is emergency (24-hour hotline telephone and/or on-line) service provided? How good is the documentation? Program documentation is often minimal, particularly early in the life of an EDA tool. The vendor is focused on getting the tool up and working, so the documentation usually comes later.

How long will the vendor company be around to support the tool? Is there a backup provision to get the source code and documentation if the vendor support ends? EDA companies may fail or be acquired or merged. Their tools may be discontinued after such an event. Users then have to provide their own support or cope with a new tool and learning curve.

Will you get the tool source code (so you can modify it yourself if need be)? Perhaps you will get the tool object code (cannot modify it), or license the tool. (You normally don't want to touch source code if you are getting support and licenses from the vendor. This becomes more of an issue with an unsupported or poorly supported tool.)

Is there a schedule for updates and releases from the vendor? How and when will change control be implemented in your shop? Who will do it —an engineer or an administrator? When will it be updated—at regular intervals or at specific points in the design?

Nora:

It sounds like a long-term relationship is necessary with the tool vendors. Do you buy all your EDA tools from vendors?

Hugo:

Yes, we use only vendor tools. It's usually the easiest and fastest way to go. Most companies use vendor tools. However, some companies develop their own tools when they are not available from a vendor.

“Make or buy” is another important EDA user decision. If done in-house, the company must commit to long-term support. Just as with vendor tools, internal customers want more support and features for the in-house tools.

We also buy tools to help with essential tasks that no one likes to do. These include design documentation, user manuals, and change notices.

Nora:

Is there any problem with compatibility between in-house and vendor tools?

Hugo:

Yes, there is a big issue of compatibility between vendors tools and between vendor and in-house tools. How compatible is the tool with our existing suite of tools? (Who will make the interface translators if there is a compatibility issue?)

Will there be backward compatibility? (Will upgrades of the tool be able to run old versions of the design files?) This can be key if revisions to a product design are made (usually the case). Some managers resist installing tool upgrades to avoid this kind of problem.

On the other hand, vendors will not fix bugs on two-year-old versions (no surprise). And managers cannot easily move people from one project to another if each group uses a different tool version. So companies must upgrade versions frequently, and all users together! This is often a major complication.

Nora:

I thought that was a problem only when they upgrade the operating system. You mentioned earlier that the tools have to match the operating system version.

Hugo:

These are issues with both tools and operating systems. In addition, improvements in the tool may often be incompatible with prior design work. Developers tend to expect you to use the new tools only on new designs. You must keep old tool versions available until you are certain they are no longer needed.

Nora:

The transition to using a new tool or upgrade sounds tricky.

Hugo:

Well, you need to be sure that an engineering group/project is willing to be the “first user” for a new version of a tool or operating system.

I mentioned earlier the update schedules from the vendors. What is their timetable for bug fixes and/or upgrades for a new tool? (A new EDA product will need more productization to get it usable for a real design.) When will it be ready for your first user and will the vendor give extra support?

Is there a Trial Period and Escape clause (i.e., if you try it and don't like it, can you get a refund)? The vendor is unlikely to negotiate a low price with such a clause. But you need an agreed-upon acceptance test as a criteria for acceptance or rejection.

The internal staff also serves as user gurus for the design engineers for all the EDA. If new tools are bought, will you need more in-house staff to support them? More staff can be a budget issue unless the EDA tools are shown to directly support revenue-generating projects.

Hugo:

So those are the five essential issues in buying EDA tools. I hope you are not overwhelmed. See the little picture I have over here that summarizes the negotiation process. Everyone has his or her own focus area, but we have to cover all the concerns. (See Figure 3.2.)

Nora:

That's a good summary. There sure are many factors to negotiate. Do the marketing people from the tool vendors assist you in that?

Hugo:

Certainly, up to a certain point. Even with reference users, we always have to try the tools ourselves. We have to ensure they are really compatible with our existing tools and design needs.

Nora:

Yes, someone else mentioned the user's tool integration issue. What is the story on that?