EP1552394A1 - Verfahren zur ereignissynchronisation, insbesondere für prozessoren fehlertoleranter systeme - Google Patents

Verfahren zur ereignissynchronisation, insbesondere für prozessoren fehlertoleranter systeme

Info

Publication number
EP1552394A1
EP1552394A1 EP03807784A EP03807784A EP1552394A1 EP 1552394 A1 EP1552394 A1 EP 1552394A1 EP 03807784 A EP03807784 A EP 03807784A EP 03807784 A EP03807784 A EP 03807784A EP 1552394 A1 EP1552394 A1 EP 1552394A1
Authority
EP
European Patent Office
Prior art keywords
cpu
operating mode
instructions
module
counter
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP03807784A
Other languages
English (en)
French (fr)
Inventor
Anton Weber
Dirk Schnabel
Pavel Peleska
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Siemens Corp
Original Assignee
Siemens AG
Siemens Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from EP02020602A external-priority patent/EP1398699A1/de
Application filed by Siemens AG, Siemens Corp filed Critical Siemens AG
Priority to EP03807784A priority Critical patent/EP1552394A1/de
Publication of EP1552394A1 publication Critical patent/EP1552394A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1675—Temporal synchronisation or re-synchronisation of redundant processing components
    • G06F11/1691—Temporal synchronisation or re-synchronisation of redundant processing components using a quantum
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1675—Temporal synchronisation or re-synchronisation of redundant processing components
    • G06F11/1683—Temporal synchronisation or re-synchronisation of redundant processing components at instruction level

