VSD impacts every aspect of software and systems development, from firmware all the way up to application stacks.

VSD for Software and Systems Development

Engineers daily challenges around hardware availability, debugging, integration and test are compounded by aggressive development schedules, expanding feature lists, and organizational cost cutting measures.
   
VSD mitigates each of these high-level issues by not only replacing hardware, but by enabling “magic” development approaches that just are not possible on physical hardware (e.g. full-system stop, run to run repeatability, full visibility & control, reverse execution, checkpointing, and scripting/automation). The result is that virtual platforms are superior in many ways to physical hardware for software and systems development. In-fact, after using VSD for just a matter of weeks, many software developers lament the return to physical hardware.

Example: Debugging Systems with Reverse Execution

There are three phases to software debugging: Repeating the bug, isolating the bug and fixing the bug. When working with physical platforms, the successful completion of these steps requires a high degree of developer skill and experience. VSD on the other hand dramatically trivializes repeating the bug, dramatically eases bug isolation and speeds correction of the bug. We have several examples of software developers who had struggled for months to repeat and isolate bugs on physical hardware, only to find them in days with VSD.

Repeating the Bug

To repeat the bug on physical hardware, the system or application may have to be restarted hundreds or thousands of times, each time using a new set of input parameters, data streams or operator actions that are hoped to provoke the bug.
   
Virtual Platforms are different. They operate in a virtual world where every data stream and IO parameter can be scripted or captured and provided again and again on all subsequent runs. As a result, the system always starts from the same point thus ensuring that all system functions, timing, activity and results are also duplicated. This ensures that a bug that has occurred once can be trivially repeated simply by loading an existing checkpoint (snapshot file) and re-running. By using checkpoint files that ensure a bug will occur, developers can easily collaborate with worldwide team members, all on a single bug.
   
For developers who desire the randomness of physical hardware, virtual platforms can be provided with different “seed” values. This will provoke different system responses - just like physical hardware, while still maintaining full repeatability for any given set of seed values. New seed values are used to provoke different system responses for corner case testing. These seeds can be provided using manual, automatic or metric driven verification techniques.

Isolating the Bug

Once the bug can be reliably repeated, the developer must find the source of the bug. Traditional hardware-centric debug methods require an iterative approach where an initial breakpoint will be set and the system run until stopped. After the system stops, standard debugging tools are used to view the CPU registers and stacks – all with the goal of finding out whether the has problem occurred yet. If the problem has occurred, another breakpoint located before the previous breakpoint is set, and the application or system is re-run. If the problem has not yet occurred, a break point is set after the previous breakpoint and the application re-run. Using this technique, developers eventually are able to find the precise offending line(s) of source code.
   
Debug procedures changes completely with a virtual platform that can run in reverse. Now, developers have the benefit of knowing when the problem occurred and they can backward step through the code – observing all hardware and software breakpoints along the way – to quickly find the precise point of origination. Such an approach does away with the iterative “guess/stop/re-start” technique required by physical hardware and instead takes a reverse linear path that begins after the problem has occurred and ends at the point where the bug begins.

Fixing the Bug

Often, the effort to fix a bug, whose source has been isolated, is much less than the preceding effort to duplicate the bug and to isolate its source. VSD does not provide tools that will help the developer to write the proper code. Developers do however benefit from those same capabilities for checkpointing, reverse execution and run-to-run repeatability that were helpful in repeating and isolating the bug.

Example: Progressive System Integration with Virtual Platforms

Physical hardware requires that each subsystem be completed before it can communicate and interact with other subsystems. VSD however requires only that the white-box functionality of each subsystem is duplicated at the level needed to “fool” the rest of the system. Often, the effort needed to provide this level of white-box functionality – just enough so that other subsystems can operate in their normal manner – is orders of magnitude less than the effort to develop the missing subsystem’s software.
   
By wisely using the incremental model approach, VSD allows system integration to begin solely on virtual platforms, expanding to a combination of virtual and physical hardware, and finally to fully physical hardware as those components become available.