VLAB in Practice: Real Binary, Virtual Board, Real Web Browser

The question posed was simple: how can we show that a virtual platform is actually real? That it runs real software, just like the real hardware board? The answer is quite simple too: build an existing software example for a development board without any changes, load the generated image onto a virtual platform, and run it. Use an application that makes it easy to see what is going on. The selected application was a web server running on an Infineon AURIX^TM MCU.  

Real Software Stack? 

Reusing the hardware image on the virtual platform keeps the entire development environment—including the compiler, bootloader, drivers, middleware, and application behavior—aligned across both virtual and real environments. This is one of the key advantages of what is commonly known in the automotive industry as “Level 4” or “L4” virtual platforms: run the real binary. It sets L4 apart from “Level 3” and below, where the software is compiled for the host and the software stack is modified to fake parts of the operating system. It allows software development, testing, and integration to begin before hardware is available and continue throughout the development lifecycle, without requiring a separate build process.  

Virtual Board and Real Web Browser? 

Real software also implies virtually real IO – the software on the virtual platform talks to the outside world through the same hardware drivers and hardware interfaces as the real board. For Ethernet, this results in network packets being sent through a virtual network device to either a virtual network or a connection to the real-world network. In this case, the real-world network is used, allowing a standard web browser to be run on the same host as the virtual platform (or a different host, the virtual platform is on the lab network effectively). The web browser connects to the web server running on the virtual platform, just like it would connect to a real development board.  

Building the Software Example “As Is” 

We selected Infineon’s iLLD_TC3XX_ADS_GETH_LWIP_HTTP example from the open-source AURIX code examples repository on GitHub. The project was imported into AURIX Development Studio and built as is, using the workflow intended for the hardware target. The resulting ELF image was then loaded into the VLAB AURIX TC37x VDM (Virtual Development Machine) using a VLAB Python script. The script prepares and starts the virtual target, loads the software image, and enables basic interfaces for logging, observing LED activity on a GPIO port, and accessing a UART terminal. 

Debugging the First Blocker 

After loading the image onto the VDM, the software started without any problems. However, the HTTP server application did not reach its expected operational state. The UART consoles printed out some initial debug messages, but it did not get to reach the code where it finishes the initialization and prints its IP address. 

This is where the virtual development workflow became especially useful. By pausing the application at its entry point and attaching GDB from Visual Studio Code, we were able to debug the target software step by step on the virtual platform, just like you could do with a hardware debugger on real hardware. We could inspect the execution and identify where initialization had stopped progressing. The analysis showed that the software example expected an external Ethernet PHY on the physical hardware, whereas the selected VDM contained the AURIX GETH MAC module but did not include the specific board-level PHY expected by the example. 

Bridging the Model Gap 

There are three ways to handle such a missing component on a virtual platform. You can modify the software, add a full model of the PHY, or stub the PHY sufficiently to let the software work.  

Instead of modifying the software source code or the hardware board, we used the VLAB Python API to provide the missing environmental behavior. Software stubs returned the expected results from the Ethernet PHY initialization and link-status functions. An execution-listener callback also updated the GETH PHY interface status register when execution reached the receiver-start routine. This approach kept the target image unchanged while making the board-level assumption explicit in the simulation harness. Because the demo also expects input from the on-chip Die Temperature Sensor (DTS), we used the VLAB Python API to simulate its register value, allowing the original HTTP application to report dynamic temperature information.  

This kind of stubbing lets software get going quickly, while the board model is extended with the missing hardware models.  

Connecting the Virtual Ethernet Network 

With the target software now fully running, the next step was to connect its virtual Ethernet port to the host environment. This can be also easily done by using the VLAB Python API to create a network bridge between the virtual target and the host machine. 

Voilà: Accessing the Virtual HTTP Server in a Standard Web Browser 

The final result was simple yet satisfying: we opened a web browser on the host machine and connected directly to the HTTP server application running on the virtual target. The page served by the AURIX example code displayed the simulated temperature data and provided controls for exercising the LED port. In the Visual Studio Code output, the resulting LED activity could be observed through logic-port logging. 

This result also demonstrates the strong runtime performance of the VLAB virtual target. The web browser regularly requests updated data from the embedded HTTP server—potentially every 100 ms—while the virtual target continues to run the application and respond smoothly. Handling these frequent HTTP requests without noticeable delay shows that the virtual platform provides the performance needed for an interactive web-based application. 

From L4 Simulation to a Complete Virtual ECU 

The most valuable outcome was not only that the demo worked, but also what it revealed about the flexibility of L4 simulation. The same production software image could be loaded, debugged, observed, and connected to standard host tools while the simulation environment supplied focused models for behavior that was not yet available. This enables developers to begin application development and testing early and continue throughout the development lifecycle on a scalable virtual platform. 

Although a virtual MCU model combined with targeted Python-based extensions was sufficient to create a realistic end-to-end workflow for this simple example, a production program requires a broader scope. The complete board or ECU environment—including the relevant processors, peripherals, networks, sensors, actuators, and external devices—must be represented with the fidelity required by each development and validation task. The ability to start with a focused use case and scale toward a complete virtual board or virtual ECU is a key strength of VLAB. It enables teams to preserve the production software image, make hardware dependencies visible, and apply the same L4 simulation approach from early shift-left development through continuous integration and later stretch-right validation. 

Learn more about what Cadence has to offer for automotive and embedded software and hardware developers at Cadence Automotive Solutions and VLABworks.com!