CN101495940A - System with multiple hardware blocks and method of operating the same - Google Patents

Abstract

The present invention relates to a system having a plurality of hardware blocks, and a method of operating the system, in which power to each hardware block is independently controlled according to whether the respective hardware block needs to be used. A counter is provided in the respective device driver of each hardware block, the counter being configured to increment each time a task requests use of the respective hardware block and to decrement each time the task stops use of the respective hardware block. The value of the counter is then used to control whether the corresponding hardware block is powered on or off.

Description

System with multiple hardware blocks and method of operating the system

The present invention relates to a system with a plurality of hardware blocks and a method of operating the system, in particular, said system and method are suitable for use in situations where power consumption is a concern, such as in demodulators of digital television receivers .

It is known that in systems such as demodulators for digital television receivers it is necessary to operate a number of hardware blocks. The system can run several different tasks that use these hardware blocks at different times. Especially if the system is provided in a battery operated device, eg in a digital television receiver conforming to the Digital Broadcast Handheld (DVB-H) standard, the power consumption will be very important.

This application is based on the realization that by controlling hardware blocks, it is possible to contribute to power saving.

According to the present invention, there is provided a method for an operating system having a plurality of hardware blocks, the method comprising independently controlling power to each hardware block according to whether the corresponding block is required to be used.

According to the present invention, there is also provided a system having a plurality of hardware blocks configured to independently control the power supply to each hardware block according to whether the corresponding hardware block is used or not.

Thus, a particular hardware block is only powered on when it is being used as part of a particular service or task running in the system. At any other time, the hardware block can be powered down, thereby reducing power consumption of the system.

Preferably, the system includes device drivers for respective hardware blocks and is configured to support a plurality of tasks, each of which uses one or more hardware blocks by communicating with the respective device drivers.

With this approach, it is relatively difficult to determine whether a hardware block should be powered on or off, and thus would require a lot of processing. Among multiple tasks, and indeed among the services used by those tasks, it is possible for any one task or service to use a particular block of hardware at some time. When a specific task no longer needs to use a certain hardware block, it does not mean that said hardware block can be powered off, because other tasks may also need to use this hardware block.

Preferably, a counter is implemented in each respective device driver, the counter being configured to increment each time one of the plurality of tasks requests to use the corresponding hardware block, and configured to be incremented each time one of the plurality of tasks stops using the corresponding hardware block. Decrements when hardware blocks.

Doing so provides an extremely efficient and advantageous way of determining whether a particular piece of hardware should be powered up or down. For example, if the initial value of the counter is 0, it is easy to determine that the corresponding hardware block should be powered up when the counter is non-zero.

Preferably, the counter is implemented as an application programming interface.

Doing so provides a simple implementation of what would otherwise be a very complex process.

Preferably, the counter provides an output for powering down the respective hardware block when the counter indicates that there are no outstanding requests for use of the respective hardware block. By this, the implication is that the counter can similarly provide an output for energizing the corresponding hardware block when the counter indicates that the corresponding hardware block needs to be used.

Preferably, the counter has an initial value of zero, so that the output can only energize the corresponding hardware block when the counter has a non-zero value.

The system may also include a hardware clock block, wherein the block has: a clock output for a system clock signal, a power input for receiving a corresponding output of the counter, a clock output for a corresponding hardware block, and a plurality of corresponding logic gates. Each respective logic gate is coupled to a clock input, a respective power input, and a respective clock output, and is configured to selectively provide a clock signal to the respective clock output based on the power input.

It should thus be understood that a hardware block is powered down by removing it from the system clock signal. At this point, it should be understood that most power consumption is due to clock transitions. The output of the counter can easily be used to control whether the system clock signal is provided to the corresponding hardware block. The hardware block may include at least one of a timer, UART, SPI, SDIO, tuner, demodulator, filter, and MPE-FEC.

The timer provides an indication of the system time and allows the alarm to be configured to go away after a predetermined amount of time has elapsed. A UART (Universal Asynchronous Receiver/Transmitter) is a standard serial communication data link used in a DVB-H receiver to track a log of activity to eg a computer for debugging. SPI (Serial Peripheral Interface) is an interface used to interconnect devices such as integrated circuits used in DVB-H receivers to communicate with and be controlled by the host application processor (that is, receive commands and send commands containing results) response) standard synchronous communication data link. As a viable alternative to SPI, SDIO (Secure Digital Input/Output) is a standard for connecting accessory devices to the host application processor used in DVB-H receivers. A tuner is an analog integrated circuit used to extract and isolate a specific radio frequency channel in the spectrum and convert it down to baseband (that is, bring the carrier frequency to 0 Hz). Demodulators are digital integrated circuits used to demodulate DVB-H signals. Filters are digital integrated circuits used to extract specific data packets that are a subset of or from an MPEG-2 transport stream, where these data packets are identified by their Packet ID (PID) and Table ID. MPE-FEC (Multiprotocol Encapsulation - Forward Error Correction) is a standard way of encapsulating any type of data (eg IP packets in the case of DVB-H) in an MPEG-2 transport stream. FEC is a method involving the encapsulation of additional codes in the MPEG-2 transport stream at the transmitter side and the use of these codes at the receiver side to detect and correct transmission errors in the MPE data.

