It's a question that we ask all the time.
How do I replace a lightswitch? How do I refinish a wood floor? How do I make a perfect cup of coffee?
For most questions in today's world, you can open a browser, type a question into your favorite search engine... and voilà, there you go! Ten seconds of typing, a few more sorting through the results, and you have an answer (or many answers!).
This process works very well for ordinary needs, like installing a home theater system, or estimating the height of a tree (before you drop it on your neighbor's car), and even for some technical questions.
However, what about questions like: How do I extract a net from a GDSII file? How do I quickly merge hundreds of GDSII files together?
When the question is how to do specific tasks with an EDA (electronic design automation) software tool, you are often out of luck with this approach.
So, what happens when design engineers get fed up with the hacked-together code or process they've used for the past two projects, and want to find a better way to do it?
The first step is still usually to search for it. Who knows? Someone might have posted it somewhere in an EDA blog or forum.
If that approach doesn't pan out, it's time to ask Bob how he did it... although Bob is in Korea (or is it India?) for a couple of months, so you might not want to wait until he has time to respond.
Hey, let's ask the account engineer... after you find the phone number. Oh, the AE's not available for 2 days?
Sigh... Well, let's go to the support site. Anybody remember their password? Eventually, someone logs on to the support site, and gets contacted by a support engineer, who usually answers the question pretty quickly.
But why is it so hard to find out how to do a specific task using a tool that costs many thousands of dollars?
Shouldn't the software interface be intuitive, or contain enough online help to make any task easy to accomplish? Shouldn't the company provide training and documentation?
Actually, EDA companies work really hard to make their software "easy to use" (really, we do!), and the documentation and training is pretty good.
The disconnect comes in three parts:
- Use it or lose it. Designers use a dizzying array of tools to accomplish their jobs, often from several vendors. Some of those tools are used frequently, others infrequently. If you don't use a tool often, or if you perform a particular task infrequently, you forget the details, and there are an awful lot of details in EDA software.
- Specificity. How-to questions are often very specific to an end-user problem, but manuals are generic descriptions of the product. Manuals describe what every button does, but not how or when to use it. Examples tend to describe how to use the product features, rather than how to solve a specific user problem.
- Accessibility. Even if the correct information is available, end-users need to be able to get to it when needed in a form that provides quick review and application. Surprisingly, users often don't have time to read a 30-page technical reference when they have a tapeout schedule to maintain. EDA companies provide a colossal volume of useful content -- and it's usually behind a support firewall (for good reason, of course). But how many users are actually familiar with all the support centers for all the EDA tools that they use? And once they get into the support site, they find every EDA vendor has a different format and framework, making it challenging to find the information they need in a timely manner.
What EDA engineers need is a better way to get practical information on how to do specific tasks. And, like I said, where does everyone go these days, when they want to get quick information about how to do something? The Internet, of course.
And if we have this medium available to us, which is accessible to everyone in the industry, why not use it? Why not take some of that useful information currently behind the support firewalls and make it available on the general Internet?
Let's make it task-specific, not generic, so people will find it when they type their question into the search engine.
In fact, why not make videos, so that engineers can see what you mean when you say "Choose the Verification menu"? Make them short, to the point, and designed from the engineer's point of view. It probably won't go viral and get 5 million hits, but somewhere out there, a design engineer will be gratefully getting a task done quickly and efficiently.
Support like this won't take away from the value of the EDA vendor's support site, because big problems still have to go through support. And it won't make obsolete your technical documentation, either, because all those new engineers still need the full roadmap through your software.
Sure, competitors can see your GUI, but that doesn't mean they can make it work as well as yours. Take a little risk, and reward your customers. Isn't that the end game?
As for making that perfect cup of coffee? Try this.
— Joe Davis is Director of Product Marketing for Calibre interfaces at Mentor Graphics. Prior to joining Mentor, Joe managed the yield simulation products at PDF Solutions and directed yield ramp projects at leading semiconductor fabs around the world.