JP2010534888A - High integrity and high availability computer processing module - Google Patents

Abstract

A high integrity N lane computer processing module ("module"), where N is an integer greater than or equal to two. A “module” is actually a “hosted application” element and input / output element per processing lane, and when requests made by software running in each of the N processing lanes are actually made by each of the N processing lanes. Regardless of whether they are received and acted upon, a time management unit (TM) configured to determine an equivalent time value for the request and the critical region in each lane spans all N processing lanes. And a critical region management unit (CRM) configured to allow identification and synchronization.
[Selection] Figure 4

Description

This application claims priority from US Provisional Application No. 60 / 935,044, filed July 24, 2007, entitled “High Integrity and High Availability Computer Processing Module and Method”. .

  The technology described herein provides high integrity (“integrity”) and high availability (“availability”) in source computing that imposes minimal design constraints on “hosted applications”. With this technology, the “hosted application” is a software application that is hosted on the module (“hosted application”). It will also be possible to operate on a complete computer processing module.

  Computer processing modules ("modules") can provide high integrity and high availability on the source side only if faults are accurately detected and isolated and false alarms are guaranteed to be minimized. “Modules” with high integrity are even more important for aircraft where failures that are not detected and isolated quickly and accurately can result in operational problems. The ability to detect and isolate an accurate fault within a module that results in high integrity on the source side is sometimes referred to as the "Fault Containment Zone Establishment Ability", which is a fault containment fault. If this zone is established in the system, a failure cannot be propagated outside the zone. It is also important for high integrity “modules” that the probability of false alarms is very low because such false alarms were misreported even though they did not actually exist. This is because it may cause a temporary loss of function or a waste of computer resources to correct the problem.

  A conventional design to achieve high integrity at a source “module” is to perform an instruction level lock-step process between multiple microprocessors on the “module”. This is what is required and this requires expensive custom circuitry. While traditional instruction-level lock-step processing techniques provide high integrity for all “hosted applications”, multiple phase-locked loops (PLLs) with embedded memory controllers and different clock recovery circuits It may be difficult (or impossible) to implement I / O support and the like that require a current state-of-the-art microprocessor.

British Patent No. 2425380A

  Thus, while imposing minimal design constraints on the “hosted application” (ie, the same “hosted application” can also run in a “module” with normal normal integrity) There is a need for high integrity in source designs for “modules” that can also utilize high-speed microprocessors (eg, integrated processors).

  One aspect of the invention relates to an N-lane computer processing module (“module”) that exhibits high integrity. Here, N is an integer of 2 or more. This “module” actually has one “hosted application” and input / output elements per processing lane, and requests made by software running in each of the N processing lanes are actually executed by each of the N processing lanes. Regardless of when it is received and acted upon, a time management unit (TM) configured to determine an equivalent time value for the request and the critical region in each lane to all N processing lanes And a critical region management unit (CRM) configured to allow identification and synchronization across.

  Exemplary embodiments are described below with reference to the accompanying drawings, in which like numerals refer to like elements.