Definitions

  • Event synchronization method especially for processors of fault-tolerant systems
  • processor boards In many cases, up to a few hundred so-called processor boards are used in telecommunications systems, data centers and other high-availability systems to provide the necessary computing power.
  • a processor board typically consists of a processor or CPU (Central Processing Unit), a chip set, main memory and peripheral components.
  • CPU Central Processing Unit
  • the probability of a hardware defect of a typical processor board occurring per year is in the single-digit percentage range. Due to the large number of processor boards combined into a system, there is a very high probability of a failure of any hardware component in relation to the year, whereby such an individual failure, if suitable precautions are not taken, can cause the failure of the entire system.
  • Known solutions to comply with such high system availability requirements provide redundant system components. The known methods can be divided into two main groups: software-based methods and hardware-based methods.
  • the basic principle of hardware-based methods is based on encapsulating the redundancy at the hardware level so that this is transparent to the software.
  • the main advantage of a redundancy managed by the hardware itself is that the application software is not affected by the redundancy principle and therefore any software can be used in most cases. .
  • Lockstep means that identical hardware, e.g. two boards, operated in isochronous mode.
  • Hardware mechanisms ensure that the redundant hardware experiences identical input stimuli at a given point in time and must therefore come to identical results.
  • the results of the redundant components are compared; in the event of a deviation, an error is identified and suitable measures are initiated (alarm operator, partial or complete safety shutdown, system restart).
  • Cyclically deterministic behavior means that these components have identical results at identical clocks if there is no error - Deliver times when the components receive identical stimuli at identical clock times. Intermittent deterministic behavior also requires the use of isochronous interfaces. In many cases, asynchronous interfaces cause a certain degree of unsharpness in the system, as a result of which the clock-synchronous overall behavior of the system cannot be maintained.
  • asynchronous interfaces offer technological advantages in increasing performance, which makes clock-synchronous operation according to the lockstep process impossible.
  • modern CPUs increasingly use mechanisms that make clock-synchronous operation impossible.
  • These are, for example, internal corrective measures that are not visible to the outside, e.g. Correction of an internal, correctable error in accessing the cache memory, which can lead to a slight delay in command processing, or the speculative execution of commands.
  • Another example is the future increasing implementation of CPU-internal clock-free execution units, which allow considerable advantages in terms of speed and power dissipation, but prevent a clock-synchronous or deterministic work of the CPU.
  • European patent application 02020602 discloses a method for the synchronization of external events which are supplied to and influence a CPU, accordingly the external NEN events are temporarily stored, the stored external events being called up in a separate operating mode of the CPU for processing by an execution unit and the CPU entering this operating mode in response to the fulfillment of a condition that can be predetermined or specified by commands. This process is also called "emulated lockstep operation".
  • EP 02020602 advantageously provides that the switch to the separate operating mode is carried out if a comparator element of the CPU determines the correspondence of a counter with a maximum instruction register (MIR), the content of the MIR being specifiable by commands and the counter contains the number of instructions executed by the execution unit since the last change to the separate operating mode.
  • MIR maximum instruction register
  • This object is achieved by a method for synchronizing external events according to the features of patent claim 1, by a processor according to the features of patent claim 6 and by a system according to the features of patent claim 7.
  • Advantageous further developments are specified in the dependent claims.
  • a method for the synchronization of external events which are supplied to and influence a module CPU, the module CPU being provided for the parallel processing of a first number of instructions, accordingly the external events are temporarily stored, the external events stored in a separate operating mode of the module can be called up for processing by at least one execution unit EU of the module and - the module enters this operating mode after a predeterminable second number MIC of instructions has been processed by a counter (IC) executing the number of executions by the execution unit Instructions are determined since the last time the separate operating mode was exited, the module is placed in a single instruction execution mode if the counter IC is greater than or equal to the difference between the second number of instructions and a third number MD of instructions, which is determined from the first number of instructions, the module remains in the single instruction execution mode until the counter IC reaches the second number MIC of instructions, whereupon the module switches to the separate operating mode and the counter when the separate operating mode is exited IC is reinitialized.
  • the third number of instructions mentioned is based on the maximum number of instructions executed in parallel and serves to compensate for the blurring explained when stopping CPUs with the ability to process instructions in parallel.
  • the third number is preferably chosen to be equal to or greater than the first number of instructions executed in parallel.
  • the method according to the invention can be implemented by software, by microcode or by specialized hardware.
  • the counter IC is monitored by a monitoring software module, the number of instructions executed by the monitoring software module is recorded separately and subtracted from the counter IC.
  • the invention further provides a processor module CPU which has at least the following: at least one execution unit EU, - at least one counter element IC for counting the instructions executed by the execution unit since the last change to a separate operating mode, - at least one register element MIR, the content of which MIC is predefined by commands or is predetermined, - at least one comparator element K and at least one
  • Control element S for switching the execution unit EU into a single instruction execution mode in response to the counting element IC reaching a predeterminable value, which is smaller than the value of the register element MIR, and for switching the execution unit into the separate operating mode in response to the correspondence of the counting element IC with the register element MIR, whereby external events, which are temporarily stored in the separate operating mode and are to be supplied to the processor module CPU and influence the processor module CPU, are called up by the processor module CPU.
  • processors can advantageously be combined to form a system, the system additionally having a connection L0, Ll between at least two of the processor modules CPU which execute an identical instruction sequence, the connection being provided for transmitting synchronization information of the separate operating modes ,
  • Invention takes into account the fact that modern CPUs with the ability to process instructions in parallel cannot always be stopped after an exact number of instructions.
  • the CPUs can be operated with different clock frequencies.
  • the CPUs can behave differently with regard to the speculative execution of instructions, since only the completed instructions are evaluated. - Different CPU-internal execution times of identical CPUs, for example due to corrections after data corruption of alpha particles, only lead to the synchronization mode being reached at slightly different times.
  • FIG. 1 shows a flow diagram of the method according to the invention.
  • FIG. 2 schematically shows a processor module according to the invention.
  • FIG. 3 shows schematically an inventive system consisting of two processor modules according to FIG. 2.
  • FIG. 1 the inventive method is shown graphically as a flow chart. The following values must be defined or initialized before the process begins: - A counter IC (instruction counter), which contains the number of instructions or machine commands processed by the CPU.
  • IC instruction counter
  • a number of MICs (Maximum Instruction Counter) according to which the CPU is to switch to the special operating mode for processing external events.
  • MD Maximum Deviation
  • the process begins by comparing the current value of the command counter IC with the difference between the values MIC and MD (block 11). If the value of the command counter is less than this difference, command processing continues in the normal operating mode; parallel execution of instructions is possible. If the value of the command counter reaches or exceeds the difference between MIC and MD, a register d is loaded with the difference between MIC and MD (block 12), and the process enters a loop, at the beginning of which there is a query as to whether the register d has reached the value MIC (block 13). In this loop, the command is processed in single step mode.
  • the process enters the separate operating mode.
  • the separate operating mode first checks whether an interrupt request has been received during the processing of the MIC commands and has been buffered by all redundant CPUs for processing at the same time (blocks 16/17). If interrupt requests have been received, these are processed (block 18), this processing being carried out by all redundant CPUs at an identical point in the program processing and all registers, memory contents, .. being identical. This step is skipped if there are no interrupt requests.
  • the separate operating mode is ended, and the normal operating mode with parallel processing of instructions is resumed after the reset of the command counter IC (block 19).
  • An interrupt request can then be processed.
  • the interrupt routine is not processed in a separate operating mode, but in normal mode. Only the interrupt vector is read in special operating mode, then the special mode is exited again. Whether the interrupt is then processed depends, for example, on whether interrupts are currently permitted. Interrupts are not permitted if an interrupt is being processed and / or an "interrupt flag" has been cleared.
  • the method according to the invention can be used directly as a sequence of instructions, i.e. as software.
  • the software ensures that an interrupt is presented at identical points in the instruction execution of several processors by programming an instruction counter in the CPU so that it receives an exception, e.g. Debug exception, or a high-priority, non-lockable interrupt, e.g. the unmaskable interrupt NMI, caused by the desired number MIC of instructions to be processed minus the "stop blur" MD.
  • the software then run reads the instruction counter to determine where the processor has actually stopped. This software is designed so that the execution of your own instructions is corrected accordingly. If the software determines that the CPU has stopped after, for example, 999 instructions, the desired 100th instruction is executed subsequently by single-step operation, controlled by the exception software. This happens with all redundant CPUs, so that all CPUs were subsequently stopped at the identical position in the code.
  • the CPU / CPUs must be presented with any interrupt request.
  • the CPU can read a register of the interrupt controller, whereupon this releases a masked interrupt signal.
  • the CPU recognizes an interrupt request based on this interrupt signal and sends an interrupt acknowledge cycle to the interrupt controller.
  • the interrupt controller then supplies the interrupt vector and again masks the interrupt signal.
  • the software can read a register whose
  • the process can also be implemented in the form of microcode instructions.
  • modern CPUs have extensive options for controlling the execution of commands using microcode. These options are often used, for example, to correct or bypass design errors.
  • the microcode is changed in such a way that the CPU interrupts normal command execution after the desired number of instructions MIC to be processed minus the “stopping blur” MD and branches into the microcode.
  • the microcode reads out the number of executed instructions IC and controls the execution via single step in such a way that the command execution is stopped at the desired location MIC.
  • An interrupt signal masked by microcode is released by microcode, and if an interrupt is pending, the CPU is switched to the corresponding interrupt routine. branch. The interrupt is then masked again using microcode. - Alternatively, the CPU can be prompted to generate an interrupt acknowledge cycle and to read an interrupt vector. This is then presented to the CPU by microcode so that it branches into the corresponding interrupt routine after leaving the separate mode.
  • code translation software could take place.
  • Some CPUs have a simple, but very fast, mostly superscalar RISC or VLIW processor core.
  • the actual command set, e.g. IA-32 is transformed into simple code by code translation software and executed by the RISC / VLIW processor.
  • the code translation software carries out the task of the method, analogously to the implementation in microcode.
  • the interrupt requests are presented in the same way as for the microcode implementation.
  • the most efficient implementation of the method according to the invention is a hardware implementation, shown in FIG. 2.
  • a processor-internal hardware unit S stops parallel execution of the command at the desired location minus the unsharpness, the instruction counter status IC is determined, and the execution unit EU is determined by the processor-internal hardware unit S. brought to the desired position in the code by means of single step or single step ES.
  • the main advantage of this procedure is the significantly reduced negative impact on performance.
  • FIG. 2 shows a processor block CPU according to the invention in a schematic representation. Only the components relevant to this invention are shown.
  • the CPU comprises one or more execution units EU, at least one comparator K, at least one counter IC for counting the instructions executed by the execution unit EU, a controller S and at least one register element MIR, Its content can be specified by commands or can be predefined. Connections from / to an interrupt register (FIG. 3) are also shown schematically.
  • the external events influencing the program flow are not fed directly to the CPU, but are initially buffered by suitably designed hardware.
  • the method can be implemented in the CPU shown in FIG. 2 by loading the register MIR with the difference between the value MIC and the value MD.
  • the comparator K compares the number of operations carried out with this register value and signals the result of this comparison to the control unit S.
  • the comparator can also transmit to the control only an event that is generated when the value of the IC reaches the value of the MIR Has. If this event has occurred or if the two registers have been signaled to be identical, the controller S queries the command counter again in order to read the number of instructions actually executed.
  • the control can initiate the execution of instructions individually by the control, signaled via the line ES to the execution unit, until the value of the command counter reaches the predetermined value MIC reached .
  • the controller S has the option of incrementing the command counter IC if the command counter does not automatically count the instructions executed in the single step.
  • the controller S of each redundant CPU generates an interrupt enable signal IF which is fed to an interrupt module. Thereupon, if necessary, a buffered interrupt request is reported to all redundant CPUs via the interrupt line INT.
  • the controller S generates an interrupt for its own CPU, whereupon the execution units send an interrupt acknowledge cycle to the interrupt module. if interrupts are allowed in command processing at this time.
  • control S generates an interrupt enable signal IF which is logically ANDed with the interrupt signal INT, i.e. the circuit logic must be selected accordingly if there are inverted signals or if the interrupt signal is presented on several lines.
  • the interrupt enable signal can also be sent outside the CPU e.g. are transmitted to the interrupt register. Any interrupts present on the interrupt line INT are thus released, and the usual interrupt handling can take place, e.g. Read the interrupt vector, execute the .interrupt routine, etc.
  • the cancellation of the single-step mode and the separate operating mode and the continuation of the command processing in the normal mode are signaled to the execution unit, and the command counter is reset via a signal CL.
  • the control can be implemented directly as hardware or in the form of microcode.
  • FIG. 3 shows an interconnection of two CPUs as described above in connection with FIG. 2.
  • the first processor CPU0 and the second processor CPU1 are shown without the details from FIG. 2.
  • the processors each exchange addresses and data via a bus A / D with assigned interrupt blocks, which among other things Include interrupt registers IR0, IR1.
  • the interrupt blocks receive interrupts INTl .. INTn, for example from input / output blocks I / O, store the corresponding characteristic data and forward the interrupts INT to the processors.
  • the interrupts are only accepted by the processors at certain points in the execution of the command. This is described in detail in connection with FIG. 2.
  • the interrupt enable signal explained in this context can also be used to signal to the interrupt module assigned to each processor that the interrupt handling can be started.
  • the interrupt modules which are connected via connections L0, L1, can exchange this information and can only release the interrupt handling, for example, by transmitting the interrupt vector to the processors when all processors generate an interrupt enable signal.
  • CPUs that have SMT (Simultaneous Multi Threading) capabilities must have a separate controller for each virtual CPU or thread.
  • the CPU has the comparator or comparator K, which compares the number of commands executed, that is to say the counter IC, with the register MIR and, in the case of equality, for example generates an interrupt request which specifies the command execution based on the number of commands carried out by the register MIR - given instructions interrupts and the CPU switches to another operating mode.
  • suitable microcode is executed, for example, or an interrupt service routine is branched out, or hardware signals indicate that this synchronization point has been reached.
  • the external events are then presented to the redundant CPUs in such a way that after leaving this operating mode, all CPUs can evaluate these events in the same way and thus subsequently execute the same commands.
  • the CPU branches into an interrupt service routine in which the status of interrupt signals kept away from the CPU by the hardware described is queried in such a way that a redundant CPU, which may query this at a slightly later point in time that receives identical information.
  • the counter IC When leaving the separate operating mode, the counter IC is reset. Then the program jumps back to the point at which the interruption occurred due to the reaching of the counter value IC specified by the register MIR. The CPU will then again execute the number of machine instructions specified by the register MIR and, when the register value MIR has been reached, change the mode by means of the counter IC and thereby enable the acceptance of external events.
  • the CPU registers MIR are advantageously designed in such a way that they can be written to by software or microcode, in order to ensure that interrupt handling takes place at appropriate intervals for different areas of application by correspondingly specifying the number of instructions to be executed between the time windows for the interrupt handling becomes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Hardware Redundancy (AREA)

Abstract