The system may be provided as a demodulator, eg as an interchangeable module of an integrated circuit. Likewise, the system can also be provided in a digital television receiver, for example as a demodulator inside the receiver. Preferably, said demodulator and/or receiver conform to the DVB-H standard.

The present invention also provides a computer program for implementing said processing. A computer program such as an application program interface may be provided for use in the described device drivers.

The invention will be more clearly understood from the following description, given by way of example only, with reference to the accompanying drawings, in which:

What Fig. 1 has described is the example that can realize the equipment of the present invention;

Fig. 2 has schematically described a system using the present invention;

Figure 3 provides an alternative schematic diagram of an embodiment of the present application;

What Fig. 4 described is to be used for the reset processing of Fig. 3 device;

What Fig. 5 has described is the cancellation (abort) process for Fig. 3 apparatus;

Figure 6 schematically depicts examples of tasks, services and device drivers working in the apparatus of Figure 3;

Figure 7 schematically depicts a device driver;

Fig. 8 schematically describes the power control of the hardware device;

Figure 9 depicts the various power-on and power-off states;

Figure 10 depicts the scheme of Figure 6 with additional time sliced tasks; and

Figure 11 depicts the relative priority of the various tasks.

The invention is intended to be applied in a mobile television receiver (2), such as the mobile telephone device (2) shown in Fig. 1 . Such a mobile television receiver may operate according to the DVB-H (Digital Video Broadcasting-Handheld) standard used in Europe.

The illustrated receiver (2) includes a display (4) for displaying images of received television programs, and a user interface (6) allowing the user to operate or control the receiver (2), wherein the user interface includes, for example, a plurality of Press the button (8). An audio reproduction of the audio portion of a received television program may be provided to the user via a pair of headphones (10).

Figure 2 schematically depicts a part of a receiver (2) used in the process of receiving digital television signals.

In the illustrated embodiment, the receiver (2) includes its own applications processor or host (12), which can be used to operate television functions and other functions of the receiver (2), such as Telephone operation when using the receiver (2) also as a telephone. In this regard, the application processor (12) may include various middleware (14) and associated memory for storing such middleware.

Also, as shown, the receiver (2) includes a module (16) specifically configured to handle television functions. The module (16) can be manufactured and sold separately and provided for use in a number of different receivers. Although not depicted, the module (16) is configured to output video data for display on the display (4) and audio data reproduced by the earphone (10). Under the control of the user interface (6), by means of the application processor (12) it is possible to control the module (16), for example to change the TV channel.

An antenna (18) is provided for receiving a plurality of television signals modulated on various radio frequency carriers.

Inside the module (16), a tuner (20) is configured to tune a particular carrier frequency and provide the received modulated signal to a demodulator (22). The demodulator (22) includes a number of hardware units (24) (in addition to the tuner (20)), such as demodulator and filter blocks. These components work under the control of firmware (26) previously downloaded from the application processor (12), thereby providing complete operation for the module (16) and outputting audio/video signals as required.

Figure 3 provides an alternative schematic view of the structure of the module (16).

A bus (28) allows communication between the blocks of the module (16). A tuner (20) and other hardware blocks (24) are then connected to communicate with the processor (30). A serial peripheral interface (32) is also provided here to communicate with the application processor (12) of the receiver (2). Additionally, ROM (34) and RAM (36) are provided here.

Fig. 4 is a flowchart schematically describing the process that takes place in the device of Fig. 3 during the start-up of the module (16). In step S10, where a reset signal is provided to the module (16) and processor (30). This will cause the processor (30) to start executing instructions at address 0x0000, which is physically mapped to the ROM (34), and which itself contains the application processor ( 12) Download the bootloader code. At step S12, using the serial peripheral interface (32), the boot loader receives boot configuration parameters from the application processor (12) and stores them in RAM (36). These parameters may include, for example, the bandwidth of the device (eg, 5, 6, 7 or 8 MHz) and the frequency of the receiver source clock.

Then, at step S14, the boot loader downloads the firmware (26) from the application processor (12) and saves it in RAM (36). The downloaded image saved in RAM (36) will include the operating system for that module (16). Obviously, for the reasons discussed, this process will take a significant amount of time, eg around 200ms.

At step S16, the ROM bootloader remaps the memory so that address 0x0000 now physically points to RAM (36) instead of ROM (34). In step S18, the processor (30) is caused to begin executing again the instruction at address 0x0000, which will now (due to step S16) be physically mapped to RAM (36), which itself contains firmware(26).

At step S20, the firmware stored in RAM (36) causes processor (30) to start the operating system, also stored in RAM (36).

In step S22, the firmware (26) retrieves those configuration parameter values stored in step S12. Preferably, these parameter values are stored at predetermined or fixed locations in RAM (36). Then, these values will be entered into the memory as needed, whereby the hardware blocks including the tuner and filter etc. can be initialized in step S24. In particular, the firmware uses these configuration parameters during hardware initialization.

Finally, appropriate threads for performing various tasks are created in step S26 (discussed further below). At this point, the module (16) will still be waiting for commands from the application processor (12) to tune or create filters for the appropriate TV program or the like.

During use of the receiver (2), it is time consuming if a large number of hardware elements or blocks (20, 24) need to be reinitialized. For example, it may be decided to change the RF channel, ie to change the carrier. In fact, if the received signal is lost, the application processor (12) can decide to move to a different carrier instead of just waiting for reception to resume.

