Abstract: A multicore processing environment (MCPE) is disclosed. In embodiments, the MCPE includes multiple processing cores hosting multiple user applications configured for simultaneous execution. The cores and user applications share system resources including main memory and input/output (I/O) domains, each I/O domain including multiple I/O devices capable of requesting inbound access to main memory through an I/O memory management unit (IOMMU). For example, the IOMMU cache associates unique cache tags to each I/O device based on device identifiers or settings determined by the system registers, caching the configuration data for each I/O device under the appropriate cache tag. When each I/O device requests main memory access, the IOMMU cache refers to the appropriate configuration data under the corresponding unique cache tag. This prevents contention in the IOMMU cache caused by one device evicting the cache entry of another, minimizing interference channels by reducing the need for main memory access.

Abstract: 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.

Abstract: A multicore processing environment (MCPE) implements a shared resource access rate (SRAR) safety net to limit the access of user applications to shared system resources (SSR). For each user application, a baseline shared resource access time (SRAT) and baseline SSR access rate (while no other competing applications interfere) may be determined. A utilization for each accessed SSR, including worst case execution time and contention SRAT for competing applications, may be determined. For the user application and competing applications, an access time delta for each accessed SSR and total delta may be determined. Based on the total delta and an access count for each SSR, a multicore derating for the user application may be determined and the time requirement adjusted or allocated to include the multicore derating and baseline SRAT. Accordingly, the core rate limiters may limit data access to each SSR by the user application to a corresponding expected value.

Abstract: 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.

Abstract: 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.

Abstract: A multicore processor system and a method of operating the system defines a processor partition (which may include one or more processor cores) as a network offload engine for a network connected to the processor system. Network operations requests from other cores or partitions of the processor system are forwarded to the network offload engine by a cross-platform inter-partition communications component including a relay task in the network offload engine for receiving network operations requests from network proxies in the other partitions. The network offload engine then controls access to network resources by the other cores or partitions and applications running thereon. A second or additional core or partition of the processor system may be similarly defined as a network offload engine for a second or additional network, receiving network operations requests from the other partitions through a similar system of relay task and network proxies.

Abstract: 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.

Abstract: 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.

Abstract: A multi-core processor system and a method of operating the system allocates fault queues in a shared system memory for each virtual machine of a partitioned guest operating system running on a core or partition of the processor system. Health monitors of the partitioned guest operating system log faults in the fault queue corresponding to the appropriate virtual machine. The health monitors may take additional action in response to warning-level or virtual machine-level faults. A health monitor of the multi-core processor resource then polls each fault queue, as well as the partition-level and module-level event logs maintained by the module operating system, for available faults and logs all faults in a single nonvolatile event log of the multi-core processor resource.