Eyck Jentzsch - MINRES® Technologies GmbH
Software development for embedded systems is becoming an increasingly challenging task, which calls for advanced design methods and tools to overcome productivity pains. Software developers have to cope with continuously growing complexity, instruction execution on multiple cores, a large number of hardware interactions (i.e. sensors & actors) and limited visibility into the device. Virtual Prototypes (VPs) can help to solve many of these issues as they allow insight into software execution and its interaction with the hardware, as described in multiple publications and tutorials before. An additional valuable aspect of using VPs is the possibility to model whole systems.
In this context the term system refers to a system-on-chip (SoC) with software components running on a hardware platform, but also the surrounding environment, which interacts with the SoC through peripherals that connect to sensors and actors. Existing environment models can be reused by connecting them into a VP. VPs enable a convenient analysis of what-if scenarios, which are often much more difficult to conduct using the real hardware. Such models are more widely accessible and available compared to a complex prototype hardware setup e.g. in a lab. Adding analysis and debug APIs (Application Programmable Interfaces) is easily possible in a software model. Some of those topics will be shown and demonstrated during the tutorial.
But how does this impact the hardware development process?
Hardware designers still only rarely use VPs for RTL verification even though VPs come “naturally” with the implementation of many reference algorithms. Therefore, this tutorial also showcases the benefits of VPs for hardware designers. It will be demonstrated how the debug capabilities of VPs can be used to better analyze hardware issues and how simulations can be accelerated. Hardware developers incorporating VPs into their workflows become valuable contributors in agile teams, which, in turn, result in productivity and quality improvements of the development process. Hardware and software teams can work more closely together and develop shared sources e.g. hardware access functions for both hardware test cases and software driver purposes.
Sharing the same development environment helps hardware designers to better understand how a peripheral is being stressed by software. Hardware designers can easily get an understanding of real bus traffic and interrupt loads while trace files can be used to convert software traces into hardware stimuli and result-expectation. Stimulus from VP tests can be logged and played back in other test environments as augmentation of existing tests. Such tests can be especially useful when it comes to verifying the synchronization between different processing units through interrupts, mailboxes and shared memory. However, these tests can only be developed and employed when a prototype is available. In the context of hardware testing, this implies that realistic stimulus from the software side is often not available until very late in the development process. Here the VP approach is one of the very few means to generate some realistic input early on.
The example in the tutorial will demonstrate some of the aforementioned issues and approaches as well as many not mentioned here.