It can also be arranged for the processor (30) to release and then restart each hardware block (20, 24) individually. However, the present application for the first time recognizes that this process is very complex and time-consuming. The present application also contemplates the possibility of reapplying the reset process described with reference to FIG. 4 . This process is a very simple and effective one. However, this process may be very time-consuming. In addition, referring to step S14 as described above, downloading the firmware to RAM (36) is time-consuming.

This application considers for the first time the use of a cancel command, where unlike the entire reset process of operating Figure 4, this command will cause the module (16) to stop any and all current operations and release all resources without requiring the processor (30) to separate Stop every single operation. As such, the firmware (26) of the control processor (30) does not stop operation and release resources alone, but simply reinitializes the operating system core.

Fig. 5 is a flowchart schematically describing the processing that occurs upon receipt of a cancel command.

At step S30, a cancel command is sent from the application processor (12) to the module (16).

In response, at step (S32), the firmware not only kills all threads, timers and events, but also kills the mutex, by means of which simultaneous operations performed by the two threads are blocked. In this way, all processes executed by the module (16) will stop their ongoing work, and all operating system memory structures will be cleared. In practice, a portion of memory contains operating system data for active threads, whereby the operating system will know which threads are active. When the firmware terminates all threads, it does not necessarily delete all stored threads, but only clears the memory block used by the operating system to store the list of active threads. From this, the operating system doesn't see any threads that ever existed. Obviously, this processing is almost instant.

In step S34, the firmware starts the operating system again. In other words, it reinitializes the boot function, and performs processing similar to S20 in FIG. 4 .

Then, compared with FIG. 4, there is no need to execute step S22, because there is no need to re-store the configuration parameters here; these configuration parameters have been correctly saved in the memory. At this point, it is worth mentioning that if a different configuration parameter needs to be used, such as using a different bandwidth, then a full reset process is required.

Then, the process jumps to step S36, where the firmware will initialize the hardware. Step S36 of the cancel process is simpler than step S24 of the reset process. In particular, those hardware involved in communication, especially the serial peripheral interface (32), are not reinitialized. In the preferred embodiment, the serial peripheral interface (32) is not reinitialized since it handles communications with the application processor (12) that involve cancel processing. On the other hand, if the processing state is kept in memory and restored to the serial peripheral interface (32) after initialization, then a complete hardware reinitialization similar to step S24 in the reset process can be performed.

In step S38, an appropriate thread is created in a similar manner to step S26 in the reset process. Furthermore, in step S40, the firmware sends a cancel response to the application processor (12) via the serial peripheral interface (32), thereby confirming to the application processor (12) that the cancellation process has been completed.

The following items are not reinitialized: module configuration (done in step S22), VIC (Vectorized Interrupt Controller). Certain other blocks are only partially reinitialized: demodulator, SPI and SDIO controllers (for host protocol communication), and DMA (direct memory access) controller.

Thus, there may be provided a demodulator device and a method for operating the demodulator device in which the operating system kernel is bootstraped to stop the receiver in order to avoid shutdown by releasing a single resource. The module (16) may be provided as a demodulator chip, such as a DVB-H demodulator chip. Embedded firmware can be provided for DVB-H demodulator chip.

This general approach is applicable to any software system that performs a single elementary operation, whether embedded or not; if the state of the system after canceling or stopping the current operation is equivalent to the initial state after power-up, then This general approach is especially applicable.

As is clear from the above, the receiver (16) implements a communication protocol that enables the host application processor (12) to control it. This protocol contains commands for configuring and starting the main functions of the receiver (16), such as scanning the spectrum to find DVB-H signals, tuning to a specific frequency and setting SI and MPE filters, and receiving payload data. As with any control system, the protocol also includes commands for stopping operations, such as stopping ongoing spectral scanning processing, and stopping and releasing (clearing) SI and MPE filters.

However, the receiver (2) implements a communication protocol which is novel in that: 1) an additional #ABORT command is defined which causes the receiver to abort any and all current operations and release all resources without requiring the host application processor to individually abort each individual task, and 2) provide a firmware implementation of the #ABORT command itself that does not individually abort operations and release resources, but instead restarts Initialize the operating system core.

For example in preparation for tuning to a different frequency or creating a different set of SI and MPE filters, the #ABORT command provides a quick and easy way for the host application processor (12) to return the receiver (16) to a clean state Way. Furthermore, if not having to cycle through all operations to stop them and not having to release all resources, the code size will be reduced and the embedded firmware will be made smaller, thus saving embedded memory.

In one particular embodiment, the receiver software (previously described as firmware) implementation runs on ThreadX, an embedded real-time core operating system from Express Logic, Inc. During the initialization process of the ThreadX system, several steps can be distinguished:

initialization process

0. System reset (interrupts are disabled)

1. Jump to the image input point

2. Development tool initialization (including global variable initialization) (this step can be removed in some embodiments).

3. main(): Execute preparatory processing (this includes hardware initialization such as setting a timer) (this step can be completed in combination as an image input point, so there will be no main() function).

4. Start ThreadX by calling tx_kernel_enter().

5. Call tx_application_define() by ThreadX:

a. Create system resources (application threads, mutexes, event flags, timers)

