KR101285665B1 - multi core system on chip supporting a sleep mode - Google Patents

Abstract

The present invention relates to a System on Chip (SoC) having a plurality of cores, and more particularly, to an SoC capable of efficient sleep mode control. The present invention, in order to achieve the above object, a first bus system for controlling access to a peripheral device of at least one core; A first core controlling the first bus system; A second bus system for controlling access to peripheral devices of the at least one core; A second core controlling the second bus system; And a first clock control module for determining whether to hold a sleep mode entry of the first bus system according to a forced signal from the second core, and the second according to a forced signal from the first core. And a clock control module including a second clock control module for determining whether to suspend entering the sleep mode of the bus system.

multi core, soc, sleep mode, forced, clock, gating control

Description

Multi core system on chip supporting a sleep mode}

1 is a block diagram illustrating a multi-core SoC according to the prior art.

2 is a diagram illustrating a gating technique of a system control block included in a multi-core SoC according to the related art.

3 is a diagram illustrating a gating technique of a system control block included in a multi-core SoC according to the present embodiment.

The present invention relates to a System on Chip (SoC) having a plurality of cores, and more particularly, to an SoC capable of efficient sleep mode control.

Hereinafter, a sleep mode operation in a system on chip having one or more cores (hereinafter referred to as 'SoC') will be described. The sleep mode is an operation mode in which a core or a bus enters due to power saving.

If there are no tasks to be processed on a particular SoC, a technique to stop the clock (ie sleep mode) is used for low power consumption. This sleep mode technique has a core sleep that stops only the core portion, and a bus stop that stops the core and the bus system of that core. There is).

The operation of the sleep mode in the single core is described below.

In a single-core system with one core, core sleep and bus sleep are controlled by the core of the bus system. On the other hand, whether or not bus sleep is applied is determined by the control of the core. That is, when there is no work to be processed from the core point of view, and the processing of the command using the bus system area is completed, the core sleep and the bus sleep can be entered. If the bus system enters the sleep mode, the core that accesses the bus system is also in the sleep mode, so that a device in the bus system area in the sleep mode is not accessed.

The operation of the sleep mode in the multi-core is described below.

In a multi-core SoC, each core (eg, first and second cores) checks whether the second core has access to the bus of the first core, such as the operation of a single core. I never do that. In addition, when applying a bus sleep mode such as a single core, when an active core accesses an area of a bus system that enters sleep mode, it receives a deadly response or continues to wait for a response. You are in a dead-lock state. In both cases, operating the sleep mode for low power causes problems in SoC operation.

Hereinafter, a conventional method for avoiding the deadlock state described above will be described.

As a method for avoiding the dead-lock state described above, the state of the second bus system to be accessed is checked before the first core accesses the area of the bus system of the second core. do. Then, when the bus system is in sleep mode, the bus system and core to be accessed are restored to an active state through an event such as an interrupt and then accessed. The core of the bus system to enter the sleep mode must write a flag indicating that the sleep mode is in a common register area that both bus systems can access.

1 is a block diagram illustrating a typical Soc with two cores 101, 102 and bus systems 103, 104 connected to each core. 1 has two cores, which may be a DSP or a CPU or the like. 1 also includes a bus system, which is a block for controlling various memories, registers, peripherals, and their access paths connected to a core. In addition, the bus bridge 105 of FIG. 1 is a device serving as a bridge for accessing a device area existing in the other bus system in two different bus systems. The system control block of FIG. 1 also controls and supplies system related signals such as clocks and resets. In addition, the system control block 106 has an interrupt controller (interrupt controller) of each core when there is a common register area having an entire system in a structure having different bus systems. do.

1 is a block diagram of a typical SoC system with two cores 101, 102 and each bus system. One low-power design uses a method of reducing dynamic power through clock-gating (clock gating indicates turning the clock on and off), which uses the clock gating input to each core and bus system. There is a system control block 106 that controls.

In a multi-core SoC, when each core's bus system is in an idle state, each core may put the bus system into sleep mode.

In the case of a single-core, when the bus system corresponding to the core enters the sleep mode, the bus system is not accessed unless it is restored to the active state by an external event such as an interrupt.

