The Problem With The Tools: 4 reasons embedded tools are not up to scratch

In the Electronic Design Automation (EDA) field it is widely acknowledged that the state of the software has not kept up with the rapid advance of the hardware. At the 2009 Design Automation Conference (DAC) in his keynote speech “The Tides of EDA“, Albert Sangiovanni-Vincentelli, co-founder of Cadence and Synopsys, said “At the system level, we should look closely at embedded-software design as a great opportunity to innovate…For the past six years, keynotes at DAC pointed out the great importance of software for electronics, even for the semiconductor industry…There is consensus about the need to change the way we design software in general…

So what is it about software tool development that has meant the tools are not up to scratch ? Here are four challenges developers have to contend with.

1. Tool complexity – the tools do a lot, whether it is dealing with routing algorithms or enabling one to build a system-on-a-chip, there is a great deal of functionality to contend with. All this has to be handled while ensuring the tool remains fast, robust and easy-to-use.

2. Short timescales and limited resources – as ever time is of the essence as the rewards are huge for being first to market. However the current economic crisis makes things worse as it means companies have to work out how to deliver in short timescales with limited resources. This often leads to compromises being made which detract from the tools.

3. Sophisticated users – today’s users are increasingly sophisticated. They have specific notions of what tools should look like and how they should work. Often embedded tools suffer from usability issues as they have not spent enough effort focusing on the end-users needs and optimizing key task flows

4. Integration Demands – an extra burden is put on developers to get integration right. Today tools cannot exist in a vacuum and must play nicely with the existing systems out there, whether they are build systems, revision control or text editors. Dealing with integration issues complicates the lives of tool developers as these requirements often arise further down the project life cycle and require a high level of adaptability.

Eclipse Summit 2009 – Short Talk Proposal

The planning for this year’s Eclipse Summit in Ludwigsburg, Germany is underway.
We’ve put in a submission for a short talk to present the work we did at Diamond Light Source. You can view the abstract here. The talk will focus on taking Eclipse into a new scientific domain, with the potential of forming the basis of an open source platform for synchrotron data acquisition. We envisage this would meet the criteria of getting people excited and engaged at the potential for Eclipse to conquer this new territory. Whether the committee agrees with this remains to be seen. The level of talks at Eclipse conferences and summits is always very high so it would be great to make the cut. However competition is stiff and at the time of writing there were 152 submissions to contend with. The talks will be chosen by August 25th, so we await the decision with bated breath…

Kichwa Coders at the Great Marlow School

Back in March, Kichwa Coders was invited to participate in a Buckinghamshire Education Business Partnership (BEBP) at the Great Marlow School.

Kichwa Coders was asked by BEBP if we could provide a mentor for an Enterprise Day. I volunteered to attend the 18th of March session for year 10 students (14-15 years old). The day focussed on a brief prepared by Urban Media looking to get input from the students on a new Family Entertainment Centre to be located in South Bucks.

An Enterprise Day is a day for the students to experiment with some real life business problems. The school or a company from the community puts forward a real life challenge to the students, and under the guidance of a group of mentors they come up with a solution and then present the results back to the mentors and their peers.

In the case of the Urban Media challenge, the class of approximately 200 year 10 students were divided up into teams of 8 students each. The teams had about 4 hours to read the brief, and complete a set of tasks before finally presenting their results to a couple of the other teams. The tasks were:

  • coming up with a name for the family entertainment centre,
  • create an advertising campaign which included 2 posters, a radio ad script and a storyboard for a TV ad,
  • develop two “zones” in the centre, a learning zone and a gaming zone, the result of which should be a diagram for the zone detailing the activities and look and feel of the zone
  • come up with the concept for two additional zones and provide the same material as above
  • create a presentation to explain to Urban Media, the mentors and fellow students what the team came up with.

As you can see, the students had a huge amount of work to do. I was mentoring three of the teams providing them with guidance and encouragement on these tasks. Some of the students really impressed me with the level of dedication to this task, clearly demonstrating a level of maturity ahead of their age. The result was that all the teams did a very good job, and even though I thought it was a very short time to complete so many tasks most of the teams did.

The Enterprise Days are very good days for everybody involved. The students have an opportunity to complete some real world experience, the mentors get invigorated by the unbounded energy of teenagers, and the sponsoring company gets invaluable ideas from brainstorming with so many people. I am really looking forward to next year’s round of BEBP Enterprise Days.

SWT_AWT Bridge and Code Reuse

Moving an existing application to a new platform can be a huge undertaking, often requiring re-writing large portions of the code base to work in the new framework. However, moving a legacy AWT/Swing application to the Eclipse platform does not mean having to abandon the existing GUIs to take advantage of what Eclipse has to offer.

