U.S. patent application number 11/948454 was filed with the patent office on 2009-06-04 for device and method for electronic controlling.
This patent application is currently assigned to INFINEON TECHNOLOGIES AG. Invention is credited to Jens Barrenscheen, Harry Siebert.
Application Number | 20090144587 11/948454 |
Document ID | / |
Family ID | 40677009 |
Filed Date | 2009-06-04 |
United States Patent
Application |
20090144587 |
Kind Code |
A1 |
Barrenscheen; Jens ; et
al. |
June 4, 2009 |
DEVICE AND METHOD FOR ELECTRONIC CONTROLLING
Abstract
An electronic controlling device and method is disclosed. One
embodiment provides at least one module performing specific
functions within one of a plurality of module modes on reception of
a corresponding module mode request. A system control unit is
provided to operate the at least module in one of a plurality of
module modes by distributing a corresponding system mode request.
The at least one module is adapted to translate the distributed
system mode request to a module mode request which is
configurable.
Inventors: |
Barrenscheen; Jens;
(Muenchen, DE) ; Siebert; Harry; (Puchheim,
DE) |
Correspondence
Address: |
DICKE, BILLIG & CZAJA
FIFTH STREET TOWERS, 100 SOUTH FIFTH STREET, SUITE 2250
MINNEAPOLIS
MN
55402
US
|
Assignee: |
INFINEON TECHNOLOGIES AG
Neubiberg
DE
|
Family ID: |
40677009 |
Appl. No.: |
11/948454 |
Filed: |
November 30, 2007 |
Current U.S.
Class: |
714/40 ; 700/7;
714/25; 714/E11.002 |
Current CPC
Class: |
G05B 2219/2637 20130101;
G05B 2219/23188 20130101; G05B 19/0426 20130101; G05B 19/0421
20130101; G05B 2219/2216 20130101; G05B 2219/25289 20130101 |
Class at
Publication: |
714/40 ; 700/7;
714/25; 714/E11.002 |
International
Class: |
G06F 11/00 20060101
G06F011/00; G05B 15/02 20060101 G05B015/02 |
Claims
1. An electronic controlling device comprising: at least one module
performing specific functions within one of a plurality of module
modes on reception of a corresponding module mode request; and a
system control unit to operate the at least one module in one of a
plurality of system modes by distributing a corresponding system
mode request; wherein the at least one module translates the
distributed system mode request to a module mode request which is
configurable.
2. The electronic controlling device of claim 1, wherein the at
least one module comprises at least one configuration unit to
define the translation of the system mode request distributed to
the at least one module into the module mode request forwarded to
the respective at least one module.
3. The electronic controlling device of claim 2, comprising wherein
the at least one configuration unit is programmable to configure
the mapping of at least one of the system modes onto a
predetermined one of the module modes.
4. The electronic controlling device of claim 2, wherein the at
least one configuration unit comprises a programmable configuration
field for mapping of at least one of the system modes onto a
predetermined one of the module modes.
5. The electronic controlling device of claim 4, comprising wherein
the system mode request distributed to the at least one module is
configured to select which configuration field is forwarded to the
at least one module in form of the corresponding module mode
request to translate the distributed system mode request to the
predetermined module mode request.
6. The electronic controlling device of claim 1, wherein the at
least one module comprises an input configured to receive the
module mode request.
7. An electronic controlling device comprising: at least one module
to perform at least one predetermined function on reception of at
least one corresponding local mode request; and at least one global
state controller (GSC) to distribute at least one global mode
request (GMR) to at least one module; wherein, for at least one
module, at least one distributed global mode request may be
individually translated to a predetermined one of the at least one
local mode request in a configurable way.
8. The electronic controlling device of claim 7, further
comprising: a plurality of clusters and within each cluster; at
least one module, and at least one global state controller,
wherein, within each cluster, the at least one module is configured
to receive the at least one global mode request from the at least
one global state controller within the respective cluster.
9. The electronic controlling device of claim 7, comprising wherein
the at least one global state controller is configured to receive a
plurality of system mode requests from a system control unit
(SCU).
10. The electronic controlling device of claim 7, comprising
wherein the at least one global state controller is configured to
receive a plurality of debug mode requests from a chip debug system
(CDS).
11. The electronic controlling device of claim 9, comprising
wherein the at least global state controller is configured to
perform a local prioritization of concurrent ones of the system
mode requests received by the respective at least one global state
controller.
12. The electronic controlling device of claim 9, comprising
wherein the at least one module is configured to return a global
mode acknowledgement to the respective at least one global state
controller depending on the respective received global mode
request.
13. The electronic controlling device of claim 7, further
comprising coupled between at least one global state controller as
at least one higher hierarchical level unit and at least one module
as at least one lower hierarchical level unit, at least one unit at
least one intermediate hierarchical level configured to distribute
and/or translate mode requests and mode acknowledgements between
the at least one higher hierarchical unit and the at least one
lower hierarchical level unit coupled to the at least one
intermediate hierarchical level unit.
14. The electronic controlling device of claim 7, comprising: the
at least one global state controller; and a plurality of modules at
least one of which comprising a local state controller; wherein the
at least one of the plurality of modules is configured to receive
the plurality of global mode requests from the global state
controller via the respective local state controller.
15. A method for electronical controlling comprising: distributing
one of a plurality of system mode requests by a system control unit
to at least one module; translating the distributed system mode
request for the at least one module into a corresponding one of a
plurality of individually configurable module mode requests; and
performing specific functions by the at least one module depending
on the respective module mode request for the respective
module.
16. The method of claim 15, wherein the plurality of system mode
requests comprises power down requests, reset requests and the like
and wherein the debug mode requests comprises suspend requests.
17. The method of claim 16, further comprising: distributing one of
a plurality of debug mode requests by a chip debug system to the at
least one module; and translating the distributed debug mode
request for the at least one module to a corresponding one of the
plurality of module mode requests.
18. The method of claim 16, further comprising: prioritizing
concurrent ones of system mode requests and/or debug mode requests
by at least one global state controller for the at least one module
or for a plurality of modules independently.
19. A method for operating an electronic controlling device
comprising: clustering the electronic controlling device in a
plurality of functional domains each comprising at least one
module, for at least one of the functional domains distributing one
of a plurality of global mode requests from a global state
controller to the at least one module within the respective
functional domain.
20. The method of claim 19, further comprising distributing one of
a plurality of system mode requests to the at least one global
state controller.
21. The method of claim 19, further comprising for at least one of
the functional domains switching on or off an independent voltage
regulator depending on the respective system mode.
22. The method of claim 20, further comprising generating the
global mode request by the at least one global state controller
wherein, depending on a priority of the system mode request
received by the respective global state controller, the respective
global mode request is defined by the received system mode request
or by a software configurable register.
23. The method of claim 22, wherein the at least one global state
controller comprises an individually configurable priority
scheme.
24. The method of claim 19, further comprising generating a module
mode request for the at least module depending on the global mode
request received by the respective module or on a software
configurable register.
Description
BACKGROUND
[0001] The present invention relates generally to an electronic
controlling device, such as a microcontroller, as well as to
methods for electronic controlling and for operating an electronic
controlling device.
[0002] One of the challenging problems regarding electronic
controlling devices, which may e.g., be used to control electrical
devices in a vehicle, relates to the way various system modes are
enabled in the functional modules of the electronic controlling
device, in particular in the case when these system modes are
supposed to have different priorities. Such system modes may
include for instance debug modes, power saving modes, reset modes
or any other predefined modes.
[0003] In current architectures of electronic controlling devices,
the modules mostly include an input to receive a request signal
which may cause a change in the behavior of the respective module,
in one embodiment to suspend, "freeze" or automatically power down
the module. That means that the triggering of the
functions--typically through usage of an "enable bit"--is assigned
to the respective module itself.
[0004] Hence, in order to change between various system modes in
existing integrated microcontroller architectures, for each system
mode, lines signaling the corresponding system mode requests have
to be distributed to every single relevant module. Accordingly, the
system mode requests are evaluated on a module by module basis.
[0005] This common solution to change between system
modes--although appearing simple and straightforward at first
sight--has one disadvantage that it causes an increased
implementation effort when the microcontroller architecture needs
to be redesigned, changed or when a new system mode has to
established.
[0006] For these or other reasons, there is a need for the present
invention.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] The accompanying drawings are included to provide a further
understanding of embodiments and are incorporated in and constitute
a part of this specification. The drawings illustrate embodiments
and together with the description serve to explain principles of
embodiments. Other embodiments and many of the intended advantages
of embodiments will be readily appreciated as they become better
understood by reference to the following detailed description. The
elements of the drawings are not necessarily to scale relative to
each other. Like reference numerals designate corresponding similar
parts.
[0008] FIG. 1 illustrates a schematic block diagram of an
embodiment of an architecture of an electronic controlling
device.
[0009] FIG. 2 illustrates a schematic block diagram of a control
handshake structure according to one embodiment.
[0010] FIG. 3 illustrates a schematic block diagram of a clock
distribution hierarchy according to one embodiment.
[0011] FIG. 4 illustrates a schematic block diagram of a handshake
signal flow between a global state controller (GCS), a local state
controller (LSC) and a kernel state controller (KSC) according to
one embodiment.
[0012] FIG. 5 illustrates a timing diagram of a standard handshake
between the local state controller and the kernel state controller
according to one embodiment.
[0013] FIG. 6 illustrates a timing diagram of a handshake between
the local state controller and the kernel state controller with an
error condition according to one embodiment.
[0014] FIG. 7 illustrates a schematic block diagram of a local
state controller configuration according to one embodiment.
DETAILED DESCRIPTION
[0015] In the following Detailed Description, reference is made to
the accompanying drawings, which form a part hereof, and in which
is shown by way of illustration specific embodiments in which the
invention may be practiced. In this regard, directional
terminology, such as "top," "bottom," "front," "back," "leading,"
"trailing," etc., is used with reference to the orientation of the
Figure(s) being described. Because components of embodiments can be
positioned in a number of different orientations, the directional
terminology is used for purposes of illustration and is in no way
limiting. It is to be understood that other embodiments may be
utilized and structural or logical changes may be made without
departing from the scope of the present invention. The following
detailed description, therefore, is not to be taken in a limiting
sense, and the scope of the present invention is defined by the
appended claims.
[0016] It is to be understood that the features of the various
exemplary embodiments described herein may be combined with each
other, unless specifically noted otherwise.
[0017] In the following, for illustration purposes, the invention
will be described with reference to a microcontroller like, for
instance, a general purpose integrated microcontroller. However,
the invention is not so limited and may find its application in
conjunction with any other type of electronic controlling unit that
might be integrated into other devices.
[0018] The basic cause of the above described inflexibility of
existing architectures of electronic controlling devices lies in
the fact that--as a consequence of the evaluation of the system
mode requests on a module by module basis--also a prioritization
among concurrent system mode requests received by the modules needs
to be carried out on a module by module basis.
[0019] Hence, when a change of the priorities among the system
modes is required, the currently used local prioritization schemes
will lead to an increased implementation effort. So far, in
practice, designers balk at this implementation effort and rather
accept the limited flexibility of the microcontroller
functionality. Moreover, the local prioritization of concurrent
system mode requests might lead to unnecessary processing
operations, if a cluster of modules uses the same priority
scheme.
[0020] Correspondingly, one or more embodiments carry out the
prioritization among the system modes on a higher
hierarchical--i.e. "system"--level of the microcontroller, which
will more accurately reflect the characteristics of the "system"
modes.
[0021] An electronic controlling device and/or a microcontroller
and/or methods for electronic controlling and/or for operating an
electronic controlling device are provided, substantially as
illustrated in and/or described in connection with at least one of
the figures, as set forth more completely in the claims.
[0022] Further features and advantages of the present invention
will become apparent from the following detailed description of the
invention made with reference to the accompanying drawings.
[0023] For different applications, it is necessary to operate
electronic assemblies or boards in different system modes.
Correspondingly, electronic devices for controlling these
electronic assemblies or boards, e.g., microcontrollers, have to
provide correspondingly different system modes as well.
[0024] In reaction to a change of a system mode according to a
corresponding system mode request, the current consumption of the
affected modules may be changed in a corresponding power saving
mode or the access behavior of possibly other affected modules may
change in a corresponding debug mode.
[0025] However, the effect of the changed system mode on different
modules of the electronic controlling device may have to vary
according to the intended application. For instance, in one
application it may be necessary to suspend a communication
interface of a specific module in a first debug case in order to
analyze the behavior of this interface, while in another debug
case, exactly this interface is used for the debug communication
and thus has to remain active.
[0026] In still another application, a mechanism has to be provided
to "wake-up" the electronic controlling device system from a power
saving mode by providing corresponding input signals to the
respective request inputs of the affected modules, or to power down
these or other modules to further reduce the power consumption. Of
course, the above application examples are just for illustration
purposes and the present invention is not so limited.
[0027] Hence, in one or more embodiments the microcontroller is
flexible and will accommodate a great variety of possible
applications.
[0028] To analyze a way to increase the flexibility of an
electronic controlling device in order to support the corresponding
plurality of possible combinations of applications, it is helpful
to express these combinations by a model of a multi-dimensional
space of functions.
[0029] The first dimension of this space is constituted by the
plurality of available system modes. With the elements of this
dimension, namely the system modes, a change between these system
modes is mainly determined by events which are unforeseeable over
time, i.e. asynchronous.
[0030] These events are detected and/or processed by hardware and
may therefore be independent from the software currently running on
the electronic controlling device. Examples for these events are
events which require the change between power modes, e.g., a low
remaining battery capacity, and points in time during the
transitions between these power modes, as well as debug accesses to
the electronic controlling device via an independent entity, or
sudden voltage drops.
[0031] A second dimension results from the functional range of each
of the modules of an electronic controlling device, which
altogether constitute the electronic controlling device system. The
functional range may e.g., include the normal operation of the
electronic controlling device and the controlled device, or a break
at a point between commands or operations which is safe for the
electronic controlling device system. For example for a CAN
(Control Area Network) module, such a safe point could be defined
by the completion of the transmission of a CAN message since, the
CAN message could otherwise block the whole corresponding CAN
bus.
[0032] A further example of the functional range of the modules is
the systematic entering of a defined state also for the controlled
device. For instance, for an electronic controlling device
including a pulse width modulation unit for controlling of electric
motors, such a defined state could be to drive the outputs into an
idle position in order to prevent damages of the system. A still
further example of the functional range of the modules may be an
instant break without any further operations (e.g., for
timers).
[0033] A third dimension of the multi-dimensional space of
functions is constituted by the various applications of the
electronic controlling device system. This element in the model of
the electronic controlling device reflects that not all of the
modules in an electronic controlling device system are supposed to
illustrate the same reaction in the different system modes.
[0034] A hard, i.e. definitely and unchangeably defined mapping of
a module reaction to a system mode would limit the flexibility of
the electronic controlling device system, since this hard mapping
might not cover some of the clients demands with respect to module
reaction in a certain system mode.
[0035] As an example for the above, the electronic controlling
device may be used in one application wherein it may communicate
over an asynchronous interface via RS232 with a debugger. In this
application the asynchronous interface must not be shut off if the
electronic controlling device system is switched to a suspend mode
by the debugger.
[0036] However in another application of the electronic controlling
device, the same asynchronous interface has to be suspended
immediately in order to check the current state of the interface
including the content of the data buffers of the interface, while
the communication with the debugger proceeds over another
interface.
[0037] Another example for the increased flexibility without an
unchangeable mapping of a module reaction to a system mode may be a
first module reaction in a first application wherein an interface
is used in order to save data to a memory in case an imminent
voltage breakdown is signalized.
[0038] However, for the affected module to be flexible, there
should be the possibility to define a second module reaction for a
second application. In this second application, in the same case of
an imminent voltage breakdown, i.e. in the same system mode, the
interface is switched off automatically in order to save as much
power as possible if saving the data is not necessary.
[0039] In embodiments of an electronic controlling device, a clear
separation of the above described dimensions is provided.
Therefore, each of the dimensions or functions is represented on a
separate hierarchical level where it causes the least amount of
effort to be implemented or where it offers the greatest amount of
flexibility.
[0040] Hence, in the described embodiment of an electronic
controlling device the architecture of the electronic controlling
device is configured to provide a clear separation between the
request of a system mode, i.e. the first dimension of the abstract
hierarchy model of an electronic controlling device, and reaction
of the modules of the electronic controlling device, i.e. the
second dimension of the model.
[0041] This causes that the request of applying or changing of the
system mode of the electronic controlling device may be prioritized
and processed more centrally, i.e. on a higher hierarchical level.
The result of this prioritization is a decision which system mode
is actually to be applied. This decision may then be distributed
throughout the system to the modules. In the words of the abstract
hierarchy model of an electronic controlling device, the
corresponding centralized prioritization units provide the
separated first dimension.
[0042] In a further embodiment, the modules are configured to
enable definitions of certain functions on a module specific basis.
These functions include e.g., the normal operation of the
electronic controlling device and the controlled device or the
acquisition of defined states, wherein the defined states cause a
reasonable system behavior according to the respective
application.
[0043] For the already mentioned example of an electronic
controlling device including a pulse width modulation unit for
controlling of electric motors such a defined state could be the
idle position at the beginning of a pulse width modulation period,
the systematic switching on or off of the pulse width modulated
outputs or an instant "freezing" of the outputs, i.e. the
suspension of any further influence on the pulse width modulated
outputs.
[0044] Hence, in the words of the abstract hierarchy model of an
electronic controlling device, the configurability of the functions
of the modules, which is independent of the system mode, provides
the separated second dimension.
[0045] The corresponding configurable function states or operation
modes of the modules will be referred to as module modes in order
to provide also a conceptual separation from the system modes.
[0046] According to one embodiment, the modules include a request
input which determines the relevant module mode for the respective
module. The request input replaces the former "enable bits" (e.g.,
a suspend enable bit, a power-down enable bit etc.) which
altogether communicated a corresponding system mode request
directly to every single module.
[0047] In the above embodiment, only the module mode to be applied
is communicated via the request input of the module. However, the
module does no longer receive any information about the cause for
the application of the module mode, which may e.g., be a certain
system mode. Thus, on the module level, a prioritization among
system modes requests is no longer required.
[0048] According to the structure of another embodiment of the
electronic controlling device, each one of the modules includes a
configuration unit to define the translation of a system mode
request distributed to the respective module to a configurable
module mode request which is forwarded to the respective module.
Hence, the configuration unit serves as a "translation
specification" between the system mode which is requested on the
system level and the corresponding module mode which is forwarded
to the module.
[0049] In another embodiment, the configuration units may be
programmable such that a user of the electronic controlling device
may configure the mapping of each system mode onto a predetermined
module mode according to the respective application of the
electronic controlling device. This mapping of the module functions
and the system modes provides the third separate dimension in the
abstract hierarchy model of an electronic controlling device,
namely the application dimension.
[0050] One embodiment of the configuration unit may include a
programmable configuration field for each system mode. In this
embodiment, the actually requested system mode may be configured to
choose which configuration field is forwarded to the respective
module in form of the corresponding module mode request.
[0051] The programmability of the configuration fields in the
configuration units provides the possibility to choose a desired
module mode for each system mode on a module specific basis and to
change it even during operation of the electronic controlling
device, as the application of the electronic controlling device may
require. This allows to change the currently applied module mode
via software without a change of the system mode.
[0052] Hence, the proposed microcontroller architecture provides a
simple and universally programmable unit, which allows to
efficiently decouple the first and the second dimensions of the
above described abstract hierarchy model of an electronic
controlling device. Moreover, the proposed microcontroller
architecture provides a clear decoupling of hardware based and
software based changes of the module behavior.
[0053] The third dimension of the above described abstract
hierarchy model of an electronic controlling device, which refers
to different application of modes within the different modules, may
be implemented by allocating an independent configuration unit to
preferably each single module.
[0054] FIG. 1 illustrates a schematic block diagram of one
embodiment of an architecture of an electronic controlling
device.
[0055] The embodiment of the electronic controlling device 1
includes two clusters 100, 200 which are configured according to
corresponding clock, power and/or reset domains.
[0056] In the embodiment of FIG. 1, within each of the two clusters
100, 200, the electronic controlling device 1 includes a plurality
of modules 120, 130, 140, 150 and 220, 230, 240, 250 respectively.
Furthermore, each of the two clusters 100, 200 includes a global
state controller 110, 210. Global state controllers 100, 200 may
act as global units to centrally control the system mode of the
electronic controlling device 1 depending on a corresponding system
mode request. Each one of the plurality of modules 120, 130, 140,
150 and 220, 230, 240, 250 is configured to receive a global mode
request signal 111, 211 from the global state controller 110, 210
within the respective cluster 100, 200 via the respective local
state controllers 121, 131, 141, 151 and 221, 231, 241, 251. Local
state controllers 121, 131, 141, 151 and 221, 231, 241, 251 may act
as part of the interface between the global state controllers and
the respective modules to complete the translation of system mode
requests to individually configurable local mode request
signals.
[0057] Further referring to the embodiment of FIG. 1, each one of
the global state controllers 110, 210 is configured to receive a
plurality of system mode requests from a system control unit (SCU)
10. In the embodiment, the system mode requests include a power
down request signal 50 and a synchronous reset request signal
51.
[0058] Moreover, each one of the global state controllers 110, 210
is configured to receive a plurality of debug mode requests from a
chip debug system (CDS) 20. In the embodiment, the debug mode
request includes a suspend request signal 60.
[0059] In one embodiment, a control handshake mechanism effects the
communication between module kernels and their environment. The
module kernels of different microcontroller instances are
preferably identical, whereas the usage of the modules in different
microcontroller instances may be different. In this context, the
kernel of a module may be understood as the functional part of a
module without the connections to the rest of the infrastructure of
the electronic controlling device.
[0060] This implies that specific functions or features of a
particular electronic controlling device instance are preferably
not handled or implemented on module level, but on a higher
implementation hierarchy level, namely, in the embodiment of FIG.
1, on the level of the global state controllers 110, 210. Specific
functions or features of a particular electronic controlling device
instance can, for instance, refer to the clustering of a particular
electronic controlling device instance in clock, power or reset
domains or clusters. A typical example for such a function may be
the step-by-step disabling of modules or clusters of modules for
power savings reasons.
[0061] In one embodiment, inside a cluster, there may only be one
synchronous clock domain visible for the user. Although other
internal clocks may be implemented in the respective cluster, they
may not be visible for the control handshake mechanism.
[0062] Furthermore, a cluster may include its own power domains or
at least a single power domain. However, in other embodiments,
several clusters may share the same power domain.
[0063] In the embodiment illustrated in FIG. 1, two clusters 100
and 200 are implemented. Each cluster 100, 200 includes its own
power domain with an independent voltage regulator (EVR) 190 and
290 respectively. The power control inside a cluster 100, 200 may
be performed by the corresponding global state controller 110, 210.
The chip debug system 20 is configured to generate a suspend
request signal 60 which is distributed to each cluster 100,
200.
[0064] The system control unit 10 is configured to generate a power
down request signal 50, which may e.g., be based on an input pin
indicating a loss of power in the near future. In order to minimize
the overall power consumption, it can be desired to switch off one
or even both of the clusters 100,200 of the electronic controlling
device 1 immediately under hardware control. Therefore, the global
state controllers 110, 210 may be configured to switch off the
respective independent voltage regulators 190, 290.
[0065] In one embodiment including a global state controller for
each cluster, the global state controllers may each handle the
following actions for the entire, respective one of the
clusters:
[0066] Switching on/off the power supply in case the cluster
includes its own independent voltage regulator
[0067] Distributing the suspend mode to all modules in the
respective cluster
[0068] Distributing a global functional (synchronous) reset request
to all modules in the respective cluster
[0069] Locally prioritizing incoming hardware requests for the
respective cluster (e.g., power a down request may overrule a
suspend request)
[0070] In one or more embodiments, in order to keep the global
state controller structure as simple as possible, one global state
controller per cluster may be used.
[0071] In the embodiment of FIG. 1, the combination of clusters
100, 200 may be controlled by applying all external signals 50, 51,
60 in parallel to all global state controllers 110, 210 in the
clusters 100, 200.
[0072] In this embodiment, there is no need for an explicit
handshake between the global state controllers 110, 210 and the
control units on a higher hierarchical level, namely, in the
embodiment of FIG. 1, the chip debug system 20 and the system
control unit 10. This is caused by the fact that the global state
controllers 110, 210 only need to execute the requests distributed
by the control units as, for instance, the system control unit 10
and the chip debug system 20. An acknowledgement is not mandatory
but advantageous for further handling of the system modes, e.g., in
a case of step-by-step powering down of clusters of modules.
Preferably, a cluster is powered down if all modules in the cluster
have reached a respective predefined state.
[0073] Still referring to the embodiment in FIG. 1, in addition to
the control functionality of the global state controllers 110, 210,
more specific functional adjustments may be enabled by the local
state controllers or local state controllers parts 121, 131, 141
and 151 as well as 221, 231, 241 and 251 associated to the
respective modules or module kernels 120, 130, 140 and 150 as well
as 220, 230, 240 and 250. On module level, the following tasks may
be handled or functions may be enabled:
[0074] Switching on/off the clock for a specific module (each
module in a cluster can be enabled individually)
[0075] Defining the suspend behavior (immediate reaction, a so
called granted suspend, when a specified state is reached, or no
effect)
[0076] Requesting a local module reset (functional,
synchronous)
[0077] In certain embodiments, all functions which may be triggered
and/or determined under hardware control may also be triggered
and/or determined under software control. For example, in one
embodiment, for each function, a selection bit may determine
whether the function is handled under hardware control such that
the software control is ignored, or under software control such
that the hardware control is ignored. The selection bit may
preferably be located where the conflict between hardware and
software might occur.
[0078] In one embodiment the actual status and the mode of a module
can be evaluated by only once reading the corresponding status
register. In embodiments which allow to change modes under software
control, the support for diagnosis by software is preferable. Since
a change of the requested mode of a module can occur at any time,
the requested mode is preferably evaluated repeatedly or even
constantly.
[0079] Referring now to an embodiment of a single cluster 100 in
FIG. 2, it is illustrated that the global state controller 110 may
generate a global mode request signal (GMR) 111 which may be
distributed to all modules 130, 140 and 150 in the cluster 100. The
global mode request signal 111 may by processed by each of the
local state controllers 131, 141, 151 which, in the block diagram
representation of FIG. 2, are located near to the module, e.g., in
a bus peripheral interface (BPI). Depending on the type of global
mode request signal 111, the local state controllers 131, 141, 151
each return a corresponding global mode acknowledge signal (GMA)
133, 143, 153 for the respective module 130, 140, 150.
[0080] In the embodiment according to FIG. 2, the communication
between the local state controllers 131, 141, 151 and the modules
130, 140, 150 is handled via the kernel state controller part 132,
142, 152 of the modules 130, 140, 150. The local state controllers
131, 141, 151 each may generate a corresponding local mode request
signal (LMR) 134, 144, 154 which depends on the global mode request
signal 111 or software actions respectively. The kernel state
controllers 132, 142, 152 answer these request by returning
corresponding local mode acknowledgement signals (LMA) 135, 145,
155 to the local state controllers 131, 141, 151.
[0081] In certain embodiments the reaction of a local state
controller to an incoming global mode request may be disabled. In
this case, the global mode request is not taken into account and
the local mode request is not changed. This functionality may be
useful if the global state controller activates a suspend request
but the module is not supposed to go into the suspend mode due to
predetermined reasons.
[0082] In certain embodiments, the module may be disabled by e.g.,
switching off the clock within the module locally by the local
state controller under software control, while the global state
controller outputs a global mode request which would--without the
disabling of the module--cause a different reaction of the
module.
[0083] Referring now to FIG. 3, it is illustrated that the clock
frequency of a cluster 100 is derived from the input frequency
f.sub.sys of the cluster 100. In order to support a full speed mode
and a reduced speed mode, the global state controller 110 may
define a divider ratio of n by the frequency divider 180. The
factor n may be programmable in the global state controller 110 and
may preferable be under software control in order to guaranty a
reproducible behavior.
[0084] The above mentioned speed modes may be characterized as
follows:
[0085] full speed mode: n=1, all clock edges are passed to the
modules
[0086] reduced speed mode: n>1, every n-th clock edge is passed
to the modules
[0087] In one embodiment, the range of n may e.g., be from 1 to 16.
In the reduced speed mode, handshake signals between modules of
different clusters may preferably take into account that not all
clock edges are available.
[0088] The reduced speed mode may be useful to reduce the power
consumption of the corresponding clusters, while a certain
performance decrease within the clusters may be accepted. With a
module being in the reduced speed mode, the number of accesses to
registers of this module may be preferably minimized.
[0089] In further embodiments, the clock of each module may be
switched on or off independently from the speed modes and
individually, e.g., under software control by a local clock gate
170, 171, 172 controlled by the corresponding local state
controller 121, 131, 141, or globally, e.g., inside the cluster
100, under software or hardware control by a global clock gate 181,
controlled by the global state controller 110.
[0090] Referring now to FIG. 4, it is illustrated that the global
state controller 110 includes a register GSC_CUR 112, defining the
global operating mode which may be defined by software, e.g., for a
normal operation mode, a clock off mode or power down mode for the
complete cluster 100. In an embodiment, the register GSC_CUR 112
may not be changed by hardware.
[0091] Depending on the priority of the externally requested modes
represented by the external mode request signals 65 stored in a
corresponding external mode register 70 of the global state
controller 110, such as a suspend mode, a power down mode or an
emergency mode, the global state controller 110 may output either
the current externally requested mode or the mode defined by the
register GSC_CUR 112 in form of the global mode request signal
111.
[0092] The priority scheme for prioritization among the externally
requested modes may be preferably handled locally inside the global
state controller 110 and, hence, does not effect the handshake
mechanism with the local state controller 121. The priority scheme
may be implemented in form of a prioritizing multiplexer 113.
[0093] Accordingly, the global mode request 111 of the global state
controller 110 may change at any point in time, depending on the
external mode request signals 65 or write actions by software to
the register GSC_CUR 112.
[0094] In the local state controller 121, software can define
whether the global mode request signal 111 is taken into account as
a corresponding configurable local mode request which may be stored
in a register LSC_REQ 126. If so, the register LSC_REQ 126 may be
permanently updated by global mode request signal 111. The register
LSC_REQ 126 outputs the local mode request signal 124.
[0095] If not, the global mode request signal 111 is not taken into
account and the register LSC_REQ 126 is only changed by software.
In an embodiment, the local state controller 121 may include a
register for defining the local operating mode by software.
[0096] In the embodiment according to FIG. 4, it may be defined
locally--e.g., by the programmable switch 121a in the local state
controller 121--whether the global mode request 111 is taken into
account and this definition may depend on the globally requested
mode. In another embodiment, all the global mode request signals of
all global state controllers may be disabled for consideration by
all local state controllers.
[0097] In further embodiments, only the suspend request signal may
be disabled locally if the corresponding module should not enter
the suspend mode.
[0098] Further referring to the embodiment in FIG. 4, the local
state controller 121 may also define the characteristics of the
suspend mode, i.e. if e.g., an immediate or granted suspend should
by applied, and may control the functional enable for the module
120 accordingly.
[0099] According to one embodiment, in the suspend mode, the module
clock is not stopped, such that the registers of the module can
still be written or read out.
[0100] In the embodiment according to FIG. 4, in case the local
mode request signal 124 corresponds to the clock off mode, the
local state controller 121 may wait for the kernel state controller
122 before switching off the module clock by the local clock gate
170.
[0101] In one embodiment, after a cluster is controlled to leave
the power down mode, e.g., by switching on again the independent
voltage regulator of this cluster, the global state controller
associated with that cluster may--preferably always--cause a reset
by activating an asynchronous reset of the entire cluster. This
reset may enable the local state controllers of the cluster to take
subsequent global state controller requests into account again.
[0102] Further referring to the embodiment in FIG. 4, the register
LSC_STAT 128 of the local state controller 121 and the
corresponding local mode acknowledgement signal 123 are configured
to indicate to the global state controller 110 when the mode
requested by the global mode request signal 111 has been reached by
the module 120.
[0103] In a local operation mode in which the local state
controller 121 is configured to ignore the global mode request
signals 111, the register LSC_STAT 128 may be configured to return
an OK signal instead of the local mode acknowledgement signal 123
to the global state controller 110. In this way--as long as the
register LSC_STAT 128 returns the OK signal--the global state
controller 110 may ignore the local state controller 121 with
respect to all mode changes which would otherwise require specific
local mode acknowledgement signals 123 as part of a handshake
signal from the local state controller 121.
[0104] In the embodiment according to FIG. 4, a local mode
handshake between local state controller 121 and the kernel state
controller 122 includes the local mode request signal 124 from the
local state controller 121 to the kernel state controller 122 and
at least local mode acknowledge signal 125 from the kernel state
controller 122 back to the local state controller 121.
[0105] With respect to the embodiment in FIG. 4, the handshake
between the local state controller 121 and the kernel state
controller 122 includes:
[0106] the local mode request signal 124 indicated by the register
LSC_REQ 126;
[0107] a first part of the local mode acknowledgement signal 125a
based on the content of a register KSC_CUR 129a of the kernel state
controller 122 wherein the register KSC_CUR 129a indicates the
current mode of the module kernel 120;
[0108] a second part of the local mode acknowledgement signal 125b
based on the content of a register KSC_STAT 129b of the kernel
state controller 122 wherein the register KSC_STAT 129b indicates
the status of the module kernel 120 and wherein the second part of
the local mode acknowledgement signal 125b is used to validate the
content of the register KSC_CUR 129a.
[0109] A timing diagram of a typical handshake between the local
state controller 121 and the kernel state controller 122 is
illustrated in FIG. 5. The first signal chart of the timing diagram
below the module clock f.sub.sys/n corresponds to the content of
the register LSC_REQ 126 which represent the requested mode. In
case that the current mode of the module kernel 120--indicated by
the content of the register KSC_CUR 129a and corresponding to the
third signal chart below the module clock f.sub.sys/n in FIG. 5--is
not equal to the requested mode in register LSC_REQ 126, a
transition to the requested mode is started represented in FIG. 5
with the content of register KSC_STAT 129b being marked with TR
which stands for transition. In order to indicate that the current
mode has reached the requested one, the content of register
KSC_STAT 129b is marked with OK.
[0110] Therefore, the contents of registers LSC_REQ 126 and KSC_CUR
129a are compared. If a not-equal condition is detected, which is
marked by the small circles in FIG. 5, the content of register
KSC_STAT 129b illustrated in the second signal chart below the
module clock f.sub.sys/n changes from OK, which indicates that the
current mode is equal to the requested one, to TR, which indicates
that the module kernel 120 is in transition to the requested mode.
The time spans SD and TD in FIG. 5 respectively represent the
synchronization delay and the transition delay of the register
KSC_CUR 129a with respect to the point of time in which the
requested mode in register LSC_REQ 126 changes.
[0111] If the module kernel 120 can reach the requested mode
directly in the next clock cycle, the transition state may be
skipped. When the requested state is reached, this is indicated by
the register KSC_STAT 129b being set to OK and the register KSC_CUR
129a being set to the requested mode. The corresponding points in
time are marked by small rectangles in FIG. 5. The state TR (in
transition) may be--preferably always--left synchronously with the
register KSC_CUR 129a indicating the new mode.
[0112] When the local state controller 121 detects that the kernel
state controller 122 signals an OK, the local state controller 121
sets the content of the register LSC_CUR 127 to the content of
register KSC_CUR 129a, which is marked by the plus signs in FIG. 5.
By software read accesses the corresponding registers LSC_REQ 126,
LSC_CUR 127, KSC_CUR 129a and KSC_STAT 129b, the current mode, the
requested mode and the transition or an error phase can be exactly
evaluated.
[0113] The error phase is illustrated in the timing diagram of a
handshake between local state controller 121 and kernel state
controller 122 in FIG. 6. Under certain conditions--e.g., because
of an internal module failure, a timeout or a request of a not
implemented mode, for example mode B--the module kernel 120 may not
be able to reach the requested mode. In case such an error
condition is detected, the first 125a and second part 125b of the
local mode acknowledgement signal indicate an error. In the error
case, the register KSC_STAT 129b is set to ER and the register
KSC_CUR 129a is set to the requested mode to indicate which mode
has lead to the error condition, while all functional internal
activities of the specific module kernel 120 may be stopped.
[0114] In case of an error condition, the local state controller
121 may automatically request the last successfully reached mode.
This mode may be stored in the register LSC_CUR 127 which may be
updated by the content of register KSC_CUR 129a if the register
KSC_STAT 129b indicates OK. In an embodiment, the automatic
reactivation of the last successfully reached mode may be enabled
or disabled under software control in the local state controller
121.
[0115] The fact that a specific action is required from a certain
module and the fact that a requested mode is taken into account by
a module (and more precisely by the local state controller of the
module) are preferably considered as two independent phenomena.
With respect to the first phenomenon, in typical embodiments some
of the global mode requests are configured to be initiated by
hardware, such as a suspend mode request, a power down mode request
or an emergency mode request. With respect to the second
phenomenon, also in typical embodiments, however, actions may be
controlled locally and individually for each module by software.
Therefore, in order to avoid possible priority conflicts between
global mode requests and software controls, a kind of arbitration
scheme may be introduced in embodiments of the invention.
[0116] In one embodiment, the arbitration scheme may work on two
levels. The first level may be located inside the global state
controller 110. There, two mechanisms may collide: The actions that
are handled under software control--e.g., with respect to the
embodiment in FIG. 4, using the register GSC_CUR 112 which defines
the global operating mode by software--and the actions triggered by
hardware, e.g., by the external mode request signals 65 stored in
the external mode register 70.
[0117] For example, software may define the desired functionality
of the entire cluster, such as:
[0118] Reset (default after power up, by enabling an independent
voltage regulator)
[0119] Power down (by disabling an independent voltage
regulator)
[0120] Clock off or reduced clock
[0121] Normal operation wherein the signification of normal
operation, i.e. the normal module behavior, may be defined
individually for each module in the corresponding local state
controller
[0122] In certain embodiments, the hardware may also request
specific modes depending on the implementation. Since the global
state controllers may be designed for each electronic controlling
device individually, the global state controllers may be designed
differently with respect to priority among or in the number of
requests under hardware control. This may not be desirable from a
design point of view in every case, but is feasible if needed for
flexibility purposes.
[0123] In certain embodiments, functions under hardware control are
mainly emergency or real-time critical functions, such as:
[0124] Suspend mode (may be requested by the chip debug system)
[0125] Power down (may be requested by the system control unit,
e.g., depending on an external emergency input signal)
[0126] In addition to the above functionalities, further hardware
controlled modes may be implemented in corresponding embodiments.
The arbitration scheme of a global state controller can be adapted
easily to introduce other functions due to its modular structure.
Furthermore, it is also possible to request a suspend mode under
software control.
[0127] Referring back to the embodiment in FIG. 4, the
functionalities requested under software control may be written to
the register GSC_CUR 112 of the global mode controller 110. The
content of the register GSC_CUR 112 represents the current mode
requested by the global state controller 110 without any
intervention of requests under hardware control. The register
GSC_CUR 112 is typically not changed by hardware, except after a
power up, when the global state controller 110 may also request a
reset of the entire cluster. In the embodiment according to FIG. 4,
each hardware request signal, here the external mode request
signals 65, may be individually enabled or disabled in the global
state controller 110.
[0128] Correspondingly, in a embodiment a first priority scheme may
be that, in case there is a hardware request, it will have priority
over a concurrent software request. Taking the example of the two
hardware requests known today, namely the suspend and the emergency
power down request, in one embodiment the following priority scheme
of the global state controller 110 is proposed:
[0129] Emergency power down (high priority)
[0130] Suspend mode and software controlled modes (low
priority)
[0131] In most of today's applications for microcontrollers, this
priority scheme will meet the requirement for system safety and
debugging.
[0132] In further embodiments, a second arbitration level may be
located in the local state controllers. In fact, the arbitration on
the local state controller level can also be understood as a
configuration. With respect to the embodiment in FIG. 7, the local
state controller 121 may include configuration bit fields 127a,
127b, 127c, 127d, 127e which may be configured under software
control for each of the different global mode request signals 111.
In certain embodiments not all global modes requests require a
programmable configuration. For example, the reset mode request may
be hard coded. In a still further embodiment, an emergency mode
request may be hard coded as well.
[0133] For example, when the global state controller requests
normal operation of a module, it is preferable to have the
possibility to enable or disable each module of a cluster
individually. As a result, the meaning of "normal operation" may be
different for each module, e.g., it may be a run mode, a clock off
mode, etc. Furthermore, in case a suspend mode is requested, it is
preferable to differentiate between an immediate suspend, a granted
suspend or no suspend at all. In a corresponding embodiment, this
suspend mode behavior is also configurable individually for each
module.
[0134] Hence, in certain embodiments, in order to avoid complex
priority schemes, the arbitration may be performed in two steps.
With respect to the embodiment according to FIG. 7, in the first
process, the global state controller 110 sends global mode requests
111, i.e. issues "only" "orders" to the local state controller
121.
[0135] These global mode requests 111 may not be directly related
to the behavior of the corresponding module. Inside the local state
controller 121, the responsiveness and the behavior of the
corresponding module as reactions or answers to these global mode
requests 111 can be configured individually. As a result, in
certain embodiments, it may suffice to implement only one "real"
arbitration mechanism between the software control and hardware
events in the global state controller 110 with very simple
rules.
[0136] In this way, a priority conflict will not occur in the local
state controller 121 due to the configuration capability under
software control.
[0137] The global state controller 110 sends global mode requests
111 and their mapping to the module modes may be defined by
configuration in the local state controller 121. By the separation
of global mode requests 111 and--preferably programmable--module
modes 127z, priority conflicts may be avoided.
[0138] The local state controller 121 may request the module kernel
to operate in a desired mode or to change to another mode. In this
process, the reason why a specific mode has been requested is not
communicated to the module kernel, since this information is not
needed in the module kernel and would not change the behavior of
the module kernel in any manner. In the embodiment according to
FIG. 4, the module 120 (more precisely the kernel state controller
122) therefore includes a single mode request input 129e driven by
the local mode request signal 124 of the local state controller
121.
[0139] Depending on the internal structure and the task of the
kernel, the effect of the module modes can differ from one module
to another. In certain embodiments, the module modes may
comprise:
[0140] a run mode (operation of the module as specified)
[0141] a synchronous reset (all flip-flops of the module are set to
their specified reset values)
[0142] reaching a specified state and stop there (granted
request)
[0143] stopping immediately and going to a defined state (like a
trap-behavior for fail-safe, not necessarily the reset state)
[0144] In certain embodiments, in order to provide flexibility for
future extensions, the following module modes are proposed, wherein
in some cases, the module mode can preferably be defined
individually for each module:
[0145] For example, the module modes may include different run
modes respectively causing a different operation behavior of the
respective module. Furthermore, different stop modes may be
implemented with different end conditions. Optionally, the module
modes may include forcing a reset or other auxiliary modes for
future extensions.
[0146] An example of a set of module modes may be the
following:
[0147] Run mode 0 (no grant signal is generated)
[0148] Run mode 1 (a grant signal is always generated)
[0149] Synchronous reset (default after power up)
[0150] Stop mode 0 (reach specified state 0, stop and generate a
grant signal)
[0151] Stop mode 1 (stop immediately, go to defined state 1 and
generate a grant signal)
[0152] Stop mode 2 (reach specified state 2 in which the clock can
be switched off, stop and generate a grant signal)
[0153] Auxiliary mode 0 and 1 (for future extensions). If an
auxiliary mode is not implemented in a module, its behavior is
preferably specified and will preferably not lead to any module
action (preferred behavior: like synchronous reset).
[0154] The behavior and the possible transitions between each of
these module modes are preferably to be defined individually for
each module, since in a microcontroller application, e.g., a
Control Area Network (CAN) has different requirements compared to a
timer or a flash array. For these requirements, a versatile control
handshake mechanism may not be suited and therefore the
requirements are preferably to be handled in each kernel.
[0155] In certain embodiments, in case a module is to be disabled
inside a running cluster, the local state controller configuration
for normal operation is preferably to be written with stop mode 2
instead of run mode 0 or 1 for the operating modules.
[0156] In further embodiments, in case a module should not react to
suspend requests, the local state controller configuration for a
suspend mode may be the same as for normal operation (e.g., run
mode 0). For an immediate suspend, a stop mode is preferably chosen
(e.g., stop mode 1). A granted suspend behavior may be reached by
programming another stop mode (e.g., stop mode 0) or other stop
modes.
[0157] In the following, an analog-to-digital conversion (ADC)
module is described as one possible application of the invention
and as a further embodiment. In this embodiment, the mode control
mechanisms for power saving, suspend and other system control tasks
may be implemented in the ADC module kernel.
[0158] In the ADC module, predetermined operations may be
interrupted under certain conditions. The conditions may be defined
by the global state controller, which combines all related
functions that may lead to an immediate module reaction, like a
suspend mode request or a power-down indication. For example, if a
power failure is detected to happen in a certain time by a
pre-warning mechanism some modules may stop operation for power
saving reasons, whereas others may continue working.
[0159] To the ADC module itself no information is communicated why
its module mode--i.e. it operation mode--changes. Correspondingly,
if a new module mode is requested, the ADC module simply enters
this module mode.
[0160] For the ADC module, the following internal operations may be
influenced or configured by the mode control mechanism:
[0161] A Current Conversion of an Analog Value:
[0162] If a digital part of the ADC module has detected a pending
request for analog-to-digital conversion, a corresponding analog
part of the ADC module may be started. This start may be enabled by
the mode control mechanism. If the current module mode allows the
conversion start, e.g., in run modes 0 and 1, the conversion will
be executed. If the module mode does not allow the conversion
start, e.g., in stop modes 0 and 1, the conversion is not started.
The request for the conversion start is not cancelled, but
"frozen". A "frozen" conversion may be started as soon as the
module mode is changed to a run mode again.
[0163] An Arbiter Round:
[0164] The start of a new arbiter round may be enabled by a certain
module mode. For example, in stop mode 1, a new arbiter round will
not start.
[0165] FIG. 8 illustrates a block diagram of a basic structure of
an interface between the local state controller 321 and the kernel
state controller 332 of the ADC module. The global mode request
signals CR, CRV 111 are distributed from the global state
controller to the prioritizing multiplexer 313. The module modes
327z corresponding to the different global mode requests 111 may be
configured by software e.g., by corresponding bit fields 327a,
327b, 327c of a kernel state configuration register KSCFG.
[0166] In the kernel state controller 332 of the ADC module kernel
320, the input signals of kernel state controller 332 KCRV 324a and
KCR 324b may be received from the local state controller 321 and
stored in corresponding registers of the kernel state controller
332. The signals KCR 324b are sampled and taken into account with
the rising edge of the signal KCRV 324a. The sampled value of the
signals KCR 324b represent the requested module mode. If the kernel
is currently in a transition, i.e. if the latest requested module
mode has not yet been reached, the signal KCR 324b is also
sampled.
[0167] The two output signals KSC_ERR 325a and KSC_ACK 325b of the
kernel state controller 332 may be read from corresponding
registers in the kernel state controller 332 and send to the local
state controller 321. The switching behavior of the signal KSC_ERR
325a may be as follows:
[0168] Set to O if the signal KCRV 324a equals O.
[0169] Set to 1 if the requested module mode can not be
reached.
[0170] The switching behavior of KSC_ACK may be as follows:
[0171] Set to 0 if the signal KCRV 324a equals 0.
[0172] Set to 1 if the requested module mode has been reached after
the signal KCRV 324a equals 1.
[0173] If the module mode has been reached while the signal KCRV
324a equals 1, the kernel state controller 332 compares the
currently reached mode with the signal KCR 324b. If they are
identical, the signal KSC_ACK 325b will be set to 1. If they are
not identical, KSC_ACK 325b is not set and a new value of the
signal KCR 324b is taken into account for a new transition. The ADC
kernel tries to reach the sampled requested mode indicated by
sampled signals KCR 324b.
[0174] With respect to the ADC module embodiment, the following
module modes may be defined:
TABLE-US-00001 TABLE 1 ADC Module modes Functional Kernel Mode
Kernel Behavior Grant activation Code.sup.1 run mode 0 operation as
specified, immediate 00.sub.B no explicit stop condition run mode 1
operation as specified, no explicit stop immediate 01.sub.B
condition stop mode 0 A currently running AD conversion is After
the result is written to 10.sub.B completely finished and the
result is the result register and the processed by the digital
part. Pending related interrupt pulse has conversion requests to
start a new been generated. conversion are ignored (but not
deleted). The arbiter and the analog part continue working (i.e.
the corresponding clocks f.sub.ADCD and f.sub.ADC1 are not
stopped). stop mode 1 Like stop mode 0, but the arbiter is stopped
After the result is written to 11.sub.B after it has finished its
arbitration round the result register, the arbiter (i.e. the
corresponding clocks f.sub.ADCD and has stopped and the related
f.sub.ADC1 are stopped.sup.2). interrupt pulse has been generated.
.sup.1This mode is represented by the value of flip-flops sampling
the KCR 324b signal inputs with the rising edge of the signal KCRV
324a. .sup.2If the clock f.sub.ADC1 is stopped during a running
conversion, the conversion result after restarting the clock again
is not valid.
[0175] The following module modes may be hard coded or may be
configured in the kernel state configuration register KSCFG:
[0176] Normal Operation Mode:
The standard operation as specified is executed, functional enable
signals 381 for the analog part and/or for the arbiter are
constantly generated. If enabled by module enable bit field MODEN
of the register KSCFG, the module clock 372 is running.
[0177] Suspend Mode:
[0178] The kernel parts may be stopped and no enable signals 381
are generated by the kernel state controller 332 when a specified
condition is reached. Acknowledge signals 382 are generated when
the kernel has reached a specified stop condition. The module clock
372 is not switched off. If enabled by the MODEN bit field of the
register KSCFG, the module clock 372 is running.
[0179] Clock-Off Mode:
[0180] The kernel parts may be stopped and no enable signals 381
are generated when a specified condition is reached. Acknowledge
signals 382 are generated when the kernel has reached a specified
stop condition. The module clock 372 is switched off
automatically--e.g., by the local clock gates 370--when all kernel
parts have generated their acknowledge signal in the stop mode,
ignoring the setting of the MODEN bit field of the register
KSCFG.
[0181] Other global mode requests 111 from the global state
controller may be ignored and treated like the above described
normal operation mode.
[0182] The mode control mechanism for system control tasks, such as
power saving, or a suspend request for debugging, allows to program
the ADC module behavior under different device operating
conditions. The behavior of the ADC kernels can be programmed for
each of the device operating modes that are requested by the global
state controller, which may be implemented as a part of the system
control unit.
[0183] In one or more embodiments, the ADC kernels of an ADC module
illustrate an identical behavior regarding the device operating
modes, e.g., to avoid that a non-suspended kernel waits for a
suspended kernel to start a synchronized conversion. Therefore, the
ADC module may include a commonly associated register ADC0_KSCFG
defining the behavior of all kernels of the ADC module in the
following device operating modes:
[0184] Normal Operation:
[0185] This operating mode is the default operating mode when
neither a suspend request nor a clock-off request are pending. The
module clock 372 is not switched off and the ADC registers can be
read or written. The kernel behavior is defined by bit field
KSCFG.NOMCFG 327a of the register KSCFG.
[0186] Suspend Mode:
[0187] This operating mode is requested when a suspend
request--which may e.g., be issued by a debugger--is pending in the
device. The module clock 372 is not switched off and the ADC
registers can be read or written. The kernel behavior is defined by
the bit field KSCFG.SUMCFG 327c of the register KSCFG.
[0188] Clock-Off Mode:
[0189] This operating mode is requested for power saving purposes.
The module clock 372 is switched off automatically when all kernels
of the ADC module reached their specified states in a stop mode. In
this case, ADC registers can not be accessed. The kernel behavior
is defined by the bit field KSCFG.COMCFG 327b of the register
KSCFG.
[0190] The behavior of the ADC kernels can be programmed for each
of the device operating modes, e.g., the normal operation mode, the
suspend mode and the clock-off mode. Therefore, the ADC kernels may
support four module modes, as illustrated in the following Table
2.
TABLE-US-00002 TABLE 2 ADC Kernel Behavior Module mode Kernel
Behavior Code run mode 0 kernel operation as specified, no impact
on 00.sub.B run mode 1 data transfer (same behavior for run mode 0
10.sub.B and run mode 1 stop mode 0 A currently running AD
conversion is 10.sub.B completely finished and the result is
processed. Pending conversion requests to start a new conversion
are not taken into account but are not deleted They start
conversions after entering a run mode as programmed. The arbiter
continues as programmed. stop mode 1 Like stop mode 0, but the
arbiter is stopped 11.sub.B after it has finished its arbitration
round
[0191] In the described embodiment, the bit field KSCFG.NOMCFG 327a
of the register KSCFG is preferably configured for run mode 0 as
default setting for standard operation. If the ADC kernels are
configured to not react to a suspend request and are to continue
operation as in normal mode, the bit field KSCFG.SUMCFG 327c is to
be configured with the same value as the bit field KSCFG.NOMCFG
327b. If the ADC kernels should illustrate a different behavior and
stop operation when a specific stop condition is reached, the code
for stop mode 0 or stop mode 1 is to be written to the bit field
KSCFG.SUMCFG 327c.
[0192] A similar mechanism applies for the clock-off mode with the
possibility to program the desired behavior by the bit field
KSCFG.COMCFG 327b. The stop mode selection strongly depends on the
application needs and it is very unlikely that different stop modes
are required in parallel in the same application. As a result, only
one stop mode type (either 0 or 1) should be used in the bit fields
of the register KSCFG. Stop mode 0 and stop mode 1 are not to be
mixed up and transitions from stop mode 0 to stop mode 1 (or vice
versa) are preferably avoided for the ADC module.
[0193] If the module clock 372 is disabled by the bit field
KSCFG.MODEN of the register KSCFG being set to 0, or in clock-off
mode when the stop condition is reached (in stop mode 0 or 1), the
ADC module cannot be accessed by read or write operations, except
for the register KSCFG which can always be accessed. As a
consequence, the ADC module can not be configured then. The bit
field KSCFG.MODEN is to be set preferably by software while all bit
fields of the register KSCFG are configured for run mode 0.
[0194] FIG. 9 illustrates a schematic diagram of the bit field
mapping of the kernel state configuration register KSCFG according
to an embodiment. The register KSCFG allows the selection of the
desired module modes for the different device operating modes. Bit
fields KSCFG.NOMCFG 327a and KSCFG.COMCFG 327b may be reset by a
class 3 reset. Bit field KSCFG.SUMCFG 327c may be reset by a class
1 reset. The register KSCFG is a common register for all ADC
kernels and may be accessed in the address range of ADC0. The
coding of the bit fields KSCFG.NOMCFG 327a, KSCFG.SUMCFG 327c and
KSCFG.COMCFG 327b is described in the following Table 3.
TABLE-US-00003 TABLE 3 Bit field map of the kernel state
configuration register Field Bits Type Description MODEN 0 rw
Module Enable This bit enables the module kernel clock and the
module functionality. 0.sub.B The module is switched off
immediately (without considering a stop condition). The module does
not react to mode control actions and the module clock is switched
off. The module does not react to read accesses and ignores write
accesses (except for accesses to register KSCFG). 1.sub.B The
module is switched on and may operate. After writing 1 to MODEN, it
is recommended to read register KSCFG to avoid pipeline effects in
the control block before accessing other ADC registers. BPMODE 1 w
Bit Protection for MODEN.sup.3 N This bit enables the write access
to the bit MODEN. It always reads 0. 0.sub.B MODEN is not changed.
1.sub.B MODEN is updated with the written value. NOMCFG [5:4] rw
Normal Operation Mode Configuration This bit field defines the
module mode applied in normal operation mode. 00.sub.B Run mode 0
is selected. 01.sub.B Run mode 1 is selected. 10.sub.B Stop mode 0
is selected. 11.sub.B Stop mode 1 is selected. BPNOM 7 w Bit
Protection for NOMCFG This bit enables the write access to the bit
field NOMCFG. It always reads 0. 0.sub.B NOMCFG is not changed.
1.sub.B NOMCFG is updated with the written value. SUMCFG [9:8] rw
Suspend Mode Configuration This bit field defines the module mode
applied in suspend mode. Coding like NOMCFG. BPSUM 11 w Bit
Protection for SUMCFG This bit enables the write access to the bit
field SUMCFG. It always reads 0. 0.sub.B SUMCFG is not changed.
1.sub.B SUMCFG is updated with the written value. COMCFG [13:12] rw
Clock Off Mode Configuration This bit field defines the module mode
applied in clock-off mode. Coding like NOMCFG. BPCOM 15 w Bit
Protection for COMCFG This bit enables the write access to the bit
field COMCFG. It always reads 0. 0.sub.B COMCFG is not changed.
1.sub.B COMCFG is updated with the written value. 0 [3:2], 6, r
Reserved 10, 14 returns 0 if read; should be written with 0.
.sup.3The bit protection bits BPxxx allow partly modification of
the configuration bit a single write operation without the need of
a read-modify-write mechanism handled by the CPU.
[0195] Although specific embodiments have been illustrated and
described herein, it will be appreciated by those of ordinary skill
in the art that a variety of alternate and/or equivalent
implementations may be substituted for the specific embodiments
shown and described without departing from the scope of the present
invention. This application is intended to cover any adaptations or
variations of the specific embodiments discussed herein. Therefore,
it is intended that this invention be limited only by the claims
and the equivalents thereof.
* * * * *