b. perform device initialization, and

c. Call the initialization method of the software module.

6. Enter the thread scheduling loop (interrupts are enabled).

After this initialization process, the system is in a known state X where it can start receiving commands from the host.

On receipt of the #ABORT command, force the system into the same known state X by re-executing part of the initialization sequence described above.

Cancellation processing:

0. Host sends #ABORT.

1. In the timer thread:

a. Disable interrupts

b. Discard all OS resources (application threads, mutexes, event flags, timers) by reinitializing OS resource structures to 0.

c. Set the PostABORT flag (a global variable that can be queried by module implementations to identify initialization processing following #ABORT)

The state now matches the state after initialization step 3.

2. Restart ThreadX by calling tx_kernel_enter().

3.ThreadX will call tx_application_define() to:

a. Recreate system resources (application threads, mutexes, event flags, timers)

b. Re-execute device initialization

c. call the initialization method of the software module, and

d. Send a response about #ABORT to the host.

4. Enter the thread scheduling loop (with interrupts enabled).

As part of step 3.c, the implementation of the software module should take into account that initialization of global and static variables is only performed in step 2 of the initialization process. If any global or static variables are reinitialized in anticipation of #ABORT, then this processing should be performed explicitly in the initialization method of the particular module.

Fig. 6 schematically depicts an example of a software side in a digital television reception, which can work, for example, in a module such as the module (16) described above.

At the top level, the various functions being performed by the modules (16) are illustrated as threads or tasks (40). Each of these threads and tasks uses one or more services (42) available from the layer below it. In at least some circumstances, the services (42) will require the use of hardware (20, 24) in the module (16) in order to perform the functions of the services (42) for these tasks. For this purpose, each service may use one or more device drivers (44) corresponding to the respective device or hardware block (20, 24).

For the first time, the application takes into account the power consumption of different devices or hardware blocks (20, 24). When these devices or hardware blocks (20, 24) are turned on, they will consume power, and the application believes that it will be beneficial to turn off these devices or hardware blocks (20, 24) when they are not in use , especially for battery-operated devices. For example, it is quite common for digital television receivers to receive and process blocks of data in bursts. Consequently, various hardware blocks or devices may or may not be in use at different times during the reception and processing of these bursts.

Referring again to FIG. 6, it should be understood that for different tasks and services running concurrently, different tasks and services may require devices and device drivers at the same time. This makes it difficult to determine whether a particular device or hardware block (20, 24) should be powered on or off at any one time. In particular, individual tasks will work independently of each other, and likewise, individual services will work independently of each other, whereby in general, one task or one service will not know which devices are being used by other tasks or services or hardware.

As a solution to this problem, the present application proposes the use of a power management application programming interface (API) (46) for each driver (44). This is schematically depicted in FIG. 7 .

In fact, the power management API includes counters that are incremented each time the service (42) requests to use the corresponding device or hardware block (20, 24), and will be stopped each time the device or hardware block is used (20, 24) decrements when. To the apparatus, it should be understood that as long as the counter has an incremented or non-zero state, there will be an indication that at least one service requires the use of the corresponding device or hardware clock (20, 24), whereby it should Stay powered up. The corresponding device or hardware block (20, 24) may be powered down only when the counter is at zero value or not incremented.

As schematically depicted in Figure 7, the power management API (46) provides a power signal (48) to the corresponding device or hardware block (20, 24). In response to this power signal (48), the corresponding device or hardware block (20, 24) can be powered on or off.

The power signal (48) can be used in a number of different ways to control the power of the corresponding device or hardware block (20, 24).

Figure 8 schematically depicts an arrangement in which a power supply signal (48) is used in conjunction with a master clock signal (50) and a clock block (52).

There are two main sources of power consumption in a device or hardware block (20, 24). First, each transition according to the clock signal has a relatively significant power consumption. Second, there is leakage even when the clock signal is not considered. For example, according to a preferred embodiment as shown in FIG. 8, all power to a particular device or hardware block (20, 24) may be turned off, but only the clock for the corresponding device or hardware block (20, 24) is stopped to prevent the The power loss caused by the conversion, which cannot meet the needs.

In the embodiment shown in Figure 8, the clock signal (50) is provided to the hardware blocks (20, 24) by means of a clock block (52). This can be implemented as a hardware block comprising a plurality of gates (54) respectively corresponding to the hardware blocks (20, 24). Each gate is enabled or disabled according to a corresponding power signal (48). Thus, the power management API (46) of the driver (44) controls whether the clock signal (50) is provided to the corresponding hardware block (20, 24).

An OR or AND gate can be used. For the AND gate, if the power signal (48) is set to 1, then the hardware will be powered on; if it is set to "zero", the hardware will be powered off. For the "OR" gate, if the power signal (48) is set to "1", it will hold the clock block at "1", thereby freezing the clock and thereby powering down the block; if the power signal ( 48) Set to zero, then the block clock will be made equivalent to the system clock, and thus the block will be powered on. Preferably, the hardware uses OR gates, and thus must invert the power signal (1 for off, 0 for on).

It should be appreciated that such an arrangement may be used in any circuit in which there are multiple individual hardware blocks that can be selectively powered on and off. Such an arrangement is particularly useful in digital television receivers, such as DVB-H receivers, or in modules such as those used in such receivers (16). However, it also has other applications, for example in mobile phones or personal computers.

Thereby a system and method of operating the system, in particular using a reference count, can be provided to save power by disabling the clocks of individual hardware blocks that are not needed. This approach is applicable to any system where the power states of hardware blocks can be individually controlled and used asynchronously by multiple software tasks or threads.

For power management, instead of having a separate main power state (on or off), the receiver hardware (20, 24, 52) will allow individual control of the power of each block (20, 24) in order to save more much electricity. For example, once a burst is received and stored in MPE-FEC memory (24), the tuner (20) can be turned off while the burst is error-corrected and transmitted to the host or application processor (12), A demodulator (24) and a filter block (24). Only after that, the MPE-FEC block is turned off. As noted above, difficulties in embedded firmware implementations stem from the fact that the power state of a single hardware block (20, 24) may depend on the activity of multiple tasks (40). For example, a tuner can be used by an interface handler (or interface handler task (40)) to execute SCAN commands, and it can also be used by a time slicer (or time slicer (40)) to receive bursts. Alternatively, the MPE-FEC may handle parallel IP services.

To simplify implementation, each device driver (44) can independently manage the power state of the hardware blocks it controls. In this regard, examples of synchronous power management APIs are as follows:

Request the device to keep its power state on POWERED_ON Err_t DrvXXX_PowerUp() Give up staying on this power state Err_t DrvXXX_PowerDown()

The client or service (42) will call the PowerUp() function to indicate that it needs to keep the device's power state at POWERED_ON. If the device (20, 24) is not already on, the driver (44) will immediately turn on the device. Then, the client or service (42) will call PowerDown() when the hold can be relinquished. In practice, however, the device's power state will only switch to POWERED_OFF if no other clients or services (42) remain powered on. This processing is accomplished by having the driver (44) maintain a power state counter. The state is initialized to 0, and is incremented each time PowerUp() is called, and decremented each time PowerDown() is called. When the counter value is zero, the device (20, 24) will be turned off.

Some services (42) (tuning, SI extraction and IP extraction) will implement the same API. Each device driver implements a power management API, and a service or task can control the power state of a corresponding hardware block by using the API. Only system tasks need to have a view of when, for example, the tuner and demodulator need to be powered on. For example, the tuning service knows that the tuner and demodulator blocks must be powered on to perform tuning operations. However, it does not know when these blocks can be powered down, which may be at the end of receiving the current burst (ie time slice), only the IP receive task knows this time.

In a preferred firmware architecture, tasks do not directly access device drivers and their APIs, but only through intermediate service blocks in the service layer. Preferably, there should be a way for the service to forward power management requests from the task to the device driver. This is accomplished by having the service implement the same power management API as the device driver.

In a service, the power management API is implemented in the same way as it is in a device driver, that is, it is implemented with reference counting. The only difference here is that instead of controlling the power signal, the service calls the underlying device driver's PowerUp() and PowerDown() functions when the reference count is non-zero or zero, respectively.

As an example, with the above API, the time slicer task shown in Figure 6 can be easily implemented as shown in the following pseudocode:

Repeat forever:

SrvTune_PowerUp()

SrvTune_AcquireSignalLock()/*asynchronous*/

SrvSi_PowerUp()

Srvlp_PowerUp()

SrvIp_ReceiveBurst() /*Asynchronous*/

SrvTune_PowerDown()

SrvSi_PowerDown()

SrvIp_ProcessBurst() /*Asynchronous*/

SrvIp_PowerDown()

RTOS sleep until SrvIp_GetNextTimeSlice()/*block*/

This application proposes a new system in which the power states of individual hardware blocks (20, 24) used in combination by multiple software tasks can be controlled by disabling the individual clock signals of the individual hardware blocks (20, 24) to control independently. In the lowest software layer (device driver) (44), when 1) there are multiple software tasks sharing the same hardware resource; and 2) when multiple software tasks use said hardware resource asynchronously (and need to power it on) , a reference count can be used to determine when a hardware block can be powered on or off.

