Patent Application
20050144401
The present invention relates generally to the field of wireless communications and in particular to a mobile terminal having multiple CPUs that share access to a memory resource.
In early wireless communications systems, mobile terminals transmitted and received audio communications across an analog air interface. The development and deployment of digital wireless communications systems added DAC and ADC operations, error correction, convolutional coding, and the like. Later recent industry standards added additional or control communications between the mobile terminal and one or more base stations, including rate control, power control, mobile-assisted hard and soft hand-off, and the like. All of these operations and communications required real-time control, often implemented by real-time software executing on a stored program microprocessor or digital signal processor, collectively referred to herein as a CPU (central processing unit). Real-time software is characterized as being time-critical, deterministic, and highly sensitive to latency.
Modern wireless communications systems offer a plethora of services and capabilities, enabled by the capability of non-voice digital data communications across the air interface and increased computational power in the mobile terminal. Such services include subscription data broadcast services such as real-time stock quotes or sports scores; Internet browsing; collaborative computing; games; email; and the transmission and display of data, image, and video files. Mobile terminal capabilities include personal productivity software such as calendar, calculator, address books, and the like. Many of these services and capabilities, while interactive in nature, are not real-time in the sense that they require real-time software to execute with subjectively sufficient response performance. These services and capabilities may be implemented by non-real-time software executing on a CPU within the mobile terminal. Non-real-time software is characterized as having relatively flexible deadlines, is often non-deterministic, and tolerates some degree of latency.
To provide sufficient computational power in a cost effective manner, many mobile terminal designers utilize two or more concurrently executing CPUs. These multiple CPUs often share a memory resource for ease of code development and management, maximum operational flexibility, and to minimize cost. Anytime multiple CPUs access a shared memory, some arbitration system is necessary to ensure data integrity. Several such arbitration schemes are known in the art.
Lockstep arbitration is useful in the case of symmetric processing with multiple identical CPUs. Each CPU executes identical instructions in “lockstep” for the purpose of parallel computation or redundancy.
Semaphore or “token bit” arbitration is useful for multiple, asynchronous processing devices. Typically, a specific memory location is designated as the semaphore location. Upon accessing the shared memory resource, a first CPU sets the semaphore bit. Other CPUs' memory accesses are limited to a read of this bit, and they do not attempt to access the memory while it is set. Upon completion of its memory operations, the first CPU clears the semaphore bit as its last memory operation. Upon a subsequent read of the semaphore bit and finding it clear, a second CPU may access the memory, setting the semaphore bit as its first memory operation to “lock out” other CPUs for the duration of its memory access. This arbitration scheme works well when the individual CPUs are able to cache instructions and data, and/or when requests to access the shared memory resource are sporadic.
Round-robin arbitration shares memory access equally among all CPUs by granting the memory to each requesting CPU in turn. No CPU is given priority access to the memory over any other requesting CPU.
In the case where one or more of the CPUs in a mobile terminal is executing real-time code, the arbitration task is complicated by the requirement that the real-time CPU be given priority access over any CPUs executing non-real-time software. None of the prior art arbitration schemes address this need for priority access.
The present invention relates to a method of arbitrating access to a memory resource between at least two CPUs in a mobile terminal. In a mobile terminal including at least two CPUs and a shared memory resource, the method comprises receiving a request and a priority indication from each said CPU and identifying the highest priority request among all requesting CPUs. If the memory resource is available, access to the memory resource is granted to the highest priority requesting CPU. If access to the memory resource is granted to another CPU of an equal or higher priority, the other CPU is allowed to complete its access to the memory resource. If access to the memory resource is granted to another CPU of a lower priority, the other CPU's access is interrupted, and access to the memory resource is granted to the highest priority requesting CPU.
The priority indication may be a signal of one or more bits, with the requesting priority encoded therein. Alternatively, the priority indication may be an address provided by the CPU along with the shared memory access request, wherein priority among requesting CPUs is determined by a memory map.
The present invention relates to the access control of a shared memory resource among multiple processors within a mobile terminal. As used herein, the term “mobile terminal” may include a cellular radiotelephone with or without a multi-line display; a Personal Communications System (PCS) terminal that may combine a cellular radiotelephone with data processing, facsimile and data communications capabilities; a Personal Digital Assistant (PDA) that can include a radiotelephone, pager, Internet/intranet access, Web browser, organizer, calendar and/or a global positioning system (GPS) receiver; and a conventional laptop and/or palmtop receiver or other appliance that includes a radiotelephone transceiver. Mobile terminals may also be referred to as “pervasive computing” devices.
The operator interface 12 includes a display 14, keypad 16, an interface control unit 18, microphone 20, speaker 22, and speaker controler 24. Display 14 allows the user to see dialed digits and call status information, displays menus by which the user selects modes and features, and may in general display a wide variety of content including text, images, graphics, video, and the like. Input 16 includes a keypad by which the operator dials numbers, and may additionally include keys, buttons, and one or more joysticks, touch sensitive pads, or stylus input areas, by which the operator enters commands, select options, and otherwise interacts with the mobile terminal. Input 16 may additionally include input from the display 14, where the display 14 has touchscreen capability. Optionally, a camera input 17 may provide image or video input, either from a camera integrally formed with the mobile terminal or a connector for connection to an external camera. Microphone 20 receives audio signals from the user and converts the audio signals to analog signals that are passed to the transmitter 80. Speaker 22 converts analog signals from the receiver 90 and/or the interface control unit 18 to audio signals that can be heard by the user. Interface control unit 18 interfaces the display 14, input 16, microphone 20 and speaker 22 to the control unit 40. As will be readily understood by those of skill in the art, the interface control unit 18 may be implemented as a software module executed by the control unit 40.
Viewing the communications electronics 30, as seen in
The receiver 90 includes a low noise amplifier 92, a received signal processor 94, and a digital to analog converter 96. Received signals are passed to the low noise amplifier 92 that boosts the low-level RF digital signal to a level appropriate for input to the digital signal processor 94. The digital signal processor 94 includes a demodulator and channel decoder. The demodulator extracts the transmitted bit sequence from the received signal. The channel decoder detects and corrects channel errors in the received signal. The channel decoder also separates control and signaling data from speech data. The digital signal processor 94 may also include an equalizer to compensate for phase and amplitude distortion of the transmitted signal. The control and signaling data is passed to the control unit 40. Speech data is processed by a speech decoder and passed to the digital to analog converter 96. The digital to analog converter 96 converts the speech data into an analog signal that is applied to the speaker 22 to generate audible signals that can be heard by the user. The transmitter 80 and receiver 90 are coupled to the antenna 32. The antenna 32 is used for both transmission and reception.
Control unit 40 functions to coordinate the operation of the transmitter 80 and the receiver 90. These functions include power control, channel selection, timing, as well as a host of other functions. The control unit 40 inserts signaling messages into the transmitted signals and extracts signaling messages from the received signals. In a mobile terminal 10, the control unit 40 responds to any base station commands contained in the signaling messages, and implements those commands. When the user enters commands via the input 16 such as a keypad, the commands are transferred to the control unit 40 for action. These tasks are typically performed by real-time software executing on a stored program processor within the control unit 40.
Increasingly, the control unit 40 also performs a variety of data processing tasks, such as compressing and decompressing image, audio and video data; executing user programs, such as calendars, games, and the like; executing browser software for user interaction with the Internet; and similar computing tasks, which may be performed by non-real-time software executing on a stored program processor within the control unit 40.
As the real-time and non-real-time software described above are required in many cases to execute simultaneously, and to deal with the increased computational load, the control unit 40 may include a plurality of processors, as depicted in
The control unit 40 is operatively connected to memory 70, which may comprise any mixture of RAM, ROM, EEPROM, etc., as is well known in the art. Memory 70 may be used for storage of various programmed features and functions, accessed and controlled via menus displayed on display 14 and control inputs received from input 16. Memory 70 may also store both real-time and non-real-time code, and by used dynamically in the execution of such code in the control unit 40. According to the present invention, memory 70 is a shared resource accessed by two or more CPUs through a memory management unit that performs prioritized arbitration among all requesting CPUs.
In particular, each CPU 42, 44 accesses to the MMU 46 via an address bus 48 and handshaking signals REQUEST 50 and WAIT 52. When a CPU 42,44 wishes to access the memory resource 47, it places an address on the address bus 48 and asserts its REQUEST signal 50. The MMU 46 grants access to a CPU 42, 44 by deasserting the appropriate WAIT signal 52. The MMU 46 then takes the address from the relevant address bus 46, optionally performs an address space translation (e.g., a virtual to physical address), and outputs an address to the memory resource 47 on the address bus 54. Additional controls, such as memory bank or chip selects, read/write signals, row and column refresh signals, and the like, which are well known to those of skill in the art, are not directly relevant to the present invention are omitted for clarity.
According to the present invention, the CPU 42, 44 executing real-time code is granted priority access to the shared memory resource 47 by the MMU 46 by memory mapping. As depicted in
Upon detecting the assertion of a REQUEST signal 50 from one or more CPUs 42, 44, the MMU 46 partially decodes the addresses on the address buses 48 of the requesting CPUs 42, 44, and determines within which range 62, 64, 66, 68 each access request falls. Based on the real-time or non-real-time property assigned to the respective ranges, the MMU 46 determines memory access priority among the requesting CPUs 42, 44 according to the following rules. When any CPU 42, 44 requests access to the memory 47:
If the memory 47 is not currently being accessed by another CPU 42, 44, the MMU 46 will allow access by the requesting CPU 42, 44 by deasserting the WAIT signal 52 associated with the requesting CPU 42, 44.
If another CPU 42, 44 is currently accessing the memory 47 within a real-time address range 64, 68, the MMU 46 will postpone the requested access by asserting the WAIT signal 52 associated with the requesting CPU 42, 44.
If another CPU 42, 44 is currently accessing the memory 47 within a non-real-time address range 62, 66, and the requested access falls within a real-time address range 64, 68, the MMU 46 will force the non-real-time CPU 42, 44 to a wait state by asserting the WAIT signal 52 associated with the currently accessing CPU 42, 44, and MMU 46 will allow access by the real-time requesting CPU 42, 44 by deasserting the WAIT signal 52 associated with the requesting CPU 42, 44.
If another CPU 42, 44 is currently accessing the memory 47 within a real-time address range 64, 68, and the requested access falls within a real-time address range 64, 68, the MMU 46 will allow access to the requesting CPU 42, 44 on a round-robin basis.
In this manner, the CPU 42, 44 executing real-time software is granted priority access to the shared memory resource 47 over the CPU 42, 44 executing non-real-time software. This reduces the latency of memory 47 accesses by the real-time CPU 42, 44. The MMU 46 determines the access priority on the bases of memory management. This method has the potential to allow greater flexibility in system design, save cost through sharing of resources, decrease software complexity, and insure deterministic execution of real-time code.
The bus interface 70 translates the priorities P1, P2, P3 of processes running on the respective CPU 42, 44 into a PRIORITY signal 49, scaling the process priorities if necessary into an appropriate range for the PRIORITY signal 49. The PRIORITY signal 49 presents the priority of the CPU 42, 44 memory access request whenever the associated REQUEST signal 50 is asserted. If multiple CPUs 42, 44 request access to the shared memory resource 47 simultaneously, the CPU 42, 44 with the highest priority encoded on its respective PRIORITY signal 50 is granted access to the memory resource 47. If two or more CPUs 42, 44 simultaneously request access with the same priority (that higher than any other requesting CPU 42, 44), the high-priority requesting CPUs 42, 44 are granted access on a round-robin basis.
The use of a PRIORITY signal 49 may provide greater flexibility than a memory-mapped arbitration scheme, as it does not impose any linking requirements on the software modules (e.g., to locate them in dedicated real-time or non-real-time regions of logical memory). This arbitration system also provides additionally flexibility, as software processes may be assigned different priority levels independently from whether they execute in real-time or non-real time. Additionally, the MMU 46 hardware may be reused for different software configurations.
Although the present invention has been described herein with respect to particular features, aspects and embodiments thereof, it will be apparent that numerous variations, modifications, and other embodiments are possible within the broad scope of the present invention, and accordingly, all variations, modifications and embodiments are to be regarded as being within the scope of the invention. The present embodiments are therefore to be construed in all aspects as illustrative and not restrictive and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.
This application claims priority under 35 U.S.C. § 119(e) from the following U.S. provisional application: Application Ser. No. 60/533,158 filed on Dec. 30, 2003. That application is incorporated in its entirety by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| 60533158 | Dec 2003 | US |
