Microprocessor device, and method of managing reset events therefor

A microprocessor device comprises at least one reset management module. The at least one reset management module is arranged to detect a reset event comprising a first reset level, determine if at least one reset condition has been met upon detection of the reset event comprising the first reset level, and cause a reset of a second reset level upon determining that the at least one reset condition has been met.

FIELD OF THE INVENTION

This invention relates to a microprocessor and a method of managing reset events therefor.

BACKGROUND OF THE INVENTION

In typical microcontroller devices, reset schemes are implemented whereby the microcontroller device will be reset upon a particular event occurring. In more intelligent systems, such a reset scheme may be divided into separate levels of reset, such as a destructive reset level and one or more functional reset levels. In a functional reset case only certain elements of the microcontroller device are reset, whilst in a destructive reset case a complete reset of the entire microcontroller device is performed. Accordingly, such a functional reset may typically be applied in response to non-critical reset events, whilst a destructive reset may be applied in response to a critical reset event. The limitation with strict implementations of separate functional and destructive resets is that reset events defined as a functional type will always generate a functional reset. However, in some cases it may be preferred that such a functional type of reset event be escalated to the destructive type in order to force a full system reset.

An example of a non-critical reset event is a system software watchdog reset event, which is typically handled as a functional reset event. However, depending on the system design it is sometimes preferable that this reset source is escalated to a destructive reset. For example, if the cause of the watchdog reset event is not removed by the functional reset, repeated software watchdog reset events may occur, resulting in reset cycling, which is typically not considered a safe state. Accordingly, escalating the reset to a destructive type in the event of such reset cycling in order to force a full system reset enables the microcontroller device to be returned to a (presumed) safe state.

SUMMARY OF THE INVENTION

The present invention provides a microprocessor and a method of managing reset events within a microprocessor device as described in the accompanying claims.

DETAILED DESCRIPTION

The present invention will now be described with reference to a microprocessor device comprising one or more processing cores. For clarity, the term ‘microprocessor device’ used herein is intended to incorporate programmable microprocessor devices intended for use within general purpose applications, as well as programmable microprocessor devices intended for use within embedded applications, such as microcontroller devices and system on chip devices, and specialised programmable processing devices such as digital signal processor devices.

Referring first toFIG. 1, there is illustrated a simplified block diagram of an example of a part of a microprocessor device100implemented as an integrated circuit device comprising at least one die within a single integrated circuit package105. In the example illustrated inFIG. 1, the microprocessor device100comprises a minimum of a single processing core110. However, it should be noted microprocessor device may comprise multiple cores, or that the processing core functionality is spread across multiple cores. The microprocessor device100further comprises reset circuitry125arranged to perform a first level reset and reset circuitry120arranged to perform a second level reset.

In the illustrated example, reset circuitry120comprises destructive reset circuitry arranged to receive a destructive reset signal112and to perform a ‘destructive’ reset of components within the microprocessor device100, such as a complete reset of the entire microprocessor device100, upon the destructive reset signal112indicating the detection of a destructive reset event.

Conversely, reset circuitry125comprises non-destructive reset circuitry arranged to receive a ‘functional’ reset signal114and to perform a functional reset of at least some components within the microprocessor device100upon the functional reset signal114indicating the detection of a functional (non-destructive) reset event. Thus, the destructive reset circuitry120is arranged to perform a more extensive reset and the functional reset circuitry125is arranged to perform a less extensive reset.