A standard power control reference count API can be implemented not only in the driver layer, but in all software layers above it, so that the top layer does not have to know which hardware blocks are used indirectly through function calls to the middle layer.

In this way, power can be saved in a multitasking multithreaded system. Furthermore, the architecture and implementation of the system can be simplified because a certain global state does not need to be queried or modified by all software elements utilizing power-controlled hardware blocks.

The following example is based on the embodiment of Figures 2 and 6, which assumes that IP extraction mainly requires the use of three main hardware elements, namely, a tuner/demodulator block, a transport filter block, and a FEC frame controller block . The software architecture includes tasks on top of the services on top of the drivers.

As mentioned above, each hardware block (20, 24) is controlled by a driver (44). A hardware block (20, 24) implementing a power management function has its PowerUp() and PowerDown() function pair. Each PowerUp() function counts the number of times it is called, the first time it is called the hardware block will be powered on and the counter usage will be incremented. And all subsequent calls to that PowerUp() will just increment the usage counter. PowerDown() works in the same way, but it decrements its usage counter until it reaches 0, at which point the hardware (20, 24) is actually powered down.

As an example, the hardware blocks and their power control functions are given below.

The tuner block needs to be powered on before any other blocks. The demodulator block also needs to be active before data can be extracted. In this example, for simplicity of illustration, it is assumed that the tuner and demodulator blocks are coupled together. However, the tuner and demodulator blocks can have their own PowerUp() and PowerDown() functions in order to save power.

