ESC Boston: Day 2

This morning before heading to ESC it dawned on me that the park across the street from my hotel was the Boston Public Garden. Maybe it was the swans on the hotel logo, but the ironic thing is that the only way I knew about this park was by reading the book Make Way for Ducklings to my kids. I previously reported that 4 weeks ago we had a new baby girl. During the week following the birth, as my wife was recovering, I took over teaching our 5 year old Kindergarten (all our kids are home schooled). I found out that one of the usual Kindergarten tasks is to do something called Five in a Row which involves reading the same book to a child five days in a row. The book I was assigned to read was Make Way for Ducklings (Viking Kestrel Picture Books). My 5 year old was quite excited to hear that I was at the park where the ducklings followed the swan boats and ate peanut shells dropped by the passengers.  Below is a picture from my visit to the park on the way to ESC.

My talk was the last session of the day, but even with the late time slot the attendees were interested in the idea of Coverage Driven Verification for Embedded Software. This was my forth talk at ESC, but first one at the Boston conference. You can take a look at the slides and the paper. Overall, I think the attendees were intrigued by the concept. The majority of attendees seemed to test software on a physical target board and were familiar with writing tests, downloading them to the board, running them, and collecting the results back on the host. The presentation could have used some more details on how to make the physical connection between the host machine and a target board via the mailbox and a hardware channel such as USB, Ethernet, JTAG, etc.

The session before mine was related to code instrumentation, a topic that is close to ISX, especially with the introduction of the monitoring features in version 8.2. The talk demonstrated a way to create your own structural coverage tool by using the C preprocessor. I think most attendees were a bit shocked to think about replacing every construct in C with a macro that inserts code to log which statements were executed, but the presenter, Ark Khasin, definitely won some points for creativity. I had seen an article on it previously on embedded.com so I wasn't as surprised as others might have been. Even if the solution is not completely practical it is worth a look. Attempting to parse C code yourself does take effort so the solution to use the C compiler you already have makes some sense. There is also a paper on the MacroExpressions website.

For ISX we have relied on extracting as much information about the embedded software to be verified from debugging information found in object files. I'll talk more about the pros and cons of code instrumentation in a future post, but there is probably no one size fits all solution.

Ideally, there is no need to instrument source code to collect code coverage, functional coverage, do performance profiling, and more. In order to provide these features on uninstrumented code it's necessary to not only use a simulator or vitual machine to run the code but it is also necessary to have some detailed knowlege about the processor that is running the software. Tools that provide a simulation engine and models can do a lot of things with uninstrumented code. For example, with VMware you can debug uninstrumented Linux kernel code running in a virtual machine.

From the start ISX was designed not to rely on the details of simulation tools and models. The main reason is that are so many ways to run software and so many combinations of processors and tools that it's impossible to keep up and users typically don't really want to hear that they can improve verification, but step one is to replace the models they are using. It also makes things like doing verification with the software running on an actual target board a bit of a problem. As a result ISX uses generic C code to provide the verification connection to embedded software. Working at the source level means the solution is generic and can be used with any processor model and C compiler.

Working at the source level is very flexible but also presents some challenges in the instrumentation area. It means some C code must be added or modified to get the benefits of verification, and sometimes engineers don't really like to think about modifying the code for verification purposes. After I get back from ESC I'll cover the details of various approaches to code instrumentation.

It's good to see the Embedded Systems Conference is still going strong. I'm always amazed by the diversity of the types of products produced by the engineers that attend.