The microprocessor device100further comprises a reset management module130. The reset management module130is arranged to detect a reset event comprising a first reset level, determine if at least one reset condition has been met upon detection of the reset event, and cause a reset of a second reset level upon determining that the at least one reset condition has been met. In particular for the example illustrated inFIG. 1, the reset management module130comprises a reset controller132arranged to receive the functional reset signal114, and thereby to detect a functional reset event. The reset controller132is further arranged to output a destructive reset signal135to be received by the destructive reset circuitry120. In the illustrated example, the destructive reset signals112,135are provided to the destructive reset circuitry120via an OR gate140. In this manner, if either of the destructive reset signals112,135comprises, in the illustrated example, a ‘1’ value (indicating that a destructive reset is to be performed) the destructive reset circuitry120will perform a destructive reset. It will be appreciated that there are multiple logical implementations for the administration of destructive reset signals, such as destructive reset signals112,135, and that the implementation illustrated inFIG. 1comprising OR gate140is just one such example. Upon detection of a functional reset event, as indicated by the functional reset signal114, the reset controller132illustrated inFIG. 1is arranged to determine if at least one reset condition has been met, and if the reset condition(s) has/have been met, to output a ‘1’ indicating to the destructive reset circuitry120that a destructive reset is required. In the manner, upon determining that the reset condition(s) has/have been met, the reset management module130is arranged to cause a destructive reset. Thus, the reset controller132, and thereby the reset management module130, is arranged to escalate a functional reset to a destructive reset upon the one or more reset conditions being met (for example as described in greater detail below).

FIG. 2illustrates a simplified block diagram of an example of the reset controller132. In the example illustrated inFIG. 2, the reset controller132comprises a functional reset count element210. The functional reset count element210is arranged to read and store a value received at a first input212thereof upon receipt of an active edge received at a second input214thereof. The functional reset count element210is further arranged to output216a currently stored value. The second input214of the functional reset count element210is arranged to receive the functional reset signal114(FIG. 1), and thus is arranged to read and store a value received at the first input212thereof upon an active edge of the functional reset signal114; i.e. upon detection of a functional reset event. In the illustrated example, the second input214of the functional reset count element210is arranged to receive the functional reset signal114via an OR gate205, which receives the functional reset signal114at a first input202thereof, and an output204of which is operably coupled to the second input214of the functional reset count element210.

The first input212of the functional reset count element210is operably coupled to an output222of a multiplexer element220. A first data input224of the multiplexer element220is operably coupled to an output232of a subtraction element230. A first input234of the subtraction element230is operably coupled to the output216of the functional reset count element210, and as such is arranged to receive the value currently stored therein. A second input236of the subtraction element230is arranged to receive, in the illustrated example, a ‘1’ value, and the subtraction element230is arranged to output232a value equal to the value received at the first input234thereof minus the value received at the second input236thereof. As such, the subtraction element230in the illustrated example is arranged to output a value one less than the value stored in the functional reset count element210.

A second data input226of the multiplexer element220is operably coupled to an output242of a programmable register240, which in the illustrated example is arranged to configurably store a threshold value. The programmable register240in the illustrated example is arranged to receive a threshold configuration signal118, for example output by the processing core110inFIG. 1, and is arranged to configure the threshold value stored therein in accordance with the received threshold configuration signal118. In this manner, software running on the processing core110is able to configure the threshold value stored within the programmable register240. In some alternative examples, the programmable register may be pre-configured with a ‘fixed’ threshold value.

The multiplexer element220is arranged to selectively output one of the values received at the first and second inputs224,226thereof in accordance with a signal received at a control input228thereof. Specifically in the illustrated example, the multiplexer element220is arranged to output the value received at the first input224thereof (i.e. the decremented value output by the subtraction element230) upon receipt of a ‘0’ value at the control input228thereof, and to output the value received at the second input226thereof (i.e. the threshold value output by the programmable register240) upon receipt of a ‘1’ value at the control input228thereof.

The control input228of the multiplexer element220is arranged to receive an initialisation signal216. In this manner, upon the initialisation signal216being set to a ‘1’ value, the multiplexer element220outputs the threshold value stored within the programmable register240. The initialisation signal216is also provided to a second input206of the OR gate205. Accordingly, upon the initialisation signal216being set to a ‘1’ value, the functional reset count element210reads and stores the threshold value output by the multiplexer element220; thereby (re-)initialising the reset controller132.

