You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • Real Time Virtualization, How Hard Can it Be?

    My first exposure to running something virtual on a computer was when I decided to run the Windows OS on my MacBook Pro using software provided by Parallels. With that virtualization I was able to run the Quicken app under Windows on my MacBook Pro, along with the popular Internet Explorer web browser. The app performance on virtualized Windows isn't the highest, so I don't watch YouTube videos or stream Netflix on the Windows side.

    Virtualization is a big trend in IT these days, and even the producers of SoC cores like ARM are offering chips that are designed for efficient virtualization. Curious about virtualization and real time applications I attended a webinar last week hosted by ARM and Mentor Graphics.

    Felix Baum from Mentor Graphics started out first and talked about the history of embedded virtualization and how they've moved from single-core to multi-core SoCs. Early markets that wanted to use embedded virtualization include: Servers, desktop and mil-aero. Drivers today for virtualization include industrial and automotive where they have requirements for certification, real time and performance.

    As an example, for automotive you may need to support multiple OS choices for ADAS and infotainment purposes: RTOS, Linux, Android. What Mentor brings to this challenge is what they call the Mentor Embedded Hypervisor.

    Article: iPhone5 Versus Samsung S3: the Key Question-mentor-embedded-hypervisor-min.jpg

    The automotive standard ISO26262-6 calls for a freedom from interference, so the recommended approach is to use embedded virtualization to secure separation. Four requirements for real time virtualization include:

    1. A type 1 (bare metal) hypervisor
    2. A hypervisor with a separation, isolation focus
    3. Support of multi-core and multi-guest with flexible scheduling
    4. An extensive device model for flexibility and performance

    Related blog - Running Multiple Operating Systems: Hypervisors

    The ARM Cortex-R52 was announced earlier this year as the first ARMv8-R processor and it has been specifically designed for real-time applications. You could even combine this R processor with a Cortex-A core in a single SoC for any apps that need higher compute requirements. Here's a diagram of how two virtual machines (VM) could run on a single Cortex-R52 chip:

    Article: iPhone5 Versus Samsung S3: the Key Question-embedded-virtualization-min.jpg

    Multi-core can be supported using a hypervisor with master-slave control:

    Article: iPhone5 Versus Samsung S3: the Key Question-multicore-min.jpg

    The hypervisor can also be used with the Cortex-A series of SoC:

    Article: iPhone5 Versus Samsung S3: the Key Question-cortex-min.jpg

    There are three ways to do device models: Direct, Shared, Virtualized

    Article: iPhone5 Versus Samsung S3: the Key Question-device-drivers-min.jpg

    With the Mentor Embedded Hypervisor you also get debug support by using JTAG which enables software tracing and analysis via agents with synchronized data support.

    Related blog - Open Source Software Platform Fuels Automotive Innovation

    Jon Taylor from ARM was the next to present and he listed the three hard, real-time requirements:
    1. System performance
    2. Safety
    3. Determinism

    The Cortex-R52 has hardware design features just for hard real-time like the MPU taking a single cycle to check permissions, and low latency peripheral support. If your clock is running at 500MHz then the R52 can give you an interrupt response in just 54ns, so you can switch operating systems every 100us taking just 1% of the CPU time. The Cortex-R52 also supports virtual interrupt management for virtual machines:

    Article: iPhone5 Versus Samsung S3: the Key Question-interrupt-routing-min.jpg

    For automotive uses you want to meet the Automotive Safety Integrity Level (ASIL), so here's what that looks like in terms of a software and hardware system:

    Article: iPhone5 Versus Samsung S3: the Key Question-asil-system-min.jpg


    Q: When guest OSes share resources, how is that handled?

    Jon - some cores have tightly coupled memories. If you can live with 100us context switching, then the R-52 works well. Felix - determinism means that your system has the same response time, every time.

    Q: What are the pros and cons of using containers?

    Felix - running isolated things on top of Linux the R-52 is better for BME and Apps. Running Linux on R-52 is not so ideal, so I recommend using the A series instead. Having a RTOS with two different Apps, then using a hypervisor is a cleaner approach for separation.

    Q: What about Memory Management Units?

    Jon - For a desktop the MMU maps virtual to physical addressing. A Memory Protection Unit is much simpler than a MMU because of single cycle checking, and being deterministic.

    Related blog - Mentor Moves to Enter IoT Fray

    Virtualization for embedded systems is practical and can meet the demands of hard real-time applications. The combination of the ARM Cortex-R52 processor with the Mentor Embedded Hypervisor is good starting point for your next automotive or industrial project. View the archived webinar online now.