Opinion: Why IDEs for hardware design fail

Hardware designers hate integrated development environments (IDEs), and they have good reasons to do so. Most EDA vendors build IDEs that lock the user in. They force a workflow on the user, limit the number EDA tools that work with their IDE, and provide half-baked usability. The only way to fix this is to stop using IDEs that are built by EDA (electronic design automation) companies. Electronic design engineers should start learning and copying from their colleagues in software engineering.

What are IDEs?
IDEs are graphical front ends that tie together all of the tools you need for developing software (or for designing hardware). The general look is pretty much the same for all IDEs. You have one or more windows with several views: an explorer that shows a list of files, a big editor view, navigation views, error views, and dozens more depending on the tools you are using. The idea is that you will never have to leave this IDE. It serves as a cockpit from where you can control every aspect of your work.

Why do EDA vendors build IDEs?
I can’t speak for any of the large EDA companies, of course, but here are some possible considerations:
They want their users to pick up new tools faster, with an easier learning curve: If you can learn my tool and be productive in a week while it takes two months to master the other guy’s tool, I have competitive advantage.
A lot of things in hardware design are really two-dimensional: chip layout, design hierarchy, etc. It’s a lot easier to click in a picture than to type coordinates on a command line. Instead of having a small graphical tool for each phase of the design, EDA companies create a bigger, bundled tool that covers several steps of the design flow. You can perform all the graphical tasks in my synthesis flow with my graphical tool, which ties all of my command-line tools together.

Why this doesn’t work
Having an integrated cockpit sounds great, but there are three big problems with the way EDA companies build their IDEs:

1. Usability sucks.
2. Users are locked in.
3. You cannot customize the design flow.

Usability sucks and there is no economic incentive to improve it. Extra functionality can create business value and convince managers to spend an extra 100k on a tool. Extra usability can save the user some time—perhaps ten seconds or perhaps half a day—but you are just counting man hours here (yeah, yeah, person hours).

An IDE for software engineers can easily have millions of users. An EDA tool with ten thousand users is doing pretty well. At $60 per hour, a one-minute usability issue is worth a million in the software world, but just $10k in the hardware world. No EDA company is going to free up resources to fix small usability issues if they can work on new advanced features instead. And that’s what you can see when you use most EDA tools—very powerful complex functionality, but a user interface that is not all that intuitive.

Users are locked in, not just to their IDE but also to the whole set of tools that the IDE integrates. You want to be able to switch from one synthesis tool to another because the price is better or because the performance is better. You want to combine different tools in your tool flow, and you want to try out a new code linter tool or a post synthesis optimization. If those tools are provided by a vendor other than your IDE vendor, chances are you’re on your own.

You cannot easily customize your design flow. Command line tools can be glued together much more easily using Tcl or other scripting languages. In the world of hardware design, IDEs don’t allow for user-created additions or customizations.

Why IDEs work in the world of software
In the software world, IDEs have not failed for two reasons: large corporate support and individual grassroots support.

It takes a lot of resources and a lot of focus to create a good IDE. Only a few companies in the world can put this much effort into creating a great IDE. IBM, Sun (now Oracle), and Microsoft have done a pretty decent job in creating Visual Studio, Netbeans, and Eclipse. Jetbrains are playing along in the “Champions League” because of their tremendous focus on creating a great IDE. None of the major EDA vendors and none of the major FPGA vendors gets close to playing in the same league as IBM and Microsoft. And none of them gets as close to focusing on their IDE as Jetbrains does.

In the software world, new innovations often start as command-line tools created by individuals or small teams of developers. These command-line tools often get integrated into the mainstream IDEs. Since IDEs have open interfaces, software developers can create new plug-ins that support their favorite new tool. Even if there is no easy way to monetize the value of a plug-in or usability improvement, there are plenty of software engineers who have the skills and the incentive to implement them. They get so annoyed or excited that they’ll work on an improvement on Saturday afternoon just so that they can use it on Monday morning.

How to fix this for hardware designers
As Pablo Picasso (and Steve Jobs) famously said, “Good artists copy, great artists steal.”
There is no reason why EDA companies have to build their IDEs from scratch. They could just as easily reuse the best IDEs from the world of software engineering. Many high quality IDEs are available as free open-source software, with a community of thousands of developers and millions of users and backed by companies such as Oracle, SAP, and IBM. Hundreds of smaller companies contribute enhancements and plug-ins to these IDEs, making it a robust and feature-rich platform.

FPGA and EDA companies have already created some solutions based on Eclipse, one of the leading IDE platforms. Unfortunately, they have done so only hesitantly and have mainly focused on embedded software tools rather than HDL design. There is no reason why VHDL and Verilog development, and integration with simulators, and synthesis tools could not be built on Eclipse. Several companies, including Sigasi, are providing EDA solutions for the Eclipse platform today.

The future for digital design in is adopting the IDEs from the software world, and when that future arrives, hardware designers will get all the benefits that software designers have experienced for over a decade now. Tool quality will go up, productivity will go up, and the quality of digital designs will go up.

About the author
Philippe Faes is co-founder of Sigasi. He has a Ph.D. in computer science engineering and has done research on hardware-software co-design before founding Sigasi. Today, Philippe and his team are working to build the very best software for writing VHDL code, inspired by software development tools like Eclipse. Philippe is proud to be a geek and a lava lamp owner.

---

If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).

Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).