A HW engineer and an embedded SW developer, who are slated to work together on a common project, strike up a conversation at the proverbial water cooler. 

HW guy: “I just finished a month long evaluation for a new
co-verification tool. We finally made a decision on the product
and vendor we’re going with.” 

SW guy (nonchalantly): “Really? I wouldn’t know much about evaluations, I build my own toolchain.”

HW guy: “How is that possible?  …And why would you? 

SW guy: “I’ve always just built my own using GNU tools and
what do you mean “why?” 

HW guy: “What happens if you run into a bug in the middle
of a project? 

SW guy: “I built it myself… there’s a community. You know how
they say with many eyes all bugs are shallow? It’ll be great.” 

HW guy: “Um… sure. So tell me, who do you call for support
and questions on updates?”

SW guy (down to mumbling, clearing of throat): “I support it…. and um… update it too, when, I uh… have time.”

HW guy walks away shaking his head thinking he needs to talk to the manager and no wonder so many projects are always delayed.

For quite some time now, embedded software developers compared to their hardware brethren, have had the option of “rolling their own” or building their own toolchain. As strange – and as risky – as that may sound to hardware designers, self-building a toolchain is not so unusual in the world of embedded design. This is due primarily to the availability of open source tools and components. 

The concept of open source is founded on the idea of creating and openly sharing your invention and its source materials with the community. The GNU project is perhaps one of the strongest examples of this concept and increasingly, embedded software developers are choosing the GNU toolchain for open source development.

So why is the GNU toolchain so popular? The GNU toolchain contains an optimizing compiler that specifically targets embedded processors. It supports programming in C, C++, assembly language, and compiler and linker extensions – all of which are specifically designed to assist embedded programmers (Figure 1). And because the GNU toolchain can support multiple target platforms, it makes porting code between processors less of a hassle since developers can use the same tools on multiple platforms. Of course, the greatest advantage as illustrated in our water cooler conversation is the fact that software developers can download all of the components free of charge and assemble them nicely into a tight little assembly line.

Figure 1:  Basic example of a typical self-build GNU toolchain.

But the times, they are a changing

Perhaps our little SW/HW enactment was a bit too harsh on the embedded developer and his chosen methodology of DIY toolchain creation. But the challenges and risks are real. Being self-reliant is a great thing; who doesn’t like to say, “I built this thing with my own two hands.” It’s also important to realize the changing landscape (read: greater design complexity) and how important it is to regularly evaluate available options before continuing down the same path over and over again.

Design needs and application requirements of today are far more stringent than they were just a few years ago. Thanks to the explosion of highly interactive and uber-connected consumer applications, product lifecycles are discussed in “months” instead of “years.” What may seem like unreasonable borderline sci-fi type consumer expectations, are actually translated into real-life complex design requirements – driven by even shorter project cycles. The penalty of missing a market window could mean lights out for many organizations.

In conjunction with the rapidly evolving market place, and more so in response to these needs, there has been an equivalent progress in new technologies. Today, embedded developers have at their disposal dual-core, multicore architectures; high-speed FPGAs with embedded cores; and more capable OSes with virtualization or graphic accelerators to name but a few of these technologies. In order to efficiently leverage such advancements, the right tools and methodologies need to be chosen. 

In light of all of this, it’s natural to look for processes that not only help to mitigate risks, but also serve as a competitive differentiator.  A do-it-yourself (DIY) GNU toolchain typically consists of bare-minimum components built to address the needs of a specific project at hand. Unless built in a very systematic manner and thoroughly validated, these toolchains are not scalable and their maintenance and upkeep can quickly turn into unexpected overhead costs to the organization. This problem takes on an even larger significance in organizations with multiple project teams designing concurrently. In this scenario, back-ups or bottlenecks are prone to occur as organizations struggle to find a work around.

As strong as its weakest link

The beauty behind open source software (OSS) is that all OSS downloads are available at no cost to developers. By now, most users understand that the only real “payment” is that most open source licenses require that they distribute source with their binaries.

On top of having to share source, there are other considerations DIYers must address. A DIY GNU toolchain is actually a build project upon itself which can be summarized as a collection of tools and tasks including:

• Decide on your build environment
• Obtain the source code
• Make decisions about configuration options
• Perform the build process
• Validation. Validation. Validation
• Package the toolchain