However, in the case of a multi-core SoC, when one bus system enters the sleep state, it may be necessary to access the sleep bus system by another core that does not enter the sleep state. In this case, because the bus system is in a sleeping state, the core requesting access cannot receive an appropriate response, causing abnormal operation or dead-lock.

As described above, the following method has been proposed in order to prevent a problem in which a bus system entering a sleep state in a multi-core SoC can be randomly accessed by another core in an active state.

First, a hardware block capable of controlling clock ON / OFF for each core and the bus system corresponding to the core is implemented for each core and bus system as in the case of a single core.

Each core then sets a flag in a register area that all cores can access before putting the bus system corresponding to that core into sleep mode. Make sure to check.

Then, before the active core accesses the bus system area of another core, the flag register area is accessed to check the state of each bus system. If the bus system to be accessed is found to be in sleep, restore the bus system to sleep and then check the flag register to see if the clock on that bus system is active. After checking, access the bus system area.

Restoring a sleeping bus system or core to an active state is possible by an external event, such as an interrupt, which is external to the interrupt control of the sleeping bus system. By adding a path that can generate an interrupt, the clock of the sleep bus system or core is activated by another core.

Various input / output signals and clocks shown in FIG. 1 are embodied by FIG. 2 and the following description.

2 is a circuit diagram illustrating a clock gating technique within the system control block 106 of a conventional multi-core SoC.

Hereinafter, a conventional clock gating technique for solving the problem of deadlock will be described with reference to FIG. 2.

Each core may enter only sleep core or sleep core and bus together. In this case, after entering Core_sleep (Core 1_sleep, Core 2_sleep) or bus_sleep bit (Core 1_bus_sleep, Core 2_bus_sleep) in the system control block 106 to enter sleep, an instruction instructing to enter the sleep mode. In this case, sleep_grant signals Core1_sleep_grant and Core2_sleep_grant are generated on the core side, and if the clock_stop_masking signal is low, core_clock_stop and bus clock_stop signals are generated. When each of the core_clock_stop and bus_clock_stop signals is activated, each clock-gating cell (201, 202, 203, 204) blocks the free-running clock (the clock that is always 'ON') and is supplied to each clock-domain. Turn the clock off. The free_run clock (or free_running clock) is a signal generated in the clock generation block for each clock domain and is a clock before being gated. This clock is always on. The logic inside the system control block operates as a non-gated free_run clock, and the block where the clock should not be stopped uses the free_run clock. In FIG. 2, the gated clock (eg, Gated_core1_bus_clk) is a clock after the free_run clock passes through the gating cells 201, 202, 203, and 204. In addition, the gating cells 201, 202, 203, and 204 are cells that generate a gated clock by turning ON / OFF the actual free_run clock, and gating ON / OFF control is performed by each clock stop signal previously generated (for example, Core1_bus_clk_stop). Is made by). In addition, the sleep_grant signal (for example, Core1_sleep_grant) may process a pre-sleep state when a core supporting sleep mode issues a sleep command, enter a sleep mode, and send a signal such as a sleep grant signal out of the core. It stops the clock after receiving this signal in the block that actually controls the clock. In addition, the sleep grant signal is released by the interrupt signal entering the core to start operation in the sleep mode and inform the outside of the core that the operation mode.

The clock_stop masking signal is generated by an external event, such as a key input from an external input device, or internal interrupt events that occur inside the SoC.If any of these events is enabled, the clock_stop masking signal is generated and the clock_stop signal is low. A low clock is supplied.

In addition, this clock_stop masking signal is input as an interrupt signal of the core, and after receiving an interrupt, releases the sleep_grant signal from the next clock and resumes operation. Each core can control gating of cores and bus systems in its own domain and can release gating by signals generated by external events or internal interrupt events.

Therefore, in order for the other core to access the bus system in the sleep mode, the other core can wake up the core in the sleep state by generating an interrupt in the form of an internal interrupt event signal.

