Flexibility Often Yields Unexpected Results

Often, when engineers set out to build something, the result is different from the original plan. Recently, I was reading a book titled Founders at Work: Stories of Startups' Early Days. One of the chapters is about the founding of Hotmail, one of the first e-mail websites. The founders set out to build a personal database to use as a back-end for websites. When they got to work on it they had trouble communicating with each other using personal e-mail accounts because of firewalls blocking e-mail. To be able to communicate better they came up with Hotmail.

Not all product development takes such a twist to end up as something completely different from the original idea, but more commonly, I think products end up being used in different ways that what the creators intended. ISX (Incisive Software Extensions) is one such product.

When ISX was conceived some years ago, the idea was to bring the concepts of Coverage Driven Verification that were popular for hardware verification to the world of embedded software. The theory was that if the ideas of constrained random stimulus, checking, and functional coverage were good for hardware they could be good for software. Increasingly, SoC projects added more and more microprocessors and DSPs and verification engineers were facing challenges about what to do with those processors during verification. The software content was on the rise and will continue to become more important as time progresses. The other key factor driving usage is that the verification engineers doing the chip-level verification are always short on time and can never do everything they would like to.

One of the primary techniques for chip-level verification is to write C diagnostic programs to test each of the hardware functions. These "test" programs have the benefit of running on the CPU and generating real system behavior, but they also have many drawbacks. They tend to be very deterministic and once they work running them over and over every night doesn't add much to the chance of finding new bugs in the hardware. It's also difficult to coordinate them with the hardware testbench to do things like error injection. This general lack of control makes the C programs hard to work with for verification engineers that are accustomed to complete control of the hardware design.

One usage of ISX is to bring improved control, better stimulus generation, and interesting cross-coverage between hardware and software states. The results is that users want to continue using the C tests now that they know how to control them and use them to actually find more bugs. So while we set out to apply CDV to real embedded software we found ISX also being used for C tests doing hardware verification and doing a pretty good job at it. There is an article from Chip Design magazine if you are interested in more details.

The next unexpected product usage results from the fact that many verification engineers don't have enough time and want to reuse code whenever possible. The reusable nature of the e language with its aspect oriented features make reuse an important concept for verification. What we found was that many verification engineers create excellent testbenches in e that are used in block level verification and they really want to use them at the chip level, but do not know how do it since much of the code models things the software is going to do on the CPU. They don't want to resort to directed C tests but don't know any other way. ISX opens up the possibility to reuse e code instead of rewriting a whole bunch of things in C that they already have in e. Now users can create system scenarios they are interested in with the CPU instantiated and write less C code and reuse more e code to save time. A mix of some C (and maybe some assembly code to do things like interrupts) and some e to mimic what the software will eventually do results in a time saving solution for chip-level verification.

My hope is that some day all verification engineers will realize that it's not necessary to give up verification best practices from the block level at the chip level and just resort to directed C tests once the processors are instantiated in the design. Although it's comfortable to run directed C programs, ISX can leverage the existing C code and improve verification without a big change in methodology.

One user has already asked about this topic on the forums so feel free to add your thoughts and ideas.

So while ISX is sometimes used to verify actual embedded software it is also used with C tests for those verification engineers that want to write more C code to verify hardware. It is also used with e code for those engineers that don't want to write more C code and would rather write more e code. It is the flexibility of ISX that enables the time savings and improved verification for all of these use models.