Conversely, when the initialisation signal216is set to a ‘0’ value, the multiplexer element220outputs the decremented value output by the subtraction element230. In this manner, upon an active edge of the functional reset signal114; i.e. upon detection of a functional reset event, the functional reset count element210reads, stores and outputs the decremented value. In this manner, whilst the initialisation signal216comprises a ‘0’ value, each time an active edge occurs within the functional reset signal114, i.e. each time a functional reset event is detected, the value stored within, and output by, the functional reset count element210is decremented. The output216of the functional reset count element210is provided to a first input252of a comparator250. A second input254of the comparator250is arranged to receive a ‘0’ value. The comparator element250is arranged to output, as the destructive reset signal135, a ‘1’ value when the signal received at the first input252thereof equals the signal received at the second input254thereof, and a ‘0’ value otherwise. Thus, the comparator element250in the illustrated example outputs a ‘0’ value whilst the value stored within and output by the functional reset count element210does not equal ‘0’. When the value stored within and output by the functional reset count element210equals ‘0’, i.e. when the number of detected functional reset events equals the threshold value stored within the programmable register240, the comparator element250outputs135a ‘1’ value, indicating that a destructive reset is required.

Thus, the reset controller130in the illustrated example in effect comprises a counter arranged to decrement a value stored therein upon detection of a functional reset event, and to cause a destructive reset upon a number of detected functional reset events equalling a threshold value. The reset controller130may alternatively be arranged to increment a value stored therein upon detection of a functional reset event, and to cause a destructive reset upon a number of detected functional reset events equalling a threshold value. For example, the subtraction element230may be replaced with an addition element arranged increment the value stored within the functional reset count element210, and the value stored within the programmable register240upon initialisation may be configured such that, upon the number of detected functional reset events equalling a desired threshold value, incrementing the value stored within the functional reset count element210causes the value stored therein to ‘roll over’ to ‘0’.

In this manner, a functional type of reset event may be escalated to the destructive type, for example in order to force a full system reset, upon the number of functional reset events detected equalling a (configurable) threshold value. Advantageously, by enabling such reset escalation within hardware, as illustrated inFIG. 1, the burden of preventing reset cycling may be substantially removed from software, thereby simplifying software development etc. Furthermore, in the illustrated example a user is able to configure the threshold value based on which a functional reset may be escalated to a destructive reset.

In the example illustrated inFIG. 2, the reset control module132further comprises a timer component260. The timer260is arranged to receive at an input262thereof the functional reset signal114, and to be initialised upon an active edge thereof; i.e. upon detection of a functional reset event. An output264of the timer260is operably coupled to the control input228of the multiplexer element220and the second input206of the OR gate204. Specifically in the illustrated example, the output264of the timer260is operably coupled to a first input272of an OR gate270, an output274of which is operably coupled to the control input228of the multiplexer220and the second input206of the OR gate105. The timer260is arranged to output a ‘1’ value upon expiration thereof. Thus, upon expiration of the timer260, the reset controller132is re-initialised. In this manner, when functional reset events are detected over a long period of time, as may be the case in long run times within industrial applications, escalation to a destructive reset may be avoided through long term accumulation of function reset events.

A second input276of the OR gate270is arranged to receive an external initialisation signal134, via which the reset controller132may be (re-)initialised. For example, and referring back toFIG. 1, the reset management module130in the illustrated example comprises an OR gate136comprising a plurality of inputs. An output of the OR gate136is operably coupled to the reset controller132and arranged to provide the initialisation signal to the second input of the OR gate270within the reset controller132. In this manner, a ‘1’ value received at any input of the OR gate136will (re-)initialise the reset controller132. In the illustrated example, the OR gate136is arranged to receive at one input thereof the destructive reset signal112. In this manner, the reset controller is re-initialised following a destructive reset. A further input of the OR gate136is arranged to receive a software configurable initialisation signal116. In this manner, software running on the processing core110is able to re-initialise the reset controller132. A still further input of the OR gate136is arranged to receive a power-on indication signal138. In this manner, the reset controller132is initialised following power-on of the microprocessor device100.

