Patent Application
20070136564
Digital systems contain processors that execute programs. A program being executed is called a process. Programs can be written to contain more than one thread of execution. A thread of execution is a part of a program that can execute independently of the other parts. A processor context can be either a process or a thread. Context switching provides efficient use of processor time by allowing the processor to work on multiple tasks. For example, if a process or thread is waiting for input, a processor may set temporarily aside that context and switch to work on another.
Context switching can be time consuming. For process switching, memory maps and file descriptor tables may need to be recreated. If switching processes involves switching applications, the operating system must perform certain computations to configure the application for the particular device. This can include initializing a graphical windowing system and building various data structures. For thread switching, the state of the processor may have to be recreated. Also, the priorities of waiting threads may have to be recalculated and in some operating systems (OS) these priorities are recalculated only occasionally. The system overhead involved with context switching can be costly in terms of processor execution time. Typically, saving and restoring contexts in digital systems requires additional buses and logic dedicated for this purpose. This adds to the design cost of digital systems in terms of complexity and size. The present inventors have recognized a need for improved context switching in digital systems.
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. It is to be understood that other embodiments may be used and structural and logical changes may be made without departing from the scope of the present invention.
This document describes systems and methods to provide context switching in digital systems. Digital systems include any system using at least one processor such as a personal computer, a personal data assistant (PDA), or a mobile telephone for example. Digital systems also include larger, multiprocessor systems. Typically, saving and restoring contexts in digital systems requires additional buses and dedicated logic which adds to the complexity and size of the systems.
Scan cells are storage circuit elements such as latches and flip-flops which are connected to functional cells to form a serial chain. A scan chain runs from a functional cell to a scan cell to the next functional cell to the next scan cell and so on. Scan cells are typically only used in digital systems for system hardware validation. In hardware validation, test patterns are run through a system using functional clocks. The functional clocks are then frozen and the data from functional cells are read out serially by clocking the scan chain with scan clocks. The test patterns are used to detect whether functional cells or other logic circuits have stuck-at-faults. Because a scan chain often exists as part of a digital system design, redesigning the functionality of a scan chain into a save/restore chain adds context switching to a digital system without also adding a large amount of additional circuitry.
To simplify the block diagram, the clock connections are not shown. Data is stored into the functional latch 115 synchronously with clock pulses. The save path 135 and the scan path 137 can be used to implement scan functionality. In some embodiments, scan data is stored into the functional latches 115, 140, 150 on a first scan clock signal and scan data is stored into the second latches 110, 155, 160 on a second scan clock signal. In some embodiments, scan data is clocked into the functional latches 115, 140, 150 and the second latches 110, 155, 160 using the same scan clock signal. This is possible if the latches are edge triggered and there are no race conditions in the design and lay out of the digital system.
The save path 135 and the restore path 145 are used to implement save/restore functionality. The save/restore functionality allows a context of the system as manifested by the data in the functional latches 115, 140, 150 to be stored in the second latches 110, 155, 160 of the save/restore cells. This stored context data can be restored o the system at a later time. Normal system operation clocks data from the data input 120 into the functional latch using a system clock. To save the context data, the system clock is stopped and data is saved in the second latches 110, 155, 160 using a save clock. Normal system operation then resumes by restarting the system clock. To restore the context data, the system clock is again stopped and the saved context data is restored to the functional latches 115, 140, 150 from the second latches 110, 155, 160 using a restore clock.
For brevity, only three save/restore cells 105 are shown in
The second latch 225 includes three inputs: a data input 240 connected to the output of the first latch 220, the scan input 245 for the functional latch 215, and the restore input 250 for the functional latch 215. The output of the second latch 225 is the output for the functional latch 225. In some embodiments, the functional latch circuit 215 includes a clock logic circuit coupled to the clock input 235 and the data clock of the second latch. The clock logic circuit causes data to be clocked into the first latch 220 on a first edge of a clock pulse and into the second latch on the second edge of the clock pulse. In an illustrative example, data is clocked into the first latch 220 on a rising edge of a clock pulse and into the second latch 225 on a falling edge of the clock pulse. In
The memory array 430 has sufficient size to store at least one save/restore chain 405, i.e., the memory array 430 includes at least one memory cell for every save/scan latch and for every functional latch in the chain 405. Thus, the memory array 430 has sufficient size to store at least one context. The context data is loaded from the save/restore chain 405 into the memory array 430. To load the context data into the memory array 430, serial-to-parallel memory input interface 435 receives the data from the save/restore chain 400 serially loads the data into a register. The contents of the register are then stored in the memory array 430.
If Context #1 remains in the save/scan latches, to restore Context #1 after Context #2 is halted, Clk 525 is halted and Context #1 data is restored into the functional latches by Restore clock 535. Context #1 then continues executing from its last saved state. If Context #1 is stored in the memory array 430, to restore Context #1 after Context #2 is halted, Clk 525 is halted and Context #1 is loaded into the save/restore chain 405 from the memory array 430. To load data into the save/restore chain 405, context data is loaded into registers in the parallel-to-serial memory output interface 440. Data is then shifted serially from the registers into the save/restore chain 405 and shifted along the save/restore chain 405 using alternating scan clocks 510, 515. When Context #1 is loaded into the save/restore chain 405, it is then transferred to the functional latches using Restore clock 535.
If the memory array 430 has sufficient size to store at least one context, then at least two stored contexts can be nested in the system 400. Nesting refers to saving and restoring the contexts in a last-in first-out manner. As an illustrative example, assume a first context of a program is executing on a processor in the system 400 and assume the memory array 430 is empty. The program receives a prompt to run a second context. The prompt can be an asynchronous event such as an input to the system from a user or an input from a second processor, for example. The first context is stored in the save/restore chain 405. During execution of the second context, the program receives a prompt to run a third context. The first context is shifted into the memory array 430 using the scan clocks 510, 515 (Sck_a, Save/Sck_b). The second context is stored in the save/restore chain 405 using the save clock 515 (Save/Sck_b). The first and second contexts are nested in that the second context must be executed next after the third context completes because there is only room for one context in the memory array 430 and the first and second context cannot be swapped. After the second context completes, the first context can be loaded into the save/restore chain 405 using alternating scan clocks 510, 515, and restored to the functional latches using Restore clock 535.
If the memory array 430 is of sufficient size to store at least two contexts, then context swapping can be performed using the memory array 430. To see this, assume as in the previous example that a third context is running and that a first context is stored in the memory array 430 and a second context is stored in the save/restore chain 405. After the third context completes, the processor can execute either the first context or the second context. To run the first context, the second context is loaded into the memory array 430 and the first contest is loaded from the memory array 430 into the save/restore chain 405 and restored. Alternatively, both contexts could be stored into the memory array 430 while the third context is executing. Either the first or second context is loaded from the memory array 430 into the save/restore chain 405 and restored into the functional latches.
If the memory array 430 is of sufficient size to store the three contexts, then any context that is executing can be interrupted, loaded into the save/restore chain 405, and stored in the memory array 430. Any context stored in the memory array 430 can then be loaded into the save/restore chain 405, restored to the functional latches, and executed. These concepts can of course be extended beyond the example of three contexts running on a digital system. For example, if there are N contexts to be run on a digital system where N is an integer, then if the memory array 430 is of sufficient size to store N contexts, then any context that is executing can be interrupted, loaded into the save/restore chain 405, and stored in the memory array 430. And any context stored in the memory array 430 can then be loaded into the save/restore chain 405, restored to the functional latches, and executed.
In some embodiments, the system 600 further includes interface logic 630 coupled to the memory circuit 605 and the save/restore chain 620 to load the microprocessor context data from the memory array 615 into the save/restore chain 620. The system 600 also includes interface logic 635 to store microprocessor context data into the memory array 615 from the save/restore chain 620. In some embodiments, the system 600 is included in a digital system such as a personal computer, a personal data assistant (PDA), or a mobile telephone.
Interrupting the second context and storing the second context may occur in response to an asynchronous event causing the third context to begin executing. An example of an asynchronous event includes an input from a second processor, such as when the first processor delays executing the third context until it receives an input signal from the second processor. Another example includes an input from a user that requests the third context. In some embodiments, the method 700 further includes recurrently interrupting execution of the second context and storing the second context in the save/restore chain, executing other contexts on the digital system, and recurrently loading and executing the second context after execution of the other contexts. This is useful when other contexts having a higher priority than the second context are to be executed on the digital system.
According to some embodiments of the method 700, loading the second context on the digital system includes loading the second context from a memory array into the save/restore chain before it is loaded into the functional latches. In some embodiments, loading the second context includes shifting context data along the save/restore chain using one scan clock, such as when the latches used in the save/restore chain are edge triggered and there are no race conditions. In some embodiments, the shifting is done using two non-overlapping scan clocks, one to clock context data into functional latches and one to clock context data into save/scan latches. In some embodiments, the shifting through the save/restore chain results in the context data loaded into the functional latches. In some embodiments, a restore clock is used to load the context data from the save/scan latches of the save/restore string into the functional latches.
According to some embodiments, the method 700 further includes swapping contexts stored in a memory for execution on a processor of a system. For the simple case of swapping a first and second context, this involves interrupting a first context executing on the system, transferring the first context from functional latches of the system into a save/restore chain, transferring the first context from the save/restore chain into a memory array for storage, and loading the second context from the memory array into the save/restore chain before executing the second context.
The contexts can also be swapped the other way. This includes interrupting the second context, transferring the second context from functional latches into a save/restore chain, transferring the second context from the save/restore chain into a memory array for storage, loading the first context from the memory array into the save/restore chain, and loading the first context from the save/restore chain into functional latches before executing the first context.
The swapping is extendible to cases involving more than two contexts. In some embodiments, the memory array holds a plurality of contexts such as N contexts, where N is a positive integer. After interrupting either the first and second contexts and storing the interrupted context in the array, any other context can be loaded through the save/restore chain for execution. In some embodiments, the plurality of contexts corresponds to a plurality of threads to be run on the system. In some embodiments, the plurality of contexts corresponds to a plurality of processes to be run on the system. In some embodiments, the processes correspond to applications to be run on the system. In some embodiments, the applications are selectable by a user of the system. In some embodiments, the plurality of contexts includes a combination of processes and threads.
In some embodiments, the contexts are created while the system is running and a state of the context is stored that is created from executing the context. In some embodiments, the contexts are provided on a computer readable medium, such as a CD-ROM, or a diskette, or a USB memory key, or the like, and are stored in the memory array before the thread or process corresponding to the context is run on the system. In some embodiments, the contexts are downloadable onto the digital system from a network, such as a computer network or a mobile telephone network. These contexts are created by a master development system by a manufacturer. The contexts are preloaded into the memory array when the system is powered up. This is useful to quickly provide graphics content upon power-up or an application change without having to wait for the system or an application on the system to boot up.
The systems and methods described herein show how processor contexts can be saved and restored in a digital system without adding buses and logic which increase system complexity and size. The systems and methods take advantage of scan logic often used to validate system hardware by modifying scan cells and the scan chain into a save/restore chain which is used for the additional purpose of context switching.
The accompanying drawings that form a part hereof, show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.
Such embodiments of the inventive subject matter may be referred to herein, individually, collectively, or both by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single invention or inventive concept if more than one is in fact disclosed. Thus, although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.
The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own.
