By Felix Baum
As you may already be aware, Wind River just released the latest version of our flagship real time OS offering, VxWorks. We worked hard to make sure that our customers can rely on it as a foundation to propel their solutions to market faster and enable them to differentiate their products from the competition by truly capitalizing on the flexibility of the leading edge silicon offerings from our partners.
Often when moving from single to multi-core processors, an SMP based solution seems like a logical next step. In SMP OS configuration, one instance of an operating system with one scheduler controls all of the cores and determines which task gets to run and on which core.
In fact, if the original software was written without explicit assumptions on the execution order of the tasks/threads based on priority levels, there is little porting required to migrate over to a multi-core hardware system.
I do have to admit that during my 10+ years at Wind River, I have seen my share of code that used task priority as the only way to define the scheduling of events in the software. This code will fail miserably when you move it to a 2+ core system as an SMP scheduler will schedule the task with a highest priority to run first, and then will proceed to schedule the rest of the tasks, with the same or lower priority to run on the rest of the available cores. What is worse, the failure of such a design will show itself in intermittent race conditions that are notoriously hard to debug even with a top class tool like Wind River Workbench.
This, along with several other reasons, is why unsupervised AMP OS configuration is a good choice in certain designs, particularly when clients consolidate their design from many independent processors to run in a multi-core environment. In an AMP configuration, each core executes its own version of the OS and user application, and they do not have to be all the same.
Some of the hardware architectures have 36-bit addressing and with the latest VxWorks on a dual core processor, you will be able to build two VxWorks 32-bit AMP images and load them side by side, covering 8 Gig of physical memory. This is extremely handy if your design has many peripherals that are memory mapped and your hardware engineer has set up a system with over 4 Gig of addressable memory. Of course if you have a 64-bit processor, this scenario is not applicable and you are better off running VxWorks in 64-bit mode.
As a number of processor cores continue to grow, I increasingly encounter customers with designs that are not fully satisfied with SMP or AMP only configurations. Often, I find that the best performance is achieved by partitioning cores so that a SMP operating system runs on the first few cores, while the rest are executing AMP configured OSes.
But what if your application is CPU intensive and one core will not be able to handle it? The latest VxWorks indeed comes with many innovative features, including the elimination of the core 0 requirement for the SMP system, or what many folks call SMP m2n (any to any). You see, up until now, due to the fact that many multi-core systems coming out of reset rely on core 0 to partition the hardware, assign interrupts, initialize peripherals and such, SMP operating systems have to run from core 0 to any-core. With VxWorks, this is no longer a requirement and you will be able to run a SMP configured OS from any core to any core. So if you just happened to have 8 cores in your processor, you might run four independent VxWorks SMP images where each will control two cores.
Of course VxWorks, in addition to these configurations, allows for much finer application partitioning via CPU reservation and affinity features. VxWorks natively offers unparalleled flexibility in extracting the best performance out of hardware for your application needs. To take it a step further, if VxWorks is configured for 64 or 32 –bit mode in conjunction with embedded virtualization technologies, such as on top of Wind River Hypervisor, the sky is the limit on the number of configurations possible when mixing and matching various operating systems and modes of OS operation between available cores.
Subscribe
Comments