The transmit filter clock can be activated or deactivated to save power by using the DrvDemux_PowerUp() and DrvDemux_PowerDown() functions.

The FEC frame controller clock can be activated or deactivated to save power by using the DrvFec_PowerUp() and DrvFec_PowerDown() functions. The FEC block requires the transmit filter block to be active in order to actually receive data, so the DrvFec_PowerUp() and DrvFec_PowerDown() functions also internally call the DrvDemux_PowerUp() and DrvDemux_PowerDown() functions respectively.

As mentioned above, software functions (non-hardware specific functions) are implemented in services (42) using drivers (44). These services (42) may also have PowerUp() and PowerDown() functions that are called by tasks using these services. Typically, they are also implemented using a usage counter and calls to the driver's power control functions.

With this architecture, sophisticated power control can be easily achieved for multiple IP extraction processes working together with SI extraction. For every IP filtering extraction process running from a task, whenever it needs certain resources, it will power on said resources, when these resources are no longer needed, it will power off these resources, here, The key architectural point is that each IP or SI filter is treated independently, and each IP or SI filter uses the power control function of each shared resource.

The following is an example of power usage for the tuner/demodulator, demux, and FEC frame controller, assuming that two IP filters work simultaneously and share hardware resources for a certain period of time. Figure 9 depicts the power counter usage values for the three master drives, and below shows the pseudocode for two independent services running concurrently, and the values in parentheses represent each Drive's power usage counter.

IP0 IP1 SrvIp_GetNextTimeSlice-＞Sleep DeltaT_0 msecSrvTuning_PowerUp-＞DrvTuner_PowerUp      (0-＞1)SrvTuning_TuneSrvIp_PowerUp-＞DrvFec_PowerUp        (0-＞1)-＞DrvDemux_PowerUp      (0-＞1)SrvSi_PowerUp-＞DrvDemux_PowerUp      (1-＞2)SrvIp_ReceiveBurstSrvTuning_PowerDown-＞DrvTuner_PowerDown    (2 ->1)SrvSi_PowerDown-＞DrvDemux_PowerDown (4-＞3)SrvIp_PowerDown-＞DrvDemux_PowerDown (3-＞2)-＞DrvFec_PowerDown (2-＞1)SrvIp_Proces sBurst SrvIp_GetNextTimeSlice-＞Sleep_DeltaT_1 msecSrvTuning_PowerUp-＞DrvTuner_PowerUp      (1-＞2)SrvTuning_TuneSrvIp_PowerUp-＞DrvFec_PowerUp        (1-＞2)-＞DrvDemux_PowerUp      (2-＞3)SrvSi_PowerUp-＞DrvDemux_PowerUp      (3-＞4)SrvIp_ReceiveBurstSrvTuning_PowerDown-＞DrvTuner_PowerDown    (1- ＞0)SrvSi_PowerDown-＞DrvDemux_PowerDown (2-＞1)SrvIp_PowerDown-＞DrvDemux_PowerDown (1-＞0)-＞DrvFec_PowerDown (1-＞0)SrvIp_ProcessBurst

As will be discussed below for certain embodiments, in a device such as module (16) of Figure 2, multiple tasks are required to be performed simultaneously or at least in an overlapping fashion. For example, after FIG. 6 , as shown in FIG. 10 , there may be multiple time slicer tasks, and each time slicer task will operate a corresponding IP (Internet Protocol) receiving process. Each time slicer task may have its own corresponding set of services in use (e.g. tuning, S/PSI:fetch and IP:fetch services), and as shown, more preferably share the same set of services . However, it is necessary to provide some system which allows all tasks to work inside the module (16) at the same time.

It is well known that separate tasks can be mapped to corresponding threads if a real-time operating system is available. A memory area is provided with a stack for each respective thread, and each thread is handled independently of all other threads, wherein said stack allows the operating system to provide resources in module (16) time shared. In particular, the stack allows detaching a thread in preference to other threads at any convenient time, and returning it when possible.

Thus, the tasks shown in FIG. 10 can be provided with separate corresponding threads, namely the idle thread, the interface handler, the signal locker, and the four time slicers.

Unfortunately, using threads in this way also requires the use of corresponding stacks that require memory. In most devices using a real-time operating system, there is often enough memory in there to make the need for a stack irrelevant. However, for devices such as module (16) in Figure 2, which are considered for handheld television reception, it can be expected that their resources in terms of memory are very limited.

Alternatively, it is possible that all individual parts of a task can be combined together as a single state machine. Doing so would not have the same memory requirements, but would be less flexible. As an example, in the case of task A requiring steps A1 and A2, and task B requiring steps B1, B2 and B3, a separate state machine can be constructed which, for example, always runs the steps in the following order: A1, B1 , B2, A2, B3. It should be appreciated that such a fastening device has very limited flexibility and may not fit well when unanticipated conditions arise. In particular, one such unexpected situation may be an event that must be handled within the time frame dictated by real-time constraints. For a fixed state machine, the wait time before the event is processed can be up to one full cycle through the state machine.

