Home > Community > Blogs > System Design and Verification > software development tool teardown
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the System Design and Verification blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Software Development Tool Teardown For The Motorola Droid

Comments(0)Filed under: android, Monkey, JTAG, ADB, DDMS, QXDM, GDB, VNC, Systemm Verification, QPST, ETM

Lately, device teardowns of consumer electronics have become popular. There are many articles and videos showing what's inside a particular device. EE Times even had an article asking if they were useful and who actually benefits from them (but after the new EE Times website was launched I can't find it). Today, I have a different kind of teardown, a software tool teardown.

The most intriguing slide (for me) in the DAC presentation by Iqbal Arshad, entitled "Designing the Motorola Droid," is the laundry list of tools that were used to ensure the software was stable and operating with expected performance. It's slide 27 of the presentation. The bottom of the slide says, "Cumbersome System Optimization". Some tools are familiar to me and some are not. I thought I would take a shot at identifying as many as possible and hopefully I will get some help from readers in a game of "Identify that Tool."

The list is directly from the slide by category: Debugging, Logging, Test, Measurement, and Benchmarking. Below is my identification attempt with links to more info. There are some I couldn't identify, so please help figure out what they are.


JTAG and ETM: These are pretty easy, JTAG is a hardware connection for a software debugger to control the CPU execution. ETM is the ARM Embedded Trace Macrocell which captures information from the running CPU and exports it back to the host machine for analysis tools to process for things like performance profiling. RealView ICE and RealView Trace are good examples. There are many more JTAG products available in the market for ARM processors.

ADB: This is the Android Debug Bridge. ADB is used to communicate with a running device to get the status, copy files to/from the device, check log messages, install applications, and more. Check out the Android developer documentation for details.

GDB: Obviously, the ubiquitous GNU debugger used to debug software.

Kmem: Probably refers to /dev/kmem or /dev/mem. These are character devices that can be used to inspect the state of memory on the target system. I'm not sure if there are any tools to help memory inspection. Reader help is needed on this one.

LTT-lite: Refers to the Linux Tracing Tool used to debug or gather statistics about the running system related to performance.


RTA: I don't have a clue here; my only guess is Real Time Audio analyzer. Maybe it's a tool to confirm multimedia performance.

ADB: Already covered above.

DDMS: The Android debugging tool called Dalvik Debug Monitor Server. DDMS provides screen capture, and more information about the running device.

Genie tool: Could be a framework for testing web applications found on SourceForge.

QXDM, QPST: These are tools provided by Qualcomm for monitoring and analyzing wireless 3G protocols. This makes sense since the Droid has a Qualcomm baseband processor/RF transceiver.


Monkey: Monkey is a testing tool for Android that generates random streams of user input as well as other system events. More details are in the Android Developer Documentation. I covered a bit about Monkey in my series on Android System Verification.

Hopper: Hopper looks like a Microsoft version of Monkey. I'm not sure why it's mentioned for the Droid since it seems to be for Windows Mobile.

Raptor: All I could find was a Java tool on SourceForge, this may or may not be it.

TestNG: Looks like a Java testing tool like JUnit.

P-unit: Another testing tool for Java on Android.

VNC: Not sure why VNC is is mentioned, maybe it's used to connect to Droid displays over the network, I have a Nokia n800 that can run a vncserver and it can be accessed from another machine. Sometimes I also use TightVNC.


Automatic Panic:


I don't think these are tools; I'm not sure why they are mentioned. Any clues would be appreciated.


High speed camera

DDMS screen capture

Maybe video capture is used to measure user experience to avoid a sluggish product -- not sure.

SunSpider: A JavaScript benchmark to test the browser performance.

CaffineMark: Benchmark developed by Pendragon Software for the Android Java Virtual Machine.

Does this tool list confirm the opinion held by some (especially in EDA) that embedded software development and testing teams do not spend much money on tools? Things like JTAG hardware and the Qualcomm tools are not free, but most of the things listed are free. Personally, I think companies would pay for tools that help find and fix system issues in a much easier way, so the fact that software engineers don't pay much for this mix of tools doesn't bother me too much.

Please help by sharing any additional insight into the tools that are listed.

Also, if you have other tools that you use to do these tasks in your embedded system, please share information about them.

Jason Andrews


Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.