Für redundante Systeme werden vielfach identisch aufgebaute Prozessorboards vorgesehen, die im Lockstep-Betrieb arbeiten. Die grundlegende Voraussetzung für die Implementierung eines Lockstep Systems ist das deterministische Verhalten aller im Board enthaltenen Komponenten, also CPUs, Chip Sets, Hauptspeicher etc. Deterministisches Verhalten bedeutet dabei, daß diese Komponenten im fehlerfreien Fall identische Ergebnisse zu identischen Zeitpunkten liefern, wenn die Komponenten identische Stimuli zu identischen Zeitpunkten erhalten. Deterministisches Verhalten setzt ferner die Verwendung taktsynchroner Schnittstellen voraus. Asynchrone Schnittstellen bewirken im System in vielen Fällen eine gewisse zeitliche Unschärfe, wodurch das taktsynchrone Gesamtverhalten des Systems nicht aufrecht erhalten werden kann. Um dennoch einen Lockstep-Betrieb durchführen zu können, sieht die vorliegende Erfindung ein Verfahren zur Synchronisation externer Ereignisse, die einem Prozessor (CPU) zugeführt werden und diesen beeinflussen, vor, demgemäß die externen Ereignisse zwischengespeichert werden, und den Prozessoren an identischer Stelle in der Befehlsausführung präsentiert werden, wobei Probleme, die durch die Fähigkeit moderner Prozessoren, Befehle parallel abzuarbeiten, entstehen, vermieden werden, indem die Parallelausführung der Prozessoren vor Erreichen der gewünschten Stelle in der Befehlsabarbeitung unterbunden und anschließend im Single-Step-Modus diese Stelle exakt erreicht wird.

Description

