by Niharika Singh | SMTS, CircuitSutra Jan 30, 2018
The use of virtual prototyping prior to the availability of physical hardware has been well-documented. The most common use cases involve architectural exploration, early software development, golden reference specifications, reduced silicon turns, software/hardware co-verification etc.
A common misconception is that once the physical hardware is available all software development should switch to hardware and no longer use the Virtual Prototype (VP). This article focuses on the VP benefits after physical hardware is available. It highlights various efficient and economical use cases of VP which are valid even when suitable physical hardware is available due to its benefits of visibility, controllability, availability, repeatability and testability.
Debug Capability:
During firmware development/validation software developers often need to step and debug the running firmware image. Debugging on physical hardware is expensive, limited to processor boundary and is relatively slow when compared to VP.
A common misconception is that once the physical hardware is available all software development should switch to hardware and no longer use the Virtual Prototype (VP). This article focuses on the VP benefits after physical hardware is available. It highlights various efficient and economical use cases of VP which are valid even when suitable physical hardware is available due to its benefits of visibility, controllability, availability, repeatability and testability.
Debug Capability:
During firmware development/validation software developers often need to step and debug the running firmware image. Debugging on physical hardware is expensive, limited to processor boundary and is relatively slow when compared to VP.
As debugging on VP is same as debugging another set of software one can synchronously pause and restart the processor core and targeted firmware image on it. Multi-core debugging further accentuates the need for virtual prototypes as the parallel cores can be stopped in synchronization and can be viewed at the same time. Gathering of debugging data on the physical hardware typically only occurs if there is a specific need, while gathering of debugging data in a VP environment can occur for every event or on every simulation run. Additionally during debugging product flash memory may need to re-program again and again, which is often a time consuming process on physical hardware but a quick approach on VP. This useful VP debug environment does not go away once the physical hardware is available. In fact it becomes more useful and provides another way to work through issues that are found on the physical hardware.
System Visibility:
VPs provide many levels of visibility to the user. The extensive simulation visibility of VP helps significantly to measure/control the internal working of processor core. When working on VP one can record internal signal changes, or even internal memory modifications in a file (in the form of VCD, binary or any other supported format). These files then can be viewed in various programs provided by EDA tool vendors such as GtkWave and SimVision etc.
On the hardware it is often difficult, if not impossible to measure the time from interrupt request assertion to the beginning of the actual software interrupt service routine. But on VP it is just about calculating the simulation time difference between the two events. One can also trace and view the internal state of processor core when working on VP but on physical hardware only the processor boundary can be accessed.
VPs provide many levels of visibility to the user. The extensive simulation visibility of VP helps significantly to measure/control the internal working of processor core. When working on VP one can record internal signal changes, or even internal memory modifications in a file (in the form of VCD, binary or any other supported format). These files then can be viewed in various programs provided by EDA tool vendors such as GtkWave and SimVision etc.
On the hardware it is often difficult, if not impossible to measure the time from interrupt request assertion to the beginning of the actual software interrupt service routine. But on VP it is just about calculating the simulation time difference between the two events. One can also trace and view the internal state of processor core when working on VP but on physical hardware only the processor boundary can be accessed.
Advance Control Capability:
The controllability of the VP is superior to the physical hardware because of the direct tie between the processor core and other peripherals. On VP read of a processor register or port may causes the firmware to act as if the fault had occurred and enable full validation of the various diagnostic routines. The careful control of simulation stimuli on VP can expose faulty implementation and significantly reduce the efforts/time taken to validate the various complex system level requirements. For instance validating various fault injection scenarios on physical hardware would normally require custom hardware variants but on VP it can be reproduced with just a register read/write.
The controllability of the VP is superior to the physical hardware because of the direct tie between the processor core and other peripherals. On VP read of a processor register or port may causes the firmware to act as if the fault had occurred and enable full validation of the various diagnostic routines. The careful control of simulation stimuli on VP can expose faulty implementation and significantly reduce the efforts/time taken to validate the various complex system level requirements. For instance validating various fault injection scenarios on physical hardware would normally require custom hardware variants but on VP it can be reproduced with just a register read/write.
Portability:
As running firmware/application software on VP is just running another piece of software, it offers greater design portability than physical hardware. VP availability enables worldwide development teams to quickly begin creating target firmware rather than trying to replicate, or share a similar physical bench system.
During software development/validation engineers often need to share their design across different teams, location etc. When working on physical bench environment, achieving design repeatability requires elaborate tool interconnections to power on/off the system, program various connected devices, monitor analog outputs, and provide run-time control of the hardware unit. But VP offers built-in repeatability and therefore allows the simulation to react in the same manner on each run without any additional external connection.
As running firmware/application software on VP is just running another piece of software, it offers greater design portability than physical hardware. VP availability enables worldwide development teams to quickly begin creating target firmware rather than trying to replicate, or share a similar physical bench system.
During software development/validation engineers often need to share their design across different teams, location etc. When working on physical bench environment, achieving design repeatability requires elaborate tool interconnections to power on/off the system, program various connected devices, monitor analog outputs, and provide run-time control of the hardware unit. But VP offers built-in repeatability and therefore allows the simulation to react in the same manner on each run without any additional external connection.
Availability:
The virtual-ness of the virtual prototype allows for greater availability of the development environment for engineers working in a global and even local environment.
A typical physical bench embedded software development requires a hardware board, power supplies, oscilloscopes, voltage and current meters, connections for debuggers, and additional setup to provide stimuli. Therefore the hardware bench setup is often very costly and may escalate project cost. In the early development stages of a project access to the hardware development bench is often very limited which in turn limits the amount of development that a software engineer can accomplish on the actual hardware.
In contrast, VPs make the entire test bench just another piece of software. This allows worldwide development teams to quickly begin creating target firmware rather than trying to replicate, or share, a physical bench system. It involves little cost of tool licensing, in replicating and deploying a virtual test bench to software developers in any global location once the initial development is completed. Additionally availability of VP even after the hardware test panel has been produced, enables higher productivity and a better use of engineering resources.
The virtual-ness of the virtual prototype allows for greater availability of the development environment for engineers working in a global and even local environment.
A typical physical bench embedded software development requires a hardware board, power supplies, oscilloscopes, voltage and current meters, connections for debuggers, and additional setup to provide stimuli. Therefore the hardware bench setup is often very costly and may escalate project cost. In the early development stages of a project access to the hardware development bench is often very limited which in turn limits the amount of development that a software engineer can accomplish on the actual hardware.
In contrast, VPs make the entire test bench just another piece of software. This allows worldwide development teams to quickly begin creating target firmware rather than trying to replicate, or share, a physical bench system. It involves little cost of tool licensing, in replicating and deploying a virtual test bench to software developers in any global location once the initial development is completed. Additionally availability of VP even after the hardware test panel has been produced, enables higher productivity and a better use of engineering resources.
Architecture Exploration:
VP also enables early architecture exploration for next generation of chips. Scaling physical hardware to adapt the new specifications, features is not possible. Developing RTL implementation requires huge effort and development process is relatively longer. Therefore when full functional models are not required, system architects often prefer VP to test new features and validate the hardware capabilities. VP provides fast platform setup, easy exploration of new scenarios and hence supports system architects in their decision making process.
Therefore, availability of the VP is essential even when the physical hardware is available due to the reduced costs of replication, ability to distribute designs, and the flexibility to change or add new features.
VP also enables early architecture exploration for next generation of chips. Scaling physical hardware to adapt the new specifications, features is not possible. Developing RTL implementation requires huge effort and development process is relatively longer. Therefore when full functional models are not required, system architects often prefer VP to test new features and validate the hardware capabilities. VP provides fast platform setup, easy exploration of new scenarios and hence supports system architects in their decision making process.
Therefore, availability of the VP is essential even when the physical hardware is available due to the reduced costs of replication, ability to distribute designs, and the flexibility to change or add new features.
RSS Feed