WP_Term Object
(
    [term_id] => 159
    [name] => Siemens EDA
    [slug] => siemens-eda
    [term_group] => 0
    [term_taxonomy_id] => 159
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 750
    [filter] => raw
    [cat_ID] => 159
    [category_count] => 750
    [category_description] => 
    [cat_name] => Siemens EDA
    [category_nicename] => siemens-eda
    [category_parent] => 157
)
            
Q2FY24TessentAI 800X100
WP_Term Object
(
    [term_id] => 159
    [name] => Siemens EDA
    [slug] => siemens-eda
    [term_group] => 0
    [term_taxonomy_id] => 159
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 750
    [filter] => raw
    [cat_ID] => 159
    [category_count] => 750
    [category_description] => 
    [cat_name] => Siemens EDA
    [category_nicename] => siemens-eda
    [category_parent] => 157
)

Real Time Virtualization, How Hard Can it Be?

Real Time Virtualization, How Hard Can it Be?
by Daniel Payne on 12-26-2016 at 12:00 pm

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.

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:

[LIST=1]

  • A type 1 (bare metal) hypervisor
  • A hypervisor with a separation, isolation focus
  • Support of multi-core and multi-guest with flexible scheduling
  • 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:

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

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

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

    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:
    [LIST=1]

  • System performance
  • Safety
  • 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:

    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:

    Q&A

    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

    Summary
    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.

    Share this post via:

  • Comments

    There are no comments yet.

    You must register or log in to view/post comments.