Beschreibung
Verfahren zur Ereignissynchronisation, insbesondere für Prozessoren fehlertoleranter Systeme
In Telekommunikationssystemen, in Data-Centern und anderen hochverfügbaren Systemen werden in vielen Fällen bis zu einigen Hundert sogenannter Prozessorboards eingesetzt, um die erforderliche Rechenleistung vorzusehen. Ein solches Prozes- sorboard besteht typischerweise aus einem Prozessor bzw. einer CPU (Central Processing Unit) , einem Chip Set, Hauptspeicher und Peripheriebausteinen.
Die Wahrscheinlichkeit des Auftretens eines Hardware-Defektes eines typischen Prozessorboards pro Jahr liegt im einstelligen Prozentbereich. Aufgrund der großen Anzahl zu einem System zusammengefaßter Prozessorboards ergibt sich eine auf den Jahreszeitraum bezogene sehr hohe Wahrscheinlichkeit eines Ausfalls einer beliebigen Hardware-Komponente, wobei ein sol- eher Einzelausfall, falls geeignete Vorkehrungen nicht getroffen werden, den Ausfall des gesamten Systems hervorrufen kann.
Insbesondere an Telekommunikationssysteme, in zunehmendem Ma- ße auch an Data-Center, wird die Forderung nach einer hohen Systemverfügbarkeit gestellt. Diese wird beispielsweise in Prozent ausgedrückt, oder es wird die maximal zulässige Ausfallzeit pro Jahr angegeben. Typische Anforderungen sind z.B. eine Verfügbarkeit von >99.999% bzw. eine NichtVerfügbarkeit von höchstens einigen Minuten im Jahr. Da üblicherweise der Austausch eines Prozessorboards und die Wiederherstellung des Dienstes im Falle eines Hardwaredefektes eine Zeit beansprucht, die im Bereich einige 10 Minuten bis einige Stunden liegt, müssen für den Fall eines Hardwaredefektes auf System- ebene entsprechende Vorkehrungen getroffen werden, um die Forderung nach der Systemverfügbarkeit erfüllen zu können. Bekannte Lösungen zur Einhaltung solch hoher Anforderungen an die Systemverfügbarkeit sehen redundante Systemkomponenten vor. Die bekannten Verfahren lassen sich in zwei hauptsächliche Gruppen einteilen: softwarebasierte Verfahren und hard- warebasierte Verfahren.
Bei softwarebasierten Verfahren wird typischerweise eine Middleware eingesetzt. Die softwarebasierte Lösung erweist sich jedoch als wenig flexibel, da lediglich diejenige (Ap- plikations-) Software in einem solchen System eingesetzt werden kann, die für dieses besondere Redundanzschema entwickelt wurde. Dies schränkt das Spektrum einsetzbarer (Applikations- ) Software erheblich ein. Darüber hinaus ist die Entwicklung von Applikationssoftware für Softwareredundanzprinzipien in der Praxis äußerst aufwendig, wobei die Entwicklung zusätzlich ein kompliziertes Testverfahren nach sich zieht.
Das Grundprinzip hardwarebasierter Verfahren beruht darauf, die Redundanz auf Hardwareebene zu kapseln, so daß dies für die Software transparent ist. Der wesentliche Vorteil einer von der Hardware selbst verwalteten Redundanz ist der, daß die Applikationssoftware durch das Redundanzprinzip nicht beeinträchtigt wird und somit in den meisten Fällen jede beliebige Software zum Einsatz kommen kann. ,
Ein in der Praxis häufig anzutreffendes Prinzip für hardware- fehlertolerante Systeme, deren Redundanz für die Software transparent -ist, ist das sogenannte Lockstep-Prinzip. Lockstep bedeutet, daß identisch aufgebaute Hardware, z.B. zwei Boards, gleichartig taktsynchron betrieben werden. Durch
Hardwaremechanismen wird sichergestellt, daß die redundante Hardware zu einem gegebenen Zeitpunkt identische Eingangsstimuli erfährt und dadurch zu identischen Ergebnissen kommen muß. Die Ergebnisse der redundanten Komponenten werden ver- glichen, im Fall einer Abweichung wird ein Fehler festgestellt und geeignete Maßnahmen werden eingeleitet (Alarmie- rung an das Bedienpersonal, partielle oder vollständige Sicherheitsabschaltung, Systemneustart) .
Die grundlegende Voraussetzung für die Implementierung eines Lockstep-Systems ist das taktweise deterministische Verhalten aller im Board enthaltenen Komponenten, also CPUs, Chip Sets, Hauptspeicher etc. Taktweise deterministisches Verhalten bedeutet dabei, daß diese Komponenten im fehlerfreien Fall i- dentische Ergebnisse zu identischen Takt -Zeitpunkten liefern, wenn die Komponenten identische Stimuli zu identischen Takt- Zeitpunkten erhalten. Taktweise deterministisches Verhalten setzt ferner die Verwendung taktsynchroner Schnittstellen voraus. Asynchrone Schnittstellen bewirken im System in vielen Fällen eine gewisse zeitliche Unscharfe, wodurch das taktsynchrone Gesamtverhalten des Systems nicht aufrecht erhalten werden kann.
Gerade für Chip Sets und CPUs bieten asynchrone Schnittstellen jedoch technologische Vorteile bei der Erhöhung der Leis- tungsfähigkeit, wodurch eine taktsynchrone Betriebsweise nach dem Lockstep-Verfahren unmöglich wird. Zudem verwenden moderne CPUs zunehmend Mechanismen, die eine taktsynchrone Betriebsweise unmöglich machen. Dies sind beispielsweise interne, nach außen nicht sichtbare Korrekturmaßnahmen, z.B. Kor- rektur eines internen, korrigierbaren Fehlers beim Zugriff auf den Cache-Speicher, die zu einer geringfügigen Verzögerung der Befehlsabarbeitung führen können, oder die spekulative Ausführung von Befehlen. Ein weiteres Beispiel ist die zukünftig zunehmende Implementierung von CPU- internen takt- freien Ausführungseinheiten, die erhebliche Vorteile hinsichtlich Geschwindigkeit und Verlustleistung ermöglichen, jedoch ein taktsynchrones bzw. deterministisches Arbeiten der CPU verhindern.
Die europäische Patentanmeldung 02020602 offenbart ein Verfahren zur Synchronisation externer Ereignisse, die einer CPU zugeführt werden und diese beeinflussen, demgemäß die exter- nen Ereignisse zwischengespeichert werden, wobei die gespeicherten externen Ereignisse in einem gesonderten Betriebsmodus der CPU zur Verarbeitung durch eine Ausführungseinheit abgerufen werden und wobei die CPU in diesen Betriebsmodus ansprechend auf die Erfüllung einer durch Befehle vorgebbaren oder fest vorgegebenen Bedingung eintritt . Dieses Verfahren wird auch "emulierter Lockstep Betrieb" genannt.
Vorteilhaft sieht die EP 02020602 vor, daß der Wechsel in den gesonderten Betriebsmodus ausgeführt wird, falls durch ein Komparatorelement der CPU die Übereinstimmung eines Zählers mit einem Maximum Instruction Register (MIR) ermittelt wird, wobei der Inhalt des MIR durch Befehle vorgebbar ist und der Zähler die Anzahl der durch die Ausführungseinheit ausgeführ- ten Instruktionen seit dem letzten Wechsel in den gesonderten Betriebsmodus enthält .
Moderne CPUs lassen sich jedoch nicht so stoppen, daß sie nach einer exakten Anzahl von Instruktionen anhalten. Dies liegt darin begründet, daß mehrere Instruktionen parallel abgearbeitet werden können, die zu einem gemeinsamen Zeitpunkt abgeschlossen werden. So können beispielsweise in einem Takt 99 Instruktionen auf allen redundanten CPUs abgearbeitet sein, im nächsten Takt sind es beispielsweise aufgrund unter- schiedlicher Ausführung dann auf einer CPU 100 Instruktionen, auf einer anderen jedoch 101 Instruktionen. Ein externes Ereignis, z.B. ein Interrupt, kann so nicht an identischen Stellen in der Befehlsausführung präsentiert werden.
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren anzugeben, mit dem externe Ereignisse auch dann an gleichen Stellen in der Befehlsausführung redundanter CPUs präsentiert werden, wenn das Anhalten der redundanten CPUs nach Ausführung ein und derselben Instruktion nicht gesichert möglich ist. Diese Aufgabe wird durch ein Verfahren zur Synchronisation externer Ereignisse gemäß der Merkmale des Patentanspruchs 1, durch einen Prozessor gemäß der Merkmale des Patentanspruchs 6 und durch ein System gemäß der Merkmale des Patentanspruchs 7 gelöst. Vorteilhafte Weiterbildungen sind in den abhängigen Ansprüchen angegeben.
Erfindungsgemäß wird ein Verfahren zur Synchronisation externer Ereignisse, die einem Baustein CPU zugeführt werden und diesen beeinflussen, wobei der Baustein CPU zur parallelen Abarbeitung von einer ersten Anzahl von Instruktionen vorgesehen ist, vorgesehen, demgemäß die externen Ereignisse zwischengespeichert werden, wobei die gespeicherten externen Ereignisse in einem gesonderten Betriebsmodus des Bausteins zur Verarbeitung durch zumindest eine Ausführungseinheit EU des Bausteins abgerufen werden und - wobei der Baustein in diesen Betriebsmodus nach Abarbeitung einer vorgebbaren zweiten Anzahl MIC von Instruktio- nen eintritt, indem ein Zähler (IC) die Anzahl der durch die Ausführungseinheit ausgeführten Instruktionen seit dem letzten Verlassen des gesonderten Betriebsmodus ermittelt, der Baustein in einen Einzelbefehlsausführungsmodus ver- setzt wird, falls der Zähler IC größer oder gleich der Differenz aus der zweiten Anzahl von Instruktionen und einer dritten Anzahl MD von Instruktionen, die aus der ersten Anzahl von Instruktionen ermittelt wird, ist, der Baustein im Einzelbefehlsausführungsmodus verbleibt, bis der Zähler IC die zweite Anzahl MIC von Instruktionen erreicht, woraufhin der Baustein in den gesonderten Betriebsmodus wechselt und bei Verlassen des gesonderten Betriebsmodus der Zähler IC neu initialisiert wird.
Die genannte dritte Anzahl von Instruktionen ist dabei an der maximalen Anzahl der parallel ausgeführten Instruktionen orientiert und dient dem Ausgleich der erläuterten Unsch rfe beim Anhalten von CPUs mit der Fähigkeit zur parallelen Abarbeitung von Instruktionen. Die dritte Anzahl wird vorzugsweise als gleich oder größer der ersten Anzahl maximal parallel ausgeführter Instruktionen gewählt.
In redundanten Systemen, die zumindest zwei Bausteine CPU aufweisen, wird eine identische Folge von Instruktionen für die Bausteine CPU vorgesehen, und durch die Bausteine werden im gesonderten Betriebsmodus identische externe Ereignisse abgerufen. Ein schnellerer Baustein CPU wird durch eine Steuerung im gesonderten Betriebsmodus belassen, bis ein langsamerer Baustein das Ende des gesonderten Betriebsmodus erreicht hat.
Das erfindungsgemäße Verfahren kann durch eine Software, durch Microcode oder durch spezialisierte Hardware realisiert werden. Bei einer Überwachung des Zählers IC durch ein Überwachungssoftwaremodul wird die Anzahl der durch das Überwachungssoftwaremodul verursachten ausgeführten Instruktionen gesondert erfaßt und vom Zähler IC subtrahiert.
Die Erfindung sieht ferner einen Prozessorbaustein CPU vor, der zumindest folgendes aufweist: mindestens eine Ausführungseinheit EU, - mindestens ein Zählerelement IC zum Zählen der durch die Ausführungseinheit ausgeführten Instruktionen seit dem letzten Wechsel in einen gesonderten Betriebsmodus, - mindestens ein Registerelement MIR, dessen Inhalt MIC durch Befehle vorgebbar oder fest vorgegeben ist, - mindestens ein Ko paratorelement K und mindestens ein
Steuerelement S zum Umschalten der Ausführungseinheit EU in einen Einzelbefehlsausführungsmodus ansprechend auf das Erreichen eines vorgebbaren Wertes, der kleiner als der Wert des Registerelementes MIR ist, durch das Zähl- element IC, und zum Umschalten der Ausführungseinheit in den gesonderten Betriebsmodus ansprechend auf die Übereinstimmung des Zählelementes IC mit dem Registerelement MIR, wobei in dem gesonderten Betriebsmodus zwischengespeicherte, dem Prozessorbaustein CPU zuzuführende externe Ereignisse, die den Prozessorbaustein CPU beeinflussen, durch den Prozessorbaustein CPU abgerufen werden.
5
Mehrere dieser Prozessoren können vorteilhaft zu einem System zusammengefaßt werden, wobei das System zusätzlich eine Verbindung L0, Ll zwischen zumindest zwei der Prozessorbausteine CPU, die eine identische Instruktionsfolge ausführen, auf- 10 weist, wobei die Verbindung zum Übertragen von Synchronisationsinformationen der gesonderten Betriebsmodi vorgesehen ist.
Ein wesentlicher Vorteil der Erfindung ist darin zu sehen, daß die Verwendung beliebiger neuer oder bestehender Software
15 auf einer hardwarefehlertoleranten Plattform ermöglicht wird, wobei in dieser Plattform eine die Erfindung unterstützende CPU zum Einsatz kommen kann, ohne daß die Forderung nach taktsynchroner, deterministischer Arbeitsweise der CPU besteht und wobei die Verwendung asynchroner Hochgeschwindig-
20 keitsschnittstellen bzw. Links möglich ist. Dabei trägt die
Erfindung dem Umstand Rechnung, daß sich moderne CPUs mit Fähigkeiten zur parallelen Abarbeitung von Instruktionen nicht in jedem Fall nach einer exakten Anzahl von Instruktionen anhalten lassen.
'25
Weitere Vorteile sind:
- Die zueinander redundanten Boards und CPUs müssen nicht phasenstarr gekoppelt betrieben werden.
- Die CPUs müssen nicht identisch sein, sie müssen ledig-
30 lieh nach der gleichen Anzahl abgearbeiteter Maschineninstruktionen anhalten und den Betriebsmodus wechseln. Die CPUs können mit unterschiedlichen Taktfrequenzen betrieben werden.
- Die CPUs können sich unterschiedlich in Bezug auf die 35 spekulative Ausführung von Instruktionen verhalten, da nur die komplettierten Instruktionen bewertet werden. - Unterschiedliche CPU-interne Ausführungszeiten identischer CPUs, z.B. aufgrund von Korrekturen nach dem datenverfälschendem Auftreten von Alpha-Teilchen, führen lediglich dazu, daß der Synchronisationsmodus zu geringfü- gig unterschiedlichen Zeitpunkten erreicht wird.
Im folgenden wird ein Ausführungsbeispiel der Erfindung im Zusammenhang mit drei Figuren näher erläutert.
Figur 1 zeigt ein AblaufSchema des erfindungsgemäßen Verfahrens . Figur 2 zeigt schematisch einen erfindungsgemäßen Prozessorbaustein. Figur 3 zeigt schematisch ein erfindungsgemäßes System beste- hend aus zwei Prozessorbausteinen gemäß Figur 2.
In Figur 1 ist das erfindungsgemäße Verfahren als Ablaufschema graphisch dargestellt. Vor Beginn des Ablaufs müssen folgende Werte festgelegt bzw. initialisiert sein: - Ein Zähler IC (Instruction Counter) , der die Anzahl der durch die CPU abgearbeiteten Instruktionen bzw. Maschinenbefehle enthält.
Eine Anzahl MIC (Maximum Instruction Counter) von Instruktionen, nach welcher die CPU in den besonderen Be- triebsmodus zur Abarbeitung von externen Ereignissen wechseln soll.
Eine Anzahl MD (Maximum Deviation) von Instruktionen, die die maximal aufgrund von Parallelität der Befehlsausführung auftretende Unscharfe des Anhaltens der CPU berück- sichtigt.
Der Ablauf beginnt damit, daß der aktuelle Wert des Befehlszählers IC mit der Differenz aus den Werten MIC und MD verglichen wird (Block 11) . Ist der Wert des Befehlszählers ge- ringer als diese Differenz, wird die Befehlsabarbeitung im normalen Betriebsmodus fortgesetzt; die parallele Ausführung von Instruktionen ist möglich. Erreicht oder überschreitet der Wert des Befehlszählers die Differenz aus MIC und MD, wird ein Register d mit der Differenz aus MIC und MD geladen (Block 12) , und der Ablauf tritt in eine Schleife ein, an deren Beginn eine Abfrage steht, ob das Register d den Wert MIC erreicht hat (Block 13) . In dieser Schleife erfolgt die Befehlsabarbeitung im Einzelschrittmodus bzw. Single Step Mode.
Solange der Wert d den Wert MIC nicht erreicht, wird in jedem Schleifendurchlauf eine einzelne Instruktion ausgeführt (Block 14) und der Wert d inkrementiert (Block 15) , bevor die Schleifenbedingung (Block 13) erneut geprüft wird. Durch dieses Vorgehen wird sichergestellt, daß trotz im Normalbetrieb paralleler Befehlsabarbeitung das Eintreten in den gesonderten Betriebszustand exakt nach MIC Instruktionen erfolgt.
Falls der Wert d den Wert MIC erreicht (Block 13) , tritt der Ablauf in den gesonderten Betriebsmodus ein. Der gesonderte Betriebsmodus überprüft zunächst, ob während der Abarbeitung der MIC Befehle eine Interruptanforderung eingetroffen ist und zur gleichzeitigen Abarbeitung durch alle redundanten CPUs zwischengespeichert wurde (Blöcke 16/17) . Sind Interruptanforderungen eingetroffen, werden diese abgearbeitet (Block 18) , wobei diese Abarbeitung durch alle redundanten CPUs an identischer Stelle in der Programmabarbeitung erfolgt und alle Register, Speicherinhalte, .. identisch sind. Dieser Schritt wird- übersprungen, falls keine Interruptanforderungen vorliegen.
Der gesonderte Betriebsmodus wird beendet, und der normale Betriebsmodus mit paralleler Verarbeitung von Instruktionen wird nach dem Rücksetzen des Befehlszählers IC (Block 19) wieder aufgenommen. Eine Interruptanforderung kann dann bear- beitet werden. Der Abarbeitung der Interruptroutine erfolgt nicht im gesonderten Betriebsmodus, sondern im normalen Modus. Lediglich das Einlesen des Interruptvektors erfolgt im besonderen Betriebsmodus, danach wird der besondere Mode wieder verlassen. Ob der Interrupt dann bearbeitet wird, hängt z.B. davon ab, ob zu diesem Zeitpunkt gerade Interrupts erlaubt sind. Interrupts sind nicht erlaubt, wenn gerade ein Interrupt bearbeitet wird und/oder ein "Interrupt Flag" gelöscht ist.
Anhand des dargestellten Ablaufs kann das erfindungsgemäße Verfahren direkt als Instruktionsfolge, d.h. als Software, implementiert werden. Dabei sorgt die Software dafür, daß ein Interrupt an identischen Stellen der Befehlsausführung mehrerer Prozessoren präsentiert wird, indem ein Instruktionszähler in der CPU so programmiert wird, daß er eine Exception, z.B. Debug-Exception, oder einen hochprioren, nicht sperrba- ren Interrupt, z.B. den nichtmaskierbaren Interrupt NMI, nach der gewünschten Zahl MIC von abzuarbeitenden Instruktionen abzüglich der "Anhalteunschärfe" MD verursacht. Beispielsweise wird der Zähler IC bei einer Unscharfe von MD=3 Instruktionen und einer gewünschten Zahl von MIC=1000 Instruktionen mit 1000-3+1=998 programmiert. Die CPU wird, in Abhängigkeit der internen Bündelung von Instruktionen, also nach IC=998 oder IC=999 oder IC=1000 Instruktionen anhalten. Die daraufhin ausgeführte Software liest den Instruktionszähler aus, um festzustellen, an welcher Stelle der Prozessor tatsächlich angehalten hat. Dabei ist diese Software so beschaffen, daß die Ausführung der eigenen Instruktionen entsprechend korrigiert wird. Falls die Software feststellt, daß die CPU nach beispielsweise 999 Instruktionen angehalten hat, wird die gewünschte lOOOste Instruktion per Single-Step Betrieb, gesteu- ert durch die Exception-Software , nachträglich ausgeführt. Dies geschieht bei allen redundanten CPUs, so daß alle CPUs anschließend an der identischen Stelle im Code angehalten wurden .
An dieser Stelle muß der/den CPU/CPUs eine eventuell vorhandene Interruptanforderung präsentiert werden. Hierzu gibt es beispielsweise folgende Möglichkeiten: - Die CPU kann ein Register des Interrupt-Controllers auslesen, woraufhin dieser ein maskiertes Interruptsignal freigibt. Die CPU erkennt anhand dieses Interruptsignals eine Interruptanforderung und sendet einen Interrupt Acknowledge Zyklus zum Interrupt-Controller. Der Interrupt-Controller liefert daraufhin den Interruptvektor und maskiert das Interruptsignal wieder.
- Alternativ kann die Software ein Register lesen, dessen
Wert bereits die Information über die Art des Interrupts liefert, d.h. den Interruptvektor. Anschließend löst die Software selbst den entsprechenden Interrupt (per Software) aus, falls Interrupts zu diesem Zeitpunkt in der Befehlsabarbeitung erlaubt sind.
Ferner kann der Ablauf auch in Form von Microcode-Anweisungen realisiert werden. Moderne CPUs weisen in vielen Fällen weitgehende Möglichkeiten auf, mittels Microcode die Befehlsausführung zu steuern. Diese Möglichkeiten werden häufig beispielsweise dazu verwendet, Design-Fehler zu beheben bzw. zu umgehen.
Für den Zweck des erfindungsgemäßen Verfahrens wird der Microcode so geändert, daß die CPU nach der gewünschten Zahl von abzuarbeitenden Instruktionen MIC abzüglich der "Anhalteun- schärfe" MD die normale Befehlsausführung unterbricht und in den Microcode verzweigt. Der Microcode liest die Anzahl ausgeführter Instruktionen IC aus und steuert die Ausführung per Single-Step so an, daß die Befehlsausführung an der gewünschten Stelle MIC angehalten wird.
An dieser Stelle muß der/den CPU/CPUs wiederum eine eventuell vorhandene Interruptanforderung präsentiert werden. Hierzu gibt es ebenfalls mehrere Möglichkeiten:
Ein per Microcode maskiertes Interruptsignal wird per Microcode freigegeben, und falls ein Interrupt anliegt, wird die CPU in die entsprechende Interruptroutine ver- zweigen. Anschließend wird der Interrupt wieder per Microcode maskiert . - Alternativ kann die CPU veranlaßt werden, einen Interrupt Acknowledge Zyklus zu generieren und einen Interruptvek- tor zu lesen. Dieser wird dann per Microcode der CPU so präsentiert, daß diese nach dem Verlassen des gesonderten Modus in die entsprechende Interruptroutine verzweigt.
Ferner kann eine Implementierung in der Codeübersetzungssoft- wäre erfolgen. Einige CPUs verfügen über einen einfachen, a- ber sehr schnellen, meist superskalaren RISC- oder VLIW- Prozessor Kern. Der eigentliche Befehlsatz, z.B. IA-32, wird durch eine Codeübersetzungssoftware in einen einfachen Code transformiert und vom RISC-/VLIW-Prozessor ausgeführt. In diesem Falle führt die Code Übersetzungssoftware die Aufgabe des Verfahrens aus, analog der Implementierung in Microcode. Die Präsentation der Interruptanforderungen erfolgt wie bei der Microcode- Implementierung.
Die effizienteste Implementierung des erfindungsgemäßen Verfahrens ist eine Hardwareimplementierung, dargestellt in Figur 2. Hierbei wird von einer prozessorinternen Hardwareeinheit S die parallele Befehlsausführung an der gewünschten Stelle abzüglich Unscharfe angehalten, der Instruktionszäh- lerstand IC ermittelt, und die Ausführungseinheit EU wird von der prozessorinternen Hardwareeinheit S mittels Single-Step bzw. Einzelschritt ES an die gewünschte Stelle im Code herangeführt. Der- wesentliche Vorteil dieses Verfahrens ist der erheblich reduzierte negative Performance-Einfluß.
Figur 2 zeigt einen erfindungsgemäßen Prozessorbaustein CPU in einer schematischen Darstellung. Dabei sind nur die für diese Erfindung relevanten Bestandteile dargestellt. Die CPU umfaßt eine oder mehrere Ausführungseinheiten EU, mindestens einen Komparator K, mindestens einen Zähler IC zum Zählen der durch die Ausführungseinheit EU ausgeführten Instruktionen, eine Steuerung S und mindestens ein Registerelement MIR, des- sen Inhalt durch Befehle vorgebbar .oder fest vorgegeben sein kann. Ferner sind Verbindungen von/zu einem Interruptregister (Figur 3) schematisch dargestellt.
Die den Programmablauf beeinflussenden externen Ereignisse werden der CPU nicht direkt zugeführt, sondern von einer geeignet gestalteten Hardware zunächst gepuffert. Die Umsetzung des Verfahrens kann in der in Figur 2 dargestellten CPU erfolgen, indem das Register MIR mit der Differenz aus dem Wert MIC und dem Wert MD geladen wird. Der Komparator K vergleicht die Zahl der ausgeführten Operationen mit diesem Registerwert und signalisiert das Ergebnis dieses Vergleichs an die Steuerungseinheit S. Alternativ kann der Komparator auch nur ein Ereignis an die Steuerung übermitteln, das generiert wird, wenn der Wert des IC den Wert des MIR erreicht hat. Ist dieses Ereignis eingetreten oder wurde Gleichheit der beiden Register signalisiert, fragt die Steuerung S den Befehlszähler nochmals ab, um die Zahl der tatsächlich ausgeführten Instruktionen zu lesen. Da im MIR durch das Laden mit dem Wert MIC-MD die Unscharfe bereits berücksichtigt wurde, kann durch die Steuerung ein Einzelschrittmodus, signalisiert über die Leitung ES an die Ausführungseinheit, die Ausführung von Instruktionen einzeln veranlassen, bis der Wert des Befehlszählers den vorgegebenen Wert MIC erreicht . Die Steuerung S ver- fügt dazu über die Möglichkeit, den Befehlszähler IC zu in- krementieren, sofern der Befehlszähler die im Single-Step ausgeführten Instruktionen nicht automatisch zählt.
Die Steuerung S jeder redundanten CPU erzeugt ein Inter- ruptfreigabesignal IF, das einem Interruptbaustein zugeführt wird. Daraufhin wird allen redundanten CPUs eine gegebenenfalls zwischengespeicherte Interruptanforderung über die Interruptleitung INT gemeldet.
Alternativ dazu erzeugt die Steuerung S einen Interrupt für die eigene CPU, woraufhin die Ausführungseinheiten einen Interrupt Acknowledge Zyklus zum Interruptbaustein senden, falls Interrupts zu diesem Zeitpunkt in der Befehlsabarbeitung erlaubt sind.
In einer weiteren Alternative wird durch die Steuerung S ein Interruptfreigabesignal IF erzeugt, welches dem Sinn nach mit dem Interruptsignal INT UND-verknüpft wird, d.h. die Schaltungslogik ist entsprechend zu wählen, falls invertierte Signale vorliegen oder falls das Interruptsignal auf mehreren Leitungen präsentiert wird. Das Interruptfreigabesignal kann ebenfalls nach außerhalb der CPU z.B. an das Interruptregister übermittelt werden. Eventuell an der Interruptleitung INT anliegende Interrupts werden somit freigegeben, und die gewöhnliche Interruptbehandlung kann erfolgen, z.B. Lesen des Interruptvektors, Ausführen der .Interruptroutine usw.
Vor der Interruptbehandlung wird die Aufhebung des Einzelschrittmodus und des gesonderten Betriebsmodus und die Fortsetzung der Befehlsabarbeitung im Normalmodus an die Ausführungseinheit signalisiert, und der Befehlszähler wird über ein Signal CL zurückgesetzt. Die Steuerung kann direkt als Hardware oder in Form von Microcode realisiert sein.
In Figur 3 wird schließlich eine Zusammenschaltung zweier CPUs gemäß vorstehender Beschreibung im Zusammenhang mit Fi- gur 2 gezeigt. Dabei sind der erste Prozessor CPU0 und der zweite Prozessor CPU1 ohne die Details aus Figur 2 dargestellt. Die Prozessoren tauschen jeweils Adressen und Daten über einen Bus A/D mit zugeordneten Interruptbausteinen, die u.a. Interruptregister IR0, IR1 umfassen, aus. Die Interrupt- bausteine empfangen Interrupts INTl .. INTn beispielsweise von Eingabe/Ausgabebausteinen I/O, speichern entsprechende Kenndaten und leiten die Interrupts INT an die Prozessoren weiter.
Erfindungsgemäß werden die Interrupts durch die Prozessoren nur an bestimmten Stellen der Befehlsausführung akzeptiert. Dies ist ausführlich im Zusammenhang mit Figur 2 beschrieben. Das in diesem Zusammenhang erläuterte Interruptfreigabesignal kann außerdem verwendet werden, um dem jedem Prozessor zugeordneten Interruptbaustein zu signalisieren, daß die Interruptbehandlung begonnen werden kann. Die Interruptbausteine, die über Verbindungen L0, Ll verbunden sind, können diese Informationen austauschen und die Interruptbehandlung ihrerseits erst dann z.B. durch Übermitteln des Interruptvektors an die Prozessoren freigeben, wenn alle Prozessoren ein Interruptfreigabesignal erzeugen.
In einer Alternative kann es sich als vorteilhaft erweisen, die CPUs nicht an einer vordefinierte Stelle MIC der Befehlsausführung anzuhalten, sondern an einer mit der Unscharfe der parallel abarbeitbaren Befehle behafteten Stelle, und dann die zurückliegenden Prozessoren per Single Step an die Stelle der Befehlsausführung heranzuführen, an der derjenige Prozessor angehalten hat, der in der Befehlsausführung am weitesten fortgeschritten ist . Hierzu ist eine Kommunikation zwischen den Prozessoren erforderlich. Diese kann beispiels- weise so erfolgen, daß jeder Prozessor die Stelle, an der er selbst angehalten hat, in ein Hardware-Register schreibt und anschließend zurückliest. Das Register wartet bis alle Prozessoren ihren Wert geschrieben haben und liefert als Lesedatum den höchsten Wert zurück. Falls erforderlich, gleichen dann alle Prozessoren ihren Stand der Befehlsausführung per
Single-Step an. Die Interruptanforderung wird den Prozessoren dann wie oben beschrieben präsentiert.
CPUs, die über SMT (Simultaneous Multi Threading) Fähigkeiten verfügen, müssen eine separate Steuerung für jede virtuelle CPU bzw. jeden Thread verfügen.
Ferner weist die CPU den Komparator oder Vergleicher K auf, der die Anzahl der ausgeführten Befehle, also den Zähler IC, mit dem Register MIR vergleicht und bei Gleichheit beispielsweise eine Interrupt-Anforderung generiert, der die Befehlsausführung nach der Zahl der durch das Register MIR vor- gegeben Instruktionen unterbricht und die CPU in einen anderen Betriebsmodus schaltet. In diesem Betriebsmodus wird beispielsweise geeigneter Microcode ausgeführt oder in eine Interrupt Service Routine verzweigt oder per Hardware-Signalen das Erreichen dieses Synchronisationspunktes angezeigt. In diesem Betriebsmodus werden dann den redundanten CPUs die externen Ereignisse so präsentiert, daß nach dem Verlassen dieses Betriebsmodus alle CPUs diese Ereignisse gleich bewerten können und somit in der Folge die gleichen Befehle ausführen werden.
Beispielsweise verzweigt die CPU nach Erreichen der durch das Register MIR vorgegeben Anzahl von Maschineninstruktionen in eine Interrupt Service Routine, in welcher der Zustand von durch die beschriebene Hardware von der CPU ferngehaltenen Interrupt Signalen so abgefragt wird, daß eine redundante CPU, die ggf. diese Abfrage zu einem geringfügig späteren Zeitpunkt stellt, die identische Auskunft erhält.
Beim Verlassen des gesonderten Betriebsmodus wird der Zähler IC zurückgesetzt. Anschließend wird zu der Programmstelle zurückgesprungen, an der die Unterbrechung durch das Erreichen des durch das Register MIR vorgegeben Zählerwertes IC stattgefunden hat. Danach wird die CPU wieder die durch das Regis- ter MIR vorgegebene Anzahl von Maschineninstruktionen ausführen und bei Erreichen des Registerwertes MIR durch Zähler IC den Mode wechseln und dadurch die Annahme von externen Ereignissen ermög-lichen.
Vorteilhaft sind die CPU-Register MIR so ausgebildet, daß sie durch Software oder Microcode beschreibbar sind, um zu gewährleisten, daß für verschiedene Einsatzgebiete eine Interruptbehandlung in adäquaten Intervallen stattfindet, indem entsprechend die Anzahl der auszuführenden Instruktionen zwi- sehen den Zeitfenstern für die Interruptbehandlung festgelegt wird.

