Patent Publication Number: US-2005144401-A1

Title: Multiprocessor mobile terminal with shared memory arbitration

Description:
RELATED APPLICATIONS  
      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. 
    
    
     BACKGROUND  
      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&#39; 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.  
     SUMMARY  
      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&#39;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. 
    
    
     BRIEF DESCRIPTION OF DRAWINGS  
       FIG. 1  is a functional block diagram of a representative mobile terminal.  
       FIG. 2  is a functional block diagram of a multi-CPU, shared memory control unit according to one embodiment of the present invention.  
       FIG. 3  is a representative memory map diagram.  
       FIG. 4  is a functional block diagram of a multi-CPU, shared memory control unit according to a second embodiment of the present invention. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION  
      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.  
       FIG. 1  is a block diagram of a representative mobile terminal  10 , showing one embodiment of an operator interface  12  and the communications electronics  30 . Operator interface  12  contains the devices and functions necessary for the user to engage in voice communications using mobile terminal  10 , as well as the inputs and display necessary for the user to control the functions and exploit the data communications capabilities of the mobile terminal  10 . Communications electronics  30  contains the circuits and devices necessary for mobile terminal  10  to form a fully functional radio transceiver capable of transmitting and receiving digital or analog voice and/or data communications signals. Specifically, communications electronics  30  is connected to antenna  32 , and may include control unit  40  with memory  70 , transmitter  80 , and receiver  90 .  
      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  FIG. 1 , the analog signals from the microphone  20  are directed to the transmitter  80 . The transmitter  80  includes an analog to digital converter  82 , a digital signal processor  84 , a modulator  86 , and an amplifier  88 . The analog to digital converter  82  changes the analog signal from the microphone  20  into a digital signal. The digital signal is passed to the digital signal processor (DSP)  84 . The digital signal processor  84  compresses the digital signal and inserts error detection, error correction and signaling information. The compressed and encoded signal from the digital signal processor  84  is passed to the modulator  86 . RF frequency generator  87  generates a reference carrier frequency, and passes it to modulator  86 . The modulator  86  converts the digital signal to a form that is suitable for transmission on a RF carrier. The amplifier  88  then boosts the output of the modulator  86  for transmission via antenna  32 .  
      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  FIGS. 1, 2  and  4 , and described in greater detail herein.  
      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.  
       FIG. 2  depicts one embodiment of a multi-CPU, shared memory control unit  40  for a mobile terminal. The control unit  40  includes CPUs  42  and  44 , both of which access shared memory resource  47  via memory management unit (MMU)  46 . The memory resource  47  also connects to both CPUs  42 ,  44  via data bus  56 .  
      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  FIG. 3 , the code portion of the logical address range is divided into at least two discrete ranges. The address range  60  may be divided into, for example, a first, non-real-time address range  62 ; a second, real-time address range  64 ; a third, non-real-time address range  66 ; and a fourth, real-time address range  68 . During the software linking process, software modules containing real-time code are located in one of the real-time address ranges  64 ,  68 . Software modules containing only non-real-time code are located in one of the non-real-time address ranges  62 ,  66 . This may be accomplished by a static linker in the case of ROM or flash memory, or by a dynamic loader in the case of code execution from RAM.  
      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.  
       FIG. 3  depicts a system featuring shared memory resource access according to another embodiment of the present invention. Each CPU  42 ,  44  executes operating system software  72  and a plurality of processes  74 ,  76 ,  78 . Each process  74 ,  76 ,  78  may be real-time or non-real-time, and may execute with varying priorities P 1 , P 2 , P 3 , as assigned by the operating system  72 . Each CPU  42 ,  44  includes a bus interface  70 , and the same interface signals to an MMU  46  as described above, with the addition of a PRIORITY signal  49 . The PRIORITY signal  49  may comprise a single bit, which may for example indicate real-time code by a “1” or non-real-time code by a “0”. Alternatively, the PRIORITY signal  49  may comprise a plurality of bits, with a range of priorities encoded in the state of the signal bits.  
      The bus interface  70  translates the priorities P 1 , P 2 , P 3  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.