Benefits of using virtual prototype even when the real hardware or hardware prototype is available
The article covers how to effectively use the SystemC, TLM2.0 based virtual prototype for setting up advanced methodologies for development & testing of embedded software.
Virtual prototypes are becoming an important component of design and verification flows for SoC, embedded software, and complete electronic systems. Virtual prototype is a fast simulation model of the hardware system, and provides an environment where the target platform binary can be run as-is, at speeds comparable to hardware speeds, using the same development environment.
The well known advantage of using virtual prototypes is that it enables the early software development much before the hardware design is complete, that helps to reduce the time to market for an electronics product, and is the primary motivation for investing in the virtual platform development.
Does it mean that virtual prototype becomes useless when the real hardware becomes available?
More and more companies are using virtual prototype even after the real hardware becomes available.
This article covers powerful features of virtual prototype which makes it suitable to be used for the development and verification of complex embedded software, even after the hardware becomes available. To setup the effective flow for embedded software development and testing using virtual prototype, it is necessary to have strong understanding of these differentiating features.
With hardware getting increasingly commoditized, companies are focusing on software to provide market differentiation. This puts pressure on software content creation requirements which are driving engineering organizations to fundamentally reevaluate their embedded system engineering processes. Sheer size of the embedded software code and the complexity of the software in the embedded device increases the chances for bugs and demand rigorous test and validation of the complete system. Hence it becomes necessary to implement modern efficient practices in place of traditional methods for embedded software development.
Virtual prototypes integrates with the same standard embedded software tools that works with hardware boards, hence embedded software engineers can seamlessly migrate from using the hardware board to the virtual prototypes for standard development and debug methodologies. Virtual prototypes also integrates with the new set of tools which allow advanced hardware level debug analysis and hardware-software co-debug. These tools are called Virtual Prototyping tools, and provides the additional features that makes using virtual prototypes more powerful as compared to using hardware boards. To effectively use these additional features, and to setup advanced methodologies, the existing skills of embedded software engineers are not sufficient. Hence embedded software engineers need to be educated about these new methodologies. Another approach that few companies have successfully deployed is to have a small methodology team to support the rest of the embedded software team with the advanced virtual prototype based methodology. CircuitSutra works with several customers and act as their methodology team for effective deployment of virtual prototypes in their embedded software development & verification flow.
Instruction trace:
The CPU models used in the virtual prototypes, provides option to dump CPU instruction traces when an embedded code is run on the VP. This advanced instruction tracing provides information about the instruction type, address and opcode of the instruction along with updated register values.
Software logs through semihosting:
As we all know, the most common method for debugging any software is to print the log messages from different parts of the code. The embedded SW engineers generally use hardware boards or real embedded products to run and test their software, hence they are not able to use this powerful debug method.
However, if you use virtual prototype, then you may print the messages from the embedded software code on the terminal window or the log file on the host computer in a non-intrusive way. For achieving this functionality, VP uses the semihosting feature which allows to use the I/O resources of the host computer in the VP.
Hardware logs:
Another important feature of virtual platform is that debug / information messages can be printed from within the hardware as well. From these messages you may judge what specific functionality of the hardware IP was invoked, what was the state of specific register / buffer / signal etc. when a specific embedded code was executing in the virtual platform.
SystemC tracing features enables one to monitor signals and interfaces against time scale. Logging and other checks can be added – in configurable manner - to the platform to monitor for significant events without modifying the source code.
Severity levels of the logs can be tweaked by the user, depending upon one’s requirement to dump different level of information.
HW or Virtual prototype logs plays a vital role in debugging and analysing the response of the system.
The sequence of the HW logs alongside with Embedded SW logs provides more information about how the functionality of embedded SW and the hardware IP works together in lock in fashion. This helps to precisely identify the buggy component of sub-system, and to debug the corner case scenarios.
Configuration & bring up:
Most of the virtual prototyping tools provide the scripting interface for monitoring & controlling the internal state of the system.
Before a hardware board / setup can be used, it have to be properly configured and bring up in a specific state. Most of the time it is a tedious, error prone and time consuming activity. Virtual prototypes provides the scripting interface through which you may load the value into internal registers and memories. It enables you to quickly bring the system into any desired state, and significantly reduce the bringup time.
A hardware board / setup supports different configuration states for different applications. With virtual prototypes you may create any number of setup with different value of configuration state, without worrying about re-configuring the same board again or without having to purchase larger number of hardware boards. In case of complex hardware setups, you do not have to physically visit the lab to change the configuration.
Automated unit testing:
One of the primary use case of the Virtual Platform is to develop the automated unit testing framework for the testing of embedded software, which could be in the form of; bare-metal applications, base hardware layer software, device drivers, or full-fledged OS applications, etc.
The features explained above: Instruction tracing, Embedded SW logs & HW logs, Scripting interface etc.. - play a vital role for creating automated unit test cases. A typical unit testcase will start with a small C / assembly code, cross compiled using tool chain, run it on the VP, generate trace and logs, compare with golden logs to decide pass fail. A top level script may be developed to run thousands of such unit test cases.
A more comprehensive setup may be created to monitor various quality parameters like coverage, memory profiling, etc..
The growing amount of embedded code has to be maintained and enhanced throughout the lifecycle of product. Every time you make changes to certain functionality of embedded code, you need to ensure that no other feature is broken. Hence you need to have right processes in place that allows you to monitor and maintain the quality of embedded software. Automated unit test suite can be part of your daily / nightly regression.
It is always desirable to have automation because manual processes don’t scale. Such an automation is not feasible with physical hardware, as it's difficult to invoke the hardware from within a script. Automation using virtual prototypes also enables you to parallelize your testing. Thousands of testcases can be run in parallel on the server farm. It also enhances the ability of the organization to react to the test failures. If a bug is introduced due to some recent code change, it gets detected in time, and corrective action can be taken quickly. Automation allows you to significantly increase the amount of testing that gets done with each iteration or software release, without having to increase the number of specialized hardware required and without having to increase the team involved in manual testing.
Visibility, Controllability and Reproducibility:
Virtual Platform allows the users to halt the simulation of complete system at any point, and observe the state of specific software, hardware IP block, sub-system, value of registers, interfaces, internal buffers, memory etc.. You can simultaneously visualize what is happening inside the software and hardware. It helps to debug and resolve the bugs related to hardware - software interaction.
Such a visibility is not feasible while using the hardware board, by putting a breakpoint through a debugger you may halt the software running on one CPU, but rest of the system (other CPUs, timers etc..) keeps on running, hence it is not possible to see the correct state of the system at a particular instance. This is feasible with the virtual prototype, because VP itself is a software and can be stopped / debugged just like any other software.
After halting the simulation at a certain instance, users may also change the state of the system by manually changing the values of registers, signals, memory etc… and then continue the simulation from there. It helps to test the behaviour of the system (software & hardware) in corner case scenarios which are hard to reproduce with real hardware in normal development setup. Another important feature of virtual prototype is its ability to reproduce the same scenario again and again due to determinate execution. By providing same sequence of inputs and following the same steps, you may bring the simulation in precisely same state again and again. It is also possible to record and replay the simulation using VP tools. Some virtual prototyping tools also provide the functionality to save & restore the state of the system. This allows you to save a snapshot of the entire simulation in a file. This snapshot may be shared with other team members or third parties who may restore the state, and continue with the simulation from that point.
Some virtual prototyping tools also provides the reverse execution capability. You may halt the simulation at any stage, and go step by step backward in your code. This can help you find exactly where the fault originated.
VP’s ability to be co-debugged with SW, along with variety of traces to enable & disable, makes one to gain a higher degree of confidence while reproducing the error scenario. Also, it provides increased visibility into, and control of the platform which greatly assists in knowing step-by-step or stage-by-stage response of the VP and thus by narrowing down the SW bugs in a timely manner.
Reproducing the complex system scenarios:
Virtual prototypes also serves as a post-silicon reference platform for simulating scenarios that are difficult to replicate and control on the real hardware. For example in automotive, there is need to be able to simulate and test potentially fatal corner cases in software without crashing real cars.
Error injection:
As we discussed, in the VP it is possible to manually change the internal state of the hardware (registers, memory, signals, etc.). Using this mechanism it is feasible to bring the system into some error state, and check the behaviour of embedded software.
Also in the virtual prototype, it is possible to provide the data at the interfaces (uart, i2c, CAN, LIN etc.. ) from a dummy model that act as a traffic generator or from a file. Protocol errors may be introduced in this traffic being fed into the virtual prototype of electronic system / SoC. This is effective mechanism to check the robustness of embedded software and how does it react to the error situations.
Such Error or Fault Injections helps one to understand the response of the system which may occur as a rare case scenario. Such debugging capabilities are difficult or nearly impossible to do it on real hardware, even with a hardware debugger or other mechanisms.
Avoiding bulky hardware prototypes and lab setups:
Many times it requires to develop bulky hardware prototypes and specialized lab setup for the development and testing of embedded software. Target hardware setups may not be made available all the time to all the engineers working in cross geographical teams. Specialized hardware setup is generally a scarce resource and developers / teams have to compete with each other to get access. Virtual platforms can be installed on the computer / laptop of every embedded software developer just like any other software tool.
Cost of developing the hardware labs may be quite high.
Virtual prototypes are also adaptive to frequent changes as compared to hardware setups, hence are more reusable and cost efficient.
Easy collaboration:
Virtual prototypes enables easy information exchange with other teams, third parties and customers.
Customer support team can have every customer configuration readily available at their end, to quickly reproduce errors and solve customer issues.
Virtual prototypes can be used by the sales team for demonstration to the customers.
The article covers how to effectively use the SystemC, TLM2.0 based virtual prototype for setting up advanced methodologies for development & testing of embedded software.
Virtual prototypes are becoming an important component of design and verification flows for SoC, embedded software, and complete electronic systems. Virtual prototype is a fast simulation model of the hardware system, and provides an environment where the target platform binary can be run as-is, at speeds comparable to hardware speeds, using the same development environment.
The well known advantage of using virtual prototypes is that it enables the early software development much before the hardware design is complete, that helps to reduce the time to market for an electronics product, and is the primary motivation for investing in the virtual platform development.
Does it mean that virtual prototype becomes useless when the real hardware becomes available?
More and more companies are using virtual prototype even after the real hardware becomes available.
This article covers powerful features of virtual prototype which makes it suitable to be used for the development and verification of complex embedded software, even after the hardware becomes available. To setup the effective flow for embedded software development and testing using virtual prototype, it is necessary to have strong understanding of these differentiating features.
With hardware getting increasingly commoditized, companies are focusing on software to provide market differentiation. This puts pressure on software content creation requirements which are driving engineering organizations to fundamentally reevaluate their embedded system engineering processes. Sheer size of the embedded software code and the complexity of the software in the embedded device increases the chances for bugs and demand rigorous test and validation of the complete system. Hence it becomes necessary to implement modern efficient practices in place of traditional methods for embedded software development.
Virtual prototypes integrates with the same standard embedded software tools that works with hardware boards, hence embedded software engineers can seamlessly migrate from using the hardware board to the virtual prototypes for standard development and debug methodologies. Virtual prototypes also integrates with the new set of tools which allow advanced hardware level debug analysis and hardware-software co-debug. These tools are called Virtual Prototyping tools, and provides the additional features that makes using virtual prototypes more powerful as compared to using hardware boards. To effectively use these additional features, and to setup advanced methodologies, the existing skills of embedded software engineers are not sufficient. Hence embedded software engineers need to be educated about these new methodologies. Another approach that few companies have successfully deployed is to have a small methodology team to support the rest of the embedded software team with the advanced virtual prototype based methodology. CircuitSutra works with several customers and act as their methodology team for effective deployment of virtual prototypes in their embedded software development & verification flow.
Instruction trace:
The CPU models used in the virtual prototypes, provides option to dump CPU instruction traces when an embedded code is run on the VP. This advanced instruction tracing provides information about the instruction type, address and opcode of the instruction along with updated register values.
Software logs through semihosting:
As we all know, the most common method for debugging any software is to print the log messages from different parts of the code. The embedded SW engineers generally use hardware boards or real embedded products to run and test their software, hence they are not able to use this powerful debug method.
However, if you use virtual prototype, then you may print the messages from the embedded software code on the terminal window or the log file on the host computer in a non-intrusive way. For achieving this functionality, VP uses the semihosting feature which allows to use the I/O resources of the host computer in the VP.
Hardware logs:
Another important feature of virtual platform is that debug / information messages can be printed from within the hardware as well. From these messages you may judge what specific functionality of the hardware IP was invoked, what was the state of specific register / buffer / signal etc. when a specific embedded code was executing in the virtual platform.
SystemC tracing features enables one to monitor signals and interfaces against time scale. Logging and other checks can be added – in configurable manner - to the platform to monitor for significant events without modifying the source code.
Severity levels of the logs can be tweaked by the user, depending upon one’s requirement to dump different level of information.
HW or Virtual prototype logs plays a vital role in debugging and analysing the response of the system.
The sequence of the HW logs alongside with Embedded SW logs provides more information about how the functionality of embedded SW and the hardware IP works together in lock in fashion. This helps to precisely identify the buggy component of sub-system, and to debug the corner case scenarios.
Configuration & bring up:
Most of the virtual prototyping tools provide the scripting interface for monitoring & controlling the internal state of the system.
Before a hardware board / setup can be used, it have to be properly configured and bring up in a specific state. Most of the time it is a tedious, error prone and time consuming activity. Virtual prototypes provides the scripting interface through which you may load the value into internal registers and memories. It enables you to quickly bring the system into any desired state, and significantly reduce the bringup time.
A hardware board / setup supports different configuration states for different applications. With virtual prototypes you may create any number of setup with different value of configuration state, without worrying about re-configuring the same board again or without having to purchase larger number of hardware boards. In case of complex hardware setups, you do not have to physically visit the lab to change the configuration.
Automated unit testing:
One of the primary use case of the Virtual Platform is to develop the automated unit testing framework for the testing of embedded software, which could be in the form of; bare-metal applications, base hardware layer software, device drivers, or full-fledged OS applications, etc.
The features explained above: Instruction tracing, Embedded SW logs & HW logs, Scripting interface etc.. - play a vital role for creating automated unit test cases. A typical unit testcase will start with a small C / assembly code, cross compiled using tool chain, run it on the VP, generate trace and logs, compare with golden logs to decide pass fail. A top level script may be developed to run thousands of such unit test cases.
A more comprehensive setup may be created to monitor various quality parameters like coverage, memory profiling, etc..
The growing amount of embedded code has to be maintained and enhanced throughout the lifecycle of product. Every time you make changes to certain functionality of embedded code, you need to ensure that no other feature is broken. Hence you need to have right processes in place that allows you to monitor and maintain the quality of embedded software. Automated unit test suite can be part of your daily / nightly regression.
It is always desirable to have automation because manual processes don’t scale. Such an automation is not feasible with physical hardware, as it's difficult to invoke the hardware from within a script. Automation using virtual prototypes also enables you to parallelize your testing. Thousands of testcases can be run in parallel on the server farm. It also enhances the ability of the organization to react to the test failures. If a bug is introduced due to some recent code change, it gets detected in time, and corrective action can be taken quickly. Automation allows you to significantly increase the amount of testing that gets done with each iteration or software release, without having to increase the number of specialized hardware required and without having to increase the team involved in manual testing.
Visibility, Controllability and Reproducibility:
Virtual Platform allows the users to halt the simulation of complete system at any point, and observe the state of specific software, hardware IP block, sub-system, value of registers, interfaces, internal buffers, memory etc.. You can simultaneously visualize what is happening inside the software and hardware. It helps to debug and resolve the bugs related to hardware - software interaction.
Such a visibility is not feasible while using the hardware board, by putting a breakpoint through a debugger you may halt the software running on one CPU, but rest of the system (other CPUs, timers etc..) keeps on running, hence it is not possible to see the correct state of the system at a particular instance. This is feasible with the virtual prototype, because VP itself is a software and can be stopped / debugged just like any other software.
After halting the simulation at a certain instance, users may also change the state of the system by manually changing the values of registers, signals, memory etc… and then continue the simulation from there. It helps to test the behaviour of the system (software & hardware) in corner case scenarios which are hard to reproduce with real hardware in normal development setup. Another important feature of virtual prototype is its ability to reproduce the same scenario again and again due to determinate execution. By providing same sequence of inputs and following the same steps, you may bring the simulation in precisely same state again and again. It is also possible to record and replay the simulation using VP tools. Some virtual prototyping tools also provide the functionality to save & restore the state of the system. This allows you to save a snapshot of the entire simulation in a file. This snapshot may be shared with other team members or third parties who may restore the state, and continue with the simulation from that point.
Some virtual prototyping tools also provides the reverse execution capability. You may halt the simulation at any stage, and go step by step backward in your code. This can help you find exactly where the fault originated.
VP’s ability to be co-debugged with SW, along with variety of traces to enable & disable, makes one to gain a higher degree of confidence while reproducing the error scenario. Also, it provides increased visibility into, and control of the platform which greatly assists in knowing step-by-step or stage-by-stage response of the VP and thus by narrowing down the SW bugs in a timely manner.
Reproducing the complex system scenarios:
Virtual prototypes also serves as a post-silicon reference platform for simulating scenarios that are difficult to replicate and control on the real hardware. For example in automotive, there is need to be able to simulate and test potentially fatal corner cases in software without crashing real cars.
Error injection:
As we discussed, in the VP it is possible to manually change the internal state of the hardware (registers, memory, signals, etc.). Using this mechanism it is feasible to bring the system into some error state, and check the behaviour of embedded software.
Also in the virtual prototype, it is possible to provide the data at the interfaces (uart, i2c, CAN, LIN etc.. ) from a dummy model that act as a traffic generator or from a file. Protocol errors may be introduced in this traffic being fed into the virtual prototype of electronic system / SoC. This is effective mechanism to check the robustness of embedded software and how does it react to the error situations.
Such Error or Fault Injections helps one to understand the response of the system which may occur as a rare case scenario. Such debugging capabilities are difficult or nearly impossible to do it on real hardware, even with a hardware debugger or other mechanisms.
Avoiding bulky hardware prototypes and lab setups:
Many times it requires to develop bulky hardware prototypes and specialized lab setup for the development and testing of embedded software. Target hardware setups may not be made available all the time to all the engineers working in cross geographical teams. Specialized hardware setup is generally a scarce resource and developers / teams have to compete with each other to get access. Virtual platforms can be installed on the computer / laptop of every embedded software developer just like any other software tool.
Cost of developing the hardware labs may be quite high.
Virtual prototypes are also adaptive to frequent changes as compared to hardware setups, hence are more reusable and cost efficient.
Easy collaboration:
Virtual prototypes enables easy information exchange with other teams, third parties and customers.
Customer support team can have every customer configuration readily available at their end, to quickly reproduce errors and solve customer issues.
Virtual prototypes can be used by the sales team for demonstration to the customers.
CircuitSutra Modeling Methodology enables the development of SystemC models that can span multiple use cases: architectural exploration, pre-silicon & post-silicon embedded software development, RTL verification, co-simulation, co-emulation. These models can integrate with all the tools required in the entire ESL design & verification flow. Support for new tools can be added without having to update the model code.
RSS Feed