The overwhelming favored tools are the compiler/assembler and the debugger, with the oscilloscope a distant third. It's also an interesting anomaly that software testing tools are way at the bottom of the list, yet users say that "test" in general is one of the key factors in the design process often taking the majority of the design time. That leaves me to conclude that users aren't happy with their current software test tools.

Advanced tools good; good practices better While it's no surprise that embedded systems designers have yet again pin-pointed the meeting of deadlines as their biggest concern, the good news is that virtual platforms and graphical system-design tools are evolving rapidly to help them meet those deadline challenges. That being said, there's no substitution for good, solid firmware-generation practices to ensure a solid design. The argument for virtual platforms from the likes of VaST or VirtuTech is pretty strong: they enable programmers to start developing code in parallel with hardware and allow reasonably accurate test and optimization before ever going to silicon. For their part, graphical systems-design environments such as National Instruments' LabView completely abstract the embedded designer from the code development and enable a system-level approach that greatly accelerates development time. While the advantages of such tools are clear, they aren't a panacea. Virtual platforms are expensive and rely on the vendor providing accurate models of the target IC. Also, "They are just one component of firmware engineering and don't address crucially important areas like design, inspections, standards, etc.," said Jack Ganssle, embedded systems consultant. Ganssle, a regular contributor to Embedded Systems Design also delivers a course on this topic at each Embedded Systems Conference (catch the next one at ESC Boston on Oct. 30). Also, code developed using LabView, whether it be C or HDL, is appreciably slower than hand-optimized code, originally up to five times slower. More recently, however, that differential has decreased dramatically. EEMBC benchmarked the LabView Microprocessor SDK and found it to be 1.05 (5%) to 2.3 (103%) times slower. Such differential reductions are set to continue as a result of tweaks such as in-line code capability where hand-generated code can be inserted in critical paths to overcome bottlenecks. In addition, the recently announced LabView 8.6 adds Component Level IP (CLIP) capability that allows the insertion of third-party IP for LabView FPGA. Despite the improvements, the overhead remains, so nothing as yet quite replaces good firmware development practices, said Ganssle. To wit, he outlined some do's and don'ts that should be adhered to: Five things to do to get better firmware faster: Inspect code before testing it, whether formally (e.g., Fagan Inspections) or a careful deskcheck. Measure bug rates and recode error-prone functions. Use configuration management, even for one-person shops. Schedule realistically, using proven approaches to scheduling. Code to a firmware standard. Five things to avoid: Jump into coding too quickly. Inadequate tests. Confusing research and development; these are two different things. Writing optimistic code - Proper engineering always revolves around worst-case design. Not allocating enough resources to the project. --Patrick Mannion Patrick Mannion is editorial director for TechOnline, Embedded.com's sister site. You may reach him at pmannion@techinsights.com.