WO2005045664A2 - Verfahren und vorrichtung zur umschaltung zwischen wenigstens zwei betriebsmodi einer prozessoreinheit - Google Patents

Verfahren und vorrichtung zur umschaltung zwischen wenigstens zwei betriebsmodi einer prozessoreinheit Download PDF

Info

Publication number
WO2005045664A2
WO2005045664A2 PCT/DE2004/001859 DE2004001859W WO2005045664A2 WO 2005045664 A2 WO2005045664 A2 WO 2005045664A2 DE 2004001859 W DE2004001859 W DE 2004001859W WO 2005045664 A2 WO2005045664 A2 WO 2005045664A2
Authority
WO
WIPO (PCT)
Prior art keywords
programs
identifier
mode
processor unit
operating modes
Prior art date
Application number
PCT/DE2004/001859
Other languages
English (en)
French (fr)
Other versions
WO2005045664A3 (de
Inventor
Reinhard Weiberle
Thomas Kottke
Andreas Steininger
Original Assignee
Robert Bosch Gmbh
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
Application filed by Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to EP04762699A priority Critical patent/EP1680736A2/de
Priority to US10/577,009 priority patent/US20070245133A1/en
Priority to JP2006534568A priority patent/JP2007508626A/ja
Publication of WO2005045664A2 publication Critical patent/WO2005045664A2/de
Publication of WO2005045664A3 publication Critical patent/WO2005045664A3/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003—Arrangements for executing specific machine instructions
    • G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/845—Systems in which the redundancy can be transformed in increased performance

Definitions

  • the invention is based on a method and a device for switching between at least two operating modes of a processor unit and a corresponding processor unit with at least two execution units for processing programs in accordance with the preambles of the independent claims.
  • Such processor units with at least two integrated execution units are also known as dual-core or multi-core architectures.
  • dual-core or multi-core architectures are proposed according to the current state of the art for two main reasons:
  • an increase in performance that is to say an increase in performance
  • the two execution units or gores process different programs or tasks. This enables an increase in performance, which is why this configuration is referred to as performance mode.
  • the second reason is to implement a dual-core or multi-core architecture, increasing security by both Execute execution units redundantly the same program. The results of the two execution units are compared and an error can then be identified in the comparison for agreement. In the following, this configuration is referred to as safety mode.
  • the two configurations mentioned are included exclusively on the dual or multi-core architecture, i. H. the computer with the at least two execution units is in principle only operated in one mode: either the performance mode or the safety mode.
  • the object of the invention is now to enable a combined operation of such a dual or multi-core processor unit with respect to at least two operating modes and to achieve an optimal switching strategy between at least two operating modes, that is to say in particular between the safety mode and the power mode.
  • processor units can on the one hand be complete gores, that is to say complete CPUs, or else in a preferred exemplary embodiment only the arithmetic unit is duplicated.
  • ALU arithmetic logic unit
  • the circuit presented additionally requires less chip area than a complete dual-core architecture. Nevertheless, with the method according to the invention, that is to say equally for double CPU or double ALU, adequate fault coverage in the safety mode, and at calculations that are not relevant to safety, a significant increase in performance can be achieved in performance mode.
  • the invention is therefore based on a method and a device for switching between at least two operating modes of a processor unit with at least two execution units for processing programs, with the programs advantageously being assigned at least one identifier which differentiates into the at least two operating modes, that is to say in particular Security mode and power mode are permitted and there is a switchover between the operating modes as a function of the identifier, so that the processor unit processes the programs in accordance with the assigned operating mode.
  • programs also encompasses program parts, that is to say blocks of code, which extend over several programs in whole or in part, via task programs which are contained in the individual programs or are formed by the programs, up to individual program commands, each of which is assigned an identifier.
  • Such an identifier assignment can be used to switch between the individual operating modes at the functional level, that is to say in particular to control operating processes in a vehicle.
  • it can also be advantageous
  • Programs or corresponding task programs, program parts or program commands that belong to an operating system of the processor unit or represent this operating system can be assigned to the corresponding operating mode by such identifiers.
  • the processing of the programs expediently compares the resulting states or results for agreement, whereby errors are identified in the event of a deviation.
  • the identifier is advantageously designed as at least one bit, such an identifier being expediently carried out by a program command, in particular by a Instruction provided in the instruction set of the processor unit, such as a write instruction is generated.
  • this identifier can be assigned to the corresponding program, program part, execution program or program command, or else it can be or be written into a special, provided memory area.
  • an optimized switchover between two operating modes in particular the power mode and the safety mode in the case of a dual-core architecture or an architecture with only a duplicated arithmetic value, that is to say a double ALU, can thus take place.
  • FIG. 1 and 2 each show a processor unit with a duplicated arithmetic value, in which the switchover according to the invention can be carried out.
  • Figure 3 shows the switch from the safety mode to the power mode and Figure 4 shows the switch from the power mode to the safety mode.
  • FIG. 5 shows the assignment of the identifiers to the programs, program parts, task programs or commands using a number of code lines 500.
  • FIGS. 1 and 2 of the drawing identical or functionally identical elements have been provided with the same reference numerals, unless stated otherwise.
  • the program-controlled unit according to the invention and its components such as Microcontroller core (CPU), memory units, peripheral units etc. have not been shown directly in FIGS. 1 and 2 for the sake of clarity.
  • the two arithmetic units ALU A and Alu B can also correspond to complete cores, that is to say CPUs in the context of the invention, so that the invention can also be used for complete dual-core architectures.
  • reference numerals 1 and 2 each denote arithmetic logic units (ALU) as execution units.
  • a respective ALU unit 1, 2 has two inputs and one output.
  • the operands intended for execution can be coupled directly from the bus 3 into the inputs of the ALU units 1, 2 or previously stored in an operand register 8, 9 specially provided for this purpose.
  • These operand registers 8, 9 are directly coupled to the data bus 3.
  • the two ALU units 1, 2 are therefore the same
  • Operand registers 8, 9 are supplied.
  • the respective operands are already provided with an ECC coding via the bus, which are stored in the register areas 8a, 9a.
  • ECC code Error Correction Code
  • the data can be secured by using an ECC code (Error Correction Code).
  • ECC code Error Correction Code
  • Such methods for error detection are diverse, the basic requirement being security with an error detection or error correction code, ie a signature. In the simplest case, this signature can only consist of a signature bit, for example a parity bit.
  • the protection can also be implemented by more complex ED codes (error detection) such as a Berger code or a Bose-Lin code etc.
  • the safety-critical mode that is to say in the safety mode SM, the safety-critical programs are processed redundantly in both execution units, that is to say both here ALUs 1 and 2, as a result of which errors in these are revealed by comparison according to the invention.
  • the non-security-relevant or non-security-critical programs or tasks, or program parts or code blocks or commands can be calculated distributed over both execution units in order to increase the performance, which increases the throughput and thus the performance. This takes place in the so-called performance mode or performance mode LM.
  • the input data from registers 10, 11 can also be compared with that from source registers 8, 9. If there is a difference in the ECC coding or in the operands, this is interpreted as an error and an error signal is output, possibly displayed and possibly corrected.
  • This comparison advantageously takes place during the processing of the operands in the ALU units 1, 2, so that they are input-side
  • Error detection and error correction goes hand in hand with almost no loss of performance. If one of the comparison units 5, 6 detects an error, the calculation can be repeated within the next cycle.
  • a shadow register can be used to always save the operands of the last calculation so that they are quickly available again in the event of an error. The provision of such a shadow register can, however, be dispensed with if the respective operand registers 10, 11 are only rewritten by an enable signal due to the absence of an error.
  • the comparison units 5, 6 deliver an error signal, as a result of which the operand registers 10, 11 are not rewritten.
  • the ALU units 1, 2 each produce a result on the output side.
  • the result data provided by the ALU units 1, 2 or their ECC coding are stored in the result registers 12, 13, 12a, 13a. These result data and / or their coding are compared with one another in the comparison unit 14. In the absence of an error, an enable signal 16 is generated. This release signal 16 is coupled into the release device 15, which is caused to write the result data on a bus 4. This result data can then be processed again via bus 4.
  • the enable signal 16 can also be used to enable the registers 8 to 11 again, so that the next operands can be read from the bus 3 and can be processed in the ALU units 1, 2.
  • the result is not checked with the arrangement in FIG. 1. Only the result data in the comparison unit 14 are compared here.
  • the ECC coding of the result data can only be checked by the arrangement in FIG. 2, in which both the result data and its ECC coding are compared with one another in the comparison unit 14.
  • a switch is used to switch between the aforementioned safety mode, in which redundant processing and testing takes place, and the performance mode, in which an increase in performance is achieved by separate program processing
  • Switching device UE 17 By means of this switching device 17, the elements 8, 9 and 1, 2 are switched so that in one case, that is to say in the safety mode SM, redundant program processing, in particular synchronous program processing, and in the second operating mode, the performance mode LM a parallel processing different programs can be carried out.
  • switches or switching means can be provided, which can be located on the one hand in the elements 8, 9 or 1, 2 or also in the switching device 17 or additionally contained in the circuit separately from the elements 8, 9, 1, 2 or 17 are.
  • the programs or task programs or program parts that is to say code blocks or also the commands, are identified by an identifier which can be used to identify whether they are safety-relevant, that is to say they must be processed in the safety mode SM or can be made accessible to the performance mode LM. This can be done by a bit in the command, or the subsequent sequence can be identified by a special command. This will be described in more detail using the different labeling options in FIG. 5.
  • the programs can include application functions on the one hand. B. to control operations in a vehicle, or switch to programs in which the
  • Marking is done at the operating system level, e.g. B. an assignment of entire operating system tasks.
  • the switchover device 17 can now recognize whether the calculation that follows is safety-relevant, that is to say should be carried out in safety mode or not. If this is the case, the data are transferred to both execution units 1 and 2. If this is not the case, so if work continues in performance mode, an execution unit receives the data and at the same time the next instruction, if this is also not security-related, can be given to the second execution unit, so that the programs are processed in parallel with a higher throughput ,
  • FIGS. 3 and 4 shows the switchover from the safety mode to the power mode and
  • FIG. 4 shows the switchover from the power mode to the
  • execution unit 1 is in the second operating mode, the performance mode.
  • the second execution unit 2 is also in the performance mode.
  • the switching device 17, which is designed, for example, as a decoder module, or contains one, the elements 8 and 9 controlled or switched.
  • block 320 or block 321 at least one identifier is determined in accordance with the program flow of the respective execution unit 1 or 2, by means of which a switchover in block 330 from both execution units to the first operating mode, the security mode SM, takes place. As a result, both branches run over the
  • Blocks 8 and 9 and the execution units 1 and 2 are again redundant and in particular synchronous with respect to the security-relevant programs identified by the identifier, so that the security mode SM is again present. It is sufficient that in a program run in the performance mode, that is to say in a branch, such an identifier for switching is available in order to lead both execution units into the safety mode. In some cases, the processing of the program code already started by the other execution unit may have to be processed so that both can then continue to work in the safety mode. On the other hand, it can also be provided to switch immediately to the safety mode and, in the case of a subsequent performance mode, to start the program starting from
  • query block 210 it is now checked whether there is a switchover identifier or whether an existing identifier makes it possible to switch to the power mode. If this is not the case, that is to say if there is no identifier or if the identifier continues to indicate the security mode, block 200 is reached again and the programs are further processed in the security mode. If an identifier is present or if this indicates the switchover, the switchover or change to the second operating mode, the power or performance mode LM, takes place in block 220.
  • FIG. 5 shows the programs P1 from line ZI to line Z6, P2 from line Z7 to line Z15 and P3 from line Z16 to line Z19.
  • AP is a
  • Task program for example, shown as part of a program P1, with several programs, eg. B. Pl and P2, together can form a task program.
  • CB represents a code block, that is to say a program part which comprises, for example, lines of two programs, here Z14 to ZI 8 of programs P2 and P3.
  • a code block that is to say a program part, can only be part of a program.
  • a program command is also shown with PB3 corresponding to line ZI 9.
  • Lines ZS1 and ZS2 represent a special memory area SSB which can contain such an identifier, here KB, as a predetermined memory area.
  • different identifiers are shown with K1, K2, K3 and K4 and KB, which take into account the different possibilities of the method according to the invention.
  • the security mode SM can be provided as the basic processing mode, that is to say as the default mode (likewise, of course, the performance mode). If an identifier is present, the system then switches to the power mode accordingly (or vice versa to the Security Mode).
  • an identifier must be present in principle and that the corresponding mode is inferred from the content of the identifier, that is to say in particular its bit values. In this case, for example, a binary value 1 (or also another value, in particular the dominant value) is assigned to the safety mode SM and the binary value 0 (or also another value in particular the recessive value) to the power mode LM.
  • identifiers K1, K2 and K3 can be of different lengths, so that, for example, in the case of identifier K2 according to line Z7, 3 bits, B1 to B3 make up the identifier, so that on the one hand with bit B1 in K2 security mode SM or power mode LM is decided and, for example, bits B2 and B3 indicate the number of lines to which this mode, for example the safety mode, applies, so that the entire program P2 or only a part thereof is processed in the safety mode.
  • code blocks that is to say program parts which, for example, do not comprise an overall task, that is to say do not represent a task program
  • CB code blocks
  • K3 identifier
  • a start line or address with bits B2 and B3 at K3 and an end line or end address with bits B4 and B5 at K3 can also be specified here, so that a special area is processed in a correspondingly assigned operating mode becomes.
  • K4 such an identification assignment can also take place for individual commands PB3 in ZI 9 or • also for each command.
  • these identifiers can thus be assigned to complete programs or task programs AP or program parts CB, or also to individual program instructions PB, here PB3, which then triggers a corresponding switchover by the switchover device 17.
  • the query in block 210 or in blocks 320 and 321 then checks for the presence of such an identifier K1 to K4 or KB or switches its content.
  • the identifier as shown here, can be designed as at least one bit, but can also comprise several bits, on the one hand depending on the different number of operating modes, on the other hand due to additional information such as the number of lines or a start or end address.
  • At least one program command can be provided, here PB1, PB2 or even PB3, which first generates an identifier which indicates whether the first or second operating mode is to be processed.
  • the identifier can be written into a specific memory area SSB, as shown here with KB in ZS2.
  • This area SSB can be located in a register, in a memory integrated in the CPU, but also in an external memory.
  • a special command e.g. B. PB3 may be provided or a command that is already present in the command set of the processor unit.
  • a command "generated identifier" can thus be implemented as a special command, for example, or a command that is already present in the processor command set, in particular a write command, can be used, as represented here by PB 1 and PB2, so that the write command WR in Z9 in FIG
  • Memory area KB writes the binary value 0, represented by WR (KB: 0) and thus all subsequent lines as long as the identifier is KBO, e.g. B. processed in security mode. With the same command, the value 1 can then be entered in Z12 at PB2 by WR (KB: 1) in the memory area for the identifier KB, so that from this point on the following lines, e.g. B. in performance mode, can be processed. I.e.
  • simple identifier-generating commands in particular a simple write command WR, a corresponding switchover identifier KB can then be generated, for example, in a special memory area which is queried regularly.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Hardware Redundancy (AREA)
  • Storage Device Security (AREA)

Abstract

Verfahren und Vorrichtung zur Umschaltung zwischen wenigstens zwei Betriebsmodi (SM, LM) einer Prozessoreinheit (100, 101) mit wenigstens zwei Ausführungseinheiten (ALUA, ALUB) zur Abarbeitung von Programmen (P1, P2, P3), wobei wenigstens den Programmen (P1, P2, P3) wenigstens eine Kennung (K2) zugeordnet ist, welche eine Unterscheidung in die wenigstens zwei Betriebsmodi (SM, LM) erlaubt und eine Umschaltung zwischen den Betriebsmodi in Abhängigkeit von der Kennung (K1-K4, KB) erfolgt, so dass die Prozessoreinheit (100, 101) die Programme (P1, P2, P3) entsprechend des zugeordneten Betriebsmodus abarbeitet.

Description

Verfahren und Vorrichtung zur Umschaltung zwischen wenigstens zwei Betriebsmodi einer Prozessoreinheit
Stand der Technik
Die Erfindung geht aus von einem Verfahren und einer Vorrichtung zur Umschaltung zwischen wenigstens zwei Betriebsmodi einer Prozessoreinheit sowie entsprechender Prozessoreinheit mit wenigstens zwei Ausführungseinheiten zur Abarbeitung von Programmen gemäß den Oberbegriffen der unabhängigen Ansprüche.
Solche Prozessoreinheiten mit wenigstens zwei integrierten Ausführungseinheiten sind auch als Dual-Core- oder Multi-Core-Architekturen bekannt. Solche Dual-Core- oder Multi-Core-Architekturen werden nach heutigem Stand der Technik hauptsächlich aus zwei Gründen vorgeschlagen:
Zum Einen kann damit eine Leistungssteigerung, also eine Performance-Steigerung erreicht werden, indem die beiden Ausführungseinheiten oder Gores als zwei Recheneinheiten auf einem Halbleiterbaustein betrachtet und behandelt werden. In dieser Konfiguration bearbeiten die zwei Ausführungseinheiten oder Gores unterschiedliche Programme respektive Tasks. Dadurch lässt sich eine Leistungssteigerung erzielen, weshalb diese Konfiguration als Leistungsmodus oder Performance-Mode bezeichnet wird.
Neben dem Einsatz als superskalare Prozessoren ist der zweite Grund eine Dual-Core- oder Multi-Core-Architektur zu realisieren, die Steigerung der Sicherheit, indem beide Ausführungseinheiten redundant das gleiche Programm abarbeiten. Die Ergebnisse der beiden Ausführungseinheiten werden verglichen, und ein Fehler kann dann bei dem Vergleich auf Übereinstimmung erkannt werden. Im Folgenden wird diese Konfiguration als Sicherheitsmodus oder safety-mode bezeichnet.
Im Allgemeinen sind die beiden genannten Konfigurationen exklusiv auf der Dual- oder Multi-Core-Architektur enthalten, d. h. der Rechner mit den wenigstens zwei Ausführungseinheiten wird prinzipiell nur in einem Modus betrieben: Entweder dem Performance-Modus oder dem Safety-Modus.
Aufgabe der Erfindung ist es nun, einen kombinierten Betrieb einer solchen Dual- oder Multi-Core-Prozessoreinheit bezüglich wenigstens zwei Betriebsarten zu ermöglichen und dabei eine optimale Umschaltstrategie zwischen wenigstens zwei Betriebsmodi, also insbesondere zwischen Sicherheitsmodus und Leistungsmodus zu erzielen.
Vorteile der Erfindung
Es ist zum Einen aus Sicherheitsgründen eine redundante Ausführung der Programme respektive Tasks, also auch von Aufgabenprogrammen, Programmteilen, also Codeblöcken oder auch einzelnen Befehlen erwünscht, aber andererseits aus
Kostengründen das Bereithalten von vollständig redundanter Hardware bei der Ausführung der nicht sicherheitskritischen Funktionen nicht erstrebenswert. Dieser Zielkonflikt wird erfindungsgemäß durch eine optimierte Umschaltung zwischen wenigstens zwei Betriebsmodi bei einer Prozessoreinheit gelöst. So geht die Erfindung von einem Verfahren und einer Vorrichtung zur Umschaltung zwischen wenigstens zwei
Betriebsmodi einer Prozessoreinheit mit wenigstens zwei Ausführungseinheiten sowie entsprechender Prozessoreinheit aus. Die Prozessoreinheiten können dabei zum Einen vollständige Gores, also vollständige CPUs sein oder aber auch in einem bevorzugten Ausführungsbeispiel wird nur das Rechenwerk dupliziert. Der Vorteil ist, wenn nur das Rechenwerk (ALU) dupliziert wird und die anderen Komponenten der CPU durch andere
Fehlerentdeckungsmechanismen abgesichert werden, benötigt die vorgestellte Schaltung zusätzlich weniger Chipfläche als eine vollständige Dual-Core-Architektur. Trotzdem kann aber mit dem erfindungsgemäßen Verfahren, also gleichermaßen für Doppel-CPU oder Doppel-ALU eine ausreichende Fehlerabdeckung im Sicherheitsmodus, und bei nicht sicherheitsrelevanten Berechnungen eine deutliche Leistungssteigerung im Leistungsmodus erzielt werden. Die Erfindung geht also von einem Verfahren und einer Vorrichtung zur Umschaltung zwischen wenigstens zwei Betriebsmodi einer Prozessoreinheit mit wenigstens zwei Ausführungseinheiten zur Abarbeitung von Programmen aus, wobei vorteilhafter Weise den Programmen wenigstens eine Kennung zugeordnet ist, welche eine Unterscheidung in die wenigstens zwei Betriebsmodi, also insbesondere Sicherheitsmodus und Leistungsmodus erlaubt und eine Umschaltung zwischen dem Betriebsmodi in Abhängigkeit von der Kennung erfolgt, so dass die Prozessoreinheit die Programme entsprechend des zugeordneten Betriebsmodus abarbeitet.
Dabei umfasst der Begriff Programme auch Programmteile, also Codeblöcke, die sich über mehrere Programme vollständig oder ansteilig erstrecken über Aufgabenprogramme, die in den einzelnen Programmen enthalten sind oder von den Programmen gebildet werden bis hin zu einzelnen Programmbefehlen, denen jeweils eine Kennung zugeordnet wird.
Dabei kann eine solche Kennungszuordnung zur Umschaltung zwischen den einzelnen Betriebsmodi auf Funktionsebene, also insbesondere zur Steuerung von Betriebsabläufen bei einem Fahrzeug, Einsatz finden. Andererseits können auch vorteilhafter Weise
Programme oder entsprechende Aufgabenprogramme, Programmteile oder Programmbefehle, die zu einem Betriebssystem der Prozessoreinheit gehören oder dieses Betriebssystem darstellen, durch solche Kennungen dem entsprechenden Betriebsmodus zugeordnet werden.
Zweckmäßiger Weise werden bei der Abarbeitung der Programme die dabei entstehenden Zustände oder Ergebnisse auf Übereinstimmung verglichen, wobei bei Abweichung auf Fehler erkannt wird.
Dabei ist es besonders zweckmäßig, dass die Programme synchron abgearbeitet werden.
Vorteilhafter Weise ist die Kennung als wenigstens ein Bit ausgebildet, wobei eine solche Kennung zweckmäßiger Weise durch einen Programmbefehl, insbesondere durch einen im Befehlssatz der Prozessoreinheit vorgesehenen Befehl, wie beispielsweise einem Schreibbefehl erzeugt wird.
Diese Kennung kann zum Einen dem entsprechenden Programm, Programmteil, Ausführungsprogramm oder Programmbefehl zugeordnet sein oder aber in einen speziellen, vorgesehenen Speicherbereich eingeschrieben sein oder werden.
Somit kann abhängig von der Kennung eine optimierte Umschaltung zwischen zwei Betriebsmodi, insbesondere dem Leistungsmodus und dem Sicherheits-Modus bei einer Dual-Core- Architektur oder eine Architektur mit lediglich dupliziertem Rechenwert, also einer Doppel-ALU erfolgen.
Weitere Vorteile und vorteilhafte Ausgestaltungen ergeben sich aus der Beschreibung sowie den Merkmalen der Ansprüche.
Zeichnung
Die Erfindung wird im weiteren anhand der in der Zeichnung dargestellten Figuren näher erläutert.
Dabei zeigt Figur 1 und Figur 2 jeweils eine Prozessoreinheit mit dupliziertem Rechenwert, bei welcher die erfindungsgemäße Umschaltung durchführbar ist.
Figur 3 zeigt die Umschaltung aus dem Sicherheitsmodus in den Leistungsmodus und Figur 4 zeigt die Umschaltung vom Leistungsmodus in den Sicherheitsmodus.
Figur 5 zeigt anhand einer Anzahl von Codezeilen 500 die Zuordnung der Kennzeichen zu den Programmen, Programmteilen, Aufgabenprogrammen oder Befehlen.
Beschreibung der Ausfuhrungsbeispiele
In den Figuren 1 und 2 der Zeichnung sind gleiche bzw. funktionsgleiche Elemente sofern nichts anderes angegeben ist - mit gleichen Bezugszeichen versehen worden. Die erfindungsgemäße programmgesteuerte Einheit sowie deren Komponenten wie Mikrocontrollerkern (CPU), Speichereinheiten, Peripherieeinheiten usw. sind der besseren Übersichtlichkeit halber in den Figuren 1 und 2 nicht direkt dargestellt worden. Allerdings können die beiden Rechenwerke ALU A und Alu B ebenso kompletten Cores, also CPUs im Rahmen der Erfindung entsprechen, so dass die Erfindung auch für komplette Dual-Core-Architekturen Einsatz finden kann. Bevorzugt ist allerdings, dass nur das Rechenwerk dupliziert wird und die anderen Komponenten der CPU durch andere Fehlerentdeckungsmechanismen abgesichert werden.
In den Figuren 1 und 2 sind mit den Bezugszeichen 1 und 2 jeweils arithmetisch logische Einheiten (ALU) als Ausführungseinheiten bezeichnet. Eine jeweilige ALU-Einheit 1, 2 weist zwei Eingänge und einen Ausgang auf. In einem Testbetrieb können die zur Ausführung vorgesehenen Operanden direkt vom Bus 3 in die Eingänge der ALU- Einheiten 1 , 2 eingekoppelt werden oder vorher in einem eigens dafür vorgesehenen Operandenregister 8, 9 abgelegt sein. Diese Operandenregistern 8, 9 sind direkt mit dem Datenbus 3 gekoppelt. Die beiden ALU-Einheiten 1, 2 werden also aus den gleichen
Operandenregistern 8, 9 versorgt. Zusätzlich kann vorgesehen sein, dass die jeweiligen Operanden über den Bus bereits mit einer ECC-Codierung versehen sind, welche in den Registerbereichen 8a, 9a abgelegt werden. D. h. an allen Stellen in den Figuren 1 und 2, in denen ECC angegeben ist, können die Daten durch Einsatz eines ECC-Codes (Error Correction Code) abgesichert sein. Solche Methoden zur Fehlererkennung sind vielfältig, wobei die Grundvoraussetzung die Absicherung mit einem Fehlererkennungs- bzw. Fehlerkorrekturcode, also einer Signatur darstellt. Im einfachsten Fall kann diese Signatur nur aus einem Signaturbit, beispielsweise einem Parity-Bit bestehen. Andererseits kann die Absicherung auch durch komplexere ED-Codes (Error Detection) wie einen Berger- Code oder einen Bose-Lin-Code usw. oder auch durch einen komplexeren ECC-Code wie beispielsweise einen Hamming-Code usw. realisiert werden, um durch entsprechende Bitzahl eine sichere Fehlererkennung zu ermöglichen. Es kann aber auch als Codegenerator, beispielsweise eine Generatortabelle (fest verdrahtet oder in Software) verwendet werden, um bestimmten Eingangsmustern der Bits im Rahmen der Adresse ein gewünschtes Codemuster beliebiger Länge zuzuordnen. Damit kann, insbesondere durch die Korrekturfunktion, die Datensicherheit gewährleistet werden. Dennoch erfolgt im sicherheitskritischen Modus, also im Sicherheitsmodus SM eine redundante Abarbeitung der sicherheitskritischen Programme in beiden Ausfuhrungseinheiten, also hier beiden ALUs 1 und 2, wodurch Fehler in diesen durch Vergleich auf Übereinstimmung erfindungsgemäß aufgedeckt werden.
Die nicht sicherheitsrelevanten bzw. nichtsicherheitskritischen Programme oder Tasks respektive Programmteile oder Codeblöcke oder Befehle können zur Leistungserhöhung auf beiden Ausführungseinheiten verteilt berechnet werden, wodurch sich der Durchsatz und damit die Leistung erhöht. Dies erfolgt im sogenannten Leistungsmodus oder Performancemode LM.
Bei Einkopplung der jeweiligen Operanden in die ALU-Einheiten 1, 2 muss besonderer
Wert auf die korrekte Dateneingabe gelegt werden. Werden z. B. die gleichen fehlerhaften Operanden in die beiden ALU-Einheiten 1, 2 eingekoppelt, ist ein Fehler am Ausgang der ALU-Einheiten 1, 2 nicht erkennbar. Es muss daher sichergestellt sein, dass zumindest eine der ALU-Einheiten 1 oder 2 einen korrekten Dateneingabewert erhält bzw. auch beide ALU-Einheiten 1, 2 unterschiedliche, jedoch falsche Dateneingabewerte erhalten. Dies wird dadurch sichergestellt, dass von zumindest einem Eingangswert einer ALU-Einheit 1, 2 eine Prüfsumme, also ein ECC-Code, wie oben erwähnt, gebildet wird. In einer eigens vorgesehenen Vergleichseinheit 5, 6 wird die ECC-Codierung 10a, 11a aus diesen zusätzlichen Datenregistern 10, 11 mit der ECC-Codierung 8a, 9a aus dem ursprünglichen Quellregister 8, 9 verglichen. Optional können auch die Eingangsdaten aus den Registern 10, 11 mit denen aus den Quellregistern 8, 9 verglichen werden. Ergibt sich ein Unterschied in der ECC-Codierung bzw. bei den Operanden, dann wird dies als Fehler interpretiert und es wird ein Fehlersignal ausgegeben, unter Umständen angezeigt und unter Umständen korrigiert. Dieser Vergleich erfolgt vorteilhafter Weise während der Bearbeitung der Operanden in den ALU-Einheiten 1, 2, so dass diese eingangsseitige
Fehlererkennung und Fehlerkorrektur nahezu ohne Leistungsverlust einhergeht. Erkennt eine der Vergleichseinheiten 5, 6 einen Fehler, so kann die Berechnung innerhalb des nächsten Zyklus wiederholt werden. Dabei kann ein Schattenregister Einsatz finden, um immer die Operanden der letzten Berechnung zu sichern, damit sie in einem Fehlerfall schnell wieder verfügbar sind. Auf die Bereitstellung eines solchen Schattenregisters kann allerdings verzichtet werden, wenn die jeweiligen Operandenregister 10, 11 erst wieder durch ein Freigabesignal aufgrund des NichtVorhandenseins eines Fehlers erneut beschrieben werden. Im Falle eines Fehlers liefern die Vergleichseinheiten 5, 6 ein Fehlersignal, wodurch die Operandenregister 10, 1 1 nicht erneut beschrieben werden. Die ALU-Einheiten 1, 2 erzeugen ausgangsseitig jeweils ein Ergebnis. Die von den ALU- Einheiten 1, 2 bereitgestellten Ergebnisdaten bzw. deren ECC-Codierung werden in den Ergebnisregistern 12, 13, 12a, 13a abgelegt. Diese Ergebnisdaten und/oder deren Codierung werden in der Vergleichseinheit 14 miteinander verglichen. Im Falle des NichtVorhandenseins eines Fehlers wird ein Freigabesignal 16 erzeugt. Dieses Freigabesignal 16 wird in die Freigabeeinrichtung 15 eingekoppelt, welche dazu veranlasst wird, die Ergebnisdaten auf einen Bus 4 zu schreiben. Über den Bus 4 können diese Ergebnisdaten dann wieder verarbeitet werden.
Das Freigabesignal 16 kann ferner dazu genutzt werden, die Register 8 bis 11 wieder freizuschalten, so dass die nächsten Operanden vom Bus 3 ausgelesen werden können und in den ALU-Einheiten 1 , 2 verarbeitet werden können.
Mit der Anordnung in Figur 1 wird das Ergebnis nicht überprüft. Hier werden lediglich die Ergebnisdaten in der Vergleichseinheit 14 miteinander verglichen. Eine Überprüfung der ECC-Codierung der Ergebnisdaten wird erst durch die Anordnung in Figur 2 möglich, bei der sowohl die Ergebnisdaten als auch deren ECC-Codierung miteinander in der Vergleichseinheit 14 verglichen werden.
Mit den in den Figuren 1 und 2 angegebenen Fehlererkennungsanordnungen werden alle transienten Fehler, permanenten Fehler und auch Laufzeitfehler erkannt. Laufzeitfehler innerhalb einer ALU-Einheit 1 , 2 werden erkannt, wenn das Ergebnis nicht oder zu spät zu der Vergleichseinheit 12 gelangt und somit ein Vergleich mit einem Teilergebnis erfolgt. Durch die Absicherung der Operandenregister 8, 9, 10, 11 mit Fehlererkennungsund Fehlerkorrekturcode und dem Vergleich der Endergebnisse ist der jeweilige Fehlerort und Fehlerzeitpunkt genau zu lokalisieren. Somit kann auf eine transiente Störung sehr schnell reagiert werden.
Es ergeben sich somit die folgenden Möglichkeiten zur Fehlerlokalisierung:
Ergibt ein Vergleich der Ergebnisdaten in der Vergleichseinheit 14 einen Unterschied, dann kann auf einen Fehler innerhalb der ALU-Einheiten 1 , 2 geschlossen werden. Ergibt ein Vergleich der ECC-Codierung in einer der Vergleichseinheiten 5, 6 einen Unterschied, dann kann auf ein fehlerhaftes Signal von dem Bus 3 bzw. vorgeschalteten Komponenten geschlossen werden.
Ergibt ein Vergleich der ECC-Codierung in der Vergleichseinheit 14 einen Unterschied, dann kann auf eine fehlerhafte Codierung des Ergebnisses geschlossen werden.
Zur Umschaltung zwischen dem genannten Sicherheitsmodus, in dem eine redundante Abarbeitung und Prüfung erfolgt und dem Leistungsmodus, bei dem eine Leistungssteigerung durch separate Programmabarbeitung erreicht wird, dient eine
Umschalteinrichtung UE 17. Durch diese Umschalteinrichtung 17 werden die Elemente 8, 9 und 1, 2 so geschaltet, dass im einen Fall, also im Sicherheitsmodus SM eine redundante Programmabarbeitung, insbesondere eine synchrone Programmabarbeitung erfolgt und im zweiten Betriebsmodus, dem Leistungsmodus LM eine parallele Abarbeitung unterschiedlicher Programme vollzogen werden kann. Dazu können Schalter oder Schaltmittel vorgesehen sein, die zum Einen in den Elementen 8, 9 respektive 1, 2 oder auch in der Umschalteinrichtung 17 lokalisiert sein können oder zusätzlich separat von den Elementen 8, 9, 1, 2 bzw. 17 in der Schaltung enthalten sind.
Zur Umschaltung erfolgt eine Kennzeichnung der Programme oder Aufgabenprogramme oder Programmteile, also Codeblöcke oder auch der Befehle durch eine Kennung, durch welche erkennbar ist, ob diese sicherheitsrelevant sind, also im Sicherheitsmodus SM abgearbeitet werden müssen oder dem Leistungsmodus LM zugänglich gemacht werden können. Dies kann durch ein Bit im Befehl erfolgen, oder es kann durch einen speziellen Befehl die darauffolgende Sequenz gekennzeichnet werden. Dies wird näher anhand der unterschiedlichen Kennzeichnungsmöglichkeiten bei Figur 5 noch einmal beschrieben.
Dabei können die Programme zum Einen Anwendungsfunktionen umfassen, also insbesondere z. B. zur Steuerung von Betriebsabläufen bei einem Fahrzeug vorhanden sein, oder aber die Umschaltung erfolgt bezüglich Programmen, bei denen die
Kennzeichnung auf Betriebssystemebene erfolgt, also z. B. eine Zuordnung ganzer Betriebssystemtasks. Bei einer Decodierung kann nun die Umschalteinrichtung 17 erkennen, ob die nun folgende Berechnung sicherheitsrelevant ist, also im Sicherheitsmodus ausgeführt werden soll oder nicht. Ist dies der Fall, so werden die Daten an beide Ausführungseinheiten 1 und 2 übergeben. Ist dies nicht der Fall, wird also im Leistungsmodus weitergearbeitet, so bekommt eine Ausführungseinheit die Daten bereitgestellt und gleichzeitig kann die nächste Anweisung, wenn diese ebenfalls nicht sicherheitsrelevant ist, an die zweite Ausfuhrungseinheit gegeben werden, so dass die Programme parallel mit höherem Durchsatz abgearbeitet werden.
Im ersten Fall beispielsweise dauert die Berechnung des Ergebnisses bei synchroner
Abarbeitung auf beiden Einheiten gleich lang. Die Ergebnisse stehen also im Sicherheitsmodus bei synchroner Abarbeitung gleichzeitig bereit. Diese Daten werden nun am Ausgang entsprechend 12 und 13 wieder mit einer Codierung versehen, und es werden die Daten und/oder die Codierung dieser Daten, wie in den Figuren 1 und 2 beschrieben, bei Result a und Result b verglichen. Stimmen sie überein, so werden die
Daten freigegeben; ansonsten erfolgt eine der angesprochenen Fehlerreaktionen. Im zweiten Fall, also im Leistungsmodus LM, wenn die Daten parallel abgearbeitet werden, wird der Komparator oder Vergleicher 14 am Ausgang der beiden Rechenwerke nicht angesteuert und die Ergebnisse Result a und Result b werden nacheinander wieder in die Registerbank zurückgeschrieben und können auch nacheinander ausgegeben werden, wie es auch in einem superskalaren Prozessor der Fall ist.
Dieser erfindungsgemäße Umschaltvorgang wird noch einmal in den Figuren 3 und 4 erläutert. Dabei zeigt Figur 3 die Umschaltung aus dem Sicherheitsmodus in den Leistungsmodus und Figur 4 die Umschaltung vom Leistungsmodus in den
Sicherheitsmodus.
Um von dem ersten Betriebsmodus, also hier dem Sicherheitsmodus oder Safetymode SM in den zweiten Betriebsmodus, also hier den Leistungsmodus oder Performancemode LM zu gelangen, ist eine Kennung und eine entsprechende Umschaltung erforderlich. In
Figur 3 ist dies noch einmal verdeutlicht. In Block 300 ist die Ausführungseinheit 1 im zweiten Betriebsmodus, dem Leistungsmodus. Ebenso ist im Block 310 die zweite Ausführungseinheit 2 auch im Leistungsmodus. Gleichermaßen werden durch die Umschalteinrichtung 17, die beispielsweise als Decoderbaustein ausgebildet ist, respektive einen solchen enthält, die Elemente 8 und 9 gesteuert bzw. geschaltet. Im Block 320 bzw. Block 321 wird nun entsprechend des Programmablaufs der jeweiligen Ausführungseinheit 1 oder 2 wenigstens eine Kennung festgestellt, durch welche eine Umschaltung in Block 330 von beiden Ausführungseinheiten in den ersten Betriebsmodus, den Sicherheitsmodus SM, erfolgt. Dadurch laufen beide Zweige über die
Blöcke 8 und 9 und die Ausführungseinheiten 1 und 2 wieder redundant und insbesondere synchron bezüglich der durch die Kennung gekennzeichneten sicherheitsrelevanten Programme, so dass wieder der Sicherheitsmodus SM vorliegt. Dabei genügt es, dass in einem Programmlauf im Leistungsmodus, also in einem Zweig eine solche Kennung zur Umschaltung vorhanden ist, um beide Ausführungseinheiten in den Sicherheitsmodus zu führen. Dabei muss unter Umständen noch die Abarbeitung des bereits angefangenen Programmcodes der anderen Ausführungseinheit abgearbeitet werden, um beide dann im Sicherheitsmodus weiterarbeiten zu lassen. Andererseits kann es auch vorgesehen sein, sofort in den Sicherheitsmodus zu wechseln und bei einem nachfolgenden Leistungsmodus das angefangene Programm beginnend von der
Unterbrechungsstelle weiter abzuarbeiten.
Um von dem ersten Betriebsmodus, also hier dem Sicherheitsmodus in den zweiten Betriebsmodus, den Leistungsmodus zu gelangen, wird nun entsprechend Figur 4 ebenfalls eine Kennung verwandt. Im Block 200 sind beide Ausfuhrungseinheiten 1 und
2 und entsprechend die Zweige mit den Blöcken 8 und 9, also der Operandenzuschaltung im Sicherheitsmodus, dem ersten Betriebsmodus. In Abfrageblock 210 wird nun geprüft, ob eine Umschaltkennung vorliegt, respektive ob eine vorliegende Kennung die Umschaltung in den Leistungsmodus möglich macht. Ist dies nicht der Fall, liegt also keine Kennung vor oder zeigt die Kennung weiterhin den Sicherheitsmodus an, gelangt man wieder zu Block 200 und die Programme werden weiter im Sicherheitmodus abgearbeitet. Ist eine Kennung vorhanden respektive zeigt diese die Umschaltung an, erfolgt im Block 220 die Umschaltung bzw. der Wechsel in den zweiten Betriebsmodus, den Leistungs- oder Performancemode LM. Da im Sicherheitsmodus parallel, also redundant, die gleichen Programme abgearbeitet werden, erfolgt hier eine Umschaltung nur, wenn für beide Zweige im Leistungsmodus, also Block 8 und ALU 1 sowie Block 9 und ALU 2 eine Umschaltung aufgrund der Kennung vorgesehen ist. Erfolgt eine vollsynchrone Abarbeitung, also eine zeitgleiche Abarbeitung des Programms, ist dies ohnehin gegeben, erfolgt eine nichtsynchrone Abarbeitung des Programms, muss von der schnelleren Ausführungseinheit auf die zurückliegende gewartet werden, so dass die Umschalteinrichtung 17 erst dann umschaltet, wenn beide Kennungen vorliegen bzw. ausgewertet sind. Eine solche Synchronität muss auch zum Ergebnisvergleich bzw. ECC- und Ergebnisvergleich gemäß der Blöcke 12, 13 und 14 sowie 12a und 13a entweder durch Zeitgleichheit erzwungen oder durch Warten erzeugt werden.
In Block 230 ist somit dann der erste Zweig, also Block 8 und Ausführungseinheit 1 wieder im Leistungsmodus und im Block 231 der zweite Zweig mit Block 9 und Ausführungseinheit 2, wodurch dann die erfindungsgemäße Umschaltung vollzogen ist.
Damit ist entsprechend der Aufgabe eine optimierte Umschaltung zwischen zwei Betriebsmodi einer Prozessoreinheit mit zwei integrierten Ausführungseinheiten erfindungsgemäß dargestellt, wobei die Kennung auf verschiedenste Art und Weise entsprechend Figur 5 in einem Programm- oder Datenzeilenabschnitt 500 eingebracht oder lokalisiert sein kann. Im Weiteren sprechen wir bei den Zeilen in Figur 5 von
Programmzeilen, wobei auch hier Programm- und Datenzeilen in beliebiger Kombination möglich sind.
So sind in Figur 5 beispielhaft die Programme Pl von Zeile ZI bis Zeile Z6, P2 von Zeile Z7 bis Zeile Z15 und P3 von Zeile Z16 bis Zeile Z19 dargestellt. Mit AP ist ein
Aufgabenprogramm beispielsweise als Teil eines Programmes Pl dargestellt, wobei auch mehrere Programme, z. B. Pl und P2, zusammen ein Aufgabenprogramm bilden können. Mit CB ist ein Codeblock dargestellt, also ein Programmteil, der beispielsweise Zeilen zweier Programme, hier Z14 bis ZI 8 der Programme P2 und P3 umfasst. Ebenso kann ein solcher Codeblock, also ein Programmteil nur Teil eines Programmes sein. Weiterhin ist mit PB3 entsprechend Zeile ZI 9 ein Programmbefehl dargestellt. Mit Zeilen ZS1 und ZS2 ist ein spezieller Speicherbereich SSB dargestellt, der als vorgegebener Speicherbereich eine solche Kennung, hier KB enthalten kann. Daneben sind mit Kl, K2, K3 und K4 sowie KB verschiedene Kennungen dargestellt, die den unterschiedlichen Möglichkeiten des erfindungsgemäßen Verfahrens Rechnung tragen. Bezüglich des
Einsatzes der Kennung gibt es nun verschiedene Möglichkeiten: Zum Einen kann als Grundverarbeitungsmodus, also als Default-Modus der Sicherheitsmodus SM vorgesehen sein (ebenso natürlich der Leistungsmodus). Bei Vorhandensein einer Kennung wird dann entsprechend in den Leistungsmodus umgeschaltet (oder umgekehrt in den Sicherheitsmodus). Andererseits kann es erfindungsgemäß auch vorgesehen sein, dass grundsätzlich eine Kennung vorhanden sein muss und aus dem Inhalt der Kennung, also insbesondere deren Bitwertes auf den entsprechenden Modus geschlossen wird. Dabei ist dann beispielsweise ein Binärwert 1 (oder auch ein anderer Wert, insbesondere der dominante Wert) dem Sicherheitsmodus SM zugeordnet und der Binärwert 0 (oder auch ein anderer Wert insbesondere der rezessive Wert) dem Leistungsmodus LM. Bezüglich der Überlegung von dominant und rezessiv hat dies zur Folge, dass bei einem Fehler oder einem Ausfall in der Regel der dominante Wert und somit der Sicherheitsmodus eingestellt ist. Entsprechend Zeile Z4 ist nun mit Kennung Kl ein Binärwert Bl, also Kl/Bl vorhanden, welcher beispielsweise anzeigt, dass das Aufgabenprogramm der Zeilen Z4 bis Z6 im Programm Pl im Leistungsmodus abgearbeitet werden kann, obwohl beispielsweise Programm Pl im Sicherheitsmodus abgearbeitet werden muss. Wie den Kennungen Kl, K2 und K3 anzusehen, können diese unterschiedlich lang sein, so dass beispielsweise bei Kennung K2 gemäß Zeile Z7 3 Bit, Bl bis B3, die Kennung ausmachen, so dass zum Einen mit Bit B 1 bei K2 Sicherheitsmodus SM oder Leistungsmodus LM entschieden wird und beispielsweise die Bits B2 und B3 die Zeilenzahl angeben, für welche dieser Modus, beispielsweise der Sicherheitsmodus, gilt, so dass das gesamte Programm P2 oder auch nur ein Teil davon im Sicherheitsmodus abgearbeitet wird. Ebenso können Codeblöcke, also Programmteile, die beispielsweise keine Gesamtaufgabe umfassen, also kein Aufgabenprogramm darstellen, hier mit CB dargestellt, durch eine Kennung, wie hier K3 einem Modus zugeordnet werden. Hier kann dann neben der Betriebsmodizuordnung mit Bit Bl bei K3 beispielsweise auch eine Anfangszeile oder Adresse mit Bits B2 und B3 bei K3 und eine Endzeile oder Endadresse mit Bits B4 und B5 bei K3 angegeben sein, so dass ein spezieller Bereich in einem entsprechend zugeordneten Betriebsmodus abgearbeitet wird. Eine solche Kennungszuordnung kann gemäß K4 aber auch bei einzelnen Befehl PB3 in ZI 9 oder • auch bei jedem Befehl erfolgen. Wie dargestellt, können also diese Kennungen vollständigen Programmen oder Aufgabenprogrammen AP oder Programmteilen CB, oder auch einzelnen Programmbefehlen PB, hier PB3, zugeordnet sein, was dann eine entsprechende Umschaltung durch die Umschalteinrichtung 17 auslöst. Durch die Abfrage in Block 210 oder auch in den Blöcken 320 und 321 wird dann das Vorhandensein einer solchen Kennung Kl bis K4 oder KB überprüft respektive deren Inhalt umgeschaltet. Dabei kann die Kennung, wie hier dargestellt, als wenigstens ein Bit ausgebildet sein, aber auch mehrere Bits umfassen, zum Einen abhängig von der unterschiedlichen Anzahl der Betriebsmodi, zum Anderen bedingt durch Zusatzinformationen wie die Anzahl der Zeilen oder eine Anfangs- oder Endadresse.
In einer speziellen Ausführungsform kann wenigstens ein Programmbefehl vorgesehen sein, hier PB1, PB2 oder auch PB3, der eine Kennung erst erzeugt, die anzeigt, ob im ersten oder zweiten Betriebsmodus abzuarbeiten ist. Dabei kann die Kennung in einem bestimmten Speicherbereich SSB eingeschrieben werden, wie hier mit KB in ZS2 dargestellt. Dieser Bereich SSB kann sich in einem Register, in einem in der CPU integrierten Speicher, aber auch in einem dazu externen Speicher befinden. Dabei kann als diese Kennung KB erzeugender Befehl ein Spezialbefehl, z. B. PB3 vorgesehen sein oder aber ein Befehl, der bereits im Befehlssatz der Prozessoreinheit vorhanden ist. Als Spezialbefehl kann somit beispielsweise eben ein Befehl "erzeuge Kennung" implementiert werden, oder es kann auf einen im Prozessorbefehlssatz bereits vorhandenen Befehl, insbesondere einen Schreibbefehl zurückgegriffen werden, wie hier durch PB 1 und PB2 dargestellt, so dass in Z9 der Schreibbefehl WR in den
Speicherbereich KB den Binärwert 0 einschreibt, dargestellt durch WR (KB: 0) und damit alle nachfolgenden Zeilen, solange die Kennung KBO ist, z. B. im Sicherheitsmodus abgearbeitet werden. Mit dem selben Befehl kann dann in Z12 bei PB2 durch WR (KB: 1) in den Speicherbereich für die Kennung KB der Wert 1 eingegeben werden, so dass ab diesem Zeitpunkt die nachfolgenden Zeilen, z. B. im Leistungsmodus, abarbeitbar sind. D. h. durch einfache kennungserzeugende Befehle insbesondere ein simpler Schreibbefehl WR kann dann beispielsweise in einem speziellen Speicherbereich, der regelmäßig abgefragt wird, eine entsprechende Umschaltkennung KB erzeugt werden.
Damit sind eine Vielzahl erfindungsgemäßer Möglichkeiten dargestellt, eine Betriebsmodiumschaltung bei einer Prozessoreinheit mit zwei Ausführungseinheiten aufgrund einer Kennung durchzuführen. Damit sind die genannten Vorteile der Erfindung erzielbar.

Claims

Ansprüche
1. Verfahren zur Umschaltung zwischen wenigstens zwei Betriebsmodi (SM, LM) einer Prozessoreinheit (100, 101) mit wenigstens zwei Ausfϋhrungseinheiten (ALUA, ALUB) zur Abarbeitung von Programmen (Pl, P2, P3), dadurch gekennzeichnet, dass wenigstens den Programmen (Pl, P2, P3) wenigstens eine Kennung (K2) zugeordnet ist, welche eine
Unterscheidung in die wenigstens zwei Betriebsmodi (SM, LM) erlaubt und eine Umschaltung zwischen den Betriebsmodi in Abhängigkeit von der Kennung (K1-K4, KB) erfolgt, so dass die Prozessoreinheit (100, 101) die Programme (Pl, P2, P3) entsprechend des zugeordneten Betriebsmodus abarbeitet.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Programme (Pl, P2, P3) Aufgabenprogramme (AP) enthalten oder diese bilden und den einzelnen Aufgabenprogrammen (AP) jeweils die Kennung (Kl) zugeordnet ist.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Programme (Pl, P2,
P3) aus einzelnen Programmteilen (CB) bestehen oder diese enthalten und den einzelnen Programmteilen (CB) jeweils die Kennung (K3) zugeordnet ist.
4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Programme (Pl, P2, P3) aus einzelnen Programmbefehlen (PB) bestehen und den einzelnen Programmbefehlen
(PB) jeweils die Kennung (K4) zugeordnet ist.
5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Programme (Pl, P2, P3) zu einem Betriebssystem der Prozessoreinheit (100, 101) gehören oder das Betriebssystem darstellen.
6. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Programme (Pl, P2, P3) zur Steuerung von Betriebsabläufen eines Fahrzeugs eingesetzt werden.
7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein erster Betriebsmodus vorgesehen ist, der einem Sicherheitsmodus (SM) entspricht, bei dem die zwei Ausführungseinheiten (ALUA, ALUB) gleiche Programme (AP, P2) redundant abarbeiten.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass bei der Abarbeitung der
Programme (AP, P2) entstehende Zustände oder Ergebnisse (ResultA, ResultB) auf Übereinstimmung verglichen (14) werden und bei Abweichung auf Fehler erkannt wird.
9. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass die Programme (AP, P2) synchron abgearbeitet werden.
10. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass im zweiten Betriebsmodus, der einem Leistungsmodus (LM) entspricht, jede Ausführungseinheit (ALUA, ALUB) unterschiedliche Programme (Pl, P2, P3) abarbeitet.
11. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Kennung (Kl, KB) als wenigstens ein Bit (Kl/Bl) ausgebildet ist.
12. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein Programmbefehl (PBl, PB2, PB3) vorgesehen ist der eine Kennung (KB) erzeugt, die anzeigt, ob im ersten oder zweiten Betriebsmodus abzuarbeiten ist.
13. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Kennung (KB) in einem bestimmten Speicherbereich (SSB) eingeschrieben ist.
14. Verfahren nach Anspruch 12 oder 13, dadurch gekennzeichnet, dass die Kennung
(KB) durch einen in einem Befehlssatz der Prozessoreinheit vorgesehenen Befehl (PBl , PB2) erzeugt wird.
15. Verfahren nach einem der Ansprüche 12-14, dadurch gekennzeichnet, dass die Kennung (KB) durch einen Schreibbefehl (WR) erzeugt wird.
16. Vorrichtung zur Umschaltung zwischen wenigstens zwei Betriebsmodi (LM, SM) einer Prozessoreinheit (100, 101) zur Abarbeitung von Programmen (Pl, P2, P3) mit wenigstens zwei Ausführungseinheiten (ALUA, ALUB), wobei Umschaltmittel (8, 9) enthalten sind, durch welche umgeschalten werden kann, dadurch gekennzeichnet, dass diese Umschaltmittel (8, 9) wenigstens den Programmen (Pl, P2, P3) wenigstens eine Kennung (K1-K4, KB) zuordnen, welche eine Unterscheidung in die zwei Betriebsmodi (LM, SM) erlaubt und die Umschaltmittel (8, 9) derart ausgestaltet sind, dass diese in Abhängigkeit von der Kennung zwischen den Betriebsmodi umschalten und die Prozessoreinheit die Programme entsprechend des zugeordneten Betriebsmodus abarbeitet.
17. Vorrichtung nach Anspruch 16, dadurch gekennzeichnet, dass als wenigstens zwei Ausführungseinheiten entsprechend wenigstens duplizierte Rechenwerke (ALUA, ALUB) vorgesehen sind.
18. Prozessoreinheit (100, 101) zur Abarbeitung von Programmen (Pl, P2, P3) mit wenigstens zwei Ausführungseinheiten (ALUA, ALUB), wobei Umschaltmittel (8, 9) enthalten sind, durch welche zwischen wenigstens zwei Betriebsmodi (LM, SM) der
Prozessoreinheit umgeschalten werden kann, dadurch gekennzeichnet, dass diese Umschaltmittel (8, 9) wenigstens den Programmen (Pl, P2, P3) wenigstens eine Kennung (K1-K4, KB) zuordnen, welche eine Unterscheidung in die zwei Betriebsmodi (LM, SM) erlaubt und die Umschaltmittel (8, 9) derart ausgestaltet sind, dass diese in Abhängigkeit von der Kennung zwischen den Betriebsmodi umschalten und die Prozessoreinheit die
Programme entsprechend des zugeordneten Betriebsmodus abarbeitet.
PCT/DE2004/001859 2003-10-24 2004-08-20 Verfahren und vorrichtung zur umschaltung zwischen wenigstens zwei betriebsmodi einer prozessoreinheit WO2005045664A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP04762699A EP1680736A2 (de) 2003-10-24 2004-08-20 Verfahren und vorrichtung zur umschaltung zwischen wenigstens zwei betriebsmodi einer prozessoreinheit
US10/577,009 US20070245133A1 (en) 2003-10-24 2004-08-20 Method and Device for Switching Between at Least Two Operating Modes of a Processor Unit
JP2006534568A JP2007508626A (ja) 2003-10-24 2004-08-20 プロセッサユニットの少なくとも２つの駆動モード間での切替方法および装置

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10349581.9 2003-10-24
DE10349581A DE10349581A1 (de) 2003-10-24 2003-10-24 Verfahren und Vorrichtung zur Umschaltung zwischen wenigstens zwei Betriebsmodi einer Prozessoreinheit

Publications (2)

Publication Number Publication Date
WO2005045664A2 true WO2005045664A2 (de) 2005-05-19
WO2005045664A3 WO2005045664A3 (de) 2006-02-23

Family

ID=34484989

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2004/001859 WO2005045664A2 (de) 2003-10-24 2004-08-20 Verfahren und vorrichtung zur umschaltung zwischen wenigstens zwei betriebsmodi einer prozessoreinheit

Country Status (7)

Country Link
US (1) US20070245133A1 (de)
EP (1) EP1680736A2 (de)
JP (1) JP2007508626A (de)
KR (1) KR20060103317A (de)
CN (1) CN1871581A (de)
DE (1) DE10349581A1 (de)
WO (1) WO2005045664A2 (de)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006045780A1 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Verfahren und vorrichtung zur trennung der abarbeitung von programmcode bei einem rechnersystem mit wenigstens zwei ausführungseinheiten
WO2006045798A1 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Verfahren und vorrichtung zur datenverteilung aus wenigstens einer datenquelle in einem mehrprozessorsystem
WO2006045779A1 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Verfahren und vorrichtung zur umschaltung bei einem rechnersystem mit wenigstens zwei ausführungseinheiten
WO2006045774A1 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Vorrichtung und verfahren zur modusumschaltung bei einem rechnersystem mit wenigstens zwei ausführungseinheiten
GB2431258A (en) * 2005-10-14 2007-04-18 Hewlett Packard Development Co Microprocessor operable in a fault-tolerant mode and a performance mode
JP2008262557A (ja) * 2008-03-31 2008-10-30 Hitachi Ltd 制御装置のタスク管理装置、及び、制御装置のタスク管理方法
JP2009505186A (ja) * 2005-08-08 2009-02-05 ローベルト ボツシユ ゲゼルシヤフト ミツト ベシユレンクテル ハフツング コンピュータシステムの機能監視方法および機能監視装置
JP2009506407A (ja) * 2005-08-08 2009-02-12 ローベルト ボツシユ ゲゼルシヤフト ミツト ベシユレンクテル ハフツング コンピュータシステムの制御方法および制御装置
US8161362B2 (en) 2005-06-10 2012-04-17 Hitachi, Ltd. Task management control apparatus and method, having redundant processing comparison
RU2453903C2 (ru) * 2006-10-10 2012-06-20 Роберт Бош Гмбх Способ и устройство для контроля работоспособности блока управления двигателем внутреннего сгорания
US8373435B2 (en) 2008-09-30 2013-02-12 Freescale Semiconductor, Inc. Method and apparatus for handling an output mismatch
US8527681B2 (en) 2007-05-25 2013-09-03 Freescale Semiconductor, Inc. Data processing system, data processing method, and apparatus
US8650440B2 (en) 2008-01-16 2014-02-11 Freescale Semiconductor, Inc. Processor based system having ECC based check and access validation information means

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7437641B1 (en) 2004-04-01 2008-10-14 Pmc-Sierra, Inc. Systems and methods for signature circuits
US20080313384A1 (en) * 2004-10-25 2008-12-18 Ralf Angerbauer Method and Device for Separating the Processing of Program Code in a Computer System Having at Least Two Execution Units
DE102005037244A1 (de) * 2005-08-08 2007-02-15 Robert Bosch Gmbh Verfahren und Vorrichtung zur Steuerung eines Rechnersystems mit wenigstens zwei Ausführungseinheiten und mit wenigstens zwei Gruppen von internen Zuständen
DE102005037260A1 (de) * 2005-08-08 2007-02-15 Robert Bosch Gmbh Verfahren und Vorrichtung zur Umschaltung bei einem Rechnersystem mit wenigstens zwei Ausführungseinheiten mittels Bitinformationen in einem Register
DE102005053681A1 (de) * 2005-11-10 2007-05-16 Bosch Gmbh Robert Verfahren zur Nutzung eines Speichers
DE102005060898A1 (de) * 2005-12-20 2007-06-28 Robert Bosch Gmbh Datenverarbeitungssystem mit mehreren Ausführungseinheiten
JP2008282178A (ja) * 2007-05-09 2008-11-20 Toshiba Corp 産業用コントローラ
US7865770B2 (en) 2008-01-10 2011-01-04 Advanced Micro Devices, Inc. Processor including efficient signature generation for logic error protection
US20090183035A1 (en) * 2008-01-10 2009-07-16 Butler Michael G Processor including hybrid redundancy for logic error protection
JP2010198131A (ja) * 2009-02-23 2010-09-09 Renesas Electronics Corp プロセッサシステム、及びプロセッサシステムの動作モード切り替え方法
US8640108B2 (en) * 2009-12-31 2014-01-28 International Business Machines Corporation Method for managing hardware resources within a simultaneous multi-threaded processing system
CN102968354A (zh) * 2012-11-13 2013-03-13 浪潮电子信息产业股份有限公司 一种基于Intel Brickland-EX平台的同频锁步模式的自动切换方法
GB2567190B (en) * 2017-10-05 2020-02-26 Advanced Risc Mach Ltd Error recovery for intra-core lockstep mode

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020073357A1 (en) * 2000-12-11 2002-06-13 International Business Machines Corporation Multiprocessor with pair-wise high reliability mode, and method therefore
WO2003010638A1 (de) * 2001-07-26 2003-02-06 Infineon Technologies Ag Prozessor mit mehreren rechenwerken
US6615366B1 (en) * 1999-12-21 2003-09-02 Intel Corporation Microprocessor with dual execution core operable in high reliability mode

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6947047B1 (en) * 2001-09-20 2005-09-20 Nvidia Corporation Method and system for programmable pipelined graphics processing with branching instructions
DE10317650A1 (de) * 2003-04-17 2004-11-04 Robert Bosch Gmbh Programmgesteuerte Einheit und Verfahren
KR20060026884A (ko) * 2003-06-24 2006-03-24 로베르트 보쉬 게엠베하 프로세서 유닛의 적어도 2개의 작동 모드 사이의 전환 방법및 상응하는 프로세서 유닛

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6615366B1 (en) * 1999-12-21 2003-09-02 Intel Corporation Microprocessor with dual execution core operable in high reliability mode
US20020073357A1 (en) * 2000-12-11 2002-06-13 International Business Machines Corporation Multiprocessor with pair-wise high reliability mode, and method therefore
WO2003010638A1 (de) * 2001-07-26 2003-02-06 Infineon Technologies Ag Prozessor mit mehreren rechenwerken

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006045798A1 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Verfahren und vorrichtung zur datenverteilung aus wenigstens einer datenquelle in einem mehrprozessorsystem
WO2006045779A1 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Verfahren und vorrichtung zur umschaltung bei einem rechnersystem mit wenigstens zwei ausführungseinheiten
WO2006045774A1 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Vorrichtung und verfahren zur modusumschaltung bei einem rechnersystem mit wenigstens zwei ausführungseinheiten
WO2006045780A1 (de) * 2004-10-25 2006-05-04 Robert Bosch Gmbh Verfahren und vorrichtung zur trennung der abarbeitung von programmcode bei einem rechnersystem mit wenigstens zwei ausführungseinheiten
US8161362B2 (en) 2005-06-10 2012-04-17 Hitachi, Ltd. Task management control apparatus and method, having redundant processing comparison
US8219796B2 (en) 2005-08-08 2012-07-10 Robert Bosch Gmbh Method and device for controlling a computer system
JP2009505186A (ja) * 2005-08-08 2009-02-05 ローベルト ボツシユ ゲゼルシヤフト ミツト ベシユレンクテル ハフツング コンピュータシステムの機能監視方法および機能監視装置
JP2009506407A (ja) * 2005-08-08 2009-02-12 ローベルト ボツシユ ゲゼルシヤフト ミツト ベシユレンクテル ハフツング コンピュータシステムの制御方法および制御装置
KR101031181B1 (ko) 2005-08-08 2011-04-26 로베르트 보쉬 게엠베하 컴퓨터 시스템의 기능을 모니터링하기 위한 방법 및 장치
KR101067264B1 (ko) 2005-08-08 2011-09-23 로베르트 보쉬 게엠베하 컴퓨터 시스템의 제어 방법 및 장치
US8108716B2 (en) 2005-08-08 2012-01-31 Robert Bosch Gmbh Method and device for monitoring functions of a computer system
GB2431258A (en) * 2005-10-14 2007-04-18 Hewlett Packard Development Co Microprocessor operable in a fault-tolerant mode and a performance mode
RU2453903C2 (ru) * 2006-10-10 2012-06-20 Роберт Бош Гмбх Способ и устройство для контроля работоспособности блока управления двигателем внутреннего сгорания
US8527681B2 (en) 2007-05-25 2013-09-03 Freescale Semiconductor, Inc. Data processing system, data processing method, and apparatus
US8650440B2 (en) 2008-01-16 2014-02-11 Freescale Semiconductor, Inc. Processor based system having ECC based check and access validation information means
JP2008262557A (ja) * 2008-03-31 2008-10-30 Hitachi Ltd 制御装置のタスク管理装置、及び、制御装置のタスク管理方法
US8373435B2 (en) 2008-09-30 2013-02-12 Freescale Semiconductor, Inc. Method and apparatus for handling an output mismatch

Also Published As

Publication number Publication date
KR20060103317A (ko) 2006-09-28
CN1871581A (zh) 2006-11-29
WO2005045664A3 (de) 2006-02-23
JP2007508626A (ja) 2007-04-05
US20070245133A1 (en) 2007-10-18
DE10349581A1 (de) 2005-05-25
EP1680736A2 (de) 2006-07-19

Similar Documents

Publication Publication Date Title
WO2005045664A2 (de) Verfahren und vorrichtung zur umschaltung zwischen wenigstens zwei betriebsmodi einer prozessoreinheit
WO2005003962A2 (de) Verfahren zur umschaltung zwischen wenigstens zwei betriebsmodi einer prozessoreinheit sowie entsprechende prozessoreinheit
WO2007057271A1 (de) Vorrichtung und verfahren zum beheben von fehlern bei einem wenigstens zwei ausführungseinheiten mit registern aufweisenden system
DE102005037246A1 (de) Verfahren und Vorrichtung zur Steuerung eines Rechnersystems mit wenigstens zwei Ausführungseinheiten und einer Vergleichseinheit
WO2006045800A1 (de) Verfahren und vorrichtung zur synchronisierung in einem mehrprozessorsystem
EP2447843B1 (de) Verfahren zur Verifizierung eines Anwendungsprogramms einer fehlersicheren Speicherprogrammierbaren Steuerung, und Speicherprogrammierbare Steuerung zur Ausführung des Verfahrens
EP1680737B1 (de) Verfahren und vorrichtung zur operandenverarbeitung in einer prozessoreinheit
DE10332700A1 (de) Verfahren zur Umschaltung zwischen wenigstens zwei Betriebsmodi einer Prozessoreinheit sowie entsprechende Prozessoreinheit
EP1043640A2 (de) Fehlersicheres Automatisierungssystem mit Standard-CPU und Verfahren für ein fehlersicheres Automatisierungssystem
EP1955164A1 (de) Programmgesteuerte einheit und verfahren zum betreiben derselbigen
DE102006012042A1 (de) Steuervorrichtung zur fehlersicheren Steuerung einer Maschine
EP1618476A2 (de) Programmgesteuerte einheit und verfahren
EP1776636A2 (de) Verfahren zum registrieren von fehlern und entsprechendes register
DE102013021231A1 (de) Verfahren zum Betrieb eines Assistenzsystems eines Fahrzeugs und Fahrzeugsteuergerät
DE102011007467A1 (de) Mehrkernige integrierte Mikroprozessorschaltung mit Prüfeinrichtung, Prüfverfahren und Verwendung
EP2228723A1 (de) Verfahren zur Fehlerbehandlung eines Rechnersystems
DE102004051991A1 (de) Verfahren, Betriebssystem und Rechengerät zum Abarbeiten eines Computerprogramms
DE102005037245A1 (de) Verfahren und Vorrichtung zur Steuerung eines Rechnersystems mit wenigstens zwei Ausführungseinheiten
EP3841439A1 (de) Automatisierungssystem zur überwachung eines sicherheitskritischen prozesses
EP1433061A2 (de) Verfahren zum überprüfen eines rechnerkerns eines mikroprozessors oder eines mikrocontrollers
EP2495625B1 (de) Verfahren und Programmiersystem für die Authentifizierung eines sicherheitsrelevanten Programms einer Automatisierungseinrichtung
WO2007017359A1 (de) Vorrichtung und verfahren zur steuerung eines rechnersystems
WO2009103372A1 (de) Anordnung zur überprüfung eines programmspeichers einer recheneinheit
DE10148157A1 (de) Programmgesteuerte Einheit
WO2016045953A1 (de) Verfahren zur parallelen verarbeitung von daten in einem rechnersystem mit mehreren rechnereinheiten und rechnersystem mit mehreren rechnereinheiten

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480031254.4

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004762699

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006534568

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020067007679

Country of ref document: KR

Ref document number: 1386/CHENP/2006

Country of ref document: IN

WWP Wipo information: published in national office

Ref document number: 2004762699

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1020067007679

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 10577009

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10577009

Country of ref document: US