Claims

Patentansprüche
1. Verfahren zur Synchronisation externer Ereignisse, die einem Baustein (CPU), zugeführt werden und diesen beeinflus- sen, wobei der Baustein (CPU) zur parallelen Abarbeitung von einer ersten Anzahl von Instruktionen vorgesehen ist, demgemäß die externen Ereignisse zwischengespeichert werden, wobei die gespeicherten externen Ereignisse in einem gesonderten Betriebsmodus des Bausteins zur Verarbeitung durch zumindest eine Ausführungseinheit (EU) des Bausteins abgerufen werden und - wobei der Baustein in diesen Betriebsmodus nach Abarbeitung einer vorgebbaren zweiten Anzahl (MIC) von Instruktionen eintritt, indem - ein Zähler (IC) die Anzahl der durch die Ausführungseinheit ausgeführten Instruktionen seit dem letzten Verlassen des gesonderten Betriebsmodus ermittelt, der Baustein in einen Einzelbefehlsausführungsmodus versetzt wird, falls der Zähler (IC) größer oder gleich der Differenz aus der zweiten Anzahl von Instruktionen und einer dritten Anzahl (MD) von Instruktionen, die aus der ersten Anzahl von Instruktionen ermittelt wird, ist, der Baustein im Einzelbefehlsausführungsmodus verbleibt, bis der Zähler (IC) die zweite Anzahl (MIC) von Instruk- tionen erreicht, woraufhin der Baustein in den gesonderten Betriebsmodus wechselt und bei Verlassen des gesonderten Betriebsmodus der Zähler (IC) neu initialisiert wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet , daß die dritte Anzahl von Instruktionen als gleich oder größer der ersten Anzahl maximal parallel ausgeführter Instruktionen gewählt wird.
Verfahren nach einem der Ansprüche 1 oder 2 , d a d u r c h g e k e n n z e i c h n e t , daß in redundanten Systemen,, die zumindest zwei Bausteine (CPU) aufweisen, eine identische Folge von Instruktionen für die Bausteine (CPU) vorgesehen ist und durch die Bausteine im gesonderten Betriebsmodus identische externe Ereignisse abgerufen werden.
4. Verfahren nach Anspruch 3 , dadurch gekennzeichnet, daß ein schnellerer Baustein (CPU) durch eine Steuerung im gesonderten Betriebsmodus belassen wird, bis ein langsamerer Baustein das Ende des gesonderten Betriebsmodus erreicht hat .
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeich e , daß bei einer Überwachung des Zählers (IC) durch ein Überwachungssoftwaremodul die Anzahl der durch das Überwachungssoftwaremodul verursachten ausgeführten Instruktionen gesondert erfaßt und vom Zähler (IC) subtrahiert wird.
6. Prozessorbaustein (CPU), der zumindest folgendes aufweist: mindestens eine Ausführungseinheit (EU) , mindestens ein Zählerelement (IC) zum Zählen der durch die Ausführungseinheit ausgeführten Instruktionen seit dem letzten Wechsel in einen gesonderten Betriebsmodus, - mindestens ein Registerelement (MIR) , dessen Inhalt (MIC) durch Befehle vorgebbar oder fest vorgegeben ist, mindestens ein Komparatorelement (K) und mindestens ein Steuerelement (S) zum Umschalten der Ausführungseinheit
(EU) in einen Einzelbefehlsausführungsmodus ansprechend auf das Erreichen eines vorgebbaren Wertes, der kleiner als der Wert des Registerelementes (MIR) ist, durch das Zählelement (IC) , und zum Umschalten der Ausführungsein- heit in den gesonderten Betriebsmodus ansprechend auf die Übereinstimmung des Zählelementes (IC) mit dem Registerelement (MIR) , wobei in dem gesonderten Betriebsmodus zwischengespeicherte, dem Prozessorbaustein (CPU) zuzuführende externe Ereignisse, die den Prozessorbaustein (CPU) beeinflussen, durch den Prozessorbaustein (CPU) abgerufen werden. 5
7. System bestehend aus mindestens zwei Prozessorbausteinen
(CPUO, CPU1) , die jeweils zumindest folgendes aufweisen:
- mindestens eine Ausführungseinheit (EU) ,
- mindestens ein Zählerelement (IC) zum Zählen der durch 10 die Ausführungseinheit ausgeführten Instruktionen seit dem letzten Wechsel in den gesonderten Betriebsmodus,
- mindestens ein Registerelement (MIR) , dessen Inhalt durch
Befehle vorgebbar oder fest vorgegeben ist,
- mindestens ein Komparatorelement (K) und mindestens ein 15 Steuerelement (S) zum Umschalten der Ausführungseinheit
(EU) in einen Einzelbefehlsausführungsmodus ansprechend auf das Erreichen eines vorgebbaren Wertes, der kleiner als der Wert des Registerelementes (MIR) ist, durch das Zählelement (IC) , und zum Umschalten der Ausführungsein-
20 heit (EU) in einen gesonderten Betriebsmodus ansprechend auf die Übereinstimmung des Zählelementes (IC) mit dem Registerelement (MIR) , wobei in dem gesonderten Betriebsmodus zwischengespeicherte, den Prozessorbausteinen zuzuführende externe Ereignisse, welche die Prozessorbaustei- '25 ne beeinflussen, durch die Prozessorbausteine abgerufen werden.
8. System nach Anspruch 7, das zusätzlich eine Verbindung
(L0, Ll) zwischen zumindest zwei der Prozessorbausteine
30 (CPU) , die eine identische Instruktionsfolge ausführen, aufweist, wobei die Verbindung zum Übertragen von Synchronisationsinformationen der gesonderten Betriebsmodi vorgesehen is .
EP03807784A 2002-09-12 2003-08-07 Verfahren zur ereignissynchronisation, insbesondere für prozessoren fehlertoleranter systeme Withdrawn EP1552394A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP03807784A EP1552394A1 (de) 2002-09-12 2003-08-07 Verfahren zur ereignissynchronisation, insbesondere für prozessoren fehlertoleranter systeme

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
EP02020602A EP1398699A1 (de) 2002-09-12 2002-09-12 Verfahren zur Ereignissynchronisation, insbesondere für Prozessoren fehlertoleranter Systeme
EP02020602 2002-09-12
EP02027848 2002-12-12
EP02027848A EP1398701A1 (de) 2002-09-12 2002-12-12 Verfahren zur Ereignissynchronisation, insbesondere für Prozessoren fehlertoleranter Systeme
PCT/EP2003/008794 WO2004034261A1 (de) 2002-09-12 2003-08-07 Verfahren zur ereignissynchronisation, insbesondere für prozessoren fehlertoleranter systeme
EP03807784A EP1552394A1 (de) 2002-09-12 2003-08-07 Verfahren zur ereignissynchronisation, insbesondere für prozessoren fehlertoleranter systeme