The concept of co-routines is also known. After a predetermined step in a co-routine, the co-routine will yield, thereby allowing the system to select steps, possibly from other co-routines, before returning to the point where the first co-routine yielded. Thus, for the example given above, the first co-routine can be constructed with yield points after step A1 and step A2, and likewise, the co-routine can be constructed with step B1, after step B2 and after step B3 with Yield point to construct. The overall process will continue in a known manner, eg by starting with step A1 and at the yield point at the end of step A1, checking to see if the system is ready to perform step B1. If the system is ready, the process moves to step B1, otherwise the process moves to A2. This arrangement provides some flexibility without the need for a stack of memory for each transaction.

This application presents for the first time an arrangement in which co-routines are built inside individual threads. In particular, processes of the same or similar priority (here otherwise described as tasks) can be scheduled as co-routines within a single thread, thereby allowing processes of completely different priorities to have their own separate thread. For the embodiment shown in Figure 10, this means that the time slicer tasks that operate on the filtering of data bursts can all work as co-routines inside a single thread. Therefore, for multiple time slicer tasks, all that is required is a single memory stack. On the other hand, as described below, if it is possible that the interface handler or signal locker needs to interrupt the time slicer task, this can be done because they operate as separate threads with corresponding memory stacks.

A similar approach can be used if multiple tuners are available. In this case, multiple interface handler or signal locker tasks may co-exist via co-routines inside the corresponding threads.

Thus, there can be provided a system and method of prioritizing, especially those time-critical routines in, for example, a digital television receiver using a real-time operating system. This proposal is applicable to software systems with hard real-time constraints on the subset of tasks performed.

In the context of module (16) above and the processing of Figures 6 and 10, the tasks performed by the software of the preferred embodiment are 1) configure and control the tuner and demodulator, schedule time slices and extract SI/PSI tables and IP service, and communicate with a host application processor (12). The goal of the architecture is to be able to execute all software tasks while optimizing timing, power consumption, and memory usage.

It is assumed that the processor (30) of Figure 3 has sufficient power to perform all software tasks. However, there are also specific events that require special attention because of the real-time constraints imposed. One such event is the semaphore lock loss interrupt. The servicing of such interruptions and the initiation of the automatic recovery process should occur as quickly as possible, suspending other activities if necessary, since any delay may result in loss of IP packets. This means that when a signal acquisition task needs to be run, that task must preempt any task that is processing SI/PSI tables or MPE-FEC frames (eg extracting IP data by performing error correction). On the other hand, tasks such as extracting SI/PSI tables, performing software AGC, or sending debug messages to the UART are less time critical than processing MPE-FEC frames and extracting IP services. They may have to be made preemptible by IP service tasks.

As mentioned above, it is envisaged here that this memory is an extremely scarce resource in devices such as DVB-H receivers. In some embodiments, it is possible that no more than 64kiB of RAM may be used. Thus, the architecture should aim to minimize the following: code size; data size; and stack space.

As noted above, a typical approach for implementing real-time constraints is to use a real-time operating system (RTOS), and assign each software task (40) a separate RTOS pre-emptible thread and priority. However, each RTOS thread requires a separate runtime stack, which increases the overall memory requirements of the system.

According to the proposal of this application, it is possible to provide a DVB-H receiver (2) in which the receiver will assign software tasks to a combination of: 1) RTOS preempting threads for tasks with these threads (40 ) implement real-time constraints, and 2) typically cooperative co-routines for tasks (40) that do not have relative real-time priority. Groups of co-routines run inside a single RTOS preempting thread, and thus will share the same execution stack. Multitasking is achieved with cooperative scheduling, which means that each task (i.e. co-routine) cooperates to produce time-varying control in order to allow other tasks (i.e. co-routine) to run. Thus, using an RTOS to pre-empt threads enables real-time control when real-time control is important, and at the same time, cooperative co-routines will save memory.

Referring to Figures 6 and 10, it should be noted that the top-level blocks (40) are called tasks, but they can also be considered threads. In reality, the time slicer thread runs several co-routines, each of which performs a corresponding IP receiving task. To limit stack space, the number of RTOS threads in the system should be kept to a strict minimum. But as mentioned earlier, some tasks should run asynchronously within low timing constraints.

An example of real-time task scheduling is shown in Figure 11. Although the tasks involved have been mentioned above, a brief overview of each task is given below.

The time slicer task is a low priority task that controls the heartbeat of the system. For each (e.g. DVB-H) time slice, it 1) requests the tuner device to wake up the hardware and reacquires signal lock, 2) waits for SI/PSI or IP events and processes them, 3) requests the tuner service to shut down the hardware , and 4) sleep until the next time slice. By using the proposal of this application, this thread actually runs several co-routines. Each co-routine performs the tasks listed above to receive a single IP service, allowing cooperative scheduling to be used to process other IP services.

The interface handler is a media-priority task that processes commands from the host processor, which is asynchronous in nature to stream processing. It manages the receiver state and uses the tuning service to implement SCAN and TUNE commands. Since the SPI host interface is a performance bottleneck, this task must have higher priority than the time slicer task.

The semaphore locker is a high-priority task that responds to a semaphore lock loss event, or any other event that needs to be handled quickly. In case of loss of signal lock, it starts the recovery process.

The idle task is the lowest priority task in the system. The task is only scheduled when all other tasks are sleeping and or waiting to process an event. Its only function is to place the processor (30) in a low power state.

