EP1680736A2

EP1680736A2 - Method and device for switching between at least two operating modes of a processor unit

Info

Publication number: EP1680736A2
Application number: EP04762699A
Authority: EP
Inventors: Reinhard Weiberle; Thomas Kottke; Andreas Steininger
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2003-10-24
Filing date: 2004-08-20
Publication date: 2006-07-19
Also published as: KR20060103317A; CN1871581A; US20070245133A1; WO2005045664A3; DE10349581A1; JP2007508626A; WO2005045664A2

Abstract

The invention relates to a method and a device for switching between at least two operating modes (SM, LM) of a processor unit (100, 101) comprising at least two execution units (ALUA, ALUB) for running programs (P1, P2, P3). At least one characteristic (K2) associated with at least the programs (P1, P2, P3) differentiates between the at least two operating modes (SM, LM), and switching between the operating modes is carried out according to the characteristic (K1-K4, KB) such that the processor unit (100, 101) runs the programs (P1, P2, P3) according to the associated operating mode.

Description

Method and device for switching between at least two operating modes of a processor unit

State of the art

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. Such dual-core or multi-core architectures are proposed according to the current state of the art for two main reasons:

On the one hand, an increase in performance, that is to say an increase in performance, can be achieved by considering and treating the two execution units or gores as two computing units on a semiconductor module. In this configuration, 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.

In addition to the use as superscalar processors, 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.

In general, 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.

Advantages of the invention

For security reasons, a redundant execution of the programs or tasks, that is to say also of task programs, program parts, that is to say code blocks or individual commands, is desired, but on the other hand

For cost reasons, it is not desirable to have fully redundant hardware available when the non-safety-critical functions are performed. According to the invention, this conflict of objectives is resolved by an optimized switchover between at least two operating modes in a processor unit. The invention thus proceeds from a method and a device for switching between at least two

Operating modes of a processor unit with at least two execution units and a corresponding processor unit. The 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. The advantage is if only the arithmetic logic unit (ALU) is duplicated and the other components of the CPU by others

If error detection mechanisms are safeguarded, 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.

The term 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. On the other hand, 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.

It is particularly useful that the programs are processed synchronously.

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.

On the one hand, 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.

Depending on the identifier, 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.

Further advantages and advantageous configurations result from the description and the features of the claims.

drawing

The invention is explained in more detail below with reference to the figures shown in the drawing.

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.

Description of the exemplary embodiments

In 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. However, 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. However, it is preferred that only the arithmetic unit is duplicated and the other components of the CPU are secured by other error detection mechanisms.

In FIGS. 1 and 2, 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. In a test mode, 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. In addition, it can be provided that the respective operands are already provided with an ECC coding via the bus, which are stored in the register areas 8a, 9a. I.e. At all points in FIGS. 1 and 2, in which ECC is indicated, the data can be secured by using an 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. On the other hand, the protection can also be implemented by more complex ED codes (error detection) such as a Berger code or a Bose-Lin code etc. or by a more complex ECC code such as a Hamming code etc. Number of bits to enable reliable error detection. However, it can also be used as a code generator, for example a generator table (hard-wired or in software), in order to assign a desired code pattern of any length to specific input patterns of the bits in the context of the address. In this way, data security can be guaranteed, in particular through the correction function. Nevertheless, in 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.

If the respective operands are coupled into the ALU units 1, 2, special must

Value on correct data entry. Are z. B. the same faulty operands are coupled into the two ALU units 1, 2, an error at the output of the ALU units 1, 2 is not recognizable. It must therefore be ensured that at least one of the ALU units 1 or 2 receives a correct data input value and that both ALU units 1, 2 also receive different but incorrect data input values. This is ensured in that a checksum, ie an ECC code, as mentioned above, is formed from at least one input value of an ALU unit 1, 2. In a specially provided comparison unit 5, 6, the ECC coding 10a, 11a from these additional data registers 10, 11 is compared with the ECC coding 8a, 9a from the original source register 8, 9. Optionally, 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. In the event 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.

