VLAB
VP & VDM Guidelines
The recent launch of VLAB VDMs has led to some existing VLAB users posing the question; VDM or VP, which one do I need? Nearly every situation is unique, meaning that a choice of one over the other, or even a Hybrid approach incorporating both may be appropriate. To assist the decision-making process, we have developed the following guidelines.
Define the Software Under Test (SUT)
Consider for a moment a typical embedded software architecture consisting of, RTOS and BSP, underpinning Application or User Space SW. The software architecture intentionally shields Applications from interacting with the hardware, interacting instead with an SW API provided by the RTOS and BSP. When developing applications, an environment that exactly replicates the target environment may seem like the gold standard, but it’s often not necessary.
In contrast to Application development, RTOS and BSP need environments that replicate the hardware; registers, memory, interrupts, etc. There are, however, a range of elements in real hardware that may or may not be important to the SUT. Power consumption is just one example of a real physical characteristic that would need to be modelled if the SUT was measuring power utilisation. However, for the bulk of software, power consumption has no influence and isn’t required to execute and/or validate the software.
VDM or VP, which one do I need?
The answer may be both…
Quick Recap… What is a VP?
VLAB Virtual Platforms (VP) are sometimes referred to as bare-metal simulators… functionally equivalent to real hardware, and capable of running unmodified software binaries compiled for the target hardware environment. Typically a VP will consist of CPU Core model(s), that emulates the Instruction Set execution, memory accesses and interrupts, along with peripheral models for elements such as Ethernet, CAN and DMA.
Given its bare-metal capability, a VP can run and execute all target software and has typically been used for BSP development and OS bring-up prior to hardware availability.
How does a VDM compare?
A VLAB Virtual Development Machine (VDM) can be considered a special class of Virtual Platform. VDMs start with the same CPU Core model(s) employed by VPs, with the corresponding memory map, interrupts etc. What makes a VDM fundamentally different is the collection of models that surround the core.
Whereas a VP models peripherals for specific embedded hardware specifications, a VDM will include generic models that provide the same functionality; for example, Ethernet communication will be available but possibly using an alternate hardware model. While such a change in hardware would require a similar change in the BSP, VDMs are pre-packaged with both OS and BSP, creating a functionally equivalent environment for application software.
Taking the idea of functional equivalence one step further, a VDM will often take advantage of para-virtualization offered through VLAB Fusion. For some hardware peripherals, virtualization is not required as VLAB Fusion intercepts calls within the target software and seamlessly emulates the functionality, often with host resources.
A final but important point. In contrast to a bare-metal VP, while a VDM does run target compiled binaries, it may be necessary to have a unique build of the software that links against a custom BSP.
Different solutions, which to choose?
With two quite different solutions, which is the best fit for your scenario? If you put yourself in the position of an Automotive OEM who is weighing up what to do for a next-generation Virtual ECU (VECU). The historical path might have seen the OEM in the early design stages for the ECU, contracting a virtualisation provider to construct the corresponding VECU. The aim has always been for the VECU to be available well in advance of actual hardware to allow early development and testing of the software.
The reality is that creating a VP is a complex, time-consuming enterprise, subject to many factors that can impact both the timeline and quality. Experience shows that new VPs are generally pegged to similar timelines as the hardware, meaning it can take between 1-3 years before reaching sufficient maturity to enable bare-metal software execution. Is the wait worth it? The answer is a definite yes, particularly for developers targeting low-level software, who can access advanced debug and analysis capabilities not possible in hardware, all in a regression-ready environment that enables CI/CD.
… VDMs redraw the timelines
So what do VDMs offer our Automotive OEM? With software playing an ever-increasing role, particularly for hardware-agnostic applications or user-level software, VDMs redraw the timelines. VDMs that approximate the final target hardware and are functionally equivalent are either available off-the-shelf or after a short period that is a fraction of VPs.
Typical ECU Development Timelines
Adopt the best of both worlds
Fortunately for an Automotive OEM, or any customer weighing an investment decision with such significant implications, there is a third alternative. A hybrid approach incorporating both VDMs and VPs, brings the best of both worlds and delivers the optimal environments for all software.
Take as a reference the scenario of an OEM setting out with creating a new VECU. In the early phases of such an enterprise, time is spent iterating around requirements, architecture, hardware decisions, etc. Amongst all of these activities, deploying off-the-shelf VDMs can assist to validate the requirements and architecture, or simply accelerate application software development.
As the requirements of an ECU are clarified, additional virtualised functionality and the corresponding OS/BSP software can be iteratively added to a VDM, allowing application developers to continue.
In parallel, or as final hardware specifications become available, work on the virtualised hardware models required for a VP can begin. The collection of VP models can be thought of as a toolbox, extending a VDM by replacing generic elements with specification accurate functional models and configurations. In the same way that a VDM can be iteratively constructed, so too can a VP. The difference is normally in the completeness of an initial version, with low-level software normally requiring a higher proportion of modelled hardware to function.