The core, which was asleep by an internal interrupt event generated by the other core, wakes up to allow bus access from the other core and performs idle mode (idle operation), and then enters the sleep mode of the core. In the following, it is necessary to determine 'core sleep') or enter the sleep mode of the core and bus systems (hereinafter referred to as 'core / bus sleep'). If the core has no tasks to perform, it decides whether to enter core sleep or core / bus sleep. To enter the core / bus, it is necessary to check whether the bus system is idle. Since the bus system of the own side is controlled by the corresponding core, it is easy to know whether the bus system is occupied, but access of the own side bus system by the other core occurs arbitrarily. Therefore, it must be determined through flag exchange with the other core in the program. In the system control block 106, a core that wishes to enter a bus sleep (sleep mode of the bus system) by placing a flag register in a register area accessible to both cores and using it is the bus system on its own side. It is necessary to determine whether or not it is occupied by the other core, and whether the core wishing to access the other bus system is determined whether the other bus system is in the sleep state.

The present invention has been proposed to improve the prior art, and an object of the present invention is to propose a multi-core SoC that does not cause a problem when entering the sleep mode.

Another object of the present invention is to propose a multi-core SoC having a sleep mode control method for solving the deadlock phenomenon according to the multi-core.

The present invention, in order to achieve the above object, a first bus system for controlling access to a peripheral device of at least one core; A first core controlling the first bus system; A second bus system for controlling access to peripheral devices of the at least one core; A second core controlling the second bus system; And a first clock control module for determining whether to hold a sleep mode entry of the first bus system according to a forced signal from the second core, and the second according to a forced signal from the first core. And a clock control module including a second clock control module for determining whether to suspend entering the sleep mode of the bus system.

The present invention proposes a multi-core SoC for low power consumption. More specifically, the present invention proposes a multi-core SoC that solves a dead-lock problem that may occur when a bus system of each core enters a sleep mode.

The configuration, operation and features of the SoC according to the present invention will be embodied by one embodiment of the present invention described below.

Hereinafter, the features of the basic deadlock prevention technique to be improved by the present invention will be described.

In multi-core SoCs, the following methods were used to prevent access to the bus system in sleep mode by another active core. That is, the activated core to be accessed generates an interrupt toward the bus system in the sleep mode, turns on the clock of the core and the bus in the sleep mode by the generated interrupt, and then performs the access.

In a single core system (ie a system with a single core SoC), sleep mode is entered when there is no task to process for some time on the core side, where only the core enters sleep mode and the core and bus systems sleep together. There is a case to go into. Once in sleep mode, the system comes back to an active state by external events such as interrupts, which are signals that require processing of some task towards the core in sleep mode. As a result, the clock, which was stopped by the interrupt, is activated, and the core and the bus system are in the sleep mode, and the core is taken out of the sleep mode.

However, cores that are active in a multi-core SoC (hereinafter referred to as 'first core' for convenience of description) are referred to as cores in sleep mode (hereinafter referred to as 'second core') and corresponding cores. An interrupt is generated to wake up the controlled bus system (hereinafter referred to as 'second bus system'). In this case, the first core may request some work from the second core, or may only be for accessing the second bus system in the sleep mode.

The following problem occurs when performing an awakening operation using an interrupt as in the conventional method for accessing the second bus system.

First, even to allow access to the bus system of the second core, i.e., the second bus system, even the second core, which does not need to process special work, must be restored to the activated state. After waking from sleep mode, the second core must handle simple service routines, such as checking the interrupt source and clearing, even if there is nothing special to do with the interrupt for access requests from the first core. If the second core wakes up in an active state even if there is no special work on its own, it is inefficient in terms of low power management because there is less time for entering the sleep mode as a whole.

In addition, since there is no work to be processed and the core and the bus system attempts to enter the sleep mode, it is always necessary to check whether the bus system on the core side is occupied by the other core. To check whether it is occupied, there may be a gap between the time of access, the reading of the actual flag value, the command to allow entry into sleep mode, and the time the actual clock stops and enters the surface. As such, it should be run with a well-defined protocol. In addition, in some cases, probabilistic errors that cannot be solved in software may occur, thereby reducing flexibility in operating a sleep scenario. For example, if you check the flag on your core to enter sleep mode and check the flag to see if it is not occupied, then you are in the process of processing a command to allow you to enter sleep mode, Access can be performed on the core. In this case, after checking if the bus system can enter the sleep mode until the actual sleep mode entry operation is completed, the other core still seems to be able to access because the bus system is still identified as active. However, in this case, deadlock occurs because the bus system you want to access is already in sleep mode.

