Eclipsing IDEs

In a discussion with Hilde Goosens at Sigasi, she reminded me of an important topic, relevant to the Sigasi platform. Some aspects of technology benefit from competition, others less obviously so and some absolutely require standardization. Imagine how chaotic mobile communication would be if wireless protocols weren’t standardized. That’s an obvious case, shared with many other “invisible” standards whose details aren’t directly apparent to us consumers. Some standards are much more visibly apparent, some open standards, some defacto standards.

The Android interface is a good example. Perhaps user experience (UX) interfaces are the next battleground for adoption of standard/open solutions. Android took off because phone manufacturers saw Android lowering the barrier to consumer acceptance and in improved integration between applications. Why shouldn’t the same reasoning apply in professional and technical applications? That doesn’t mean that, following Highlander, there shall only be one. We still have iOS and Android but, thank goodness, we don’t have 50 different phone UXes.

In system UXes we have Windows and MacOS and a variety of flavors for Linux – Gnome and KDE among others. This is a bit more scattered, but users tend to live in one environment or switch between a favorite Linux UX and one of the mainstream UXes, so not too bad. IDEs (integrated development environments) tend to be much more tool-specific. Think of Visual Studio from Microsoft and DreamWeaver from Adobe. These are custom-crafted interfaces, tuned to work with the vendor’s underlying technology – compilers, profilers, debuggers and so on. They allow for plugins from 3[SUP]rd[/SUP]-parties but if there isn’t a suitable plugin or you want to link to a tool from a competing vendor, you may be out of luck.

Which is probably why Eclipse, an open-source IDE, recently ranked in one index as one of the top two IDEs (Visual Studio was slightly ahead) with more than 2x market share over the nearest rival. Software developers need to jump around between a lot of different development, build, test, debug and visualization contexts, so the less unnecessary differences there are between these contexts, the better. Individual application windows still have their own menus, buttons and visualizations but the basic look and feel across the system is the same and the platform encourages tight interoperability between views (copy/paste, cross-probing and so on). Eclipse already has support for C/C++, Java, PHP, JS, CSS, HTML, along with lots of tools for Python, UML, Git, Subversion, among other development options. Why try to recreate or integrate all of that in a custom UX?

What does this have to do with hardware design? Tool vendors necessarily started and have evolved with the UX platforms that were available – originally perhaps Tcl/Tk, more recently Qt. Switching to a new UX platform is a very big and expensive transition (not so much a competitive issue), so movement in this area isn’t happening quickly. Nevertheless, Xilinx, Altera, Mentor and ARM all have investment in Eclipse-based tools for obvious reasons. If development in your environment also must support integration with a wide range of embedded software tooling, you have no hope of adequately supporting all possibilities in a proprietary UX; you must go with an open environment. The same pressures are likely to be seen in EDA tooling, where the line between hardware and software build and debug is increasingly blurred.

There’s another important consideration; safety standards like ISO 26262 are creating a lot of interest in building integration around common platforms like Eclipse, to minimize potential disconnects and information loss in transitioning between disconnected tools. Over time, expectations here are likely to switch from desired to required. I’d be unsurprised to learn that hardware tool vendors are fully aware of this need and already have plans in this direction.

Of course Sigasi already support Eclipse. You can integrate Sigasi code creation, checking and other tooling directly alongside your other Eclipse tools. You can get more information HERE.

More articles by Bernard…