Referring now toFIG. 3, there is illustrated a simplified flowchart300of an example of a method of managing reset events within a microprocessor device, such as may be implemented within the microprocessor device100ofFIG. 1. The method starts at310with the detection of a reset event, and moves on to320. If the detected reset event comprises a destructive reset event, the method moves on to330where a counter is re-initialised. A destructive reset is then initiated at340. Referring back to320, if the detected reset event comprises a non-destructive (e.g. functional) reset event, the method moves on to350where the counter is, in the illustrated example, decremented. Next, at360, it is determined whether the counter value equals ‘0’. If the counter value does not equal ‘0’, the method moves on to370and a functional reset is initiated. Conversely, if the counter value does equal ‘0’, the method moves on to380where the reset event is escalated to a destructive reset event, and the method moves on to340where a destructive reset is then initiated.

Referring now toFIG. 4, there is illustrated a simplified block diagram of an alternative example of a part of a microprocessor device400. In the example illustrated inFIG. 4, the microprocessor device400comprises multiple processing cores410,415. In the illustrated example, the microprocessor device400comprises n processing cores, where n may comprise two or more. The microprocessor device400comprises reset circuitry125arranged to perform a first level (functional) reset of at least some components within the microprocessor device400upon a functional reset signal114indicating the detection of a functional (non-destructive) reset event. The microprocessor device400further comprises reset circuitry120arranged to perform a first level (destructive) reset of components within the microprocessor device400, such as a complete reset of the entire microprocessor device400, upon a destructive reset signal112indicating the detection of a destructive reset event. Thus, the destructive reset circuitry120is arranged to perform a more extensive reset and the functional reset circuitry125is arranged to perform a less extensive reset.

The microprocessor device400further comprises a reset management module430. The reset management module430is arranged to detect a reset event comprising a first reset level, determine if at least one reset condition has been met upon detection of the reset event, and cause a reset of a second reset level upon determining that the at least one reset condition has been met. In particular for the example illustrated inFIG. 4, the reset management module430comprises a reset controller132arranged to receive indications of a functional reset event (as described in greater detail below). The reset controller132is further arranged to output a destructive reset signal135to be received by the destructive reset circuitry120. In the illustrated example, the destructive reset signals112,135are provided to the destructive reset circuitry120via an OR gate140. In this manner, if either of the destructive reset signals112,135comprises, in the illustrated example, a ‘1’ value (indicating that a destructive reset is to be performed) the destructive reset circuitry120will perform a destructive reset. Upon detection of a functional reset event, the reset controller132illustrated inFIG. 4is arranged to determine if at least one reset condition has been met, and if the reset condition(s) has/have been met, to output a ‘1’ indicating to the destructive reset circuitry120that a destructive reset is required. In the manner, upon determining that the reset condition(s) has/have been met, the reset management module430may be arranged to cause a destructive reset. Thus, the reset controller132, and thereby the reset management module430, may be arranged to escalate a functional reset to a destructive reset upon the one or more reset conditions being met (for example as described in greater detail above).

The reset management module430illustrated inFIG. 4further comprises an escalation access controller435arranged to receive requests to update the reset controller132, and to perform arbitration of such received requests. Such requests may comprise, by way of example, requests to indicate a functional reset event, requests to re-initialise the reset controller132, etc. In the illustrated example, the escalation access controller435is arranged to receive requests to update the reset controller132from the processing cores410,415, and thus to perform arbitration of update requests from the plurality of processing cores410,415. For example, upon receipt of a request to update the reset controller132from a first processing core410, the escalation access controller435may be arranged to provide an indication of the received request to update the reset controller132to at least one further processing core415, and to update the reset controller132upon receipt of confirmation of the update from the at least one further processing core415. In some examples, the escalation access controller435may be arranged to only update the reset controller132upon receipt of confirmation of the update from all further processing cores415.

