As far as Linux IDE's go, there's a decent number of modern options outside of Eclipse - KDevelop has matured a great deal and is quite stable. Anjuta 3 is a great alternative to KDevelop on GNOME desktops. QT Develop is a good C/C++ IDE, even if it's centric to QT development obviously. Code::Blocks is a good option if you're using wxWidgets for development. Don't forget NetBeans works quite well on Linux workstations.
I cross trained from EE to MS .NET in 2004. since that time i have been designing/building .net based remote control apps of embedded device under test, and control of electronic test equipment. I am now working on .net GUI to embedded device remote control, next FPGA/CPLD. I would like the opportunity to provide unique .net based tools that provide functionality that development teams desire. i am taking these comments here to heart as to discover desired functionality.
have a good day.
I had to admit from my experience that eclipse is the only IDE environment I could find and afford (free). My ear is wide-open to anyone out there, if there is any other IDE that is capable of flexibility at no-cost.
However, I was only able to use eclipse IDE in 2 projects in my 20 years DV experience. It is not that I donít want to use, but I donít know how to set it up as if I used to have or a company does not want me to spend a time on it.
In authorís article, there is a quick mention about consultant. You read my mind. Every client has their own directory structure, library name and corresponding instance name, simulation and log files/directories, not to mention about a debugging by matching waveform, error message and waveform. I had a very sweet time over 2 projects, because someone already set it up to link each Eclipse window for its own usage.
Other GUI environment, xvcs, questasim, incisive, or Debussy, tried to implement its own IDE. That is much uglier. My clients decide to use their own choice of tools to substitute one or many part of those EDAs. It is not matter of linux command line pipeline. It is not matter of emacs vs. vi.
In my matter, it is a consistent environment to deal with regardless who is my client would be. If someone develops a well-developed eclipse and plug-in together, I will be the first person to use it.
I am also not a fan of Eclipse-like IDE. The people I know who use Eclipse are those coming to Linux world from a Windows background. It looks to me they do not know how to use vi, emacs and the tool chain (effectively). They are not the best programmers in the team no matter what titles they have. While there's no Visual Studio on Linux, the resort to Eclipse, feeling back at home (Windows). For a Unix/Linux veteran, the initial Eclipse experience can be very uncomfortable. It is slow and a memory hog. When it crashes, everything just disappears instantly from your desktop.
I am not against graphical IDE in general; I like Visual Studio when I work on Windows. But on Linux, I haven't seen a graphical IDE that really productive yet. Maybe we can expect a really good open-source open platform IDE (as efficient as Linux tool chain, graphically appealing and feature-rich as Eclipse but written in native C/C++, but Java) in the next 10 years.
Anyway, people just have different tastes, keep up the efforts and I am sure that it has its own market.
For SystemVerilog, I use emacs almost by default. The combination of verilog-mode (http://www.veripool.org/wiki/verilog-mode) and snippets (http://coverification.com/2009/12/17/systemverilog-snippets-for-emacs/) works well enough, but when I'm deep in my environment trying to remember the name of a function or task for a specific class, I would love a nice IntelliSense like any other software IDE. And emacs (still) isn't really for the faint of heart, even with all the help online.
I've tried SVEditor plugin for Eclipse (http://sveditor.sourceforge.net/), and it works fairly well, but the intellisense breaks down a bit for macros and large projects.
Doesn't EMACS provide a lot of the capabilities of an IDE? Syntax driven editor, change, build, debug flow support. Also what about the GUI's offered by the various tool vendors: where do they fit in? Historically these have been seen as for beginners and tend to slow down the development process requiring lots of mouse clicks to do something a couple of keystrokes can do (e.g. !r). Also graphical tools have been seen, historically, as associated with out-dated design methods (schematics)
No matter how good the IDE is, I believe what you call toolchain management should be based on the command line ad command scripts. The reason being is that with confidence comes the desire to stretch your tool in ways not envisaged by the GUI. Having all functions accessible by script will allow one to automate a flow in the way one wants and in the scripting language one chooses.
My Mom the Radio Star Max MaxfieldPost a comment I've said it before and I'll say it again -- it's a funny old world when you come to think about it. Last Friday lunchtime, for example, I received an email from Tim Levell, the editor for ...
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...