Publications (1)

Publication Number Publication Date
EP1552394A1 true EP1552394A1 (de) 2005-07-13

Family

ID=31889442

Family Applications (2)

Application Number Title Priority Date Filing Date
EP02027848A Withdrawn EP1398701A1 (de) 2002-09-12 2002-12-12 Verfahren zur Ereignissynchronisation, insbesondere für Prozessoren fehlertoleranter Systeme
EP03807784A Withdrawn EP1552394A1 (de) 2002-09-12 2003-08-07 Verfahren zur ereignissynchronisation, insbesondere für prozessoren fehlertoleranter systeme

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP02027848A Withdrawn EP1398701A1 (de) 2002-09-12 2002-12-12 Verfahren zur Ereignissynchronisation, insbesondere für Prozessoren fehlertoleranter Systeme

Country Status (6)

Country Link
US (1) US20050229035A1 (de)
EP (2) EP1398701A1 (de)
CN (1) CN1639691A (de)
AU (1) AU2003251697A1 (de)
CA (1) CA2498596A1 (de)
WO (1) WO2004034261A1 (de)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7231554B2 (en) * 2002-03-25 2007-06-12 Availigent, Inc. Transparent consistent active replication of multithreaded application programs
US7305582B1 (en) * 2002-08-30 2007-12-04 Availigent, Inc. Consistent asynchronous checkpointing of multithreaded application programs based on active replication
US7206964B2 (en) * 2002-08-30 2007-04-17 Availigent, Inc. Consistent asynchronous checkpointing of multithreaded application programs based on semi-active or passive replication
EP1398700A1 (de) * 2002-09-12 2004-03-17 Siemens Aktiengesellschaft Verfahren und Schaltungsanordnung zur Synchronisation redundanter Verarbeitungseinheiten
DE102004038590A1 (de) * 2004-08-06 2006-03-16 Robert Bosch Gmbh Verfahren zur Verzögerung von Zugriffen auf Daten und/oder Befehle eines Zweirechnersystems sowie entsprechende Verzögerungseinheit
JP4289293B2 (ja) * 2004-12-20 2009-07-01 日本電気株式会社 起動制御方法、二重化プラットフォームシステム及び情報処理装置
JP2006178636A (ja) * 2004-12-21 2006-07-06 Nec Corp フォールトトレラントコンピュータ、およびその制御方法
US20060271812A1 (en) * 2005-05-26 2006-11-30 David Horton Systems and methods for providing redundant application servers
GB0602641D0 (en) * 2006-02-09 2006-03-22 Eads Defence And Security Syst High speed data processing system
FR2912526B1 (fr) * 2007-02-13 2009-04-17 Thales Sa Procede de maintien du synchronisme d'execution entre plusieurs processeurs asynchrones fonctionnant en parallele de maniere redondante.
US9086977B2 (en) 2011-04-19 2015-07-21 Freescale Semiconductor, Inc. Cache memory with dynamic lockstep support
US9208036B2 (en) 2011-04-19 2015-12-08 Freescale Semiconductor, Inc. Dynamic lockstep cache memory replacement logic
US9176828B2 (en) * 2012-09-04 2015-11-03 Opshub, Inc. System and method for merging results from multiple runs based on run inputs
US9176830B2 (en) * 2013-05-24 2015-11-03 Hyundai Motor Company Method for determining software error in virtualization based integrated control system

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3235762A1 (de) * 1982-09-28 1984-03-29 Fried. Krupp Gmbh, 4300 Essen Verfahren und vorrichtung zur synchronisation von datenverarbeitungsanlagen
CA2003338A1 (en) * 1987-11-09 1990-06-09 Richard W. Cutts, Jr. Synchronization of fault-tolerant computer system having multiple processors
US5226152A (en) * 1990-12-07 1993-07-06 Motorola, Inc. Functional lockstep arrangement for redundant processors
DE19625195A1 (de) * 1996-06-24 1998-01-02 Siemens Ag Synchronisationsverfahren
JP2001523855A (ja) * 1997-11-14 2001-11-27 マラソン テクノロジーズ コーポレイション 故障回復／耐故障計算機
DE19943790C2 (de) * 1999-09-13 2001-11-15 Ericsson Telefon Ab L M Verfahren und Vorrichtung zur Bestimmung eines Synchronisationsfehlers in einem Netzwerkknoten
US6802024B2 (en) * 2001-12-13 2004-10-05 Intel Corporation Deterministic preemption points in operating system execution

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004034261A1 *