Every task requires careful consideration as each decision can influence the quality of the resulting toolchain. To start off, creating a build environment requires the right “build” tools. For example, it is most convenient to build the toolchain using another version of GCC, but if the version of GCC you are using has defects, it may incorrectly compile your entire toolchain. The urge to call it done, when the toolchain is “built,” is understandable. But it’s extremely important to validate the toolchain before deploying it in a production environment.

Validation is the task that answers “will it work in my project?” Therefore, it’s vital that you perform this thoroughly – over and over again as the code base evolves. The task involves automated tests, facilitated by available framework and testsuites, as well as interactive testing. Tasks such as compiling programs and running those programs in the target environment, compiling programs and inspecting the generated object file or executable image, compiling fragments of a program with multiple compilers and linking the fragments together, etc., are all part of a normal toolchain validation methodology.

However, in the real world, under typical project constraints, it is not reasonable to expect that every DIY GNU toolchain is fully validated as per the recommended practices. Naturally, this could have an impact on not only the quality of the toolchain, but in a worst-case scenario, on the project schedule itself.

And let’s say you pull a rabbit out of your hat and your DIY GNU toolchain is fully validated. That’s really just the beginning. As the head GNU toolchain DIYer, are you also in charge of release management and ongoing maintenance? Even though these are not part of the actual build process, they are equally important when looking at costs, time and resources spent, and the overall competiveness of your product or company. 

Moving over to the dark side

Ah, but there is a way out. An approach that gives you a fully functional and validated GNU toolchain. We’re talking about an alternative to the DIY approach that makes more sense today when you look at the complexity that’s swarming around every new embedded design. Many reputable software vendors now offer a commercial solution of the GNU toolchain. With a commercial alternative, developers still get to leverage the benefits of open source, but without the overhead and risks associated with a DIY methodology. Another advantage to this approach is that typically, they are well integrated with other embedded design solutions, such as performance analysis tools, JTAG probes, RTOSes, etc. offered by that vendor. An embedded development ecosystem on your desktop if you will. 

Mentor® Embedded Sourcery CodeBench™ from Mentor Graphics is one of those GNU toolchain solutions (Figure 2). Based on open source standards, it is a complete IDE for embedded C/C++ development on ARM, Power Architecture, Coldfire and other popular architectures. The product is developed, validated, and supported by Mentor Embedded engineers who have contributed thousands of enhancements to the GNU toolchain since 1997.  

Figure 2:  The enhanced capabilities of Mentor’s GNU toolchain (Sourcery CodeBench).

With Mentor though, it’s more than software. Going back to our HW/SW conversation at the beginning of this article, imagine if both our HW guy and SW guy shared some middle ground (Figure 3). Neutral territory. Mentor is uniquely positioned as an established EDA company to carve out some territory where both of these “counter disciplines” can actually talk back and forth. The recent announcement of a unified embedded software debugging platform, which takes users from pre-silicon to final product, based on the integration of the Sourcery CodeBench with Mentor’s electronic system level (ESL) technology, is an example of such a solution. This platform, among other things, includes Mentor’s Vista™ virtual prototyping and the Veloce® hardware emulator. Working within this platform, embedded developers can access technology data from hardware design tools without leaving their native embedded software environment. 

Figure 3: Building the ideal software development ecosystem – where all can play nice together (yellow).

So not only are things looking up for the software developer, but maybe, just maybe we can begin to change to dialog between the HW and SW guy as well. 

For more information and to download a trial version of Sourcery CodeBench, please visit http://go.mentor.com/codebench

About the Authors:

Brad Dixon is a senior marketing manager at Mentor Graphics responsible for Android, Linux, and Nucleus. Brad has been at the nexus of open source and embedded software as a developer, field application engineer, and product manager since 2000. Previously at MontaVista, Brad has helped some of the world’s most demanding companies understand how to apply Linux and other open source technology to design new applications and devices. In addition to technical nuts and bolts, Brad is involved in licensing, quality assurance, networking, and security.

Anil Khanna has over 15 years of technical and product marketing experience with a background in both design automation tools (EDA) as well as programmable logic hardware design. Anil is currently senior product marketing manager of Mentor Embedded Sourcery tools. Previously, Anil was responsible for worldwide market development for Mentor’s ASIC/FPGA synthesis solutions including Catapult and Precision Synthesis. Anil holds a Masters in Electrical and Computer engineering from Portland State University in Portland, Oregon.