A system-level virtual prototype, usually just referred to as a virtual prototype, is a fully functional software model of a system, including the processors, memories, I/O and user interface, that is capable of running unmodified production code, including the drivers, OS or application. Speed is of the essence with these prototypes as they must run as close to real time as possible so that execution times for long operations are kept to a reasonable length. Other concerns that users may have about virtual prototypes are time of availability, accuracy, development cost, bring up cost, debug insight, execution control and system interfaces to the environment in which a system resides.
SystemC and TLM 2.0 have been accepted in the industry as a respectable way of integrating models together and promoting interoperability. This does not mean that all models are written in SystemC. Many models are written in pure C for speed purposes and only use SystemC and TLM for the model interfaces.
When transaction-level models are not available, a way is needed to integrate RTL models into the virtual prototype. If these are executed in a simulator, the resultant performance is often too slow to be of much value. There are two approaches to this problem. Either the models can be transformed into faster models, or an emulator or FPGA prototype can be used to execute them. A hardware engine coupled to a virtual prototype is usually referred to as a hybrid prototype. While both pieces of the system could now execute fast, the communications between them is a bottleneck. Transaction level interfaces such as the Accellera standard co-emulation – modeling interface (SCE-MI) have been addressing these issues.
When choosing model types, virtual prototype users have eight major concerns:
• Time of Availability: Once the specifications for a specific design are frozen, the time it takes for a software execution platform and its associated development environment to become available directly determines how long software developers will have to wait before starting on the project.
• Execution Speed: Ideally the chosen development method provides an accurate representation of how fast the real hardware will execute. For software regressions, execution that is faster than real time can be beneficial.
• Accuracy: The type of software being developed determines how accurate the development methods have to be to faithfully represent the actual target hardware. This is necessary to ensure that issues identified at the hardware/software boundary are not introduced by the development method itself.
• Production Cost: The cost of a development method is comprised of both the actual cost of production, as well as the overhead cost associated with bringing up a hardware/software design within it. The production cost determines how easily a development method can be replicated to all members of a software development team.
• Bring-up Cost: Any activity that is expended on a development method that goes beyond what is absolute necessary to get to silicon can be considered overhead. The overhead for the creation of a virtual prototype must be small in comparison to the returns that will be obtained in order to make it a good investment.
• Debug Insight: The ability to analyze the internals of a design, such as being able to access signals, registers and the state of the hardware/software design.
• Execution Control: During debug, it is important to be able to stop the representation of the target hardware using assertions in the hardware or breakpoints in the software, especially for designs with multiple processors in which all components have to stop in a synchronized fashion.
• System Interfaces: If the target design is an SoC, it is important to be able to connect the design under development to real-world interfaces. For example, if a USB interface is involved, it is important to connect the development method to real USB protocol stacks for verification and software development. Similarly, for network and wireless air interfaces, connection of the design representation to real world software is important for software development.
Use models for a virtual prototypes include early verification and validation, architectural analysis, software development and debug and visibility.