FIG. 6 illustrates a first scenario where it is desired that the failure be mitigated such that the failure state is eliminated for “hosted application”. FIG. 6 illustrates a first scenario where it is desired that the failure be mitigated such that the failure state is eliminated for “hosted application”. Logic blocks showing a time management (TM) unit, a critical region management (CRM) unit, a data input management (IM) unit, and a data output management (OM) unit FIG. FIG. 2 is a block diagram illustrating a high integrity loosely synchronized computer processing module (“module”) according to an exemplary embodiment. FIG. 3 is a block diagram illustrating details of a time management unit according to an exemplary embodiment. FIG. 3 is a block diagram illustrating details of a critical area management unit according to an exemplary embodiment. FIG. 2 illustrates a first scenario (of FIG. 1) in which a potential fault condition is eliminated by utilizing the system and method according to an exemplary embodiment. FIG. 3 illustrates a second scenario (of FIG. 2) in which a potential fault condition is eliminated by utilizing the system and method according to an exemplary embodiment.

  In the following description, in the description, numerous specific details are set forth in order to provide a thorough understanding of the technology described herein. However, it will be apparent to those skilled in the art that the exemplary embodiments may be practiced without these specific details. In other instances, structures and devices are shown in diagram form in order to facilitate describing the exemplary embodiments.

  Exemplary embodiments are described below with reference to the drawings. These drawings illustrate certain details of specific embodiments that implement the modules, methods, and computer program products described herein. However, the drawings should not be construed as imposing limitations that may exist in the drawings. The method and computer program product can be provided on any machine-readable medium to accomplish its operations. Embodiments may be implemented using existing computer processors, with special purpose computer processors incorporated for this or other purposes, or with hardwired systems.

  As noted above, the embodiments described herein include a computer program product that includes a machine-readable medium that carries or is stored on machine-executable instructions or data structures. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. For example, such machine readable media may be in the form of RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or machine-executable instructions or data structures. Any other medium that can be used to carry or store any other program code and that can be accessed by a general purpose or special purpose computer or other machine having a processor. When information is transferred or supplied to a machine over a network or another communication connection (either hardwired, wireless, or a combination of hardwired or wireless), the machine will of course make the connection machine-readable. Consider it a medium. Accordingly, all such connections are naturally referred to as machine readable media. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machine to perform a certain function or group of functions.

  Embodiments are described in the general context of method steps that can be implemented in one embodiment by a program product that includes machine-executable instructions, such as program code in the form of program modules that are executed by machines in a networked environment, for example. To do. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Machine-executable instructions, associated data structures, and program modules represent examples of program code that perform the steps of the methods disclosed herein. A particular sequence of such executable instructions or associated data structures represents an example of a corresponding act of performing the functions described in such steps.

  Embodiments can be practiced in a networked environment using logical connections to one or more remote computers having processors. Logical connections can include a local area network (LAN) and a wide area network (WAN), which are presented here by way of example and not limitation. Such networking environments are commonplace in office-wide or enterprise-wide computer networks, intranets, and the Internet, and can use a variety of different communication protocols. Many types of such network computing environments typically include personal computers, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. Those skilled in the art will appreciate that the present invention includes the following computer system configuration.

  Distributed computing environment in which tasks are performed by local and remote processing devices linked by a communication network (either by hard wire drinks, wireless links, or a combination of hard wire drinks or wireless links) Can also be practiced. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

  An exemplary system for implementing all or part of an exemplary embodiment is a general-purpose computing device in the form of a computer that includes a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. Can be included. The system memory can include read only memory (ROM) and random access memory (RAM). The computer has a magnetic hard disk drive that reads from and writes to a magnetic hard disk, a magnetic disk drive that reads from or writes to a removable magnetic disk, and an optical disk drive that reads from or writes to a removable optical disk such as a CD-ROM or other optical media. Can also be included. The drives and associated machine-readable media provide non-volatile storage for machine-executable instructions, data structures, program modules, and other data computers.

  In the remainder of this specification, the first embodiment will be described in detail, which provides sparse synchronization (high perfect synchronization) that provides high integrity in a source system consisting of computer processing modules (hereinafter “modules”). ).

  High integrity in source computing currently monitors at least two processing lanes, one lane to process and one to monitor, operating in a lockstep manner at the instruction level Need a lane. The problem to be solved for high integrity in dual lanes in the source computing “module” can be compared to a finite state machine model. That is, software running in each processing lane of a “module” receives the same input (data, interrupt, time, etc.) and before sending the output or before receiving a new input. If the same “amount” of processing can be performed on the data, each lane will produce exactly the same output if there is no failure. Note that this embodiment is primarily described in terms of “modules” where each processing lane has the same microprocessor. However, this embodiment also applies to “modules” having different processors in one or more of the N lanes. In this case, each processing lane is expected to produce an “identical” output within a specified range (possibly due to, for example, variations due to differences in the floating point unit of the microprocessor).

  The meaning of the analogy by the finite state machine model is as follows. When software that runs on the “module” receives certain inputs, those inputs must be the same in both lanes, and receive both inputs when both lanes are in exactly the same state. There must be. An input must be considered as an input that is explicitly requested (eg, ARINC 653 port data, timestamp, etc.) or received due to an external event (hardware interrupt, virtual interrupt, etc.) . There is a need to pay particular attention to inputs that change the thread of execution (state) of the software that occurs due to, for example, priority preemptive operations. When software running on a “module” sends an output, the data from both lanes must be compared before the output. To ensure that there is no output data comparison failure (due to improper state synchronization), the software portion of the software responsible for generating the output data can compare the outputs and then The same state must be reached between both lanes before it can be sent.

  The scenarios shown in FIGS. 1 and 2 provide an illustration of two potential failure scenarios so that the occurrence of a failure condition can be eliminated by the “module” design. These specific scenarios were chosen because the “module” design that can mitigate these fault conditions is the equivalent of input data to software running on N-lane “modules”. This is because it seems likely that a more general design constraint can be addressed (or can be expected to be addressed) and that there is a high probability of being able to control the synchronization.

  Turning now to FIG. 1 of the two-lane high integrity “module”, the first type of potential fault condition will be described. In this “module”, lanes 1 and 2 operate in a loosely synchronized manner, but the TM unit and the CRM unit described in this specification are not added. In this case, the sparsely synchronized operation state means that lane 1 is advanced or delayed with respect to lane 2 by a time length ranging from less than one instruction to an arbitrary number of instructions. For the example shown in FIG. 1, lane 1 is “before” lane 2. The initial state of the Boolean (Boolean variable) used in this example is “False”.

  In step 1, lane 1 process 1 has just set Boolean to "True" when a timer interrupt occurs. Process 1 in lane 2 does not yet have an opportunity to set a Boolean to “True” (thus, that Boolean is still “False”).

  At step 2, an interrupt occurs, causing both “lane 1” and “lane 2” “hosted applications” to switch to process 2 (due to priority preemption).

  Step 3 is that process 2 in lane 1 and process 2 in lane 2 read each Boolean and send an output containing the state of each Boolean. Lane 1 outputs True and lane 2 outputs False.

  In step 4, the data output management (OM) unit detects a mismatch between the two lanes. This is a type of failure that could have been prevented (and therefore increased availability) if the correct synchronization between the two compute lanes was provided by the “module”.

  Turning now to FIG. 2, a second type of potential failure condition is described for a two-lane high integrity “module”. In this system, lanes 1 and 2 are loosely synchronized, but are not equipped with TM and CRM units as will be described herein. In this example, sparse synchronization means that lane 1 is advanced or delayed with respect to lane 2 by a time length ranging from less than one instruction to an arbitrary number of instructions. For the example shown in FIG. 2, lane 1 is “before” lane 2.

  At step 1, process 1 in lane 1 (which is a low priority background process) has just completed an output transaction at port FOO when the timer interrupt occurs. Process 1 in lane 2 has not completed the same output transaction.

  At step 2, the background process (process 1) is no longer running because it is low priority. Rather, a high priority process (Process 2) runs on both lanes and receives input data that causes Process 1 to restart. Thus, process 1 in lane 2 never sends its output.

  In step 3, eventually (within some limited time limit) the data output management unit reports a failure due to the fact that lane 2 does not output on port FOO. This is a type of failure that could be prevented (and therefore highly available) if correct synchronization between the two compute lanes was provided by the “module”.

  The architectural approach utilized in the first embodiment is that the “module” hardware and software components work together to determine the software state of each processing lane before (and during) the I / O processing. Guarantees that they are synchronized. Note that “software” refers to both “hosted application” software and “module” software components. Also, the term “synchronized” means that each of the lanes is in the same critical area where both have completed the same set of critical areas and both collect the same input, or both lanes have the same output. Note that it means that you are in the same critical region that you are sending. Input or output (I / O) outputs from each of the N lanes are compared and must pass this comparison before being output.

  The top level attributes of the architectural approach are as follows: This architecture provides a robust temporally and / or spatially partitioned environment typical of “modules” that support virtualization (eg, as specified by the ARINC specification 653) and a single “module”. Support environments that only support "hosted applications". This architecture supports the same or different processors (two or more) on N processing lanes of a “module”. This architecture is sparsely synchronized, thereby synchronizing the computational state. This architecture abstracts redundancy management (synchronization and comparison) from the “hosted application” to the largest possible range. This allows "hosted application" suppliers to use traditional design standards in their software (they are not required to add special high integrity features) and they Allows the same “hosted application” software to run on ordinary integrity “modules”. This architecture is parametric so that units that provide high integrity and high availability can be statically configured. This allows some “hosted applications” (or data to / from these “hosted applications”) to be configured as normal integrity. This architecture ensures that faults are detected in time to mitigate functional hazards due to false outputs.

  To implement this approach, the system and method according to the first embodiment includes a mechanism (including data input management (IM), time management (TM), critical region management (CRM), and data output management (OM)). Or element). FIG. 3 shows a logical block diagram of how these elements relate to both “module” and “hosted application” software. Each of these elements will be described in detail.

  In one possible implementation of the first embodiment, the IM mechanism, TM mechanism, CRM mechanism, and OM mechanism provide a high speed bus (eg, PCI-Express or proprietary bus) to the “hosted application” processor element. Embedded in the input / output elements connected via Two input / output elements are used (with a communication channel between them) to support high integrity requirements. In addition, the “hosted application” element software interacts with these mechanisms at defined synchronization points.