Also Published As

Publication number Publication date
US20050229035A1 (en) 2005-10-13
WO2004034261A1 (de) 2004-04-22
AU2003251697A1 (en) 2004-05-04
EP1398701A1 (de) 2004-03-17
CA2498596A1 (en) 2004-04-22
CN1639691A (zh) 2005-07-13

Similar Documents

Publication Publication Date Title
DE68928360T2 (de) Hochleistungsrechnersystem mit fehlertoleranter Fähigkeit; Verfahren zum Betrieb desselben
DE3781486T2 (de) Verfahren zur stossfreien umschaltung von aktiven einheiten zu ersatzeinheiten in datenverarbeitungsanlagen und datenverarbeitungsanlage zur durchfuehrung dieses verfahrens.
EP1807763B1 (de) Verfahren und vorrichtung zur überwachung einer speichereinheit in einem mehrprozessorsystem
EP1552394A1 (de) Verfahren zur ereignissynchronisation, insbesondere für prozessoren fehlertoleranter systeme
DE102005037246A1 (de) Verfahren und Vorrichtung zur Steuerung eines Rechnersystems mit wenigstens zwei Ausführungseinheiten und einer Vergleichseinheit
DE2319753B2 (de) Anordnung zur Datenverarbeitung mittels in Mikroprogrammierung betriebener Prozessoren
EP1952239A1 (de) Vorrichtung und verfahren zum beheben von fehlern bei einem wenigstens zwei ausführungseinheiten mit registern aufweisenden system
EP2513796B1 (de) Verfahren zum betreiben einer recheneinheit
EP1537482B1 (de) Verfahren und schaltungsanordnung zur synchronisation synchron oder asynchron getakteter verarbeitungseinheiten
EP0543821B1 (de) Einrichtung zur funktionsüberwachung externer synchronisations-baugruppen in einem mehrrechnersystem
WO2001037058A1 (de) Automatisierungsgerät und aufdat-verfahren
EP1543421A2 (de) Verfahren zur ereignissynchronisation, damit synchronisierte prozessoren und fehlertoleranter systeme mit derartigen prozessoren
DE102004051991A1 (de) Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
EP2287742B1 (de) Programmgesteuerte Einheit
EP0584512A1 (de) Verfahren zum zeitlichen Überwachen einer Programmabarbeitung
DE10148157B4 (de) Programmgesteuerte Einheit
EP2248021B1 (de) Anordnung zur überprüfung eines programmspeichers einer recheneinheit
DE102005054081B3 (de) Schaltungstechnisch realisierte Einheit zur nahezu verzögerungsfreien, nach Altersklassen sortierten Ausgabe zuvor sequenziell zugeführter Datenwortmengen
DE102008042088B3 (de) Vorrichtung zum temporären Abschalten von Interrupts in einem Rechnersystem
DE102004051964A1 (de) Verfahren und Vorrichtung zur Überwachung einer Speichereinheit in einem Mehrprozessorsystem
DE102004051992A1 (de) Verfahren und Vorrichtung zur Verzögerung von Zugriffen auf Daten und/oder Befehle eines Mehrprozessorsystems
DE102009001422A1 (de) Verfahren zur Fehlerbehandlung eines Rechnersystems
DE102006037907A1 (de) Verfahren und Anordnung zur Steuerung des Programmablaufs in einem Prozessor
DE102005041469A1 (de) Datenverarbeitungssystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20040709

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB SE

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20060301