In some examples, the indication provided to the further processing core(s)415may comprise a simple indication (e.g. a ‘1’ value) that a request to update the reset controller132has been received, and confirmation from the further processing core(s)415may similarly comprise a simple response, such as a ‘1’ value. In some examples, the escalation access controller435may be arranged to only update the reset controller132upon receipt of confirmation of the update from the further processing core(s)415within a limited period of time.

In some alternative examples, a request to update the reset controller132received from a first processing core410may comprise an access key. The indication of the received request to provided by the escalation access controller435to the further processing core(s)415may thus comprises the access key received from the first processing core410, and the escalation access controller435may be arranged to only update the reset controller132upon receipt of confirmation of the update from the further processing core(s)415comprising the respective access key.

Thus, in this manner, arbitration may be provided between requests to update reset controller (e.g. to indicate a functional reset event or to re-initialise the reset controller132) received from different processing cores410,415within a multi-processor architecture.

Referring now toFIG. 5, there is illustrated a simplified flowchart500of an alternative example of a method of managing reset events within a microprocessor device, such as may be implemented within the microprocessor device400ofFIG. 4. The method starts at505with the detection of a reset event, and moves on to510. If the detected reset event comprises a destructive reset event, the method moves on to515where a counter is re-initialised. A destructive reset is then initiated at520. Referring back to510, if the detected reset event comprises a non-destructive (e.g. functional) reset event, for example where the reset event is detected by way of request to update a counter received from a first processing core, the method moves on to525where an indication of a request to update a counter is provided to other processing cores. If, at530, one or more processing cores to not confirm/agree to the updating of the counter, the method moves on to535and a functional reset is initiated. Conversely, if all other processing cores confirm/agree to updating of the counter, the method moves on to540where the counter is, in the illustrated example, decremented. Next, at550, it is determined whether the counter value equals ‘0’. If the counter value does not equal ‘0’, the method moves on to535and a functional reset is initiated. Conversely, if the counter value does equal ‘0’, the method moves on to560where the reset event is escalated to a destructive reset event, and the method moves on to520where a destructive reset is then initiated.

In the examples hereinbefore described, the reset management module130,430has been arranged to detect reset events comprising a less extensive reset level (e.g. functional reset events), determine if at least one reset condition has been met (e.g. a number of detected reset events equals a threshold value), and cause a reset of a more extensive reset level (e.g. a destructive reset level) upon determining that the at least one reset condition has been met.

It is contemplated that such a reset management module may additionally/alternatively be arranged to detect reset events comprising a more extensive reset level (e.g. destructive reset events), determine if at least one reset condition has been met, and cause a reset of a less extensive reset level (e.g. a functional reset level) upon determining that the at least one reset condition has been met. In this manner, a similar mechanism for stopping destructive reset cycling may be provided by staying in reset after, say, n destructive resets have been detected until a power-down-and-up of the microprocessor device is performed.

For example, and as illustrated inFIG. 6, there is illustrated a simplified block diagram of an alternative example of a part of a microprocessor device600. In the example illustrated inFIG. 6, the microprocessor device600comprises a processing core610. The microprocessor device600further comprises reset circuitry125arranged to perform a first level (functional) reset of at least some components within the microprocessor device600upon a functional reset signal114indicating the detection of a functional (non-destructive) reset event. The microprocessor device600further comprises reset circuitry120arranged to perform a first level (destructive) reset of components within the microprocessor device600, such as a complete reset of the entire microprocessor device600, upon a destructive reset signal112indicating the detection of a destructive reset event. Thus, the destructive reset circuitry120is arranged to perform a more extensive reset and the functional reset circuitry125is arranged to perform a less extensive reset.