With the error detection arrangements indicated in FIGS. 1 and 2, all transient errors, permanent errors and also runtime errors are recognized. Runtime errors within an ALU unit 1, 2 are recognized if the result does not reach the comparison unit 12 or comes too late, and thus a comparison is made with a partial result. By protecting the operand registers 8, 9, 10, 11 with error detection and error correction code and comparing the final results, the respective error location and time of error can be localized precisely. This means that you can react very quickly to a transient disturbance.

This results in the following options for fault localization:

If a comparison of the result data in the comparison unit 14 results in a difference, then an error within the ALU units 1, 2 can be concluded. If a comparison of the ECC coding in one of the comparison units 5, 6 reveals a difference, then an incorrect signal from the bus 3 or upstream components can be concluded.

If a comparison of the ECC coding in the comparison unit 14 results in a difference, then an incorrect coding of the result can be concluded.

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. For this purpose, 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.

To switch over, 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. In the case of decoding, 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 ,

In the first case, for example, the calculation of the result takes place with synchronous

Processing on both units of the same length. The results are thus simultaneously available in safety mode with synchronous processing. These data are now provided with a coding at the output corresponding to 12 and 13, and the data and / or the coding of this data are compared, as described in FIGS. 1 and 2, for Result a and Result b. If they match, they will

Data released; otherwise one of the mentioned error reactions occurs. In the second case, i.e. in power mode LM, when the data are processed in parallel, the comparator or comparator 14 at the output of the two arithmetic units is not activated and the results Result a and Result b are written back to the register bank one after the other and can also be output one after the other as is the case in a superscalar processor.

This switching process according to the invention is explained again in FIGS. 3 and 4. 3 shows the switchover from the safety mode to the power mode and FIG. 4 shows the switchover from the power mode to the

Security mode.

In order to switch from the first operating mode, that is to say here the safety mode or safety mode SM to the second operating mode, that is to say here the power mode or performance mode LM, an identifier and a corresponding switchover are required. In

This is illustrated again in FIG. 3. In block 300, execution unit 1 is in the second operating mode, the performance mode. Likewise, in block 310, the second execution unit 2 is also in the performance mode. Likewise, the switching device 17, which is designed, for example, as a decoder module, or contains one, the elements 8 and 9 controlled or switched. In 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

Work on the point of interruption further.

In order to switch from the first operating mode, ie here the safety mode to the second operating mode, the power mode, an identifier is now also used in accordance with FIG. 4. In block 200, both execution units 1 and

2 and correspondingly the branches with the blocks 8 and 9, ie the operand connection in the safety mode, the first operating mode. In 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. Since the same programs are processed in parallel in the security mode, that is to say redundantly, a switchover takes place here only if a switchover is provided for both branches in the power mode, that is to say blocks 8 and ALU 1 and blocks 9 and ALU 2, on the basis of the identifier. If the program is fully synchronized, i.e. if the program is processed at the same time, if this is done anyway, the program must be executed non-synchronously faster execution unit are waited for the previous one, so that the switching device 17 only switches when both identifiers are present or have been evaluated. Such a synchronicity must also be enforced for the result comparison or ECC and result comparison according to the blocks 12, 13 and 14 as well as 12a and 13a either by equality of time or by waiting.

In block 230 the first branch, ie block 8 and execution unit 1, is then again in the power mode and in block 231 the second branch with block 9 and execution unit 2, whereby the switchover according to the invention is then completed.

According to the task, an optimized switchover between two operating modes of a processor unit with two integrated execution units is thus shown according to the invention, the identifier being able to be introduced or localized in a variety of ways in accordance with FIG. 5 in a program or data line section 500. In the following we speak of the lines in FIG. 5

Program lines, whereby here too program and data lines are possible in any combination.

For example, 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. With 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. Likewise, such 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. In addition, 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. Regarding the

There are now various options for using the identifier: on the one hand, 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). On the other hand, it can also be provided according to the invention that 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. With regard to the consideration of dominant and recessive, this means that the dominant value and thus the safety mode is usually set in the event of an error or failure. Corresponding to line Z4, there is now a binary value Bl, that is to say Kl / Bl, which identifies, for example, that the task program of lines Z4 to Z6 can be processed in program Pl in performance mode, although program Pl must be processed in safety mode, for example. As can be seen from the identifiers K1, K2 and K3, these 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. Likewise, 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, can be represented here with CB by an identifier, such as K3 here, being assigned to a mode. In addition to the operating mode assignment with bit B1 at K3, 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. According to K4, such an identification assignment can also take place for individual commands PB3 in ZI 9 or • also for each command. As shown, 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.

