Moving Past The Missing Model Syndrome

One of the issues that has hindered the progress of using Virtual Platforms for early software development is missing models. I recall seeing Axys Design's Maxsim tool back around 2001 and thinking how cool it was. All the user had to do was drag and drop models and wire them together to create a working Virtual Platform.  At the time I was working at Axis Systems so we always called Axys "the other Axis".  Axys was eventually acquired by ARM in 2004, but the block diagram editor still exists today in Fast Models from ARM. After the coolness of the demo wore off, I started thinking about the latest and greatest SoC being developed by Samsung, TI, or whoever, and realized that the library to drag-and-drop from probably was missing almost everything needed to create a complete SoC Virtual Platform. I'm sure the ARM CPU was there and probably the memories and a few relatively simple peripherals, but that was about it. Where would the rest of the models come from? Would the Virtual Platform for early software development always suffer from the Missing Model Syndrome?

Over the years it seems a few different approaches have been taken to address the case of the missing models.

The first is to simply brute force as many models as possible to cut down on the number of missing models. This approach is a lot of work, but results in a useful library of models with far more coverage. A drawback of this approach is that SoC designs will always have custom blocks that are the differentiating features of a device (and usually the most complex ones) so there is no way to cover the models for all of the new or proprietary design blocks. Another drawback is that all of the effort is in the model library so the models tend to be closed source or black box models that cannot be modified by the user. The bummer for users is they are now picking tools based on model availability, not based on what they really want to use the models for.

The second approach is to provide a language and tools that enable a user to do the model creation themselves; the "teach a man to fish" approach. Since Virtual Platforms are abstract and start from the programmers view of the device, a programming language or description of what the hardware does can be used. This has the advantage of letting users create models without vendors having to add something to a library. A drawback of this approach is that it relies on the person writing the description to correctly describe the hardware behavior, in most cases from a paper specification. The result can be a model that doesn't behave like the actual device leading to software that works great on the model, but doesn't work on the actual silicon. Of course, a mix of both of these approaches is possible, but neither is ideal.

Could the Missing Model Syndrome be the reason why stand-alone Virtual Platform tools have yet to be able to Cross the Chasm to mainstream users?

One of the nice things about emulation is that when you visit a company interested in using emulation there is never a question about the input that goes into the emulator. The input to emulation is RTL code, and every company has it since it's the starting point for chip implementation. Virtual Platforms are starting to benefit in the same way due to growth in High Level Synthesis tools like C-to-Silicon.

Is the lack of a connection between Virtual Platform creation and hardware implementation a factor in the Missing Model Syndrome? 

Certainly, models (and a fast simulator) are a necessary, but not enough to provide the benefits needed to improve software quality. I really try to control my reaction when I hear people say that a free simulator is good enough, but it's not easy.

Simulation is only the base upon which to build features to enable engineers to do the tasks they need to do in a shorter time with improved quality. I have have said many times, step one is to run, step two is to debug (because software never works the first time), and only on step three do you really get to what you wanted to do in the first place, to verify software quality and tune system performance. Virtual Platforms provide value because they are capable of things that are very hard to do with real hardware. Some examples include:

• Reliably reproduce hard to find bugs like race conditions
• Debug without help from JTAG, monitors, or stubs
• Analyze memory usage to optimally size memories to avoid extra cost
• Non-intrusively profile software performance to understand where time is spent
• Understand how software changes influence power
• Non-intrusively monitor data structures to see if they are adequately sized
• Find out why a new release of the operating system results in degraded system performance
• Insert hardware errors or inject artificial function return values to fully test software corner case handling
• Collect functional coverage on variables and function arguments
• Confirm performance is sufficient to avoid multimedia issues like choppy audio
• Experiment with trade-offs between running functions as C code on a processor compared to implementing a hardware co-processor

I'm sure there are many more you can think of. My most interesting Virtual Platform discussions are those that get beyond talking about models and simulators and cover the real issues facing engineers trying to get systems working in a shorter time and with higher quality.

Jason Andrews