I would like to add to Brian Bailey's comment.

It's true that today's designs are very interdependent and iterative. An example in the FPGA Design might include the fact that routing can affect electrical characteristics and hence the performance of the design. Hence, the tool must be a 'Jack of all, master of all'.

One can argue between open-source and closed-source EDA tools, but to categorize Eclipse as the former one might not be a suitable one. And plug-ins is a too-cute word to work as a 'pronoun' for integrated, complex tools within EDAs !

BTW, I = Integrated :-)

Hendrik, it's great to see you working on a piece of the IDE puzzle. Maybe I should switch from emacs VHDL mode.

I recall discussing the need for an IDE with some colleagues while working as a VHDL design engineer almost a decade ago. We were familiar with CodeWarior and Eclipse, so we knew what was possible. My, things have come a long way since then for Eclipse in the software world. For the hardware world, there is still a long way to go INHO. The FPGA space may offer the most hope.

I wonder if the EDA user-base is broad enough to support re-factoring the flow to Eclipse. There is just so much legacy built into the leading tools and flows. An Eclipse based flow is ideal and I think it could meet all the requirements if there was enough market support.

Someone recently asked me if our SpectaReg register management tool works with Eclipse. "Yep, it does," was my response, "and you don't even have to install a plugin."

"How can it work in Eclipse without a plugin?", the person asked in bewilderment.

It runs in all the main browsers, including Eclipse's "Internal Web Browser." SpectaReg's GUI is 100% javascript/DHTML.

We use Eclipse for a lot of internal development at PDTi and I think it's good for the most part. Great to have so many useful plugins and such dynamic support for coding and debugging. My main complaint is that it's a resource hog, and it's hard to get all the different plug-ins working with a specific instance due to dependencies.

I think more EDA apps should be offered as a Software as a Service. Think Google Apps for EDA. This provides simplicity, platform independence, no installation, no updates and patches to worry about, built in collaboration, versioning and permissioning.

[If you haven't tried Google spreadsheet for a collaborative effort, I'd highly recommend it.]

Eclipse has seen use in the EDA world. Mentor Graphics' Platform Express, Space Codesign's SpaceStudio and Duolog's Socrates platforms are built as Eclipse plug-ins. ARM created an IP-XACT XML 'packager' in 2006-07 for the 1.2 release, again built on Eclipse. There are probably a few more, but the tendency does seem to be newer tools rather than releases of older and likely more complex platforms (harder to port as Eclipse plug-ins). Other EDA offerings exist, I'll let them speak for themselves!


[Disclaimer: I was part of the Platform Express program while at Mentor Graphics.]

I think it is very clear why hardware developers do not use IDEs. The work they do is very different from a software engineer in terms of the tools and flows involved. In the software world, the edit, compile, execute, debug flow is fairly well contained. What is that flow for hardware people? This is why many HW EDA tools contain mini IDE's for examining and editing source code within the context of a single tool. Those IDEs are consistent enough that it does not take an awful lot of learning for each one, but yes - there would be an advantage if they all used the same one - the same code. Now all you have to do is persuade Mentor, Cadence and Synopsys, for starters, that they should create all of their tools as plug-ins.