How Do I...?

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?

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?

Yes agreed not much information is easily available regarding EDA tools if you need any help. May be there can be more forums and engineers who have hands-on experience using specific tools give their comments with some screenshots. And then like in all forums all similiar topics are together it can be. Experience people can come in together across the world online and contribute.

I just came across this cool Web-app that makes quick videos of your screen or web-cam or audio-only, and shares them with your target list. It can make video FAQs and video knowledge base articles to drastically reduce trouble ticket volume. There is a free single-user version.

dougwithau wrote: I doubt they will ever open source the tool chains. It only makes sense to protect the income.

I don't want the vendors to open-source their tools. I just want them to document their chip architectures so that people can write and distribute alternative tools.

I didn't realize Intel produced compilers -- I thought the last one was PL/M. Just goes to show how much impact they have. Does ARM write its own compilers or do they just re-sell compilers written by a partner?

I agree, the vender version problem is a mess. Maybe tagging by version. I have found fixes and patches for old versions in mailing list threads that are completely wrong too many times to count.

Documenting the failings of a given version is not popular with the vendors.

The fact you have to poke around to figure out how to use the include files is a reason to have a Q&A site. If there is a question with the ultimate answer, you can just go back to the question and not have to figure it out yourself every time. Plus, maybe it would save someone else from the same pain.

I doubt they will ever open source the tool chains. It only makes sense to protect the income. Even open initiatives like UVM and open cores are not well supported. Intel does make it's own compilers, as does ARM. They cost money, so not many people use them. Because the tools are free, no one wants to pay for anything.

There are a number of problems. Here are several that come to mind (vendor names have been omitted to protect me):

1. Each tool release often behaves (and misbehaves) a little (or a lot) differently from the other releases. So the answer to the question could depend a lot on which release you're using, so even if someone wants to help the answer may not apply to the release used by the questioner.

2. There's one particular set of vendor tools I use that's really inscrutable about how it finds "include" files and other things. I typically only use it for one week per year, so when I get back to it I have to "explore" quite a bit to come back up to speed. I'm terrified that someone will ask me how to use the tool and I'll look like an idiot because I can't even explain to myself how to use it -- "you kind of poke around here and there and hope you get lucky". The tool suite actually has some great things in it, but finding them isn't easy.

OTOH, a different vendor's tools allow me to bypass the GUI and go directly to the command line and use a Make file to re-build a design. This is a very nice option.

3. One pet peeve is the myriad "false-alarm" warnings one gets when synthesizing a design. Hidden within those may be some important warnings, so you can't just ignore the whole lot. I wrote a "sed" script to process the synthesizer report and extract the warnings. This makes it easier to compare to the previous warnings after a design change. This only works for one release of the vendor software -- a different release could very easily make big changes in the warnings.

I suppose I should be glad that FPGA tools are so hard to grok because it makes work for FPGA consultants, but then we have to suffer as well. Plus, clients try to avoid FPGAs because it's hard to find people who can design with them.

There's a very simple solution to all this: FPGA vendors should open up their architectures so that the open source movement can produce more useable tools. Vendors would save a fortune by not having to maintain all that software and they could concentrate on silicon. You don't see ARM and Intel writing their own compilers, and look how they ended up.

Is the number of users too small? Are we all to busy to answer questions and help out other engineers?

Maybe the tools are too proprietary, and kept under the control of the vendors. Makes no sense really. You would think letting people help each other on the web would be better than paying for support people.