Take Diamond Light Source’s GUI for Data Acquisition (GDA) as an example.

Diamond’s GDA application was originally developed as a monolithic application using Swing for rendering GUIs. As the number of users and developers grew, Diamond decided that Eclipse could quickly provide new features, scalability and improved component interoperability. However, there was a problem with transitioning to a new platform: a large investment had already been made in Swing.

The Eclipse developers had already solved this problem though. They created an SWT_AWT bridge that allows a Swing/AWT component to be added as a component to an SWT composite. This bridge significantly simplified how Diamond was able to transition, by reusing existing Swing components, but still taking advantage of the new capabilities that Eclipse/SWT has to offer. A prime example of a feature that Diamond GDA users and developers desired was more control over the layout of the GUI. By embedding the existing Swing components into individual Eclipse views in a short period of time all the previously mostly static components were draggable, dockable and closeable.

The SWT_AWT bridge lowered the barriers that Diamond had to transitioning GDA to the Eclipse platform. Instead of having to re-write all the necessary component in the new framework, Diamond developers were able to take advantage of Eclipse very quickly and roll out those improvements to the users in record time.

For the technical details on how to use the bridge, see the excellent article by Gordon Hirsch Unfortunately, integrating the SWT_AWT bridge has suffered from some headaches when using Xlib (as used on Linux/GTK systems). Some of the Xlib APIs are inherently not thread safe in their design. For example, XSetErrorHandler, which returns the old error handler when setting a new one. Without some application level locking, it is easy to get the error handler into a state when the currently installed error handler is incorrect. When using the SWT_AWT bridge, two separate threads are both accessing Xlib APIs. This can cause the AWT thread to have a stack overflow. The underlying problem will remain due to the Xlib APIs, however, SWT and AWT can avoid using XSetErrorHandler, and therefore avoid this issue. These issues are discussed more fully in Eclipse Bug 171432. The AWT issue has already been fixed in JDK7 build 60, but the fix has not yet been back ported to JDK 6. See Bug and Revision with fix.

Leveraging the Power of the Plug-in

The beauty of the Eclipse platform lies in its plug-in architecture. This extensible architecture was the key motivation for migrating Diamond Light Source’s existing IDE (GDA) to the Eclipse platform. In doing so it was hoped that the GDA would benefit hugely by being able to leverage open source plug-ins. Work began on developing a rich-client platform (RCP) prototype to try to achieve this goal.

In developing the prototype, this goal was quickly demonstrated. The GDA had a custom log panel which was used to display log messages. In Eclipse, the logback plug-in was dropped into the prototype and this instantly gave an equivalent log console that was able to display the log messages – without requiring a single line of code change. In addition, the new log console came with additional features the original lacked, such as the ability to configure the message properties. It was not all plain sailing though, as one issue with using the logback plug-in was managing the versioning. On upgrading to a newer version of the plug-in the console failed to work, meaning that GDA could not take advantage of the latest version until the issue was fixed. When incorporating third-party plug-ins it is up to the user to ensure they contend with handling the versioning and compatibility of the plug-ins. The more they are in touch with the plug-in providers, the easier issues can be resolved.

Following on from the quick success of the logback plug-in, the next step was to attempt to use the Pydev plug-ins to provide a Jython editor and Jython console to replace those of the existing IDE. This was trickier to do, but nonetheless after going through the readily-available code and understanding how things worked, we were able to provide a fully-featured Jython editor and console in a relatively short time. In addition we were able to integrate the plug-ins with the existing codebase in such a way that it allowed auto-completion on not just Jython keywords but also GDA system specific functions. It was a great example of leveraging open source plug-ins out there. Some of the issues in general with using the Pydev plug-ins revolved around the dependencies – for example using the editor plug-in relied on pulling in the JDT plug-ins which then introduced unwanted functionality into the GDA RCP prototype. Once again these issues can be resolved, even more so by working closely and contributing back to the Pydev project.

In addition, we were also able to demonstrate integration with the Desy project. Using their plug-ins we were able to use their Signal Probe view and connect up the GDA back-end to it to generate the data. This was done after alot of time understanding the code-base and done to a prototype level, but nonetheless showed how two independent plug-ins developed within the same field could be used together thanks to the Eclipse plug-in architecture.

Thanks to the nature of Eclipse’s plug-ins, IDE providers are able to take advantage of existing code-bases to obtain functionality that would take months to develop in-house. Also code bases can be shared between different institutions, thereby helping pave way for setting standards within the field. Of course to receiving the maximum benefit comes by working closely with those who produced the code in the first place – but the more you put in the more you get out.