In a special embodiment, 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. In this case, as a command generating this identifier KB, 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. By means of 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.

This represents a large number of possibilities according to the invention for carrying out an operating mode switch in a processor unit with two execution units on the basis of an identifier. The aforementioned advantages of the invention can thus be achieved.

Claims

Expectations

1. A method for switching between at least two operating modes (SM, LM) of a processor unit (100, 101) with at least two execution units (ALUA, ALUB) for processing programs (P1, P2, P3), characterized in that at least the programs ( Pl, P2, P3) is assigned at least one identifier (K2) which one

A distinction is made between the at least two operating modes (SM, LM) and the operating modes are switched depending on the identifier (K1-K4, KB), so that the processor unit (100, 101) programs (Pl, P2, P3) processed according to the assigned operating mode.

2. The method according to claim 1, characterized in that the programs (P1, P2, P3) contain or form task programs (AP) and the individual task programs (AP) are each assigned the identifier (Kl).

3. The method according to claim 1, characterized in that the programs (Pl, P2,

P3) consist of individual program parts (CB) or contain these and each identifier (K3) is assigned to the individual program parts (CB).

4. The method according to claim 1, characterized in that the programs (P1, P2, P3) consist of individual program instructions (PB) and the individual program instructions

(PB) is assigned the identifier (K4).

5. The method according to claim 1, characterized in that the programs (P1, P2, P3) belong to an operating system of the processor unit (100, 101) or that Represent operating system.

6. The method according to claim 1, characterized in that the programs (P1, P2, P3) are used to control the operating sequences of a vehicle.

7. The method according to claim 1, characterized in that a first operating mode is provided which corresponds to a security mode (SM), in which the two execution units (ALUA, ALUB) redundantly process the same programs (AP, P2).

8. The method according to claim 7, characterized in that when processing the

Programs (AP, P2), resulting states or results (ResultA, ResultB) are compared (14) and if there is a deviation, an error is recognized.

9. The method according to claim 7, characterized in that the programs (AP, P2) are processed synchronously.

10. The method according to claim 1, characterized in that in the second operating mode, which corresponds to a power mode (LM), each execution unit (ALUA, ALUB) processes different programs (Pl, P2, P3).

11. The method according to claim 1, characterized in that the identifier (Kl, KB) is designed as at least one bit (Kl / Bl).

12. The method according to claim 1, characterized in that a program command (PBl, PB2, PB3) is provided which generates an identifier (KB) which indicates whether it is to be processed in the first or second operating mode.

13. The method according to claim 1, characterized in that the identifier (KB) is written in a specific memory area (SSB).

14. The method according to claim 12 or 13, characterized in that the identifier

(KB) is generated by an instruction (PB1, PB2) provided in an instruction set of the processor unit.

15. The method according to any one of claims 12-14, characterized in that the identifier (KB) is generated by a write command (WR).

16. Device for switching between at least two operating modes (LM, SM) of a processor unit (100, 101) for processing programs (P1, P2, P3) with at least two execution units (ALUA, ALUB), switching means (8, 9) being included through which switching can take place, characterized in that these switching means (8, 9) assign at least one program (P1, P2, P3) to at least one identifier (K1-K4, KB) which differentiates between the two operating modes (LM , SM) and the switching means (8, 9) are designed such that they switch between the operating modes depending on the identifier and the processor unit processes the programs in accordance with the assigned operating mode.

17. The apparatus according to claim 16, characterized in that at least two execution units correspondingly at least duplicated arithmetic units (ALUA, ALUB) are provided.

18. Processor unit (100, 101) for processing programs (P1, P2, P3) with at least two execution units (ALUA, ALUB), wherein switching means (8, 9) are included, by means of which between at least two operating modes (LM, SM) the

Processor unit can be switched, characterized in that these switching means (8, 9) at least assign at least one program (P1, P2, P3) to an identifier (K1-K4, KB) which differentiates between the two operating modes (LM, SM) allowed and the switching means (8, 9) are designed such that they switch depending on the identifier between the operating modes and the processor unit

Executes programs according to the assigned operating mode.