Figure 11 depicts a typical scheduling scheme and demonstrates how an RTOS can help construct simple designs that meet low-latency timing and power constraints.

Part (a) shows idle tasks scheduled between time slices. The only processing performed by this task is to place the processor (30) in a low power state. The processor (30) will wake up in the next time slice (timer set by the time slicer task), or wake up when a host command (SPI/SDIO interrupt) is received and processed by the interface processor.

Part (b) describes how the real-time scheduling property enables fast service host commands even while the time slicer is running. For example, if the host sends a SEND_STAT_DATA command while the time slicer is processing the SI table, the only delay before that request is serviced is essentially a context switch.

Part (c) describes multi-level preemption. It shows how an RTOS can help handle signal lock loss interrupts with almost no latency.

Managing a single IP service as described in the above section is simple enough. However, as shown in Figure 10, the receiver will support simultaneous reception of up to four IP services, each of which has its own delta-t value and its own power-up period that can be compared with the power-up periods of the other IP services The cycles overlap.

A simple way to implement this is to create a thread for each IP service, but as mentioned above, it is advisable to limit memory usage. Since different attributes are not a requirement for IP services, cooperative multitasking is used. This could be implemented with a state machine, but the preferred embodiment uses co-routines which are more refined, easier to read and easier to maintain. As mentioned above, co-routines allow multiple exit points within a function while maintaining execution state, which in doing so results in more explicit control flow than a switch-based state machine. In effect, co-routines allow cooperative tasks to be implemented in a manner independent of other tasks.

Claims (22)

1. system with a plurality of hardware blocks, this system are configured to according to whether needs use the relevant hardware piece independently to be controlled to the power supply of each hardware block.

2. according to the system of claim 1, comprising: be used for the device driver of corresponding hardware block, this system is configured to support a plurality of tasks, and wherein each task has all been used one or more hardware blocks by communicating with the corresponding apparatus driver.

3. according to the system of claim 2, wherein in each relevant device driver, implemented counter, this counter is configured to increase progressively when corresponding hardware block is used in the each request of one of a plurality of tasks, and successively decreases when one of a plurality of tasks are stopped using corresponding hardware block at every turn.

4. according to the system of claim 3, wherein this counter is implemented as application programming interface.

5. according to the system of claim 3 or 4, wherein this counter provides an output, with the indication of convenient counter require to use the relevant hardware piece do not finish request the time with corresponding hardware block outage.

6. according to the system of claim 5, wherein this counter has initial value 0, and has only when this counter has nonzero value, and this output can make the energising of relevant hardware piece.

7. according to the system of claim 5 or 6, also comprise the hardware clock piece, it has the clock input of the clock signal that is used for this system, be used to receive the power supply input of the corresponding output of described counter, be used for the clock output of corresponding hardware block, and a plurality of corresponding logic gates, wherein each corresponding logic gate all links to each other with clock input, corresponding power supply input and corresponding clock output, and is configured to import according to power supply and clock signal is offered corresponding clock selectively exports.

8. according to the system of aforementioned arbitrary claim, wherein said a plurality of hardware blocks comprise at least one among timer, UART, SPI, SDIO, tuner, detuner, wave filter and the MPE-FEC.

9. according to the system of aforementioned arbitrary claim, wherein this system is a detuner.

10. according to the system of aforementioned arbitrary claim, wherein this system is the interchangeable module.

11. according to the system of aforementioned arbitrary claim, wherein this system is an integrated circuit.

12. according to the system of aforementioned arbitrary claim, wherein this system is a digital television receiver.

13. according to the system of aforementioned arbitrary claim, wherein this system meets the DVB-H standard.

14. a method that is used for operating system, wherein this system has a plurality of hardware blocks, and this method comprises: according to whether needs use relevant block independently to be controlled to the power supply of each hardware block.

15. the method according to claim 14 also comprises: the power supply of controlling independent hardware block by the clock of forbidding the relevant hardware piece selectively.

16. the method according to claim 14 or 15 also comprises: use the reference count in the minimum software layer to determine when and with the hardware block energising or to cut off the power supply.

17., also comprise according to claim 14,15 or 16 method:

For each hardware block provides counter;

Use the relevant hardware piece and thus in the request with its energising, increase progressively described counter receiving at every turn;

Stop using the relevant hardware piece and thus in the request with its outage, this counter successively decreases receiving at every turn; And

When counter indication do not require for the hardware block energising do not finish request the time, the signal with corresponding hardware block outage is provided.

18. the method according to claim 17 also comprises:

When the indication of described counter do not require with the hardware block energising do not finish request the time, the relevant hardware piece is cut off the power supply.

19. the method according to claim 17 or 18 also comprises:, and in the corresponding apparatus driver, implement described counter for each hardware block provides device driver.

20. a computer program, this program has comprised program code devices, and when moving described program on computers, described program code devices is used for institute that enforcement of rights requires 14～19 arbitrary claims in steps.

21. according to the computer program of claim 20, wherein said computer program is implemented as the application programming interface of using in device driver.

22. computer program, wherein this product has comprised the program code devices that is kept on the computer-readable medium, when moving described program product on computers, described program code devices is used for the method that enforcement of rights requires 14～19 arbitrary claims.

Images