This embodiment does not wake up another core (core in sleep mode) via an interrupt to access the bus system (bus system in sleep mode on a multi-core SoC), but on the remaining cores (the active core you want to access). Newly designed and added clock control blocks that directly control the ON / OFF clocks of other cores and other bus systems.

The clocks supplied to the respective cores and the bus system are gated by the core_sleep (Core1_sleep, Core2_sleep) signal and the bus_sleep (Core1_bus_sleep, Core2_bus_sleep) signal as in the related art, so that the clock is turned on / off. The Core_sleep and bus sleep signals are generated by executing a series of commands related to entering sleep mode when each core has no work to process.

When the core is in idle mode and no work is using the bus system, the core can enter sleep mode with the bus system.

In this embodiment, when checking whether the bus system is used to enter the sleep mode together with the bus system, access by the other core does not need to be checked. This is referred to as the other core (hereinafter referred to as 'B core') regardless of the clock control of the core (hereinafter referred to as 'A core') and bus system (hereinafter referred to as 'A bus system') itself to enter sleep mode. This is because the clock control of the A bus system is performed by the "

Core B wishing to access an area of the A bus system sets the clock of the A bus system to Forced ON before accessing it. Setting Forced_ON means that the forced signal received from the B core is set to on. Because of this, even when a command (sleep command) is executed to allow the A core and A bus systems to enter sleep mode, the A bus system does not turn off the clock due to the Forced_ON signal, so the bus of the A bus system remains active. There is. Therefore, even while accessing the area of the A bus system from the B core while executing a command to allow the A core and the A bus system to enter the sleep mode, the bus to the A bus system is set by the Forced_ON signal set before the access. Sleep is put on hold, which solves the problem.

Upon completion of the access, the B core releases the Forced_ON signal to turn off the clock of the bus system in which the sleep commands for the A core and the A bus system are issued. The A core and / or A bus system can then be woken up by external events such as interrupts. In addition, when the B core attempts to access the A bus system again while the clock of the A bus system is turned off, the clock of the A bus system is turned on through the Forced_ON signal. Thus, when accessing only the area of the A bus system that is sleeping, not requesting any work from the A core, wake-up interrupts turn on the A bus system and the A core clock. This feature enables only the clock on the A bus system via the Forced_ON signal without the need to restore the entire system to an active state. Since core B releases the Forced_ON signal after accessing the area of the bus A system to turn off the clock of the bus A system, the core A returns to the active state to service the access of core B. Can be solved.

A-Core and A-bus systems that have already gone to sleep can be woken up from sleep mode as in the conventional way by means of a wake-up interrupt factor. Wake-up interrupt elements can include timer interrupts, external events such as keystrokes such as a keypad, interrupts by the other core, and the like.

3 is a block diagram showing the structure of a system control block of a multi-core SoC according to the present embodiment. 3 illustrates a new clock gating technique that provides a way for the other core (e.g., B-core) to be forced on regardless of the state of the other bus system (e.g., A bus system). Show the clock gating scheme. That is, the above-mentioned forced signal is set to on to force it to the state of the bus system. In FIG. 3, the forced signals are Force_on_from_core2 and Force_on_from_core1. Each signal is received from the other core to force a specific bus system on.

Applying the proposed clock gating scheme to the system control block, the B core accesses the A bus system when determining whether a core in idle (eg, A core) should enter the bus sleep. Regardless of whether you do so, you can perform bus sleep procedures for both A-core and A-bus systems.

If the bus on the A bus system is being used on the B core side, the clock on the A bus system side will remain supplied without being gated even though the bus sleep procedure for the A core and the A bus system is being performed. This is because the forced_ON signal was set to active before accessing the A bus system on the B core. That is, according to block 301 of FIG. 3, the bus_clock_stop signal (for example, Core1_bus_clk_stop) generated by the instruction to allow sleep performed in the core A is masked and changed to a low state, and a gate clock is made. I do not lose.

When wake-up, the clock gated by an external wake-up event or an internal interrupt event is released and the core resumes operation after the sleep grant signal (sleep_grant) is released. Is the same as the existing system.

