Rockwell Collins, Inc.

John L Hagen

David J Radack

Lloyd F Aquino

Branden H Sletteland

Todd E Miller

Joshua R Bertram

Carl J Henning

Ramon C Redondo

Jonathan W Polley

Wade D Paustian

A multi-core processing environment (MCPE) capable of quantifying shared system resource (SSR) access includes several processing cores, each core having several applications running thereon and accessing SSRs via virtual machines (VM). Each core includes core-specific shared memory and a guest operating system (GOS) for writing timestamped VM data entries to a core-specific data queue, each entry identifying an activated VM and its activation time. Hypervisor-accessible memory stores performance monitor registers (PMR) for monitoring specific MCPE features as well as PMR data queues for each core, the PMR data including timestamped values of the monitored features. The hypervisor writes the VM/PMR data to the corresponding queues and frequently samples PMR data. A correlation module correlates the queued VM/PMR data to determine execution times of each activated VM and (for each execution time) counts of PMR changes, each PMR change corresponding to an SSR access by a core of the MCPE.

Product line avionics system multi-core analysis architecture

A system and related method for optimizing warm-start loading in a multi-core processing environment (MCPE) responds to a power transient event. The MCPE system memory activates a self-refresh mode, maintaining stored data throughout the power event. A boot loader in nonvolatile flash memory identifies the warm-start condition and fetches from the flash memory the hypervisor binary image. Rather than copy the entire image to allocated system memory, the boot loader copies only the modifiable portions of the hypervisor image, transferring control to the hypervisor. The hypervisor spawns guest processes that copy guest OS and application images from flash memory, copying only the modifiable portions of these images to the appropriate destinations in allocated memory before transferring control to the guest processes. By loading only modifiable image segments and sections, the system reduces the time required for the warm-start sequence.

Multi-core optimized warm-start loading approach

A system and related method for PCIe device configuration in a certified multi-core avionics processing system on which several guest operating systems (GOS) are running may allow a GOS to access or communicate with PCIe devices not owned by that GOS. The system may configure PCIe controllers and the PCI devices connected by those controllers by issuing addresses and determine, via a configuration vector of the system hypervisor, which PCIe devices are accessible to which non-owning guest operating systems. The hypervisor may provide each non-owning GOS with the GOS physical addresses corresponding to each non-owned PCIe device accessible to that GOS. Configuration of an unpowered or otherwise unprepared PCIe device may be deferred until device information is requested by the owning GOS to preserve compliance with system timing requirements.

Multicore safe PCIe solution

A control circuit includes a plurality of processing circuits integrated in a single chip assembly and coupled to a memory device via an electronic bus. At least a first processing circuit is configured to execute avionics instructions independent of at least a second processing circuit. The memory device includes an avionics circuit, a configuration circuit, and a sequencing circuit. The avionics circuit includes a plurality of avionics instructions that when executed control operation of avionics systems in an airborne platform. The configuration circuit includes a plurality of criticality indications corresponding to the plurality of avionics instructions. The sequencing circuit is configured to generate a sequence for execution of avionics instructions based on the plurality of criticality indications to satisfy a system requirement for operation of the airborne platform, and cause the plurality of processing circuits to execute the plurality of avionics instructions according to the sequence.

Systems and methods for configurable avionics start sequencing

A system and related method for guest OS loading in a multi-core processing environment optimizes the startup process by loading a hypervisor runtime image to an allocated memory location, from which the processing cores individually activate and execute the runtime image rather than reloading the runtime image. For guest operating systems executing across multiple processing cores, a single core may load the associated guest OS image to allocated memory space in the system RAM. The remaining cores on which that guest OS is configured to execute may then copy the loaded guest OS image to their own respective allocated system RAM, and execute the copied guest OS images therefrom.

Multi-core guest operating system loading approach

A system and method for verifying cache coherency in a safety-critical avionics processing environment includes a multi-core processor (MCP) having multiple cores, each core having at least an L1 data cache. The MCP may include a shared L2 cache. The MCP may designate one core as primary and the remainder as secondary. The primary core and secondary cores create valid TLB mappings to a data page in system memory and lock L1 cache lines in their data caches. The primary core locks an L2 cache line in the shared cache and updates its locked L1 cache line. When notified of the update, the secondary cores check the test pattern received from the primary core with the updated test pattern in their own L1 cache lines. If the patterns match, the test passes; the MCP may continue the testing process by updating the primary and secondary statuses of each core.

Multi-core cache coherency built-in test

A system and method for detection and correction of single-bit errors in a multi-core processing resource (MCPR) of an avionics processing system includes a RAM EDAC testing module called by the MCPR health monitor to access EDAC registers of a system-on-chip module coupled to the MCPR and access memory addresses passed by the MCPR health monitor to detect single-bit errors. Single-bit errors detected in memory mapped to the hypervisor are corrected by the RAM EDAC testing module. Single-bit errors detected in memory associated with a partition or core of the MCPR are corrected by the health monitor running on the particular partition or core with which the memory portion is associated. Single-bit errors may be detected in unmapped memory associated with a partition or core by accessing the unmapped memory via a temporary TLB entry.

Multi-core RAM error detection and correction (EDAC) test

A system and method may monitor a mission critical processor power supply and recover from an intermittent power interruption. A subsystem of one or more processors may be tasked with a power monitoring function enabling processor self-monitoring and recovery. The subsystem monitors the power state of the processors and should a power interruption be sensed, the subsystem may be directed by a memory source external to the primary memory source for normal system operation. The subsystem directs each processing function within each processor to disable and remain disabled until the power interruption ceases. Once the power interruption is complete, the subsystem directs each processing function to refresh and restore to a previous state of full functionality.

Growing community of inventors

Marion, IA, United States of America

John L Hagen