Abstract:
A method and apparatus are provided for sharing multipath-accessible memory between a plurality of processors, the method including connecting the plurality of processors in read/write communication to a same shared memory region; connecting the plurality of processors in read communication to a same semaphore area; selectably connecting one of the plurality of processors in write communication to the same semaphore area; exchanging shared memory access command messages between two processors for negotiating access to the same shared memory region; and storing protected variables indicative of the currently negotiated access to the same shared memory region in the same semaphore area, wherein the shared memory region has a channel relative to each processor, each channel having at least one buffer disposed for transferring a plurality of data packets in a burst mode.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims foreign priority under 35 U.S.C. §119 to Korean Patent Application No. P2008-0054432 (Atty. Dkt. IB-200803-018-1), filed on Jun. 11, 2008, in the Korean Intellectual Property Office, the disclosure of which is incorporated by reference herein in its entirety, and to Korean Patent Application No. P2008-0076129 (Atty. Dkt. IB-200803-017-1), filed on Aug. 4, 2008, in the Korean Intellectual Property Office, the disclosure of which is incorporated by reference herein in its entirety. 
       BACKGROUND OF THE INVENTION 
       [0002]    The present disclosure generally relates to semiconductor memory devices. More particularly, the present disclosure relates to a method of driving a multipath-accessible shared bank memory device for low-level burst communications. 
         [0003]    A semiconductor memory device having more than one access port may be called a multiport memory. In particular, a memory device having two access ports may be called a dual-port memory. A conventional dual-port memory is known in the art. For example, a conventional dual-port memory may be used as an image processing video memory. The conventional dual-port memory has one random access memory (RAM) port accessible in a random sequence and one serial access memory (SAM) port accessible only in a serial sequence, and is commonly known as dual-port RAM (DPRAM). 
         [0004]    Another type of multiport memory includes an array of memory cells, such as dynamic random access memory (DRAM) cells, which can be accessed randomly through two or more ports. This type of device is called a multipath-accessible memory. A multipath-accessible memory is distinguishable from a conventional multiport memory, in which only one of the two or more ports supported random access. 
       SUMMARY OF THE INVENTION 
       [0005]    These and other issues are addressed by a method and apparatus for driving a multipath-accessible shared bank memory device for low-level burst communications. Exemplary embodiments are provided. 
         [0006]    An exemplary embodiment provides a multipath-accessible memory device comprising a plurality of input/output ports, each disposed for connection to one of a plurality of processors; a shared memory region connected in read/write communication to each of the plurality of ports; a plurality of mailboxes, each connected in read communication to one of the plurality of ports for receiving shared memory access command messages from other processors; a semaphore area connected in read communication to each of the plurality of ports and connected in selectable write communication to one of the plurality of ports for storing protected variables indicative of the currently negotiated access to the shared memory region, wherein the shared memory region has at least one channel relative to each processor, the at least one channel having at least one buffer disposed for transferring a plurality of data packets in a burst mode. 
         [0007]    Another exemplary embodiment provides a method of sharing multipath-accessible memory between a plurality of processors, the method comprising: connecting the plurality of processors in read/write communication to a same shared memory region; connecting the plurality of processors in read communication to a same semaphore area; selectably connecting one of the plurality of processors in write communication to the same semaphore area; exchanging shared memory access command messages between two processors for negotiating access to the same shared memory region; and storing protected variables indicative of the currently negotiated access to the same shared memory region in the same semaphore area, wherein the shared memory region has a channel relative to each processor, each channel having at least one buffer disposed for transferring a plurality of data packets in a burst mode. 
         [0008]    Yet another exemplary embodiment provides a mobile communications device comprising: a plurality of processors; a plurality of input/output ports, each disposed for connection to one of the plurality of processors; a shared memory region connected in read/write communication to each of the plurality of ports; a plurality of mailboxes, each connected in read communication to one of the plurality of ports for receiving shared memory access command messages from other processors; a semaphore area connected in read communication to each of the plurality of ports and connected in selectable write communication to one of the plurality of ports for storing protected variables indicative of the currently negotiated access to the shared memory region, wherein the shared memory region has at least one channel relative to each processor, the at least one channel having at least one buffer disposed for transferring a plurality of data packets in a burst mode. 
         [0009]    A further exemplary embodiment provides a mobile communications apparatus comprising: a first processor; at least one second processor; and a multipath-accessible memory configured to transfer a plurality of data packets between the first and at least one second processors; wherein the multipath-accessible memory is configured to be selectively accessed by the first or at least one second processors and to store command and data transit information for transferring the plurality of data packets between the processors. 
         [0010]    The present disclosure will be further understood from the following description of exemplary embodiments, which is to be read in connection with the accompanying drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    The present disclosure provides a method of driving a multipath-accessible shared bank memory device for low-level burst communications in accordance with the following exemplary figures, in which like reference numerals may be used to indicate like elements in the several figures, where: 
           [0012]      FIG. 1  shows a schematic block diagram of a multiprocessor system with two processors and an inter-processor communications (IPC) device in accordance with an exemplary embodiment of the present disclosure; 
           [0013]      FIG. 2  shows a schematic block diagram of a memory device having an application module, an inter-processor communications (IPC) driver module and a device driver module, each executable by the processors of  FIG. 1  in accordance with an exemplary embodiment of the present disclosure; 
           [0014]      FIG. 3  shows a schematic block diagram of a memory device having two multi-threaded application modules executable by the processors of  FIG. 1  in accordance with an exemplary embodiment of the present disclosure; 
           [0015]      FIG. 4  shows a schematic block diagram of an application programming interface (API) supported by the device drivers of  FIGS. 2 and 3  in accordance with an exemplary embodiment of the present disclosure; 
           [0016]      FIG. 5  shows a table of application programming interface (API) functions supported by the device drivers of  FIGS. 2 and 3  in accordance with an exemplary embodiment of the present disclosure; 
           [0017]      FIG. 6  shows a schematic block diagram of an application programming interface (API) supported by the inter-processor communications (IPC) drivers of  FIGS. 2 and 3  in accordance with an exemplary embodiment of the present disclosure; 
           [0018]      FIG. 7  shows a table of application programming interface (API) functions supported by the inter-processor communications (IPC) drivers of  FIGS. 2 and 3  in accordance with an exemplary embodiment of the present disclosure; 
           [0019]      FIG. 8  shows a schematic block diagram of exemplary inter-processor communications (IPC) channels supported by the IPC driver of  FIG. 6  in accordance with an exemplary embodiment of the present disclosure; 
           [0020]      FIG. 9  shows a schematic block diagram of the inter-processor communications (IPC) device of  FIG. 1  in accordance with an exemplary embodiment of the present disclosure; 
           [0021]      FIG. 10  shows a schematic block diagram of a bank or shared storage region of  FIG. 9  in accordance with an exemplary embodiment of the present disclosure; 
           [0022]      FIG. 11  shows a schematic block diagram of a shared memory bank with inter-processor communications (IPC) channels for a processor to modem in accordance with an exemplary embodiment of the present disclosure; 
           [0023]      FIG. 12  shows a schematic data diagram for a user data format in the inter-processor communications (IPC) channels of  FIGS. 10  or  11  in accordance with an exemplary embodiment of the present disclosure; 
           [0024]      FIG. 13  shows a schematic data diagram for a message data format for a mailbox of  FIG. 9  in accordance with an exemplary embodiment of the present disclosure; 
           [0025]      FIG. 14  shows a schematic flow diagram for a method of communication between two processors through a mailbox in accordance with an exemplary embodiment of the present disclosure; 
           [0026]      FIG. 15  shows a schematic flow diagram for a change of ownership of the shared region from the second processor to the first processor in accordance with an exemplary embodiment of the present disclosure; 
           [0027]      FIG. 16  shows a schematic flow diagram for a data exchange through a shared region in accordance with an exemplary embodiment of the present disclosure; 
           [0028]      FIG. 17  shows a schematic block diagram for to minimize memory copy operations in the processor in accordance with an exemplary embodiment of the present disclosure; 
           [0029]      FIG. 18  shows a schematic hybrid diagram for ownership acquisition, data transfer and data suspension in accordance with an exemplary embodiment of the present disclosure; 
           [0030]      FIG. 19  shows a schematic block diagram for an IPC channel in accordance with an exemplary embodiment of the present disclosure; 
           [0031]      FIG. 20  shows a schematic hybrid diagram for transmission resumption and data transfer in accordance with an exemplary embodiment of the present disclosure; 
           [0032]      FIG. 21  shows a schematic hybrid diagram for a data transfer in single packet mode in accordance with an exemplary embodiment of the present disclosure; 
           [0033]      FIG. 22  shows a schematic hybrid diagram for a data transfer in burst mode in accordance with an exemplary embodiment of the present disclosure; 
           [0034]      FIG. 23  shows a graphical plot diagram where the burst mode is significantly faster the single mode in accordance with an exemplary embodiment of the present disclosure; 
           [0035]      FIG. 24  shows a schematic block diagram for a communications system where one processor comprises a modem in accordance with an exemplary embodiment of the present disclosure; 
           [0036]      FIG. 25  shows a table for a OneDRAM™ specification, which is usable as the IPC device in accordance with exemplary embodiments of the present disclosure; 
           [0037]      FIG. 26  shows a comparative block diagram for a UART driver with multiplexer (MUX), a OneDRAM™ driver with MUX, and a OneDRAM™ Driver without MUX in accordance with an exemplary embodiment of the present disclosure; 
           [0038]      FIG. 27  shows a comparative hybrid diagram for a MUX driver versus a OneDRAM™ IPC driver as applied to minimize memory copy operations in accordance with an exemplary embodiment of the present disclosure; 
           [0039]      FIG. 28  shows a comparative graphical plot of performance test results for single mode versus burst mode in accordance with an exemplary embodiment of the present disclosure; 
           [0040]      FIG. 29  shows a comparative hybrid diagram for single mode versus burst mode in accordance with an exemplary embodiment of the present disclosure; 
           [0041]      FIG. 30  shows a comparative block diagram for a MUX driver versus a OneDRAM™ IPC driver in accordance with an exemplary embodiment of the present disclosure; 
           [0042]      FIG. 31  shows a schematic block diagram for flow control using receive buffer thresholds in accordance with an exemplary embodiment of the present disclosure; 
           [0043]      FIG. 32  shows a schematic hybrid diagram for a flow control example with send suspend in accordance with an exemplary embodiment of the present disclosure; and 
           [0044]      FIG. 33  shows a schematic hybrid diagram for a flow control example with send resume in accordance with an exemplary embodiment of the present disclosure. 
       
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
       [0045]    The present disclosure provides a method of driving a multipath-accessible shared bank memory device for low-level burst communications. Exemplary embodiments will be described. A multipath-accessible shared bank memory device is disclosed in co-pending U.S. patent application Ser. No. 11/829,859, entitled “MULTIPATH ACCESSIBLE SEMICONDUCTOR MEMORY DEVICE WITH HOST INTERFACE BETWEEN PROCESSORS”, filed Jul. 27, 2007, which is incorporated herein by reference in its entirety. A multipath-accessible shared bank memory device may comprise a OneDRAM™, for example, which is a fusion DRAM manufactured by Samsung Electronics Co., Ltd. 
         [0046]    An exemplary multipath-accessible shared bank memory device includes at least one mailbox. The multipath-accessible shared bank memory device with mailbox may be disposed between a modem and a processor executing an application process (AP) to facilitate low-level burst communications. A device driver for the multipath-accessible shared bank memory device supports communications between the processor and the modem, which may be further connected to another modem or external communications device. The device driver supports a bi-directional burst mode with burst control between the processor and the modem. 
         [0047]    Alternatively, the multipath-accessible shared bank memory device may be disposed between two or more processors in a multiprocessor system to facilitate smooth access to at least one shared bank of the memory device by the multiple processors. A device driver for the multipath-accessible memory device supports inter-processor communications. The device driver supports a multi-directional burst mode with burst control between the multiple processors. 
         [0048]    As shown in  FIG. 1 , a multiprocessor system is generally indicated by the reference numeral  100 . The system  100  includes a first processor  120  in signal communication with an inter-processor communications (IPC) device  140 . The IPC device  140  comprises a multipath-accessible shared bank memory device. The system  100  further includes a second processor  130  in signal communication with the IPC device  140 . The IPC device  140  has a first outgoing interrupt port  142  and a first bi-directional data port  144 , each in signal communication with the first processor  120 . In addition, the IPC device  140  has a second outgoing interrupt port  146  and a bi-directional data port  148 , each in signal communication with the second processor  130 . 
         [0049]    Turning to  FIG. 2 , a computer-readable memory device is indicated generally by the reference numeral  200 . The device  200  includes an application module  230  in signal communication with a kernel  240 . The kernel  240  includes an inter-processor communications (IPC) driver  220  in signal communication with the application module  230  and a device driver  210 . The drivers  210  and  220  and the application  230  are executable by the processor  120  of  FIG. 1 . 
         [0050]    Turning now to  FIG. 3 , another computer-readable memory device is indicated generally by the reference numeral  300 . The device  300  includes a first multi-threaded application module  330  and a second multi-threaded application module  350 , each in signal communication with a kernel  340 . The kernel  340  includes an inter-processor communications (IPC) driver  320  in signal communication with the application modules  330  and  350 , and further in signal communication with a device driver  310 . The drivers  310  and  320  and the applications  330  and  350  are executable by the processor  130  of  FIG. 1 . 
         [0051]    As shown in  FIG. 4 , an application programming interface (API) is indicated generally by the reference numeral  400 . The API  400  comprises the device drivers  210  and  310  of  FIGS. 2 and 3 , respectively, and a device API  411 . 
         [0052]    Turning to  FIG. 5 , application programming interface (API) functions are generally indicated by the reference numeral  500 . The API functions include command functions, data functions and miscellaneous functions. The command functions include a WriteCommand function to write a command or message to a mailbox, and a ReadCommand function to read a command or message from a mailbox. The data functions include a WriteData function to write data to a shared bank, and a ReadData function to read data from a shared bank. The miscellaneous functions include an Init function to initialize a device driver, a CheckOwnership function to check the current ownership of a shared bank, a GetLastError function to retrieve the last error code, and a GetChaAddr to retrieve an address of a channel. These functions are each supported by the device drivers  210  and  310  of  FIGS. 2 and 3 , respectively. 
         [0053]    Turning now to  FIG. 6 , a driver with application programming interface (API) is generally indicated by the reference numeral  600 . The driver  600  comprises the IPC driver  220  of  FIGS. 2 and 3 . Here, the IPC driver includes an IPC API  621 , a plurality N of IPC channels  623  in signal communication with the IPC API, and an IPC thread  622  in signal communication with the IPC channels. Thus, the IPC API  621  is supported by the IPC drivers  220  and  320  of  FIGS. 2 and 3 , respectively. While one IPC channel  623  may be sufficient for exemplary applications, multiple channels may be provided for the convenience of user applications, since they may help to keep data in context Thus, the data packets include a channel number in embodiments having more than one channel. 
         [0054]    As shown in  FIG. 7 , application programming interface (API) functions are generally indicated by the reference numeral  700 . These API functions are supported by the inter-processor communications (I PC) drivers  220  and  320  of  FIGS. 2 and 3 , respectively. The IPC API commands include data functions and miscellaneous functions. The data functions include an IPCSend function to send a data packet, and an IPCReceive function to receive a data packet. The miscellaneous functions include an IPCOpen function to open an IPC channel handle, an IPCClose function to close an IPC channel handle, and an IPCIOCntl function to control settings of the IPC driver. For example, when an IPC channel status is closed, no more reads or writes are permitted. 
         [0055]    Turning to  FIG. 8 , an exemplary inter-processor communications (IPC) channel is indicated generally by the reference numeral  800 . The IPC channel  800  is supported by the IPC driver  220  of  FIGS. 2 ,  3  and  6 , and comprises one of the plurality of channels  623  of  FIG. 6 . The IPC channel  800  includes a transmit side  824  and a receive side  825 . The transmit side  824  includes a plurality M of transmit packets  841 ,  842  . . .  843 . Each transmit packet includes a transmit packet pointer TX_PTR and a transmit packet length TX_LEN. The receive side  825  includes a plurality N of receive packets  851 ,  852  . . .  853 . Each receive packet includes a receive packet pointer RX_PTR and a receive packet length RX_LEN. 
         [0056]    Turning now to  FIG. 9 , an inter-processor communications (IPC) device  140  of  FIG. 1  is indicated generally in greater detail by the reference numeral  900 . The IPC device  900  includes a plurality of ports  931 - 932  in signal communication with at least one bank  911 - 914 , and a semaphore/mailbox area  920 . Here, a first bi-directional data port  931  and a second bi-directional data port  932  are both in bi-directional signal communication with at least one dual-port bank  912 . Optional banks  911 ,  913  and  914  are in bi-directional signal communication with one or more of the ports. In this example, the bank  911  is connected to the first port  931 , while the banks  913  and  914  are connected to the second port  932 . The banks  911 ,  912 ,  913  and  914  may be implemented in dynamic random access memory (DRAM) cells, for example. 
         [0057]    The semaphore/mailbox area  920  is in bi-directional signal communication with each of the ports, and includes a semaphore area  921 , a MailboxAtoB area for messages from a processor connected to the first port to a processor connected to the second port, and a MailboxBtoA area for messages from the processor connected to the second port to the processor connected to the first port. The MailboxAtoB area includes a first interrupt INT 1  from the processor connected to the first port to the processor connected to the second port, and the MailboxBtoA area includes a second interrupt INT 2  from the processor connected to the second port to the processor connected to the first port. The semaphore area  921  defines the current ownership of the shared bank. For embodiments with two ports, the semaphore may be just one bit, for example. Only the processor that is the current owner can write or change the semaphore. 
         [0058]    For ease of explanation, the IPC device  900  includes just one dual-port bank  912 , one semaphore bit  921 , two RAM ports  931  and  932 , and two mailboxes  922  and  923 , but alternate embodiments having a greater number of RAM ports, dual-port banks, semaphore bits, and/or mailboxes are contemplated. For example, an alternate embodiment with N ports may have up to N(N−1)/2 dual-port banks, up to N(N−1)/2 semaphore bits and up to N(N−1) mailboxes. Thus, a fully versatile three-port embodiment might have three dual-port port banks, three semaphore bits and six mailboxes; while a fully versatile four-port embodiment might have six dual-port banks, six semaphore bits and twelve mailboxes. 
         [0059]    On the other hand, reduced versatility embodiments, where all processors need not communicate in burst mode with every other processor, are also contemplated. For example, an eight-port embodiment for which four pairs of processors need to communicate within the pair, but not with processors of the other three pairs, might include four dual-port banks, four semaphore bits, the four RAM ports, and eight mailboxes. 
         [0060]    As shown in  FIG. 10 , a shared storage region or bank is indicated generally by the reference numeral  1000 . The bank or shared storage region  1000  may be any dual-port bank, such as the dual-port bank  912  of  FIG. 9 . The bank  1000  includes a plurality N of channels CH 1 -CHN, each channel including a plurality L of transmit buffers TX_BUF and a plurality M of receive buffers RX_BUF. 
         [0061]    Turning to  FIG. 11 , another shared memory or bank is indicated generally by the reference numeral  1100 . The bank  1100  supports a modem embodiment of the present disclosure by providing one IPC channel for a voice mail service (VMS), one IPC channel for a modem database in non-volatile random access memory (NVRAM), four IPC channels for network data service packets (NDIS), and three IPC channels for modem commands (AT). Here, each channel has ten transmit buffers and ten receive buffers, and uses a memory area of (2 KB+4 B)*(10+10) bytes In alternate embodiments, the number of transmit and receive buffers is user selectable. 
         [0062]    Turning now to  FIG. 12 , a shared bank channel, which may hold the actual data corresponding to the pointers of the IPC channel  800  of  FIG. 8 , is indicated generally by the reference numeral  1200 . User or application data is stored in buffers  1210  of the channel  1200  of a shared bank, such as the bank  912  of  FIG. 9 . The buffers  1210  may include a plurality L of transmit buffers TX_BUF, and a plurality M of receive buffers RX_BUF. It shall be understood that the designation of transmit and receive buffers for the shared buffers are different with respect to each of the processors. That is, a shared buffer known as a transmit buffer to one processor may be known as a receive buffer to the other processor. 
         [0063]    Each buffer  1210  includes a PCK_SZ packet size field  1212 , which may be four bytes, for example, and a PCK_DATA packet data field  1214 , which may have a maximum size of 2 Kbytes, for example. A table  1250  further describes the user data buffers  1210  for this exemplary embodiment. According to the table, the PCK_SZ field is four bytes long and contains the size of the data packet, and the PCK_DATA field is up to 2 Kbytes long and contains the data to be transferred. 
         [0064]    As shown in  FIG. 13 , message data for a mailbox of  FIG. 9  is indicated generally by the reference numeral  1300 . Here, the message data may be formatted into four fields  1310 . The fields may include an eight-bit command field, an eight-bit channel number field, an eight-bit packet count field, and an eight-bit reserved field. For example, the message data may be formatted into at least three fields  1340 , including a command (CMD) region  1341 , a channel index (CH_IDX) region  1342 , and a packet number storage region (PCK_CNT)  1343 . 
         [0065]    Command values  1350  are further described. The eight-bit CMD field  1341  may hold any value between 0x01 and 0xFF. Here, the command value 0x01 is an ownership request command, the command value 0x02 is an ownership release command, the command value 0x03 is a transmit suspension command, the command value 0x04 is a transmit resumption command, the command value 0x05 is a transmit completion command, the command value 0x06 is an IPC channel status command, the command value 0x07 is a transmit completion and ownership request command, the command value 0xF0 is a reset request command, and the command value 0xFF is an error command. 
         [0066]    Turning to  FIG. 14 , a method of communication between two processors through a mailbox is indicated generally by the reference numeral  1400 . The method  1400  includes a start block S 100  that passes control to function block S 110 , where a first processor writes a command to a first mailbox. The first processor passes control to a function block S 130 , where an IPC device generates a first interrupt signal. The IPC device passes control to a function block S 150 , where a second processor receives a first interrupt signal. The second processor, in turn, passes control to a function block S 170 , where it reads a command from its mailbox, and then passes control to an end block S 180 . 
         [0067]    Turning now to  FIG. 15 , a method to change ownership of the shared region from a second processor to a first processor is indicated generally by the reference numeral  1500 . The method  1500  includes a start block S 200  that passes control to function block S 211 , where a first processor checks ownership by accessing a semaphore. The block S 211  passes control to a decision block S 213 , which determines from the semaphore whether the first processor has ownership of the shared bank. If so, control is passed to an end block S 230 . If not, control is passed to a function block S 215 , where the first processor writes an ownership request to the first mailbox, and passes control to a function block S 217 . 
         [0068]    At function block S 217 , an IPC device generates a first interrupt signal, and passes control to a function block S 219 . At S 219 , a second processor receives the first interrupt signal, and passes control to a function block S 221 . At block S 221 , the second processor reads the ownership request command from the first mailbox, and passes control to a function block S 223 . At block S 223 , the second processor writes an ownership release command to a second mailbox, and passes control to a function block S 225 . 
         [0069]    At block S 225 , the IPC device generates a second interrupt signal, and passes control to a function block S 227 . At block S 227 , in turn, the first processor receives the ownership release command, and passes control to a function block S 229 . At the block S 229 , the first processor reads the ownership release command from the second mailbox, and passes control to an end block S 230 . 
         [0070]    As shown in  FIG. 16 , a method to exchange data through a shared region is indicated generally by the reference numeral  1600 . The method  1600  includes a start block S 300  that passes control to function block S 310 , where a first processor acquires ownership of a shared bank, and passes control to a function block S 320 . At block S 320 , the first processor writes a data packet to the shared bank, and passes control to a function block S 330 . At block S 330 , the first processor writes a transmit completion command and information about the stored data packet to a first mailbox, and passes control to a function block S 340 . 
         [0071]    At block S 340 , in turn, an IPC device generates a first interrupt signal, and passes control to a function block S 350 . At block S 350 , a second processor receives the first interrupt signal, and passes control to a function block S 360 . At block S 360 , the second processor reads the transmit completion and information about the stored data packet from the first mailbox, and passes control to a function block S 370 . At block S 370 , the second processor reads a data packet from the shared bank based on the information about the stored data packet, and passes control to an end block S 380 . 
         [0072]    Turning to  FIG. 17 , a processor and IPC device interconnected to minimize memory copy operations in the processor are generally indicated by the reference numeral  1700 . The processor may be the first or second processor  120  or  130  of  FIG. 1 , for example, and the IPC device may be the IPC device  140  of  FIG. 1 . 
         [0073]    The processor  120  includes the application module  230 , the IPC driver  220  and the device driver  210 , all of  FIG. 2 . Here, the application module  230  includes a transmit buffer  1711  and a receive buffer pointer  1727 . The IPC driver includes a transmit buffer pointer  1713  and a receive buffer  1725 . The IPC device  140  includes a transmit buffer  1717  and a receive buffer  1721 . 
         [0074]    The application module  230  is disposed to send a call by pointer for its transmit buffer  1711  to the transmit buffer pointer  1713  of the IPC driver  220 . The device driver  210  is disposed to perform a copy of the application module transmit buffer  1711  indicated by the IPC driver transmit buffer pointer  1713  to the IPC device transmit buffer  1717 . 
         [0075]    The device driver  210  is disposed to perform a copy from the receive buffer  1721  of the IPC device  140  to the receive buffer  1725  of the IPC driver  220 . The IPC driver is disposed to return a pointer for its receive buffer  1725  to the receive buffer pointer  1727  of the application module  230 . 
         [0076]    Turning now to  FIG. 18 , a method for ownership acquisition, data transfer and data suspension is indicated generally by the reference numeral  1800 . At a step S 400 , a first processor  120  of  FIG. 1  has an active device driver  210  and an active IPC driver  220 , both of  FIG. 2 . The IPC driver  220  has an IPC transmit channel  824  of  FIG. 8  presently containing packets PCK 3 , PCK 4  and PCK 5 . An IPC device  140  of  FIG. 1  is disposed between the first processor  120  and a second processor  130  of  FIG. 1 , which has an active device driver  310  and an active IPC driver  320 , both of  FIG. 3 . The IPC driver  320  has an IPC receive channel  825  of  FIG. 8  presently containing packets PCK 1  and PCK 2 . 
         [0077]    At a subsequent step S 410 , ownership acquisition is performed. Here, the first processor uses the IPC driver  220  to send an ownership request command through the device driver  210 , which writes to the IPC device  140  of  FIG. 1  the ownership request command value 0x01, as set forth in table  1350  of  FIG. 13 , to the highest order byte of the mailbox  922  of  FIG. 9  according to the format  1340  of  FIG. 13 , where the two lower order bytes are not needed for this particular command. 
         [0078]    In the second processor, the IPC driver  320  reads the ownership request command through the device driver  310 , which copies the value 0x01 from the mailbox  922 . The IPC driver  320  then writes to the IPC device an ownership release command through the device driver  310 , which writes the ownership release value of 0x02 to the second mailbox  923  of  FIG. 9 . Back in the first processor, the IPC driver  220  reads the ownership release command through the device driver  210 , which copies the value 0x02 from the mailbox  923 . 
         [0079]    At a subsequent step S 420 , data transfer is performed. Here, the first processor uses its IPC driver  220  to write data packets PCK 3 , PCK 4  and PCK 5  through its device driver  210  to the data packet buffers  1210  of a first processor transmit side channel  1200  of a shared bank  912  of the IPC device  140 . The first processor then writes a transmit completion command with arguments to the mailbox  922 , where the value of the transmit completion command is 0x05, the value of the channel index is 0x01, and the value of the packet count is 0x03. 
         [0080]    In the second processor, the IPC driver  320  reads the transmit completion command through the device driver  310 , which copies the transmit completion command value 0x05, the channel index value 0x01, and the packet count value 0x03 from the mailbox  922 . Next, the IPC driver  320  reads the data packets PCK 3 , PCK 4  and PCK 5  through the device driver  310  from the buffers  1210  of the shared bank  912 , and appends them to the receive side IPC channel  825 . Here, the receive side IPC channel  825  has a total of five packets, which exceeds its suspend threshold of four packets in this particular example. 
         [0081]    Thus, at a step S 430 , transmission suspension is performed. Here, the second processor writes a transmission suspension command having a value of 0x03 through the device driver  310  to the second mailbox  933  of the IPC device  140 . The first processor uses its IPC driver  220  to read the transmission suspension command through its device driver  210  from the mailbox  923 . Therefore, the first processor does not yet try to send two more packets PCK 6  and PCK 7  that are present in its IPC channel  824 . 
         [0082]    As shown in  FIG. 19 , an IPC channel is indicated generally by the reference numeral  1900  The IPC channel  1900  may be any pointer-type IPC channel  623  of  FIG. 6 , for example, as used by the IPC drivers  220  or  320  of  FIGS. 2  or  3 , respectively. The channel  1900  includes a transmit side channel and a receive side channel, both with respect to one of the processors. The transmit side channel includes N transmit side buffers  1941 ,  1942  . . .  1943 . Here, unlike the IPC channel  800  of  FIG. 8 , the receive side channel has a different number M of receive side buffers  1951 , 1952  . . .  1953 , but alternate embodiments may have any number of buffers, where the number of receive side buffers need not be the same as the number of transmit side buffers. Each packet includes a packet pointer PTR and a packet length LEN. 
         [0083]    Turning to  FIG. 20 , a method for transmission resumption and data transfer is indicated generally by the reference numeral  2000 . At a step S 440 , the first processor  120  of  FIG. 1  has an active device driver  210  and an active IPC driver  220 , both of  FIG. 2 . The first processors IPC driver  220  has an IPC channel  824  that presently contains packets PCK 6  and PCK 7 . An IPC device  140  of  FIG. 1  is disposed between the first processor  120  and the second processor  130  of  FIG. 1 , which has an active device driver  310  and an active IPC driver  320 , both of  FIG. 3  The IPC driver  320  has an IPC channel  825  of  FIG. 8  presently containing two packets PCK 4  and PCK 5 , where two packets is the resumption threshold. Here, the second processor uses its IPC driver  320  to write a transmit resumption command through its device driver  310  to the IPC device mailbox  923  of  FIG. 9 , where the transmit resumption command has a value of 0x04 in accordance with table  1350  of  FIG. 1300 . The first processor, in turn, uses its IPC driver  220  to read the transmit resumption command through its device driver  210  from the mailbox  923  on the IPC device. 
         [0084]    At a subsequent step S 450 , the first processor&#39;s IPC driver  220  empties its IPC channel  824  by writing data packets PCK 6  and PCK 7  through its device driver to the first processor&#39;s transmit side channel  1200  of a shared bank  912  of the IPC device  140 . The first processor then writes a transmit completion command with arguments to the mailbox  922 , where the value of the transmit completion command is 0x05, the value of the channel index is 0x01, and the value of the packet count is 0x02. 
         [0085]    In the second processor, the IPC driver  320  reads the transmit completion command through the device driver  310 , which copies the transmit completion command value 0x05, the channel index value 0x01, and the packet count value 0x02 from the mailbox  922 . Next, the IPC driver  320  reads the data packets PCK 6  and PCK 7  through the device driver  310  from the second processor&#39;s receive side channel  1200  of the shared bank  912 , and appends them to the receive side IPC channel  825 . Here, the receive side IPC channel  825  has a total of four packets, which does not yet exceed its suspend threshold of four packets in this particular example. 
         [0086]    Turning now to  FIG. 21 , a method for data transfer in single packet mode is indicated generally by the reference numeral  2100 . At a step S 500 , the first processor  120  has a transmit side IPC channel  824  containing packets PCK 1 , PCK 2  and PCK 3 . The second processor  130  has a receive side IPC channel  825  that is empty. 
         [0087]    At a step S 510 , the first processor writes an ownership request command of 0x01 to the first mailbox  922  on the IPC device. The second processor  130 , in turn, reads the ownership request command from the first mailbox  922  and writes an ownership release command of 0x02 to the second mailbox  923 . The first processor reads the ownership release command from the mailbox  923 . 
         [0088]    At a step S 520 , the first processor writes one data packet PCK 1  to the first processor&#39;s transmit side channel  1200  of a shared bank  912  of the IPC device  140 , and then writes a transmit complete command of 0x05 with arguments for channel index of 0x01 and packet count of 0x01 to the mailbox  922 . The second processor reads the transmit completion command with arguments from the mailbox  922 , and then reads the data packet PCK 1  from the second processor&#39;s receive side channel  1200  to the second processor&#39;s receive side IPC channel  825 . Thus, the first processor  120  has a transmit side IPC channel  824  containing packets PCK 2  and PCK 3 , while the second processor  130  has a receive side IPC channel  825  containing packet PCK 1 . 
         [0089]    At a step S 530 , the first processor writes an ownership request command of 0x01 to the first mailbox  922  on the IPC device. The second processor  130 , in turn, reads the ownership request command from the first mailbox  922  and writes an ownership release command of 0x02 to the second mailbox  923 . The first processor reads the ownership release command from the mailbox  923 . 
         [0090]    At a step S 540 , the first processor writes one data packet PCK 2  to the first processors transmit side channel  1200  of a shared bank  912  of the IPC device  140 , and then writes a transmit complete command of 0x05 with arguments for channel index of 0x01 and packet count of 0x01 to the mailbox  922 . The second processor reads the transmit completion command with arguments from the mailbox  922 , and then reads the data packet PCK 2  from the second processor&#39;s receive side channel  1200  to the second processors receive side IPC channel  825 . Thus, the first processor  120  has a transmit side IPC channel  824  containing packet PCK 3 , while the second processor  130  has a receive side IPC channel  825  containing packets PCK 1  and PCK 2 . 
         [0091]    At a step S 550 , the first processor writes an ownership request command of 0x01 to the first mailbox  922  on the IPC device. The second processor  130 , in turn, reads the ownership request command from the first mailbox  922  and writes an ownership release command of 0x02 to the second mailbox  923 . The first processor reads the ownership release command from the mailbox  923 . 
         [0092]    At a step S 560 , the first processor writes one data packet PCK 3  to the first processor&#39;s transmit side channel  1200  of a shared bank  912  of the IPC device  140 , and then writes a transmit complete command of 0x05 with arguments for channel index of 0x01 and packet count of 0x01 to the mailbox  922 . The second processor reads the transmit completion command with arguments from the mailbox  922 , and then reads the data packet PCK 3  from the second processors receive side channel  1200  to the second processors receive side IPC channel  825 . Thus, the first processor  120  has a transmit side IPC channel  824  that is empty, while the second processor  130  has a receive side IPC channel  825  containing packets PCK 1 , PCK 2  and PCK 3 . 
         [0093]    Turning now to  FIG. 22 , a method of transferring data in a burst mode is indicated generally by the reference numeral  2200 . At a step S 600 , the first processor  120  has a transmit side IPC channel  824  containing packets PCK 1 , PCK 2  and PCK 3 . The second processor  130  has a receive side IPC channel  825  that is empty. 
         [0094]    At a step S 610 , the first processor writes an ownership request command of 0x01 to the first mailbox  922  on the IPC device. The second processor  130 , in turn, reads the ownership request command from the first mailbox  922  and writes an ownership release command of 0x02 to the second mailbox  923 . The first processor reads the ownership release command from the mailbox  923 . 
         [0095]    At a step S 620 , the first processor writes data packet PCK 1 , PCK 2  and PCK 3  to the first processor&#39;s transmit side channel  1200  of a shared bank  912  of the IPC device  140 , and then writes a transmit complete command of 0x05 with arguments for channel index of 0x01 and packet count of 0x01 to the mailbox  922 . The second processor reads the transmit completion command with arguments from the mailbox  922 , and then reads the data packets PCK 1 , PCK 2  and PCK 3  from the second processor&#39;s receive side channel  1200  to the second processor&#39;s receive side IPC channel  825 . Thus, the first processor  120  has a transmit side IPC channel  824  that is empty, while the second processor  130  has a receive side IPC channel  825  containing packets PCK 1 , PCK 2  and PCK 3 . 
         [0096]    As shown in  FIG. 23 , a comparative plot of single packet mode versus burst modes with different burst lengths is indicated generally by the reference numeral  2300 . Here, burst lengths of 10 packets and of 20 packets are compared to single packet mode. The burst length may be implemented by setting the suspend threshold of the receiving processor&#39;s IPC driver to the desired length. Alternatively, the burst length may be implemented by setting the number of buffers in the transmit side IPC channel  824  to the desired length. The plot  2300  puts transfer speed in MBPS on the vertical axis against packet size in bytes on the horizontal axis. The plot  2300  includes a first curve  2310  for single packet mode, a second curve  2320  for a burst mode of length  10 , and a third curve  2330  for a burst mode of length  20 . As indicated, the burst mode of length  20  is about  10  times faster than single packet mode. 
         [0097]    Turning now to  FIG. 24 , another embodiment multiprocessor system is generally indicated by the reference numeral  2400 . The system  100  includes a an external communications link  2410  in signal communication with a first processor or modem  2420 , the modem  2420  in signal communication with an inter-processor communications (IPC) device  2440 . The IPC device  140  comprises a multipath-accessible shared bank memory device. The system  2400  further includes a second processor  2430  comprising an application and/or media in signal communication with the IPC device  2440 . 
         [0098]    The system  2400  includes a flash memory  2450  in signal communication with the application processor  2430 , and a system bus  2490  in signal communication with the application processor  2430 . The system  2400  further includes an LCD display  2960 , an audio speaker  2970 , and an input device  2480 , each in signal communication with the system bus  2490 . In an alternate embodiment, the LCD display  2960  and the input device  2480  may be combined in a touch screen device. 
         [0099]    As shown in  FIG. 25 , device specifications for an exemplary IPC device  140  of  FIG. 1  are indicated generally by the reference numeral  2500 . The device  2500  includes 64 MB of DRAM cells organized into four banks, including one bank dedicated to a first port, two banks dedicated to a second port, and one shared bank. The access control is per bank, the I/O width is not necessarily the same for each port, and the ports operate independently of each other. Such a device may comprise a OneDRAM™, for example. 
         [0100]    Turning to  FIG. 26 , a driver comparison is indicated generally by the reference numeral  2600 . A universal asynchronous receiver-transmitter (UART) driver with multiplexer (MUX)  2610  includes a serial channel application  2612  in signal communication with a serial MUX driver  2614  The MUX driver  2614  is in signal communication with a UART driver  2616 , which, in turn, is in signal communication with a UART  2618 . The speed of the UART driver with MUX  2610  is on the order of about 1 Mbps. 
         [0101]    A multipath-accessible shared bank memory device may be embodied in a OneDRAM™ device. A OneDRAM™ with MUX  2620  includes a serial channel application  2622  in signal communication with a serial MUX driver  2624 . The MUX driver  2624  is in signal communication with a OneDRAM™ driver  2626 , which, in turn, is in signal communication with a OneDRAM™  2628 . The speed of the OneDRAM™ with MUX  2620  is on the order of about 10 Mbps. 
         [0102]    IPC and device drivers may be adapted to a OneDRAM™ multipath-accessible shared bank memory device. A OneDRAM™ with IPC driver  2630  includes a serial channel application  2632  in signal communication with a OneDRAM™ IPC driver  2634 , such as the IPC driver  220  of  FIG. 2 . The OneDRAM™ IPC driver  2634  is in signal communication with a OneDRAM™ device driver  2636 , such as device driver  210  of  FIG. 2 , which, in turn, is in signal communication with a OneDRAM™  2638 . The speed of the OneDRAM™ with IPC driver  2630  is on the order of about 100 Mbps. 
         [0103]    Thus, the OneDRAM™ with IPC driver  2630  may more fully utilize a high-speed IPC between a modem, such as the modem  2420  of  FIG. 24 , and an AP processor, such as the processor  2430  of  FIG. 24 . Serial devices include UART, SPI, USB and the like. Shared memory devices include DPRAM, OneDRAM™, and the like. 
         [0104]    While a MUX driver may be adequate for a serial device, it is not fast enough for a multipath-accessible shared bank memory device, such as a OneDRAM™, for example. Here, a OneDRAM™ IPC Driver with multiple channels and high-speed capabilities is significantly more efficient. 
         [0105]    Turning now to  FIG. 27 , a memory copy method comparison for a MUX driver versus a OneDRAM™ IPC driver is indicated generally by the reference numeral  2700 . A memory copy method  2702  uses a OneDRAM™ IPC driver to communicate between a an IPC application on a processor and an IPC device, here a OneDRAM™. The processor may be the first or second processor  120  or  130  of  FIG. 1 , for example, and the IPC device may be the IPC device  140  of  FIG. 1 . 
         [0106]    Here an IPC application module  230  communicates with a OneDRAM™ IPC driver  220 , both of  FIG. 2 . The application module  230  includes a transmit buffer  2711  and a receive buffer pointer  2727 . The IPC driver  220  includes a transmit buffer pointer  2713  and a receive buffer  2725 . The IPC device  140  includes a transmit buffer  2717  and a receive buffer  2721 . 
         [0107]    The application module  230  is disposed to send a call by pointer for its transmit buffer  2711  to the transmit buffer pointer  2713  of the IPC driver  220 . A copy of the application module transmit buffer  2711  indicated by the IPC driver transmit buffer pointer  2713  is performed to the IPC device transmit buffer  2717 . 
         [0108]    On the receive side, copy is performed from the receive buffer  2721  of the IPC device  140  to the receive buffer  2725  of the IPC driver  220 . The IPC driver is disposed to return a pointer for its receive buffer  2725  to the receive buffer pointer  2727  of the application module  230 . 
         [0109]    In contrast, a memory copy method  2701  uses a MUX driver to communicate between a an IPC application on a processor and a physical device. Here an IPC application module  2730  communicates with a MUX driver  2722 . The application module  2730  includes a transmit buffer  2712  and a receive buffer pointer  2728 . The MUX driver  2722  includes a transmit buffer  2714  and a receive buffer  2726 . A physical device  2742  includes a transmit buffer  2718  and a receive buffer  2724 . 
         [0110]    The application module  2730  is disposed to perform an actual copy from its transmit buffer  2712  to the transmit buffer pointer  2714  of the MUX driver  2722 . Another copy of the MUX driver transmit buffer  2714  is performed to the physical device transmit buffer  2718 . 
         [0111]    On the receive side, copy is performed from the receive buffer  2724  of the physical device  2742  to the receive buffer  2726  of the MUX driver  2722 . The MUX driver then performs another actual copy from its receive buffer  2726  to the receive buffer pointer  2728  of the application module  2730 . 
         [0112]    Thus, while the data is actually copied only two times in the method  2702  using the IPC driver  220 , the data is actually copied four times in the method  2701  using the MUX driver  2722 . Therefore, the method  2702  using the IPC driver is more efficient, and should be applied to minimize the number of memory copy operations. 
         [0113]    As shown in  FIG. 28 , a comparative plot of performance test results for single mode versus burst mode is indicated generally by the reference numeral  2800 . A table  2840  sets forth the test environment, in which a modem has an ARM clock of 282 MHz and a memory clock of 69 MHz, and an application processor (AP) has an ARM clock of 533 MHz and a memory clock of 133 MHz. 
         [0114]    The plot  2800  puts transfer speed in Mbps on the vertical axis against decreasing packet size in bytes on the horizontal axis. The plot  2800  includes a first curve  2810  for single packet mode, a second curve  2820  for a burst mode having a length of 10 packets, and a third curve  2330  for a burst mode having a length of 20 packets. 
         [0115]    A table  2850  sets forth the test results. As indicated in the table, a packet size of 2048 bytes produced speeds of 3.0 Mbps, 36.70 Mbps and 26.67 Mbps for single, burst of length  20  and burst of length  10  modes, respectively. A packet size of 1500 bytes produced speeds of 2.3 Mbps, 28.67 Mbps and 21.74 Mbps for the single, burst of length  20  and burst of length  10  modes, respectively. A packet size of 1024 bytes produced speeds of 1.4 Mbps, 19.95 Mbps and 13.72 Mbps for the single, burst of length  20  and burst of length  10  modes, respectively. Thus, the burst mode of length  20  is greater than 10 times faster than single packet mode for all of the tested packet sizes. 
         [0116]    Turning to  FIG. 29 , comparative methods for single mode versus burst mode are indicated generally by the reference numeral  2900 . Here, a single packet mode method  2910  is compared to a burst mode method  2920 . 
         [0117]    In the single packet mode method  2910 , a modem has a transmit side IPC channel or queue  824  containing three packets. An application processor has a receive side IPC channel or queue  825  that is empty. The modem writes an ownership request command to the first mailbox on the IPC device, and the IPC device sends a mailbox interrupt to the application processor. The application processor, in turn, reads the ownership request command from the first mailbox and writes an ownership release command to the second mailbox. The IPC device sends a mailbox interrupt to the modem. The modem reads the ownership release command from the second mailbox. 
         [0118]    Next, the modem writes one data packet to a channel of a shared bank on the IPC device, and then writes a transmit complete command to the first mailbox. The IPC device sends a mailbox interrupt to the application processor. The application processor reads the transmit complete command from the first mailbox, and then reads the data packet from the channel on the IPC device to the second processor&#39;s receive side IPC channel or queue  825 . Thus, the modem now has a transmit side IPC channel  824  containing two packets, while the application processor has a receive side IPC channel or queue  825  containing the transferred packet. 
         [0119]    To transfer the second packet, the modem writes an ownership request command to the first mailbox on the IPC device, and the IPC device sends a mailbox interrupt to the application processor. The application processor, in turn, reads the ownership request command from the first mailbox and writes an ownership release command to the second mailbox. The IPC device sends a mailbox interrupt to the modem. The modem reads the ownership release command from the second mailbox. 
         [0120]    Next, the modem writes one more data packet to the channel of the shared bank on the IPC device, and then writes a transmit complete command to the first mailbox. The IPC device sends a mailbox interrupt to the application processor. The application processor reads the transmit complete command from the first mailbox, and then reads the data packet from the channel on the IPC device to the second processor&#39;s receive side IPC channel or queue  825 . Thus, the modem now has a transmit side IPC channel  824  with one packet remaining, while the application processor has a receive side IPC channel or queue  825  containing a total of two transferred packets. 
         [0121]    To transfer the third packet, the modem writes another ownership request command to the first mailbox on the IPC device, and the IPC device sends a mailbox interrupt to the application processor. The application processor, in turn, reads the ownership request command from the first mailbox and writes an ownership release command to the second mailbox. The IPC device sends a mailbox interrupt to the modem. The modem reads the ownership release command from the second mailbox. 
         [0122]    Next, the modem writes the third and final data packet to a channel of a shared bank on the IPC device, and then writes a transmit complete command to the first mailbox. The IPC device sends a mailbox interrupt to the application processor. The application processor reads the transmit complete command from the first mailbox, and then reads the data packet from the channel on the IPC device to the second processor&#39;s receive side IPC channel or queue  825  Thus, the modem has now emptied its transmit side IPC channel  824 , while the application processor has a receive side IPC channel or queue  825  containing all three transferred packets. 
         [0123]    In the burst mode method  2920 , the modem begins with a transmit side IPC channel or queue  824  containing three packets, and the application processor begins with a receive side IPC channel or queue  825  that is empty. These are the same starting conditions as for the single mode  2910 . 
         [0124]    The modem writes an ownership request command to the first mailbox on the IPC device, and the IPC device sends a mailbox interrupt to the application processor. The application processor, in turn, reads the ownership request command from the first mailbox and writes an ownership release command to the second mailbox. The IPC device sends a mailbox interrupt to the modem. The modem reads the ownership release command from the second mailbox. 
         [0125]    Next, the modem performs a burst write of all three packets to a channel of a shared bank on the IPC device, and then writes a transmit complete command to the first mailbox. The IPC device sends a mailbox interrupt to the application processor. The application processor reads the transmit complete command from the first mailbox, and then reads all three data packets from the channel on the IPC device to the second processors receive side IPC channel or queue  825 . Thus, the modem has now emptied its transmit side IPC channel  824 , while the application processor has a receive side IPC channel or queue  825  containing all three packets transferred in the burst mode. 
         [0126]    Thus, only one data packet can be transferred at a time in the single mode  2910 , while multiple data packets can be transferred at once in the burst mode  2920 . Further, the single mode generates more interrupts than the burst mode, which creates additional overhead for the processor. In addition, the use of the burst mode can save the time spent on additional ownership requests in single mode. 
         [0127]    Turning now to  FIG. 30 , a system comparison of a MUX driver versus an IPC driver is indicated generally by the reference numeral  3000 . A MUX driver system  3001  includes a serial channel application  2730  for receiving data from a MUX driver  2722 . The MUX driver  2722  is in signal communication with a UART driver  3010 , which, in turn, is in signal communication with a UART  2742 . The MUX driver  2722  includes a plurality of MUX units  3021 , each in signal communication with a plurality of MUX channels  3023 . The MUX channels, in turn, are all in signal communication with a MUX process  3022 , which is in signal communication with MUX driver (MUXD) control unit  3029 . 
         [0128]    An IPC driver system  3002  includes a serial channel application  230  for receiving data from an IPC driver  220 , both introduced in  FIG. 2 . The IPC driver  220  is in signal communication with a device driver  210 , which, in turn, is in signal communication with an IPC device  140 . Here, the IPC device  140  may be an exemplary OneDRAM™, for example. The IPC driver  220  includes an IPC interface API  621  in signal communication with a plurality of IPC channels  623 , all as introduced in  FIG. 6 . The plurality of channels, in turn, are all in signal communication with an IPC thread  622 . 
         [0129]    The IPC driver  220  supports multiple channels, and its IPC interface API  621  is used in the upper layer to control the IPC channels. As introduced in the table  700  of  FIG. 7 , functions supported by the IPC interface API include ipcOpen, ipcClose, ipcSend, ipcRecv, ipcloctl, and the like. Thus, each IPC channel is configurable, and has a TX/RX message queue for buffering data. The IPC channel handles the data as packets. Just one IPC thread manages all of the IPC channels. The IPC thread operations include sending messages, receiving messages, and interpreting IPC control commands. The OneDRAM™ device driver  210  provides interface functions to manage and control a OneDRAM™ IPC device  140 . 
         [0130]    As shown in  FIG. 31 , a method of flow control using receive buffer thresholds is indicated generally by the reference numeral  3100 . In flow control for a send suspend operation  31101  a receive (RX) queue  3112  contains a number of data packets that exceeds its suspend threshold  3114 . Thus, in a function block  3118 , the IPC driver performs an enqueues the data, and transfers control to another function block  3116 . In the function block  3116 , the IPC driver sends a transmission suspend command to the transmit (TX) side. 
         [0131]    In flow control for a send resume operation  3120 , the receive queue  3122  contains a number of data packets that is less than a resume threshold  3124 . Thus, in a function block  3128 , the IPC driver dequeues the data, and passes control to another function block  3126 . In the function block  3126 , the IPC driver sends a transmission resume command to the transmit side. The TX side may now transmit a new data packet  3130  to be received by the RX side. 
         [0132]    Thus, the receive buffer queue threshold is used for flow control in the receive side&#39;s IPC driver, which suspends the sending operation if the number of received packet buffers is greater than the RX queue suspend threshold, and sends the ‘TX Suspend’ command to IPC driver on transmit side to make sure that the TX side does not send any more packets. 
         [0133]    The RX side&#39;s IPC driver orders resumption of the sending operation if the number of received buffers is less than the RX queue resume threshold by sending the ‘TX Resume’ command to TX side to permit the TX side to send more packets. 
         [0134]    Turning to  FIG. 32 , a method for flow control example with send suspend is indicated generally by the reference numeral  3200 . In the method  3200 , the receive (RX) queue size is 6, the transmit (TX) queue size is 3, the RX suspend threshold is 3, and the RX resume threshold is 2. A semaphore value of 0x01 means that the application processor (AP) has ownership of the shared bank, while a semaphore value of 0x00 means that the modem has ownership of the shared bank. The mailbox format  1310  and commands  1350  are those of  FIG. 13 . 
         [0135]    Here, the modem begins with a transmit side IPC channel or queue  824  containing three packets, and the application processor begins with a receive side IPC channel or queue  825  containing two packets. The initial semaphore bit value of 0x01 means that the AP currently has ownership. 
         [0136]    The modem writes an ownership request command to the first mailbox  922  on the IPC device. The IPC device sends a mailbox interrupt to the application processor. The AP, in turn, reads the ownership request command from the first mailbox. Next, the AP writes an ownership release command to the second mailbox  923 , and writes a value of 0x00 to the semaphore bit  3226 , giving ownership to the modem. 
         [0137]    The modem reads the ownership release command from the second mailbox. Next, the modem performs a burst write of all three packets to a channel  1200  of a shared bank on the IPC device, writes a transmit complete command to the first mailbox  922 , and writes a value of 0x01 to the semaphore bit  3226 , giving ownership to the AP. The IPC device sends a mailbox interrupt to the application processor The application processor reads the transmit complete command from the first mailbox  922 , and then reads all three data packets from the channel on the IPC device to the second processors receive side IPC channel or queue  825 . Thus, the modem has transferred the three packets from its TX side IPC channel or queue  824 , while the AP has received the additional three packets into its RX side IPC channel or queue  825 , and has a total of five packets in the RX queue. 
         [0138]    In the meantime, the modem has generated two new packets in its TX queue  824 . However, the five packets in the AP&#39;s RX queue exceeds its suspend threshold of three packets. Thus, the AP issues a transmit suspend command to the second mailbox  923 , maintains ownership of the shared block and does not change the semaphore bit  3226 . The IPC device sends a mailbox interrupt to the modem, and the modem reads the TX suspend command from the IPC device. 
         [0139]    Turning now to  FIG. 33 , a method of flow control with send resume is indicated generally by the reference numeral  3300 . The method  3300  picks up where the method  3200  of  FIG. 32  ends. Here, the modem has two new data packets in its TX queue  824 . The application processor has reduced the number of packets in its RX queue  825  to one packet, which is less than its resume threshold of two packets. 
         [0140]    Thus, the AP writes a TX resume command to the second mailbox  923  of the IPC device, and a value of 0x00 to the semaphore bit of the IPC device, transferring ownership to the modem. The IPC device, in turn, issues a mailboxinterrupt to the modem. The modem reads the TX resume command from the second mailbox  923 , sends its two data packets to the shared bank channel  1200 , writes a TX complete command to the first mailbox  922 , and writes a value of 0x01 to the semaphore bit, transferring ownership back to the AP. The IPC device issues a mailbox interrupt to the AP. The AP, in turn, receives the TX complete command from the first mailbox  922 , and receives the two new message packets from the shared bank channel  1200 , increasing the number of packets in its RX queue to three. 
         [0141]    Thus, embodiments of the present disclosure feature multiple channels, efficient flow control, a minimized number of memory copy operations, and burst send and receive operations. A plurality of channels may be provided for two or more processors, and support multiple processes per processor. IPC drivers of the present disclosure use pointer operations rather than copy operations, and fully support burst transfer modes. For example, HSDPA requirements may be easily satisfied by embodiments using burst modes with a length of 20 packets. 
         [0142]    Alternate embodiments are contemplated. For example, mailboxes and/or semaphores may be implemented in software rather than hardware. Ownership of individual channels may be accomplished with additional semaphores and/or an increased number of bits per semaphore. In addition, parallel channel communications for transmit and receive channels with different ownerships can be implemented. 
         [0143]    Although illustrative embodiments have been described herein with reference to the accompanying drawings, it is to be understood that the present disclosure is not limited to those precise embodiments, and that various other changes and modifications may be effected therein by those of ordinary skill in the pertinent art without departing from the scope or spirit of the present disclosure. All such changes and modifications are intended to be included within the scope of the present disclosure as set forth in the appended claims.