In order for B core to request some work from A core, it can wake up A core by generating an internal interrupt event. However, if core B did not request any work from core A, but only accessed the A bus system area, the existing architecture had to wake up core A through an internal interrupt event. In this case, the A core needs to decide whether to enter the sleep mode by checking the occupancy of the A bus system again after the access of the B core.

However, in the proposed architecture, when the bus system in the sleep mode, that is, the A bus system is accessed from the B core, the forced_ON signal is set without checking whether the A bus system is in sleep mode and wake-up. . The bus_clock_stop signal (for example, Core1_bus_clk_stop) is masked by the forced_ON signal to turn on the gated_bus_clock signal (for example, Gated_core1_bus_clk) that is blocked by the clock_gating cell 302. This allows access to the A bus system area without waking the A core from the B core.

After completion of the access, the B core which set the forced_ON signal releases the masking of the bus_clock_stop signal by clearing the setting so that the gated_bus_clock is turned off again by the gating cell 302. Therefore, the B core only needs to be turned on / off while accessing the stopped bus clock through the setting / clearing of the forced_ON signal when requesting only access to the A bus system without requesting any work toward the A core.

With the new architecture, there is no need to check whether the bus of the A bus system is occupied by the B core on the A core side to enter sleep mode. In addition, the B core, which wishes to access the A bus system area, does not need to perform a series of software controls to check whether the A bus system is asleep and generate an interrupt when it is asleep to wake up the A core.

The A core and the A bus system may enter the sleep mode when there is no work to be processed and the processing of the command using the A bus system issued by the end is completed. In addition, the B core that wants to access the A bus system always sets the forced_ON signal to turn on the A bus system's clock before accessing it regardless of whether the A bus system is turned on or off. After access, clear the forced_ON signal and return control of the bus clock_stop signal to the A core.

It will be apparent to those skilled in the art that the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Accordingly, the above detailed description should not be construed as limiting in all aspects and should be considered as illustrative. The scope of the invention should be determined by reasonable interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

The effects of the present invention are as follows.

According to the present invention, an active core, which wishes to access a bus system that has entered a sleep state, does not need to check the state of the bus system that is to be accessed.

In other words, in multi-core SoCs that support sleep mode, when the active core accesses the other bus system, it can eliminate processes such as checking the other bus state and wake-up through interrupts during sleep. This has the beneficial effect of reducing time.

In addition, there is no wake-up section to allow bus system access even when the core has nothing to do, thus maximizing sleep mode operation to reduce the SoC overall operating power.

In addition, it is possible to enter the core and bus system sleep mode without having to check whether the other side of the bus system accesses, so it is easy to manage and operate the sleep scenario, and between the sleep entry time, sleep release time and access check time. Probabilistic errors due to spaces can be eliminated.

Claims (5)

A first bus system controlling access to a peripheral device of at least one core; A first core controlling the first bus system; A second bus system for controlling access to peripheral devices of the at least one core; A second core controlling the second bus system; And A first clock control module for determining whether to hold a sleep mode entry of the first bus system according to a forced signal from the second core, and the second bus according to a forced signal from the first core A clock control module including a second clock control module that determines whether to suspend entering a sleep mode of the system Multi-core system on a chip that includes a sleep mode that includes. The method of claim 1, The first clock control module, It is determined whether the first bus system enters a sleep mode according to a sleep signal from the first core and a control signal generated by a specific event. Suspend entering the sleep mode of the first bus system whenever the forced signal from the second core is set to on Multi-core system-on-chip supporting sleep mode. The method of claim 1, The second clock control module, It is determined whether the second bus system enters the sleep mode according to a sleep signal from the second core and a control signal generated by a specific event. Always suspend entering the sleep mode of the second bus system when the forced signal from the first core is set to on Multi-core system-on-chip supporting sleep mode. The method of claim 1, The clock control module, Determining whether to enter the sleep mode of the first core according to a sleep signal from the first core and a control signal generated by a specific event; Multi-core system-on-chip supporting sleep mode. The method of claim 1, The clock control module, Determining whether the second core enters the sleep mode according to a sleep application signal from the second core and a control signal generated by a specific event. Multi-core system-on-chip supporting sleep mode.

Images