FIG. 4 shows a block diagram of how the above functionality can be implemented in the two-lane high integrity “module” of the first embodiment. One skilled in the art will recognize that there are many other possible implementations of the first embodiment, including the following two examples:
(I) Each lane includes a highly integrated dual (or multiple) core microprocessor and associated clock, memory device, input / output device, etc. The functionality of element 310 is implemented utilizing one or more microprocessor cores (and associated clocks, memory, input / output devices, etc.) via the “module” hardware and software components. , One or more microprocessor cores (and associated memory, input / output devices, etc.) in which the functionality of the input / output elements 320 is incorporated on each lane via the “module” hardware and software components ) In a such things, it consists of two processing lanes "module",
(Ii) Each lane includes a single core microprocessor and associated clock, memory device, input / output device, etc., all of the functionality of the “hosted application” element 310 and input / output element 320 for each lane A “module” consisting of two such processing lanes, implemented through the “module” hardware and software components provided by the microprocessor core and associated memory, input / output devices, etc. on each lane .

  As shown in the example of FIG. 4, the highly fully sparse synchronous “module” 300 according to the first embodiment includes two lanes, lane 1 and lane 2, whereby the first embodiment is N (a positive integer greater than or equal to 2) lane “module” can be used. The “module” 300 also includes a “hosted application” element 310, which has a processor CPU (350A, 350B) for each lane (in the example shown in FIG. 4). , One processor CPU for lane 1 (there are two processor CPUs 350A and one processor CPU (350B) for lane 2) Each processor CPU (350A, 350B) is a non-volatile memory (NVM) 330A, 330B and synchronous dynamic random access memory (SDRAM) 340A, 340B, and a clock circuit is provided for each processor CPU, which is shown in FIG. Supply One clock circuit 360 is shown, whereby a clock monitor 365 is also provided to ensure that a stable clock signal is always provided to the processor CPU (350A, 350B) in each lane. While staying within the spirit and scope of the embodiments described herein, the clock 360 and clock monitor 365 on the “Hosted Applications” element 310 can be replaced with independent clocks operating in each lane. It will be appreciated that the clock 384 and clock monitor 382 on the output element 320 can be replaced with independent clocks operating in each lane.

  The “hosted application” element 310 is communicatively coupled to the I / O element 320 in each respective lane by a PCI-E bus. Further, each lane of the “hosted application” element 310 is connected to the other lane of the “hosted application” element 310 by a PCI-E bus. Those skilled in the art will utilize other types of buses, switching networks, or memory devices while remaining within the spirit and scope of the embodiments described herein in the “hosted application” element 310 and It will be appreciated that such a communication connection can be provided between the “hosted application” element 310 and the input / output element 320.

  The input / output element 320 includes a lane 1 input / output processor 370A and a lane 2 input / output processor 370B, so that these input / output processors 370A and 370B are communicatively connected to each other by a PCI-E bus. Those skilled in the art will be able to use other types of buses, switching networks, or memory devices to maintain the input / output processors 370A, 370B of each lane while remaining within the spirit and scope of the embodiments described herein. It will be appreciated that such communication connections can be provided between.

  Each input / output processor 370A, 370B includes a data input management element (IM), a time management element (TM), a critical area management element (CRM), and a data output management element (OM). Each I / O processor 370A, 370B also includes other I / O elements 375A, 375B and an ARINC 664 Part 7 element 380A, 380B, which are known to those skilled in the art of aircraft computer processing, No further explanation is given for the sake of brevity. Those skilled in the art will utilize other types of input / output data buses (other than ARINC 664 Part 7) while remaining within the spirit and scope of the embodiments described herein to communicate such “modules”. You will admit that you can provide a connection.

  A clock unit 384 and a clock monitor 382 are also shown in FIG. 4 to provide a stable clock signal to each input / output processor 370A, 370B within each lane of the multi-lane “module”. Those skilled in the art will recognize that the clock 384 and clock monitor 382 on the input / output element 320 can be replaced with independent clocks operating in each lane, while remaining within the spirit and scope of the embodiments described herein. Will.

  FIG. 4 includes an input / output PHY unit 386A, 386B for each lane, an XFMR unit 388A, 388B for each lane, and a power supply that provides power signals and performs monitoring of the components in each lane of the multilane “module”. A monitor unit 390 is also shown. The interface unit 395 provides power connection (eg, 12V DC, PWR ENBL) to the various components of the “module” 300. Power is supplied, for example, from the aircraft engine (when the aircraft engine is turned on) or from the battery or generator (when the aircraft engine is turned off) to the interface unit 395 (hence the high integrity “module”). 300 different components). Those skilled in the art will recognize that the power supply and monitor 390 can be either independent (one per lane) or a single power supply and monitor for a “module” while remaining within the spirit and scope of the embodiments described herein. I will admit that it can be implemented as well.

  The following provides an overview of the IM, TM, CRM, and OM mechanisms.

  IM ensures that software running on all compute lanes receives an exact identical set of high integrity input data. If the same set of data cannot be supplied to each lane, the IM discards the data, prevents any lane from receiving the data, and reports an error condition.

  There may be a large amount of data flow that is considered normal integrity. That is, it does not require a dual lane I / O interface (and associated overhead for performing cross lane data validation), flows into a “module” or flows from a “hosted application” within a “module” There may be data. The first embodiment allows a normal integrity data flow to be supplied to both computation lanes from one common integrity source. This optimization is via configuration parameters that specify each data flow (eg, each ARINC 664 Part 7 virtual link destined for or coming from a “hosted application”) as either normal or high integrity. Can be implemented.

  In one possible implementation of the first embodiment used in commercial aircraft, examples of services that need to provide input data equivalence on multiple lanes are ARINC 653 Part 1 I / O API calls (eg, Sampling and queuing ports), ARINC 653 Part 2 I / O API calls (eg, file system and service access point), OS I / O API calls (eg, POSIX interprocess communication), and other (eg, platform specific) API calls It is.

  TM ensures that all computation lanes receive equivalent time values for the same request, even if the requests are skewed in time (due to loose synchronization between computation lanes). In this regard, the time is “hosted application” because its value is created / controlled by the “module” rather than by another “hosted application” or LRU outside of the “module”. Is a special type of input data. FIG. 5 shows a block diagram of TM 400 and the signals it sends to the lane and receives from the lane of the multi-lane “module” according to the first embodiment.

  In essence, TM ensures that all computational lanes have the same exact time corresponding to requests made by other lanes. A depth 1 buffer (eg, a buffer that stores only one time entry) holds a time value that is delivered to both lanes after both lanes issue a request for time. If a computational lane “waits” on the other lane to issue a time request for a long period of time (most likely as a result of an error on the other lane) A watchdog timer mechanism (not shown) is used to detect and respond to this error condition.

  The TM according to the first embodiment is implemented in a “module” via hardware / software logic (eg, in an FPGA on an input / output element in combination with “module” software that controls access to the FPGA). be able to. In order to provide an efficient synchronized time, the TM can be made accessible in “user” mode (so that no system calls are required).

  In one possible implementation of the first embodiment used in commercial aircraft, the TM is applicable when the “hosted application” is applicable to ARINC 653 Part 1 and Part 2 API calls (eg, Get_Time). Called when making POSIX API calls (eg, Timers APIs), and other (eg, platform specific) API calls.

  TM is invoked when the platform software has a need for system time. The TM shown in FIG. 5 includes a time buffer. The TM receives a time signal requested from each lane, and outputs time data to each lane. The current time is supplied to the TM by the time hardware unit.

  The time buffer, in an alternative implementation of the first embodiment, can be implemented as a depth N buffer (eg, a buffer capable of storing N time values) rather than a depth 1 buffer. This is the case when it is determined that there is a large amount of skew / drift potential between computational lanes, and the synchronization point (corresponding to the point where one lane must wait for the other lane to catch up) Performance optimization can be provided when it is desired to minimize the number.

  FIG. 6 shows a block diagram of the CRM 500 and the signals it sends to the lane and receives from the lane of the multi-lane “module” according to the first embodiment. CRM allows critical regions in multiple lanes to be identified and synchronized across computational lanes. These critical regions are essentially regions in software that cannot be preempted by all other threads of execution within the same processing context. Certain epochs generated by “hosted application” and “module” software interact with the CRM to properly synchronize across all compute lanes. The CRM ensures that all lanes enter and exit the “module” CR state in a synchronized manner.

  As can be seen from the block diagram of FIG. 6, the CRM logic has three sets of input events for a two-lane module: a lane 1 request to enter or exit a critical region, a lane 2 request to enter or exit a critical region, and Requires a “module” interrupt. Each lane may generate a request to enter the critical region by software running on that lane or by the lane's hardware (eg, hardware interrupt). Each lane can generate a request to exit the critical region by software running on that lane or by the hardware of that lane. For a two-lane “module”, the CRM has a single output event, a critical event serialized. Serialized critical events include serialization of timer interrupts and critical region state change events. All computation lanes perform the same state transition based on serialized critical events. For N-lane processing “modules”, N is an integer greater than or equal to 2, but the CRM is output to N input requests to enter or exit the critical region, “module” interrupts, and all N lanes Supports one serialized critical event. It will be apparent to those skilled in the art that the CRM can serialize additional critical events based on the “module” implementation. It will also be apparent to those skilled in the art that the CRM can be extended to support multiple levels of critical regions to support multi-level operating systems (eg, user mode, supervisor mode), etc.

  The CRM may be implemented as a combination of hardware logic (eg, field programmable gate array) and / or software logic.

  In general, the CRM according to the first embodiment is used whenever data that can be input to a thread of execution different from the currently running thread (or process) is manipulated (the CRM spans all computation lanes). Guarantees atomicity), whenever data (including time of day) is being input or output from the software, whenever the software tries to change its thread of execution, the thread of execution is a “module” restart Called (via a request to enter / exit CR and a module interrupt) whenever the data required to persist through is being changed and whenever an event that generates a module interrupt occurs.

  FIG. 7 shows an example of how the CRM cooperates with other features of the I / O processor to mitigate the scenario shown in FIG.

  In the system of FIG. 7, lanes 1 and 2 are operating loosely synchronized, including the addition of OM units and CRM units as described herein. In this case, sparse synchronization means that lane 1 may be somewhere before or after less than one instruction in lane 2 and before or after any number of instructions in lane 2. For the example shown in FIG. 7, lane 1 is “before” lane 2.

  In step 1, process 1 in lane 1 calls the ARINC 653 Lock-Preemption API before setting the global Boolean to True. A call to Lock-Preemption generates a request to enter the critical region (CR). However, Lane 1 is not allowed to go to the “lock-preemption” state until Lane 2 also calls the ARINC 653 Lock-Preemption API, and the ARINC 653 Lock-Preemption API in Lane 2 is called the critical region (CR) Generate a request to enter, after which the CRM sends a critical event serialized to both lanes.

  In step 2, when a timer interrupt occurs (a “module” interrupts as shown in FIG. 6), a request to enter the CR is generated. The CRM cannot allow a timer interrupt to cause a context switch for any lane. This is because the CRM cannot generate another serialized critical event until each lane has generated a request to exit the CR.

  In step 3, at some point in the future, lane 1 unlocks the preemption and lane 2 locks and unlocks the preemption (this creates a request to exit CR). At this point, both lanes have been successfully updated with global data, and priority preemption (starting process 2 on both lanes) now delivers the next serialized critical event for the CRM. Can be generated through.

  In step 4, process 2 in both lanes reads Boolean and sends output (True). A data output management (OM) unit verifies that the outputs of both lanes are equal. As can be seen from FIG. 7, CRM mitigates the scenario shown in FIG.

  FIG. 8 shows an example of how the CRM cooperates with the OM to mitigate the scenario shown in FIG.

  In the system of FIG. 8, the same software having two processes (Process 1 and Process 2) is operating on both Lane 1 and Lane 2 in a loosely synchronized fashion. In this case, sparse synchronization means that lane 1 may be somewhere before or after less than one instruction in lane 2 and before or after any number of instructions in lane 2. For the example shown in FIG. 8, lane 1 is “before” lane 2.

  In step 1, lane 1 process 1 (low priority background process) sends a request to enter the critical region to the CRM so that it can start an output transaction on the port FOO. Allows to start its output transaction. Process 1 in lane 2 also sends a request to enter the critical region to the CRM and has started an output transaction on port FOO, but is “lagging behind” lane 1. The processing in lane 1 is at a point where FOO has been output from lane, but FOO has not yet been output from lane 2. Due to the introduction of CRM in the “module”, the CRM can leave lane 1 out of the critical region until process 1 in lane 2 also completes the same output transaction and requires it to exit out of the critical region Don't make it.

  In step 2, waiting for lane 1 to leave the critical area, a timer interrupt is generated while lane 2 is still performing its output transaction in the critical area.

  In step 3, a serialized interrupt can be delivered after both lanes have completed their I / O transaction and sent a request to exit the critical region, and process 2 in both lanes begins operation. . After this point, process 2 can safely restart process 1 (on both lanes). As can be seen from FIG. 8, the addition of CRM mitigates the fault condition that occurs in the scenario shown in FIG.

  OM ensures that high integrity data output from the software of all calculation lanes flows. If an error is detected in the output data flow, the OM prevents data from being output and provides an error indication.

  Note that there may be a large amount of data that is considered normal integrity. That is, there may be a large amount of data (and the entire software application) that does not require dual lane input / output elements (and associated overhead to perform cross-lane comparisons). The system and method according to the first embodiment allows normal integrity data to be output from one of the calculation lanes (outputs from other calculation lanes are ignored). In one possible implementation of the first embodiment, the configuration parameters specify specific data or the entire “hosted application” as either normal integrity or high integrity.

  The method and system according to the first embodiment supports requirements for high integrity and availability at the source. Furthermore, since the synchronization point is abstracted into the state of software running on the platform, the first embodiment can be extended to support different processors.

  The performance of the first embodiment can be limited by the amount of data that can be moderately synchronized and verified on the input / output plane. If this is a problem, performance can be optimized by taking advantage of the distinction (in the system) between normal and high integrity data and software applications. .

  The design and implementation of the CRM, TM, IM, and OM units does not rely on attributes of custom hardware functions (custom FPGA, ASIC) or current and / or possibly obsolete microprocessor functions. Thus, a module made according to the first embodiment exhibits the following exemplary beneficial attributes: a state-of-the-art micro, including an embedded memory controller, multiple phase-locked loops (PLLs) with different clock recovery circuits, and the like. The ability to utilize the processor (this easily increases the performance of the “module” without requiring a significant redesign of the “module” components that provide CRM, TM, IM, and OM (microprocessor upgrade The frequency of synchronization epochs (ie overhead) must be much less in an instruction level lockstep architecture. Thus, all synchronization mechanisms must be directly accessible from the software that needs to access it (no additional system calls are required). Therefore, the additional overhead due to synchronization must be on the order of 2-3 instructions at each epoch.

  Other benefits of the system and method according to the first embodiment are provided. The performance improvement must be scaled directly with the hardware performance improvement. That is, performance improvements do not require specialized hardware that can impose many constraints on the interface between the processor and the memory subsystem. The entire “hosted application” (DO-178B Level B, C, D, E) can be made identifiable as normal integrity. When this is done, the IM, TM, CRM, and OM elements are disabled for all data and control associated with this “hosted application” and all transactions are on one compute lane. Only occur, and other computational lanes can be idle during this time. This is not only for performance, but also leads to a reduction in power consumption (heat generation) when the processor of inactive compute lanes can be put into a “sleep” mode during a normal integrity time window. be able to.

  This first embodiment introduces the concept of normal integrity “hosted application” by allowing system integrators to use the free time of inactive compute lanes to execute different “hosted applications”. It is possible to use. This can lead to performance improvements for systems with a large amount of normal integrity “hosted applications”.

  The system and method according to the first embodiment is suitable for operating dual independent computing lanes, thus effectively doubling the performance of the “module” in normal integrity mode.

  The system and method according to the first embodiment supports different processors on different computation lanes on the “module”. In this case, different processor floating point units may be able to provide different rounding / truncation behavior (for example), which may result in slightly different data coming out of different computation lanes. There is sex. Thus, approximate data comparison (rather than exact data comparison) can be used for a class of output data flows to support different processors.

  Software application interaction with mechanisms using IM, TM, CRM, and OM can be incorporated into any operating system API (ie, no “special” API is required). Thus, the system and method according to the first embodiment is considered to impose only minimal constraints on the software application developer.

  The only impact on system integrators (and / or tools) is that the I / O configuration data has (optional) attributes to identify the data flow and "hosted application" as high or normal integrity. Expected to be.

  This written description uses examples to disclose the invention, including the best mode, and also to enable any person skilled in the art to make and use the invention. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are equivalent if they have structural elements that do not differ from the literal words of the claims, or if they have a substantial difference from the literal words of the claims. Where structural elements are included, they are intended to be within the scope of the claims.

300 Highly Sparsely Synchronized “Module”
310 “Hosted Application” Element 320 I / O Element 330A Nonvolatile Memory (NVM)
330B non-volatile memory (NVM)
340A Synchronous dynamic random access memory (SDRAM)
340B Synchronous dynamic random access memory (SDRAM)
350A processor CPU
350B processor CPU
360 Clock circuit 365 Clock monitor 370A Lane 1 input / output processor 370B Lane 2 input / output processor 375A Other input / output elements 375B Other input / output elements 380A ARINC 664 Part 7 elements 380B ARINC 664 Part 7 elements 382 Clock monitor 384 Clock 386A I / O PHY unit 386B I / O PHY unit 388A XFMR unit 388B XFMR unit 390 Power supply and monitor unit 395 Interface unit 500 CRM

Claims (9)

A “module” for a computer processing module (“module”) system of N (N is an integer greater than or equal to 2) lanes with high integrity,
One “hosted application” element and input / output element per processing lane;
An equivalent time value for the request, regardless of when the request generated by software running in each of the N processing lanes is actually received and acted upon by each of the N processing lanes. A time management unit (TM) configured to determine
A “module” comprising a critical region management unit (CRM) configured to allow a critical region in each lane to be identified and synchronized across all of the N processing lanes. Data input management configured to ensure that each respective lane receives exactly the same set of high integrity data as all other of the N processing lanes, and otherwise outputs an error condition An (IM) unit;
Data configured to determine whether each respective lane outputs a set of exactly the same integrity data as all other of the N processing lanes, and to output an error condition otherwise. The “module” of claim 1, further comprising an output management (OM) unit. The claim 1, wherein the critical region identified by the CRM corresponds to a region in software that cannot be preempted by any other thread of execution that is separate from the thread of execution that is currently running. module". The “module” of claim 1, wherein the TM includes a depth one buffer. The “module” according to claim 1, wherein the TM includes a buffer having a depth of M, and M is an integer of 2 or more. The high integrity data and the normal integrity data both flow through the N processing lanes, and only the high integrity data is manipulated by the high integrity "module". "Module". The “module” of claim 1, wherein the TM is implemented as a finite state machine. The “module” of claim 1, wherein the CRM is implemented as a finite state machine. In a “module” for a computer processing module (“module”) system having N (an integer greater than or equal to 2) lanes with high integrity,
One “hosted application” element and input / output element per processing lane;
Regardless of when requests made by software running in each of the N processing lanes, implemented as a finite state machine, are actually received and acted upon by each of the N processing lanes, A time management unit (TM) configured to determine an equivalent time value;
A critical region management unit (CRM) implemented as a finite state machine and configured to allow critical regions in each lane to be identified and synchronized across all of the N processing lanes ,
Data input management configured to ensure that each respective lane receives exactly the same set of high integrity data as all other of the N processing lanes, and otherwise outputs an error condition An (IM) unit;
Data configured to determine whether each respective lane outputs a set of exactly the same integrity data as all other of the N processing lanes, and to output an error condition otherwise. Both high integrity data and normal integrity data flow through the N processing lanes, and only the high integrity data is the high integrity “module”. "Module" operated by.

Images