The microprocessor device600further comprises a reset management module630. The reset management module630comprises a first reset controller132arranged to receive the functional reset signal114, and thereby to detect a functional reset event. The first reset controller132is further arranged to output a destructive reset signal135to be received by the destructive reset circuitry120. In the illustrated example, the destructive reset signals112,135are provided to the destructive reset circuitry120via an OR gate140. In this manner, if either of the destructive reset signals112,135comprises, in the illustrated example, a ‘1’ value (indicating that a destructive reset is to be performed) the destructive reset circuitry120will perform a destructive reset. Upon detection of a functional reset event, as indicated by the functional reset signal114, the reset first controller132is arranged to determine if at least one reset condition has been met (e.g. if a number of detected functional reset events equals a threshold value), and if the reset condition(s) has/have been met, to output a ‘1’ indicating to the destructive reset circuitry120that a destructive reset is required. In the manner, upon determining that the reset condition(s) for detected functional reset events has/have been met, the reset management module130is arranged to cause a destructive reset. Thus, the first reset controller132, and thereby the reset management module130, is arranged to escalate a functional reset to a destructive reset upon the one or more reset conditions being met.

The reset management module630further comprises a second reset controller632arranged to receive the destructive reset signal112, and thereby to detect a destructive reset event. The second reset controller632is further arranged to output a functional reset signal635to be received by the functional reset circuitry125. In the illustrated example, the functional reset signals114,635are provided to the functional reset circuitry125via an OR gate650. In this manner, if either of the functional reset signals114,635comprises, in the illustrated example, a ‘1’ value (indicating that a functional reset is to be performed) the functional reset circuitry125will perform a functional reset. Upon detection of a destructive reset event, as indicated by the destructive reset signal112, the second reset controller632is arranged to determine if at least one reset condition has been met (e.g. if a number of detected destructive reset events equals a threshold value), and if the reset condition(s) has/have been met, to output a ‘1’ indicating to the functional reset circuitry120that a functional reset is required. In the manner, upon determining that the reset condition(s) for detected destructive reset events has/have been met, the reset management module130is arranged to cause a functional reset. In the example illustrated inFIG. 6, the output of OR gate140is operably coupled to the destructive reset circuitry120via AND gate640. The functional reset signal635output by the second reset controller632is provided to an inverting input of the AND gate640. In this manner, when the function reset signal635is set to a ‘1’ value to indicate that a functional reset is required, the destructive reset signal112is isolated from the destructive reset circuitry120to prevent a destructive reset being performed. Thus, the second reset controller632, and thereby the reset management module130, is arranged to de-escalate a destructive reset to a functional reset upon the one or more destructive reset conditions being met.

Thus, a method and apparatus for enabling reset events to escalated or de-escalated have been described. In particular, a method and apparatus of configurably and flexibly enabling such (de-)escalation of reset events have been described. In addition, enabling such escalation of reset events allows reset events that would be configured as destructive events in a ‘fixed’ reset level system, to be initially configured as non-destructive (e.g. functional) reset events. Such reset events may subsequently be escalated to destructive events upon one or more reset criteria being met (e.g. such events occur more than n times). In this manner, system availability may be improved by initially avoiding destructive resets, with functional safety subsequently being provided by escalating the reset level for such reset events upon one or more reset criteria being met.

Furthermore, the terms ‘assert’ or ‘set’ and ‘negate’ (or ‘de-assert’ or ‘clear’) are used herein when referring to the rendering of a signal, status bit, or similar apparatus into its logically true or logically false state, respectively. If the logically true state is a logic level one, the logically false state is a logic level zero. And if the logically true state is a logic level zero, the logically false state is a logic level one.

Those skilled in the art will recognize that the boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or circuit elements or impose an alternate decomposition of functionality upon various logic blocks or circuit elements. Thus, it is to be understood that the architectures depicted herein are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. For example, in the illustrated examples the destructive and functional reset circuits120,125have been illustrated as separate logical blocks. However, it will be appreciated that the destructive and functional reset circuits120,125have one or more common components, and/or may comprise a single functional component.

Any arrangement of components to achieve the same functionality is effectively ‘associated’ such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as ‘associated with’ each other such that the desired functionality is achieved, irrespective of architectures or intermediary components. Likewise, any two components so associated can also be viewed as being ‘operably connected,’ or ‘operably coupled,’ to each other to achieve the desired functionality.