“If I could find it, I could fix it!”

So ran the advertising copy for a new logic analyzer, circa 1995. The sentiment is a familiar one. Programmers are generally smart people, and if they know where a bug is, they can usually swat it in short order. The problem is finding the bug in the first place—or even knowing that there is one.

This was a recurring theme at last week’s Embedded Systems Conference (ESC) event in downtown San Jose. A number of companies with whom I met showed off front-end tools that help hardware and software engineers find problems. It was the finding, not necessarily the fixing, that got most of the attention.

One big example was Microchip. The company that wins the award for most descriptively named firm in our industry showed off its new software-development system. Inexplicably named MPLAB X (that’s the letter X, not a Roman numeral ten), it supersedes the previous version 8 (go figure). Version X is a complete re-do of v8, with a new look and feel and, significantly, much better visualization tools. It’s got its own call-graph window so you can see who’s doing what to whom, a “task navigator,” and a built-in diff feature. On the editor side, version X highlights keywords with different colors, automatically formats code (based on your rules or its own), and flags syntax errors as you type, the same way that Microsoft Word underlines spelling and grammar errors in real time (or so I’m told; I’ve never seen this myself). It can even make suggestions, such as closing braces or inserting == as you type. All of these features can be turned off if you like, and some (such as the diff) can be replaced with external equivalents. 

The whole MPLAB X bundle is free and supports more than 800 varieties of Microchip processors. As part of the overhaul, MPLAB now runs on Mac OS and Linux development systems, instead of just Windows. If you’re of a mind to create your own MPLAB add-ons, it now supports NetBeans as a way to accommodate external plug-ins. You could create a specialized plug-in for yourself — or go into the business of making plug-ins for others.

Over in EDA land, Mentor showed off the new System Analyzer, a component of its larger Sourcery CodeBench IDE. System Analyzer is all about presenting and visualizing what’s going on in your embedded system. In addition to the spiffy (but typical) bar charts showing how much time you’re spending in each procedure or task, it can also illuminate multicore task allocation. In one brief example, System Analyzer showed how multithreaded code written for an eight-processor system was wasting most of its time serializing the handoff from one thread to another. Although the program ran correctly, it wasn’t making good use of all eight CPU cores. That’s tough information to tease out of standard tools. A table or call graph doesn’t highlight the nuances of multicore cooperation in the same way. Mentor’s graphical presentation made the inefficiencies clear, getting you that much closer to solving your problem.

RTOS vendor Express Logic’s TraceX tool serves a similar function for its ThreadX operating system. Like Mentor’s System Analyzer, it graphs out multicore utilization, execution profiles, performance statistics, and stack usage. Unlike System Analyzer, it works only on the ThreadX RTOS. The Express Logic folks were proud to announce they’ve “shipped” their billionth copy of ThreadX, thanks mostly to wireless chipsets in which it’s embedded: HP printers, a few million cell phones… and two NASA space probes. At this rate, ThreadX may overtake McDonald’s in terms of customers served.

Back in meatspace, I moderated a panel discussion on the trials and tribulations of multicore development. Multicore is like the weather: everyone talks about it but nobody does anything about it. The assembled masses were more or less unanimous in their contempt for current multicore tools, but they seemed undecided on how best to remedy the situation. As Bryon Moyer has noted elsewhere on this site, programmers would like to see more input into the hardware architecture, rather than just getting tossed a hardware platform that they then have to decode.

There was also consensus that finding, not fixing, multicore bugs was the bigger problem. We all know how to write code, the crowd averred, but we can’t be expected to magically figure out how to partition multicore, multithreaded, or multitasking projects, especially when we have little or no input on the hardware design. What we need are better tools… we just don’t know what those would look like.

Few members of the audience (with one long-winded exception) liked the idea of entirely new programming languages. Instead, the hope is that some sort of “compiler accelerator” will be able to extract parallelism from traditional C source code. Recent commercial attempts, as well as some academic research, suggest that such a thing is possible in a limited way. But wholesale “multicore-ifying” of existing C code seems unlikely.

For the time being, simply being able to see what the tasks, threads, and cores are doing is a big step in the right direction. Developers can then iteratively tweak and experiment to see what works and how best to utilize all the hardware resources at their disposal. Given some time and experience, allocating tasks might become second nature.

In the meantime, staring at charts and graphs and diagrams is more helpful than staring at tables and lists. Software, hardware, and EDA companies are doing their best to give us what we want… if only we knew what that was.