JP5558713B2 - Method for communicating instructions and data related to events in a processor within a data processing system - Google Patents

Description

  The present invention generally relates to improved data processing systems and methods. More specifically, the present invention is directed to a system and method for communicating instructions and data between a processor and an external device.

  Typically, in the prior art, when the CPU or other processing unit (PU) is waiting for some event outside the program, the operating system or active program executes a polling loop where it Will continue to read the event register used by the PU for the program until the event is waiting. While the program is running, the PU is polling the event register and is not performing useful work.

  Typical modern processors often use virtual memory and external device memory mapping for this communication. On the other hand, some processors can only access local memory, not virtual memory, especially in a multiprocessor environment. Local memory is finite and in a typical multiprocessor configuration, no memory outside of this local memory can be accessed by load and store operations. Therefore, using local memory for other PU functions while waiting for a response from an external device is limited. If the PU is waiting for communication responses from several devices at the same time, the memory available for other functions is further limited.

The memory can also be used to track whether there is valid data in the incoming or outgoing registers. Valid data is data that has been placed in a register for use by a receiving device but has not yet been accessed by the receiving device. Thus, from the above, it is clear that there are many drains on memory resources in modern computing devices.
US Patent Application Publication No. 2004/0264445

  In view of the above, the processor and other devices external to the processor, such as other processors, input / output (I / O) devices, such communication does not burden the processor's local memory or virtual memory It would be beneficial to have a system and method for communicating with and the like. Moreover, it would be beneficial to have a system and method that allows the processor to enter a low power state while waiting for data or events.

  The present invention provides a system and / or method for communicating instructions and data between a processor and an external device and / or a system and / or method for communicating with a processor event function. The system and method of the present invention utilizes the channel interface as the primary mechanism for communicating between the processor and the memory flow controller. The channel interface provides a channel for communicating with, for example, processor functions, memory flow control functions, machine status registers, and external processor interrupt functions. These channels serve to reduce the burden on the processor's local store and minimize bus traffic.

  These channels can be designated as blocking or non-blocking. For the blocking channel, the processor is low power "stall" when no data is available to read from the corresponding register, or no space is available to write to the corresponding register. It becomes a state. When data becomes available or space is freed, the processor is automatically activated via communication over the blocking channel. Thus, the channel of the present invention allows the processor to remain in a low power state rather than continuously polling or spinning on the event register as in prior art systems.

  These and other features and advantages of the present invention are described in, or will be apparent to those skilled in the art, the following detailed description of exemplary embodiments of the present invention. .

  The novel features believed characteristic of the invention are set forth in the appended claims. However, the invention itself, as well as preferred uses of the invention, and other objects and advantages, when read in conjunction with the appended drawings, by reference to the following detailed description of an exemplary embodiment, Will be best understood.

  FIG. 1 is an exemplary block diagram of a data processing system in which aspects of the present invention may be implemented. The exemplary data processing system shown in FIG. 1 is an example of an implementation of a heterogeneous broadband processor architecture such as a CELL broadband engine processor available from International Business Machines. The Broadband Processor Architecture (BPA) is used in the description of the preferred embodiments of the present invention, but the present invention is not limited to this, as will be readily apparent to those skilled in the art upon reading the following description. It is not limited to such a thing.

  As shown in FIG. 1, the BPA 100 includes a power processor unit (PPU) 116 and a power processor element (PPE) 110 having its L1 and L2 caches 112 and 114, each with a dedicated processing unit. Multiple coprocessors having (SPU) 140-154, memory flow control (MFC) 155-162, local memory or store (LS) 163-170, and bus interface unit (BIU unit) 180-194 Including a heterogeneous arrangement with elements (SPEs) 120-134, the bus interface unit being, for example, a combination of direct memory access (DMA), memory management unit (MMU), and bus interface unit It is possible. A high bandwidth internal element interconnect bus (EIB) 196, a bus interface unit (BIC) 197, and a memory interface controller (MIC) 198 are also provided. The broadband engine 100 can be a system-on-a-chip such that each of the elements depicted in FIG. 1 can be provided on a single microprocessor chip. .

  The BPA 100 can be a one-chip system such that each of the elements depicted in FIG. 1 can be provided on a single microprocessor chip. In addition, the BPA 100 is a heterogeneous processing environment in which each SPU can receive various instructions from each of the other SPUs in the system. Moreover, the instruction set for the SPU is different from that of the PPU, for example, the PPU can execute reduced instruction set computer (RISC) based instructions, and the SPU executes vectorized instructions.

  SPEs 120-134 are coupled together and coupled to L2 cache 114 via EIB 196. In addition, SPEs 120-134 are coupled to MIC 198 and BIC 197 via EIB 196. The MIC 198 provides a communication interface to the shared memory 199. The BIC 197 provides a communication interface between the BPA 100 and other external buses and devices.

  PPE 110 is a dual thread PPE 110. Combining the dual thread PPE 110 and the eight SPEs 120-134 results in a BPA 100 that can handle 10 simultaneous threads and 128 or more outstanding memory requests. PPE 110 operates as a controller for the other eight SPEs 120-134 that handle most of the computational workload. PPE 110 can be used to run a conventional operating system, and SPEs 120-134 perform, for example, vectorized floating point code execution.

  SPEs 120-134 include cooperative processing units (SPUs) 140-154, memory flow control units 155-162, local memory or stores 163-174, and interface units 180-194. The local memory or store 163-174, in one exemplary embodiment, is visible to the PPE 110 and includes 256 KB of instruction and data memory that is directly addressable by software.

  The PPE 110 can load a small program or thread into the SPEs 120-134 and chain the SPEs together to handle each step in a complex operation. For example, a set top box incorporating BPA 100 can load programs for reading DVDs, for video and audio decoding, and for display, and the data will eventually arrive on the output display Will be passed from SPE to SPE.

  Memory flow control units (MFCs) 155-162 serve as interfaces for the SPU to the rest of the system and other elements. MFCs 155-162 provide the primary mechanism for data transfer, protection, and synchronization between main storage and local stores 163-174. Logically, there is one MFC for each SPU in one processor. Some implementations may share a single MFC resource among multiple SPUs. In such a case, all functions and commands defined for the MFC must appear to be independent to the software for each SPU. The effect of sharing the MFC is limited to implementation-dependent functions and commands.

Memory Flow Control (MFC) Unit FIG. 2 is an exemplary block diagram of an exemplary memory flow control (MFC) unit 200 according to an exemplary embodiment of the present invention. In this exemplary embodiment, the MFC 200 has two interfaces 210 and 212 to the SPU, two interfaces 214 and 216 to the bus interface unit (BIU) 220, and two to the optional SL1 cache 230. Two interfaces 222 and 224. SPU interfaces 210 and 212 are an SPU channel interface 210 and an SPU local storage interface 212. The SPU channel interface 210 allows the SPU to access MFC functions and issue MFC commands. The SPU local storage interface 212 is used by the MFC 200 to access a local store within the SPU. One interface 214 to the BIU 220 allows memory mapped input / output (MMIO) access to the MFC function. In addition, this interface 214 allows other processors to issue MFC commands. Commands issued using MMIO are called MFC proxy commands.

  Interfaces 222 and 224 to the SL1 cache are mainly for data transfer. One interface 222 is used by the MFC 200 to access the address translation table in the main storage device, and the other interface 224 is used to transfer data between the main storage device and the local storage device.

  As shown in FIG. 2, the main units in a typical MFC include a memory mapped input / output (MMIO) interface 240, an MFC register 250, and a DMA controller 260. The MMIO interface 240 maps the SPU's MFC function to the real address space of the system. This allows access to the MFC function from any processor or any device in the system. In addition, the MMIO interface 240 can be configured to map the local store of the SPU to the real address space. This allows direct access to the local store from any processor or device in the system, and enables the ability to transfer between local stores and I / O devices directly access the local store domain of the SPU. Become.

  The MFC register unit 250 houses most of the MFC functions. Some functions are housed in a direct memory access controller (DMAC) 260. A list of functions in the MFC 200 is as follows. User mode environment functions, ie, environment functions accessible from non-privileged applications include (1) mailbox function, (2) SPU signal notification function, (3) proxy tag group completion function, and (4) MFC. Includes multi-source synchronization function, (5) SPU control and status function, and (6) SPU separation function. Privileged mode environment functions, that is, functions accessible only by privileged software such as an operating system include (1) MFC status register 1, (2) MFC logical partition ID register, (3) MFC storage description register, (4 ) MFC data address register, (5) MFC data storage interrupt status register, (6) MFC address comparison control register, (7) MFC local storage address comparison function, (8) MFC command error register, (9) MFC data storage interrupt pointer register, (10) MFC control register, (11) MFC atomic flash register, (12) SPU outbound interrupt mailbox register, (13) SPU privilege function, (14) SPU privilege control register , (15) PU local memory limit registers, including (16) SPU Configuration Register, and (17) SPE context save restore.

  For functions of particular importance to the mechanism of the present invention, namely mailbox function, SPU signal notification function, proxy tag group completion function, MFC multi-source synchronization function, SPU channel access function, SPU event function, and interrupt function, This will be described in more detail below.

  Data synchronization and transfer is generally the role of the DMAC 260 within the MFC 200. The DMAC 260 can move data between the SPU's local storage and main storage. Optionally, data can be placed in the SL1 cache.

  The SPE and PPE instruct the MFC 200 to perform these DMA operations by queuing DMA command requests to the MFC by one of the command queues 270 and 280. Commands issued by the SPE are queued in the MFC SPU command queue 280. Commands issued by the PPE are queued in the MFC proxy command queue 270. The MFC uses a memory mapping unit (MMU) 290 to perform all MFC address translation and MFC access protection checks necessary for DMA transfers.

  MFC commands provide a primary method that allows code executed in the SPU to access main memory and maintain synchronization with other processors and devices in the system. Commands are also provided for managing optional caches. MFC commands can be issued by code executing on the SPU or by code executing on other processors or devices such as PPE. The code executed on the associated SPU executes a series of channel instructions for issuing MFC commands. Code executed on other processors or devices performs a series of memory mapped input / output (MMIO) transfers to issue MFC commands to the SPE. Issued commands are queued in one of command queues 270 and 280.

  In general, commands can be queued using MMIO registers or by channel instructions executed by the associated SPU. The MMIO method is for use by the PPE to control the transfer of data between main storage and associated local storage on behalf of the SPE. An MFC command for transferring data is called an MFC DMA command. The data transfer direction related to the MFC DMA command is always referred from the viewpoint of SPE. Therefore, a command that transfers data to the SPE (from the main storage device to the local storage device) is regarded as a get command, and a command that transfers data from the SPE (from the local storage device to the main storage device) is put (put). ) Is considered a command.

  An MFC command uses a plurality of parameters that affect the operation of the command. FIG. 3 is an exemplary diagram illustrating parameter mnemonics for MFC commands according to an exemplary embodiment of the present invention. Not all parameters are used by all commands. For example, the EAH parameter is optional. If an optional parameter is not specified in the command, the optional parameter is set to “0” by the hardware.

  MFC commands can be categorized into three classes: predefined commands, illegal commands, and reserved commands. The class of a command is determined by examining the instruction code and, if present, the extended instruction code. A command is illegal if the command instruction code or combination of instruction code and extended instruction code is not for a predefined command or a reserved command.

  Predefined commands fall into one of three categories: data transfer commands, SL1 cache management commands, and synchronization commands. Data transfer commands are further divided into sub-categories that define the direction of data movement (ie, to or from local storage). The put command is a data transfer command for moving data from the local store to the main storage device. The acquisition command is a data transfer command for moving data from the main storage device to the local store. The application can place data transfer commands in the MFC proxy command queue 270. Unless otherwise noted, these commands can be executed in any order (asynchronously).

  “Illegal” class commands target commands that do not fall into a defined or reserved class. “Reserved” class commands are for implementation-dependent use.

  The SL1 storage control command is a command for controlling operations related to the SL1 cache. These storage control commands include, for example, a “hint” to notify the SL1 cache that a particular type of data transfer command is probably issued, such as a get or put command, an address range manipulation command, and a flush command. (Hint) "command.

  The MFC synchronization command is used to control the order in which storage accesses are performed for other MFCs, processors, and other devices. MFC synchronization commands include commands for enforcing in-order execution, barrier commands for ordering all subsequent commands for all commands prior to the barrier command in the DMA command queue, This includes a transmission signal command for logically setting signal bits in the targeted signal notification register.

  The MFC command may be an individual DMA command or a DMA list command. Details of the DMA list command according to an exemplary embodiment of the invention are shown in FIG. The DMA list command uses a valid address and transfer size pair stored in local storage or a list of list elements as parameters for DMA transfer. These parameters are used for SPU start DMA list commands that are not supported on the MFC proxy command queue. The first word of each list element contains the transfer size and a stall-and-notify flag. The second word contains the lower 32 bits of the effective address. The starting effective address is specified for each transfer element in the list, and the local storage address involved in the transfer is specified only for the primary list command (the term “primary” is specified by the parameters shown in FIG. 3). Pointed list command).

  The local storage address is incremented internally based on the amount of data transferred by each element in the list. However, due to alignment constraints, if the local storage address does not start on a 16-byte boundary for list element transfer, the hardware automatically increments the local storage address until the next 16-byte boundary. This is done only if a transfer size of less than 16 bytes is used. List elements with a transfer size of less than 16 bytes use the local storage offset within the current quadword (16 bytes) defined by the least significant 4 bits of the effective address.

  The effective address specified in the list element is relative to the 4 GB area defined by the upper 32 bits of the effective address specified in the base DMA list command. The DMA list start address is relative to a single 4GB region, and transfers within one list element can cross a 4GB boundary.

  Setting the "S" (stop notification) bit causes the DMA operation to suspend execution of this list after the current list element has been processed and sets the stop notification event status for that SPU. Execution of the stopped list does not resume until the MFC receives a stop notification confirmation response from the SPU program. The stop notification event is notified to the SPU program using the related command tag group ID. If there are multiple DMA list commands in the same tag group with a stop notification element, the software can use tag-specific barriers or to force ordered execution of the DMA list commands to avoid ambiguity. Ensure that global barriers are used.

  All DMA list elements in a DMA list command are guaranteed to be started and issued in sequence. Every element in the DMA list command has a unique local ordering. A single DMA list command contains up to 2048 elements and can occupy 16 KB of local storage.

Channel Interface In BPA, the channel is used as the primary interface between the cooperative processing unit (SPU) and the memory flow control (MFC) unit. The SPU channel access function is used to configure, save and restore the SPU channel. The SPU Instruction Set Architecture (ISA) provides a set of channel instructions for communicating with external devices via a channel interface (or SPU channel). Table 1 lists these instructions.

  Architecturally, an SPU channel can be configured to have an access type of read-only or write-only. Channels cannot be configured as reads and writes. In addition to the access type, each channel can be configured as non-blocking or blocking. A channel configured as blocking causes the SPU to stop when reading a channel with a channel count of “0” or writing to a full channel (ie, a channel with a channel count of “0”). A “read” channel means that only a read channel command (rdch) can be issued to this channel, and data is always returned. A “write” channel means that only a write channel command (wrch) can be issued to this channel, and data is always accepted by that channel.

  A “read blocking” channel means that only read channel commands (rdch) can be issued to this channel. A read channel command (rdch) sent to the read blocking channel is completed only if the channel count is not zero. A channel count of “0” indicates that the channel is empty. Performing a channel read (rdch) on a read blocking channel with a count of “0” stops the SPU until data is available in that channel.

  A “write blocking” channel means that only a write channel command (wrch) can be issued to this channel. A write channel instruction (wrch) sent to the write blocking channel is completed only if the channel count is not zero. A channel count of “0” indicates that the channel is full. Performing a write channel (wrch) on a write blocking channel with a count of “0” stops the SPU until items in the addressed channel are available.

  Note that an invalid channel instruction interrupt is generated if a channel instruction inappropriate for the channel configuration is issued. For example, issuing a read channel instruction (rdch) to a channel configured as a write channel or a write blocking channel causes an invalid channel instruction interrupt.

  Each channel has a corresponding count (ie, depth), which indicates the number of outstanding operations that can be issued for that channel. The channel depth (ie, the maximum number of outstanding transfers) is implementation dependent. The software must initialize the channel count when establishing a new context in the SPU or when it resumes an existing context.

  The operation of the channel and channel interface was filed on June 26, 2003 and is co-pending and assigned to the present applicant under the name “External Message Passing Method and Apparatus” US 2004/0264445. Which is incorporated herein by reference. FIG. 5 is an exemplary diagram illustrating the placement of SPU issue control logic and data flow for a channel circuit for a pair of channels in accordance with the mechanism described in US Patent Application Publication No. 2004/0264445. The operation of the channel interface will now be described with respect to the various blocks depicted in FIG.

  As shown in FIG. 5, block 430 represents an external device instruction issue control block of the SPU. Block 432 represents the data flow to and from the SPU. As is known, a processor can be in communication with many different external devices at the same time. In this processor, communication is performed via a channel register. Each channel operates in only one direction and is referred to as a read channel or a write channel, depending on the operations that can be performed on that channel by the SPU. Block 434 represents channel logic for a set of channels for a single external device represented by block 435. As discussed in more detail below, this external device 435 can be an MFC, such as MFC 200, a machine status register, or any other type of external device. In particular, the use of the channel interface to communicate with the MFC, machine status register, event function, mailbox function, and signal notification function is described below following this general description of the channel interface.

  Within block 434, a read channel counter 436, a read register 438, a write channel counter 440, a write register 442, a MUX (multiplexer) 444, and a MUX 446 are shown. Channel instructions are delivered from the SPU issue control logic 430 on bus 448 to read and write counters 436 and 440 and the gate inputs of MUX 444 and 446. These instructions are also supplied to a suitable external device such as 435 on channel OUT lead 450. The data IN lead 452 provides data from the external device 435 to the read register 438. The channel count IN signal is provided on the channel IN lead 454 from the external device 435 to the counter 436 to indicate that data has been entered into the register and operates to change the count in the counter 436 by one value or number. To do.

  Data being output from the write register 442 to the external device 435 is supplied on the data OUT lead 456. When the external device 435 completes satisfactory reception of the data and operates to change the count in the counter 440 by one value unit or number, the external device 435 to the write channel counter 440 on the channel ACK read 458. A channel acknowledgment signal is returned. In a preferred embodiment of the present invention, the appropriate read or write counter is decremented by a signal on bus 448 and the appropriate read or write counter is incremented by a signal on either lead 454 or 458.

  As shown, the counts of both counters 436 and 440 are provided to SPU issue control logic 430 on channel stop lead 460 through MUX 444. Channel write data is provided to write register 442 on channel write data lead 462 from SPU data flow block 432. Outputs from blocks 436, 438, and 440 are returned on bus 464 to data flow block 432. Non-channel instructions are communicated between blocks 430 and 432 via bus 466.

  FIG. 6 shows a flowchart outlining an exemplary operation of the channel interface according to an exemplary embodiment of the present invention. It will be understood that each block and combination of blocks in the flowchart of FIG. 6 and the flowchart of subsequent figures described below can be implemented by computer program instructions. These computer program instructions are such that instructions executed on a processor or other programmable data processing device create a means for implementing the functions specified in one or more blocks of the flowchart. Can be provided to a processor or other programmable data processing device for production. These computer program instructions also comprise an apparatus (article of manufacture) that includes instruction means for instructions stored in a computer readable memory or storage medium to implement functions specified in one or more blocks of the flowchart. It can also be stored in a computer readable memory or storage medium that can instruct a processor or other programmable data processing device to function in a particular manner as it is produced.

  Thus, the flowchart blocks support a combination of means for performing the specified function, a combination of steps for performing the specified function, and a program instruction means for performing the specified function. It is also understood that each block of the flowchart and combinations of multiple blocks of the flowchart can be implemented by a special purpose hardware-based computer system that performs a specified function or step, or by a combination of special purpose hardware and computer instructions. It will be.

  As shown in FIG. 6, when a channel read or write command is issued, a determination is made as to whether the specified channel is one that implements the above control mechanism (step 576). If not, a determination is made as to whether channel error logic is available (step 578). If so, the processor is stopped (step 580). If not, a determination is made as to whether the command is read or write (step 582).

  If the non-implemented command is a write, nothing is done about that command (step 584). On the other hand, if the unimplemented command is a read, zero is returned in the data processor data flow (step 586). In either case, the process returns to waiting for the next read or write instruction. In the preferred embodiment shown, all valid read instructions must return a value. As defined herein, channel read instructions to unimplemented channels all return a value of zero.

  It can be noted that for a specific implementation, not all channels have to be defined. Each channel will have a unique numeric ID. In a preferred embodiment, this channel ID is in the range of 0-127. However, not all IDs can be used because not all channels need to be defined. Thus, if there are instructions for undefined channels, the process proceeds along the unimplemented path referenced above. In some implementations, it may be desirable for a channel read or write command to an unimplemented channel to be considered an illegal operation. Subsequent actions may likely force the processor to stop, as shown in step 580 above.

  Returning to FIG. 6, if it is determined in step 576 that the specified channel is implemented, a check is made to see if the specified channel is a blocking channel (step 588). If not, the count for that channel is decremented but cannot be less than zero (step 590). If it is determined that the channel is blocking, a check is made to determine if the count for that channel is greater than zero (step 592). If greater than zero, the process returns to step 590.

  As determined in step 592, if the count is already zero, the external device provides input associated with this channel, so that the SPU stops until the count is changed from zero (steps 594 and 595). . Therefore, the loop of steps 594 and 595 is periodically processed until the count for this channel changes. If the count is changed, the process proceeds from step 595 to step 590.

  Thereafter, it is determined whether the channel is active or passive (step 596). If the channel is passive, a check is made to see if the command is a write command or a read command (step 598). If the command is a write command, the data is stored locally for external reading (step 600). If the command is a read instruction, the data is returned to the SPU via the SPU data flow 432 of FIG. 5 (step 602).

  Note that in the passive channel situation, the SPU relies on an external process to complete the operation. As an example, a read channel may rely on an external device to load data. On the other hand, in the active channel, the SPU actively completes operations that perform read or write operations. An example of this type of operation is when the attached hardware makes an external request for data from the active read channel.

  If it is determined in step 596 that the channel is an active channel, a check is made to see if the command is a read command or a write command (step 604). If the command is a write, the write data is output outside the SPU or to an internal register (step 606). If the command is read, a read request is sent to the appropriate external device (step 608).

  Waiting for input of the requested data (step 610). Periodically, a determination is made as to whether read data has been received (step 612). If not, the process returns to step 610 until time for the next check occurs. Once the data is received, the process is complete (step 602).

  From the above, it will be apparent that each channel is accessed using a specific channel read or write command with the channel number specified in the command. Each channel has a count specified thereby. This count is read using a read channel count instruction in which the channel of interest for the instruction is specified. Channel commands are not speculative and cannot be processed out of order at the external interface. This channel architecture does not require devices external to the SPU to process channel commands in the proper order, but can do so depending on the implementation of the processor and external devices. The value in this count register keeps track of the number of accesses to this register against the number of external acknowledgments made to this register.

  In operation, the method of changing the channel count via access by external interface (s) is based on an implementation. In a preferred embodiment, the count is incremented by 1 for each normal data transfer to and from the register. For each channel, SPU access can be defined as a read or write channel. Furthermore, in this preferred embodiment, a “0” count is used to stop further operations when the channel is defined or implemented as a “blocking” channel. If a channel register is defined as having a queue depth of “1”, a “0” count can be used to indicate that the data in that channel is not valid. If the count is “0”, the channel can also be defined on that command to stop SPU operations for read or write channel commands until the count is no longer “0”.

  In a preferred embodiment, the counter value is decremented for every SPU start read or write channel command and incremented for each external start read or write access (with or without data). In other words, the counter maintains an input-to-output display. Thus, a value or count of “0” indicates that no more external write slots are available for writing. On the other hand, a count value of “0” in the case of reading indicates that there is no valid data. If an additional SPU read or write channel command is issued when the count is zero and the channel is defined as non-blocking, the count remains “0” and the data in the register is lost. As implemented in the preferred embodiment, the previous most recent data in that register is lost. If the count is the maximum number of bits for that channel register implementation and an additional transaction is made to increment the count out of range, the count will remain at that maximum.

  The method of initializing the count value is implementation-dependent, and one method is initial setting by an external interface. This count can be used for flow control for the write queue. This count can be preset to the number of items in the external queue. A value of zero in the count register means that there is no more space in this external queue. For an external queue item number of “1”, the count must be preset to “1”. When the SPU writes to this channel, the count is “0”. When the external device reads from this channel, the count is incremented to “1”, thereby indicating that the channel is ready for another write operation.

  As described above, in the case of a channel register read, this allows the count to indicate valid data. If the count register is preset to “0”, this indicates that the data is not valid. When the external device writes to this channel, the count increments to “1”, indicating that the data is valid for SPU reading. When the SPU reads from this channel, the count decrements and returns to “0”, indicating that another external write can be performed.

  In a preferred embodiment of the invention, a computer code channel count read instruction is sent to the counter to verify the count for both the read channel and the write channel. If the external device is an intelligent device, such as another SPU or computing device in a multiprocessor environment, the external device can also send a channel count read instruction to the counter to confirm the count. In this way, the external device determines when the channel contains unread data on either the read channel or the write channel and / or when it is appropriate to send additional data to the processor containing the read channel. be able to.

  For use in accordance with the present invention, the read and write channels can be either non-cumulative or cumulative. The accumulation channel is a channel that accumulates a plurality of writes. That is, incoming data is logically added to data already contained in a register or other storage means until the channel is read. When reading that channel, the accumulation register is typically reset to "0" and the channel begins to accumulate again. This action can be performed for both read and write channels.

  Further, the cumulative channel can be blocking or non-blocking. Typically, a cumulative channel will only have a count depth of “1”, in contrast to a non-cumulative channel that can operate to count each write to that channel.

  In summary, the channel interface uses a predefined channel to free memory, but still remains when the data in the register is valid, i.e. when the data in the register has not been read previously. Provide easily accessible information. This information is obtained by sending a channel count read command to the counting mechanism. When an intelligent external device is connected to a given channel, the external device can use similar instructions when sending or receiving data to or from the given channel. The channel interface further prevents accidental overwriting of the data in the register when the specified channel is defined as a non-blocking channel by using a channel count read instruction.

  The present invention utilizes channel interfaces and predefined channels to communicate commands and data between various types of external devices and functions provided by such external devices. For example, the present invention provides a mechanism for using the SFC's channel interface to communicate MFC, machine status registers, and interrupt functions and instructions and data. In addition, the channel interface is used to communicate commands and data with BPA event functions, mailbox functions, multi-source synchronization functions, proxy tag group completion functions, signal notification functions, and the like.

  FIG. 7 is an exemplary diagram illustrating the manner in which channels are used according to one embodiment of the present invention. As shown in FIG. 7, channel interface 620 provides a plurality of channels through which SPU 622 can communicate with MFC 624, machine status register 634, and interrupt function 636. Each channel can be composed of elements similar to those described above with respect to FIG. 5, and the operation is similar to that described in FIG. In an exemplary embodiment of the invention, the channel interface 620 may correspond to a collection of all channel pairs represented by block 434 in FIG. SPU 622 may correspond to a combination of blocks 430 and 432 in FIG. 5, for example, all other blocks in FIG. 6 correspond to block 435 in FIG.

  As shown in FIG. 7, channels 631, 633, and 635 provide a communication path associated with SPU 622 so that SPU event function 630 and decrementer 632 can communicate with MFC 624. The SPU event function 630 provides a mechanism for handling events generated within the BPA. Channel 633 provides a mechanism for identifying events of interest and obtaining information about those events of interest, as discussed in more detail below. The decrementer 632 provides a mechanism by which software running on the SPU can measure the progress of time or notify the software of the passage of time on a given scale. The decrementer 632 may have its value set via the channel 631 and the status read.

  SPU (Issue Control Logic, Processor Data Flow) 622 provides instructions, data, and functions for communicating with external devices. For example, the SPU 622 provides an SPU channel access function that is a privileged function to initialize, save and restore SPU channels. This function consists of three MMIO registers: SPU channel index register, SPU channel count register, and SPU channel data register. The SPU channel index register is a pointer to the channel whose count and data are accessed by the SPU channel count register and SPU channel data register, respectively. The SPU channel index register selects which SPU channel is accessed using the SPU channel count register or the SPU channel data register. The SPU channel data register is used to read or initialize the SPU channel data selected by the SPU channel index register.

  In addition to channels 631, 633, and 635 for communicating with the functions of SPU 622, channel 637 provides a communication path associated with machine status register 634. Machine status register 634 contains the separation status and interrupt status of the current machine. The separation status indicates whether the SPU is separated. The BPA separation feature allows privileged software and applications to separate code images and load them into one or more SPUs. The SPU separation function ensures that the code image loaded into the SPU's associated local storage has not been altered at all. The interrupt status related machine status register is used to save and restore interrupt status information when nested interrupts are supported.

  In addition, channel 639 provides a communication path associated with interrupt function 636. The interrupt function 636 is used to route interrupts and interrupt status information to the PPE or external device, prioritize interrupts presented to the PPE, and generate interprocessor interrupts.

  Further, channel 641 provides a communication path associated with mailbox function 638. Mailbox function 638 is used to send information to and receive information from other external devices such as SPUs, PPE, and the like.

  Channel 643 provides a communication path associated with SPU signal notification function 640. The SPU signal notification function 640 is used to transmit a signal such as a buffer completion flag from other processors and devices in the system to the SPU.

  Channel 645 provides a communication path associated with proxy tag group completion function 642. Similarly, the proxy tag group completion function 642 is a function for determining when processing of a group of instructions with a tag is completed.

  Channel 647 provides a communication path associated with MFC multi-source synchronization function 644. The MFC multi-source synchronization function 644 achieves cumulative ordering between the local storage and main storage address domains. The ordering of storage accesses performed by multiple sources (ie, two or more processors or units) relative to other processors or units is called cumulative ordering.

  8 and 9 are exemplary diagrams listing SPU channel maps according to an exemplary embodiment of the present invention. As shown in FIG. 6, the SPU channel interface supports various types of channels for conveying instructions and data. These channels include SPU event channel 650, SPU signal notification channel 652, SPU decrementer channel 654, MFC multi-source synchronization channel 656, SPU reserved channel 658, mask read channel 660, SPU state management channel 662, MFC command Includes parameter channel 664, MFC tag status channel 666, and SPU mailbox channel 668. These “channels” are essentially memory mapped registers and corresponding circuitry for writing to these registers. Thus, the term “channel” can also be used herein to refer to one or more registers for storing data values corresponding to a specified “channel”. The operation of each channel will be described below. PPE, SPU, and MFC are provided with various functions for using these channels. Each of these types of channels is described in detail below, starting with the channel used to communicate with the MFC.

MFC Command Parameter Channel MFC command parameter channel 664 is the channel used to write data to the MFC command parameter register of the MFC SPU command queue (see FIG. 2 and Table 1 above). . The MFC command parameter channel 664 is non-blocking and does not have a channel count associated with it. Thus, executing a read channel count (rchcnt) instruction sent to any of these channels returns a count of “1”.

  MFC command parameter channel 664 includes MFC local storage address channel, MFC valid address high channel, MFC valid address low or list address channel, MFC transfer size or list size channel, MFC command tag Includes an identification channel, an MFC command instruction code channel, and an MFC class ID channel. Each of these channels is described in detail below.

MFC Command Instruction Code Channel Details of the MFC command instruction code channel are shown in FIG. 10 according to an exemplary embodiment of the present invention. The MFC command instruction code channel identifies the operation to be performed based on the instruction code. The validity of this instruction code is checked asynchronously with respect to the instruction stream. If either the MFC command or command parameter is invalid, MFC command queue processing is interrupted and an invalid MFC command interrupt is generated.

  The MFC command and class ID parameters are written to the MFC SPU command queue using a single channel instruction. As shown in FIG. 10, in a preferred embodiment, the MFC command instruction code parameter is the lower 16 bits of a 32-bit word. The upper 8 bits of this field are reserved, and the lower 8 bits identify the MFC command instruction code.

MFC Class ID Channel The MFC class ID channel is used to specify a replacement class ID and a transfer class ID for each MFC command, as shown in FIG. These IDs are used by the SPU and software to improve the overall performance of the system. In particular, a replacement class ID (RclassID) is used with a replacement management table (RMT) to control cache replacement. The replacement class ID can be generated from, for example, a load-and-store address for PPE operation (the PPE cache effective management or real address for PPE load and store and instruction fetching) Including an address range function that provides a method for mapping to class IDs for).

  RclassID is used to generate an index to the privileged software management table, ie, the replacement management table (RMT) used to control the replacement policy. The format of RMT is implementation dependent. The RMT is composed of an implementation-dependent number of items, which must include a set-enable bit, a valid bit, and other control information. Optionally, the implementation may provide cache bypass bits and algorithm bits. The number of items in the RMT table and the size of each item are implementation dependent.

  FIG. 12 depicts a typical RMT entry for an 8-way set associative cache. The RMT table is located in the real address space of the system. Privileged software must map these RMT tables as privileged pages. In one implementation, one RMT must be provided for each primary cache structure.

  Returning to FIG. 11, the transfer class ID (TclassID) is used to identify access to storage with various characteristics. TclassID is used to allow an implementation to optimize transfers corresponding to MFC commands based on storage location characteristics. The setup and use of TclassID is implementation dependent.

  The contents of RclassID and TclassID are referred to hereinafter as “class ID parameters”, but are not permanent and must be written for each MFC command enqueue sequence. The class ID parameter performs the same function when used with commands issued from either the PPE side or the SPU side of the SPU command queue. The class ID parameter is used to control resources associated with the SPE and has no effect on resources associated with other SPEs or PPEs. The validity of the class ID parameter is not verified. The number of class ID parameters supported is implementation dependent.

MFC Command Tag Identification Channel The MFC command tag identification channel is used to specify one ID for each command or command group. Details of the MFC command tag identification channel are depicted in FIG. This identification tag is, for example, an arbitrary value between x′0 ′ and x′1F ′. The identification tag has a pure local scope in the hardware. Thus, the same tag can be used with different SPEs or PPEs.

  Any number of MFC commands can be tagged with the same identification code. MFC commands tagged with the same identification code are called tag groups. Tags are associated with commands written to a specific queue. The tags supplied to the MFC SPU command queue are independent of the tags supplied to the MFC proxy command queue. The contents of the MFC command tag identification parameter are not permanent and must be written for each MFC command enqueue sequence. The validity of this parameter is checked asynchronously with respect to the instruction stream. If the upper bits (eg, bits 0-10) are not set to 0, MFC command queue processing is interrupted and an interrupt is generated.

MFC transfer size or list size channel The MFC transfer size or list size channel is used to specify the size of the MFC transfer, or the size of the MFC DMA transfer list, ie, a list of DMA transfer commands. . Details of the MFC transfer size or list size channel are shown in FIG. In one general embodiment, the transfer size can have a value from 1, 2, 4, 8, 16, or multiples of 16 bytes up to a maximum of 16 KB. The MFC DMA transfer list size can have a value of 8 or multiples of 8 up to a maximum of 16 KB. The contents of the MFC transfer size or list size channel are not persistent and must be written for each MFC command enqueue sequence. The validity of this parameter is checked asynchronously with respect to the instruction stream. If the size is invalid, MFC command queue processing is interrupted and an MFC DMA alignment interrupt is generated.

MFC local storage address channel The MFC local storage address channel is used to provide the SPU local storage address associated with the MFC command to be queued. The MFC local storage address is used as the source or destination of the MFC transfer defined in the MFC command. Details of the MFC local storage address channel are shown in FIG.

  The contents of the MFC local storage address channel are not persistent and must be written for each MFC command enqueue sequence. The validity of the MFC local storage address parameter is checked asynchronously against the instruction stream. If the address is not aligned, MFC command queue processing is interrupted and an MFC DMA alignment exception is generated. To be considered aligned, for example, the least significant 4 bits of the local storage address must match the least significant 4 bits of the effective address.

MFC effective address row or list address channel The MFC effective address row or list address channel specifies a lower effective address for an MFC command or a local storage pointer that points to a list element for an MFC DMA list command Used for. If translation is enabled in the MFC status register, the effective address is translated to a real address by the PPE address translation function. FIG. 16 shows details of the MFC effective address row or list address channel.

  The contents of the MFC effective address row or list address channel are not persistent and must be written for each MFC command enqueue sequence. For transfer sizes less than 16 bytes, bits 28-31 of this parameter must provide natural alignment based on the transfer size. For a transfer size of 16 bytes or more, bits 28-31 must be "0". If translation is not available, this parameter must be within the limits of the real address space of the main storage domain. For MFC list commands, bits 29-31 of the list address must be "0". If any of these conditions are not met, the parameter is invalid and considered unaligned.

  The validity of the MFC effective address row or list address parameter is checked asynchronously against the instruction stream. For example, if the address is invalid because of a segment failure, mapping failure, protection violation, or if the address is invalid, MFC command queue processing is interrupted and an interrupt is generated. The types of interrupts that can be generated are MFC data segment interrupts, MFC data store interrupts, and DMA alignment interrupts.

MFC effective address high channel The MFC effective address high channel is used to specify an effective address for MFC commands. If translation is enabled in the MFC status register, the effective address is converted to a real address by the address translation function. Details of the MFC effective address high channel are shown in FIG.

  The contents of the MFC effective address high channel are not persistent and must be written for each MFC command enqueue sequence. If the upper 32 bits are not written, the hardware sets EAH and the upper address bits are set to 0, ie the address is between 0 and 4 GB. The validity of this parameter is checked asynchronously with respect to the instruction stream. For example, if the address is invalid due to a segment failure, mapping failure, or protection violation, MFC command queue processing is interrupted and an interrupt is generated. The types of interrupts that may be generated include MFC data segment interrupts and MFC data store interrupts. Note that the validity of the effective address is checked during the transfer. A partial transfer can be performed before an invalid address is detected and an exception is generated.

  Using the MFC command parameter channel described above, in order to queue MFC commands from the SPU, the MFC command parameters must first be written to the MFC command parameter channel. This can be done in any order except that the MFC command instruction code and class ID parameter must be written last. Therefore, the operation outlined in FIG. 18 is followed to write the MFC command parameters.

  As shown in FIG. 18, the operation includes writing the local storage address parameter to the MFC local storage address channel (step 810). The effective address high parameter is written to the MFC effective address high channel (step 820). The effective address row or list address parameter is written to the MFC effective row or list address channel (step 830). The MFC transfer or list size parameter is written to the MFC transfer size or list size channel (step 840). The MFC command tag parameter is written to the MFC command tag ID channel (step 850). After all of the above parameters are written to the respective channels, the MFC command instruction code and class ID parameters are written to the MFC instruction code and MFC class ID channel (step 860), and the operation ends. It should be understood that steps 810-850 can be performed in any order, and step 860 occurs following the writing of other parameters to the respective channel.

  The MFC command parameters are held in the MFC command parameter channel until the writing of the MFC command instruction code and class ID parameter is processed by the MFC. A write channel (wrch) instruction to the MFC command instruction code channel and MFC class ID channel causes the parameters held in the MFC command parameter channel to be sent to the MFC command queue. The MFC command parameters can be written in any order before issuing the MFC command itself to the MFC command queue. The value of the last parameter written to the MFC command parameter channel is used in the enqueue operation.

  After the MFC command is queued, the value of the MFC parameter becomes invalid and must be re-specified for the next MFC command queuing request. Failure to specify all of the required MFC parameters (ie, all parameters except the optional EAH) can lead to improper operation of the MFC command queue.

  The MFC command instruction code channel and the MFC class ID channel have a maximum count configured by the hardware depending on the number of MFC queue commands supported by the hardware. The software initializes the channel count for the MFC command opcode channel to the number of empty MFC proxy command queue slots supported by the implementation after power up and after purging the MFC proxy command queue. There must be. Also, the channel count of the MFC command instruction code channel must be saved and restored on the SPE preemptive context switch.

MFC Tag Group Status Channel As described above, each command can be tagged with an ID called an MFC command tag, for example, a 5-bit ID. The same ID can be used for multiple MFC commands. A set of commands with the same ID is defined as a tag group. The software can use the MFC command tag to check or wait for the completion of all wait commands for each tag group. In addition, the MFC command tag checks the list element to check or wait for the MFC DMA list command, to reach the element with the stop notification flag set, and to resume the MFC DMA list command. Used by software to confirm.

  First, the MFC tag group status channel will be described, and then the procedure for determining the status of the tag group and determining completion of the MFC DMA list command will be described.

  MFC tag group status channel includes MFC write tag group query mask channel, MFC read tag group query mask channel, MFC write tag status update request channel, MFC read tag group status channel, MFC read list stop notification Includes a tag status channel, an MFC write list stop notification tag acknowledge channel, and an MFC read atomic command status channel. Each of these channels is described in detail below.

MFC write tag group query mask channel The MFC write tag group query mask channel is used to select a tag group to be included in a query or wait operation. Details of the MFC write tag group query mask channel are shown in FIG.

  The data provided by this channel is held by the MFC until changed by a subsequent write channel (wrch) instruction issued for this channel. Thus, the data need not be respecified for each status query or wait. If this mask is changed by software when an MFC tag status update request is pending, the meaning of the result is ambiguous. The pending MFC tag status update request must be canceled before changing this mask. The MFC tag status update request can be canceled by writing a value of “0” (that is, immediate update) to the MFC write tag status update request channel. The current contents of this channel can be accessed by reading (rdch) the MFC read tag group query mask channel. This channel is non-blocking and has no associated count. If a read channel count (rchcnt) instruction is sent on this channel, the count is always returned as "1".

MFC read tag group query mask channel The MFC read tag group query mask channel is used to read the current value of the proxy tag group query mask register. Details of the MFC read tag group query mask channel are shown in FIG. Reading this channel always returns the data that was last written to the MFC Write Tag Group Query Mask channel. This channel can be used to avoid software shadow copies of proxy tag group query masks and for SPE context save and restore operations. This channel is non-blocking and has no associated count. Thus, if a read channel count (rchcnt) instruction is sent on this channel, the count is always returned as “1”.

MFC write tag status update request channel The MFC write tag status update request channel controls when the MFC tag group status is updated in the MFC read tag group status channel. Details of the MFC write tag status update request channel are shown in FIG.

  MFC write tag status update request channel is updated immediately or when a condition occurs, eg, when any available MFC tag group completion has a "no operation outstanding" status Or all available MFC tag groups can be specified to be updated only when they have a “no outstanding behavior” status. A write channel (wrch) instruction for this channel must occur before a read channel (rdch) from the MFC read tag group status channel occurs.

  The MFC write tag status update request must be executed after setting the tag group mask and after issuing a command for the tag group of interest. If a command for a tag group is completed before issuing an MFC write tag status update request, thereby satisfying the update status condition, the status is returned without waiting. Writing to the MFC write tag status update request channel causes a software-induced deadlock when first reading from the MFC read tag group status channel without requesting a status update.

  The previous MFC tag status update request issues an immediate update status request to the MFC write tag status update request channel and reads the count associated with the MFC write tag status update request channel until a value of “1” is returned; It can then be canceled by reading from the MFC read tag group status channel to determine and discard unwanted results.

  If a conditional update request is made twice without an intervention status read request, an unpredictable tag status is returned. To avoid unpredictable results, the software pairs the tag status read with the tag status update request unless a request cancellation is performed via an immediate update request.

  The privileged software initializes the count for this channel to “1”. When a write channel (wrch) instruction is issued for this channel, the count for this channel is set to "0". When the MFC receives the tag status update request, this count is set to “1”. This channel is write blocking enabled and has a maximum count of “1”.

MFC read tag group status channel The MFC read tag group status channel contains the status of the tag group from the last tag group status update request. Details of the MFC read tag group status channel are shown in FIG.

  Only the status of tag groups available at the time of tag group status update is valid. The bit position corresponding to the tag group that cannot be used at the time of updating the tag group status is set to “0”.

  Before reading from this channel, the MFC Write Tag Status Update Request channel must be requested. Failure to do so will result in software induced deadlock conditions. This is considered a programming error and requires privileged software to remove the deadlock condition.

  A read channel count (rchcnt) instruction sent to the MFC read tag group status channel returns “0” if the status is not yet available, and “1” if the status is available. return. This instruction can be used to avoid stopping the SPU when the MFC read tag group status channel is read. The software initializes the count for this channel to a value of “0”. This channel is enabled for read blocking and has a maximum count of “1”.

MFC Read List Stop Notification Tag Status Channel Details of the MFC read list stop notification tag status channel are shown in FIG. As described above, the list element for the MFC list command includes a stop notification flag. If the flag is set on the list element, the MFC stops executing the MFC list command, ie, the DMA list command, and sets the bit corresponding to the tag group of the MFC list command in this channel. Set. The count associated with this channel is also set to “1”. The MFC list command remains stopped until confirmed by writing the tag value to the MFC write list stop notification tag acknowledge channel.

  The MFC list stop notification function is useful when it is necessary to notify the program when the DMA list execution has reached a specific point. This is also useful when the application needs to dynamically change the list element (transfer size or effective address) that follows the stopped list element. Further, the list element can be skipped by setting the transfer size to “0”. The hardware cannot prefetch list elements beyond the stop notification element.

  The privileged software must initialize the MFC read list stop notification tag status channel count to zero. The software can determine which tag group has a command that has been stopped since the last read of this channel by reading the contents of this channel again. When a read channel (rdch) instruction is issued for this channel, all bits are reset to 0 and the count corresponding to this channel is set to “0”. Thus, issuing an unresolved list element that includes a stop notification flag set to “1” as well as a read channel (rdch) instruction that does not include any stopped commands causes a software-induced deadlock.

  Issuing a read channel (rdch) instruction on this channel when no tag group is stopped will cause SPU execution to stop until a list element with the stop notification flag set is detected. The software can also read (rchcnt) the count associated with this channel for use with the SPU event function to determine when an MFC list element with a stop notification flag set is detected. The read channel count (rchcnt) instruction sent to the MFC read list stop notification tag status channel returns “0” if no new stop MFC list command has been present since the last read of this channel. This channel is read blocking and has a maximum count of “1”.

MFC Write List Stop Notification Tag Confirmation Response Channel Details of the MFC write list stop notification tag confirmation response channel are shown in FIG. The MFC Write List Stop Notification Tag Acknowledgment Channel is used to identify a tag group that contains a stopped MFC list command on a list element that has a stop notification flag set. The tag group is confirmed by writing the MFC tag group to this channel. After writing, all stop MFC list commands in the tag group that match the value written to this channel are restarted.

  The MFC list stop notification function is useful when it is necessary to notify the program when the DMA list execution has reached a specific point. This is also useful when the application needs to dynamically change the list element (transfer size or effective address) that follows the stopped list element. Also, list elements can be skipped by setting the transfer size to zero. The hardware cannot prefetch list elements beyond the stop notification element.

  Checking tag groups that are not currently stopped by the stop notification condition is not defined. When executed in this way, an invalid status occurs in the MFC read list stop notification tag status channel. For consistency, this condition is treated as a no-op.

  This channel is a non-blocking channel and does not have an associated count. If a read channel count (rchcnt) instruction is sent on this channel, the count is always returned as "1".

MFC Read Atomic Command Status Channel Details of the MFC read atomic command status channel are shown in FIG. The MFC read atomic command status channel contains the status of the last completed immediate MFC atomic update command. An atomic command is a command that is executed without waiting for other commands in the MFC SPU queue and executed independently of other commands in the MFC SPU queue. Atomic commands supported by MFC include getllar (get lock line reservation), putllc (lock line conditional put), putlluc (lock line unconditional put), and putqlluc (standby lock line unconditional put) There are four ways. These commands conventionally perform functions similar to cacheable store instructions used by software to release "locks". The difference between the putluc command and the putqluc command is that the putqluc command is tagged, queued behind other MFC commands in the MFC SPU command queue, and the putluc command is executed immediately.

  Since the putqlluc command is tagged and has an implicit tag-specific fence, it is ordered with respect to all other commands in the same tag group that are already in the MFC SPU command queue. The getllar, putllc, and putlluc commands are not tagged and are therefore executed immediately. Even if the getlar, putllc, and putlluc commands are executed immediately, these commands still require an available slot in the MFC SPU command queue. No ordering by other commands in the MFC SPU command queue need be assumed. After issuing each getllar command, putllc command, or putlluc command, the software must issue a read from the MFC read atomic command status channel to verify the completion of the command. Issuing a channel read (rdch) instruction for this channel before issuing an immediate atomic command causes a software induced deadlock.

  The software can read the channel count (rchcnt) associated with this channel to determine if the immediate atomic MFC command is complete. If a value of “0” is returned, the immediate atomic MFC command is not complete. If a value of “1” is returned, the immediate atomic MFC command is complete and the status becomes available by reading (rdch) this channel.

  A read (rdch) from the MFC read atomic command status channel must always follow an immediate atomic MFC command. Executing multiple atomic MFC commands without intervening reads from the MFC read atomic command status channel results in an incorrect status.

  The privileged software initializes the count of this channel to “0”. This channel is read blocking and the maximum count is “1”. The contents of this channel are cleared when read. When the subsequent immediate MFC atomic update command is completed, the status of the previous MFC command is overwritten.

  The MFC tag group status channel described above is used to facilitate the determination of the status of the tag group, as well as to determine the completion of the MFC DMA list command. Three basic procedures are supported to determine tag group status: MFC read tag group status channel polling, tag group update wait or event wait, and tag group status update event interrupt Has been. The basic procedure for polling for MFC command completion or MFC command group completion is as shown in FIG.

  As shown in FIG. 26, any pending tag status update request is cleared (step 1010). This can be done, for example, by writing “0” to the MFC write tag status update request channel, reading the channel count associated with the MFC write tag status update request channel until a value of “1” is returned, and the MFC read tag group status. This can be done by reading the channel and discarding the tag status data.

  The tag group of interest is then made available by writing to the MFC write tag group query mask channel with the appropriate mask data (step 1020). Next, an immediate tag status update is requested, for example, by writing to the MFC write tag status update request channel with a value of “0” (step 1030).

  Next, a read of the MFC read tag group status channel is performed (step 1040). The data returned is the current status of each tag group with a tag group mask applied. A determination is made as to whether there are additional tag groups of interest (step 1050). If so, operation returns to step 1030. If it does not exist, the operation ends.

  The basic procedure for waiting for a tag group update or waiting for an event (one or more tag group completions) is as shown in FIG. As shown, the operation begins with clearing any pending tag status update request (step 1110). This can be done, for example, by writing “0” to the MFC write tag status update request channel, reading the channel count associated with the MFC write tag status update request channel until a value of “1” is returned, and the MFC read tag group status. This can be done by reading the channel and discarding the tag status data.

  A conditional tag status update is requested by writing to the MFC write tag status update request channel with a value of “01” or “10” (step 1120). A value of “01” specifies that a tag group update is performed when any available tag group is completed. A value of “10” specifies that all available tag groups must be completed so that an SPU tag group status update will result.

  The MFC read tag group status channel is then read to wait for the specific tag event specified in step 1120 (step 1130). By this reading, the execution of the SPU is stopped until the condition specified in step 1120 is satisfied. Alternatively, a count read associated with the MFC read tag group status channel may be performed to poll or wait for a specific tag event (step 1132).

  A determination is made as to whether the returned count has a value of “1” (step 1140). If not, operation returns to step 1132. If the count is “1”, the MFC read tag group status channel is read to determine which one or more tag groups are complete (step 1150). Next, the operation ends.

  An alternative to waiting for conditional tag events or polling for conditional tag events is to use the SPU event function. This procedure is typically used when the application is waiting for one of multiple events to occur or when the application can perform other work while waiting for command completion. This procedure is as shown in FIG.

  As shown in FIG. 28, any pending tag status update request is cleared (step 1210). As described above, this can be done, for example, by writing “0” to the MFC Write Tag Status Update Request channel, reading the channel count associated with the MFC Write Tag Status Update Request channel until a value of “1” is returned, This can be done by reading the tag group status channel and discarding the tag status data.

  One or more tag groups are selected (step 1220). Any pending tag status update event is cleared by writing to the SPU write event acknowledgment channel with a value of “1” (step 1230). By writing “1” to the SPU write event mask channel, the MFC tag group status update event is unmasked (step 1240). Next, the SPU read event status channel is read to wait for an available event to occur (step 1250). This reading stops the execution of the SPU until a usable event occurs. Alternatively, the count associated with the SPU read event status channel can be read to poll or wait for a particular tag event until the count is returned as “1”.

  The SPU read event status channel is read and a determination is made as to whether an available event has occurred (step 1260). If not, operation returns to step 1250. If an available event occurs, the MFC read tag group status channel is read to determine which tag or tag group caused the event (step 1270). Next, the operation ends.

  Polling the MFC read list stop notification tag status channel, waiting for an MFC DMA list command stop notification event, and determining whether the MFC DMA list command has reached the list element with the stop notification flag set, and Three basic procedures are supported: interrupting an MFC DMA list command stop notification event. The basic procedure for polling to determine if the MFC DMA list command has reached the list element with the stop notification flag set is as shown in FIG.

  As shown in FIG. 29, operation begins with an MFC DMA list command having a list element with a stop notification flag set (step 1310). The count associated with the MFC read list stop notification tag status channel is read (rchcnt) until a value of “1” is returned (step 1320). If a value of “1” is returned (step 1330), the MFC read list stop notification tag status channel is read (rdch) (step 1340). The data returned is the current status of each tag group, which has reached the list element with the stop notification flag set since the last read of this channel.

  A determination is made as to whether one or more tag groups of interest have reached the list element with the stop notification flag set (step 1350). If not, operation returns to step 1340 until one or more tag groups of interest reach the list element with the stop notification flag set.

  If one or more tag groups of interest have reached a list element with the stop notification flag set, the tag corresponding to the stopped tag group to resume the MFC DMA list command Write to the MFC write list stop notification tag confirmation response channel using the group number (wrch) (step 1360). Next, the operation ends.

  The basic procedure for waiting for an MFC DMA list command to reach a list element with a stop notification flag set is as shown in FIG. As shown, operation begins with an MFC DMA list command having a list element with a stop notification flag set (step 1410). The reading (rdch) of the MFC reading list stop notification tag status channel is executed (step 1420). The data returned is the current status of each tag group that has reached the list element with the stop notification flag set since the last read of this channel. This reading stops the SPU until the MFC DMA list command reaches the list element with the stop notification flag set.

  A determination is made as to whether one or more tag groups of interest have reached the list element with the stop notification flag set (step 1430). The corresponding bit is set in the return data. Because the bit is reset with each read, the software must perform tag group accumulation while waiting for multiple tag groups to stop.

  If not, operation returns to step 1420 until one or more tag groups of interest reach the list element with the stop notification flag set. If so, a write (wrch) is performed on the MFC write list stop notification tag acknowledge channel with the tag group number corresponding to the stopped tag group to restart the MFC DMA list command. (Step 1440).

  An alternative to waiting for list stop notification tag group status or polling for list stop notification tag group status is to use the SPU event function. This procedure is typically used when other work can be performed by the SPU program while the MFC DMA list command is being executed. This procedure is, for example, as outlined in FIG.

  As shown in FIG. 31, the procedure begins with clearing any pending MFC DMA list command stop notification event (step 1510). This can be done, for example, by writing to the SPU write event acknowledgment channel with a value of “1”. The MFC DMA list command stop notification event is enabled by writing “1” to the Sn bit of the SPU write event mask channel (step 1520). An MFC DMA list command having a list element with a stop notification flag set is issued (step 1530).

  To wait for an available event to occur, a read (rdch) from the SPU read event status channel may be performed (step 1540). This reading stops the execution of the SPU until a usable event occurs. Instead, the count read count (rchcht) associated with the SPU read event status channel is removed to poll for a specific tag event until the count is returned as "1".

  A determination is made as to whether a usable event has occurred (step 1550). If not, operation returns to step 1540. If an available event has occurred, a determination is made as to whether a DMA list stop notification event has occurred (step 1560). If no DMA list stop notification event has occurred, operation returns to step 1540.

  If a DMA list stop notification event has occurred, a read (rdch) from the MFC read list stop notification tag status channel is performed to determine which tag group or groups caused the event (step rdch). 1570). Next, in order to restart the MFC DMA list command, writing to the MFC write list stop notification tag confirmation response channel (wrch) is performed with the tag group number corresponding to the stopped tag group (step 1580). .

MFC Write Multi-Source Synchronization Request Channel Details of the MFC Write Multi-Source Synchronization Request Channel are shown in FIG. The MFC write multi-source synchronization request channel is part of the MFC multi-source synchronization function and causes the MFC to start tracking outstanding transfers sent to the associated MFC. The MFC multi-source synchronization function includes an MFC multi-source synchronization register that allows the processor or device to control synchronization from the main storage address domain, and an MFC that allows the SPU to control synchronization from the local storage address domain. And a write multi-source synchronization request channel (MFC_WrMSSyncReq).

  Synchronization can be requested by writing to the MFC write multi-source synchronization request channel. When the requested synchronization is complete, the channel count is set to the original “1” and data written to this channel is ignored. When the second write is performed on this channel, the SPU is stopped until the outstanding transfer tracked by the first write is completed.

  To use the MFC write multi-source sync request channel, the program writes to the MFC write multi-source sync request channel and then waits for the MFC write multi-source sync request channel to be available, i.e. the channel count is original Wait for the time set to “1”. The software initializes the count for this channel to a value of “1”. This channel is write blocking enabled and has a maximum count of “1”.

Mailbox Function In addition to the channel for communicating with the MFC, the channel interface of the present invention further provides a channel for communicating with the mailbox function provided in the SPU. The MFC provides a set of mailbox queues between the SPU and other processors and devices. Each mailbox queue is assigned an SPU channel as well as a corresponding MMIO register. SPU software accesses the mailbox queue by using SPU channel instructions. Other processors and devices access the mailbox queue by using one of the MMIO registers. In addition to queues, the MFC provides queue status, mailbox interrupts, and SPU event notifications for mailboxes. MMIO registers, channels, status, interrupts, mailbox queues, and events are collectively referred to as “mailbox functions”. As described above, the mailbox function is provided in the MFC register unit 250 of FIG.

  To send information from the SPU to other processors or other devices, two mailbox queues are provided by the MFC: the SPU outbound mailbox queue and the SPU outbound interrupt mailbox queue. These mailbox queues are for sending short messages (eg, return codes or status) to the PPE. Data written to one of these queues by the SPU using a write channel (wrch) instruction is available to any processor or device by reading the corresponding MMIO register.

  An interrupt can also be sent to a processor or other device in the system by a write channel (wrch) instruction sent to the SPU write outbound interrupt mailbox channel. An MMIO read from either one of these queues (SPU outbound mailbox or SPU outbound interrupt mailbox register) can set an SPU event, which in turn causes an SPU interrupt.

  One mailbox queue, ie, the SPU inbound mailbox queue, is provided for either the external processor or other device to send information to the SPU. This mailbox queue is for writing by the PPE. However, other mailboxes, SPUs, or other devices can also use this mailbox queue. Data written to this queue by a processor or other device using MMIO writes is available to the SPU by using the SPU read inbound mailbox channel. An MMIO write to the SPU inbound mailbox register can set an SPU event, which in turn can trigger an SPU interrupt.

  The SPU outbound mailbox register is used to read 32 bits of data from the corresponding SPU outbound mailbox queue. The SPU outbound mailbox register has a corresponding SPU write outbound mailbox channel for writing data to the SPU outbound mailbox queue. A write channel (wrch) instruction sent to the SPU outbound mailbox queue reads the 32-bit instruction specified in that instruction for reading by other processors or other devices. To load. If the SPU outbound mailbox queue is full, the SPU stops on the write channel (wrch) instruction sent to this queue until an MMIO read from this mailbox register occurs.

  An MMIO read of this register always returns information in the order in which it was written by the SPU. The information returned when reading from an empty SPU outbound mailbox queue is undefined. The number of items (or the number of queue items) in the SPU outbound mailbox queue is implementation dependent.

  A MMIO read of the SPU mailbox status register returns the status of the mailbox queue. The number of valid queue items in the SPU outbound mailbox queue is indicated in the SPU_Out_Mbox_Count field of the SPU mailbox status register. A MMIO read of the SPU outbound mailbox register sets a pending SPU outbound mailbox available event. SPU read event if the amount of data remaining in the mailbox queue is less than the implementation dependent threshold and this condition is available (ie, SPU_WrEventMask [Le] is set to “1”) The status channel is updated (ie, SPU_RdEventStat [Le] is set to “1”) and its channel count is set to “1”. This causes an SPU outbound interrupt mailbox available event.

  The SPU inbound mailbox register is used to write 32-bit data to the corresponding SPU inbound mailbox queue. The SPU inbound mailbox queue has a corresponding SPU read inbound mailbox channel to read data from this queue. The read channel (rdch) instruction for the SPU read inbound mailbox channel loads 32-bit data from the SPU inbound mailbox queue into the SPU register specified by the read channel (rdch) instruction. The SPU cannot read from an empty mailbox. If the SPU inbound mailbox queue is empty, the SPU stops on a read channel (rdch) instruction for this channel until data is written to this mailbox. A read channel (rdch) instruction for this channel always returns information in the order in which it was written by the PPE or other processor and device.

  The number of items in this queue (or the number of queue items) is implementation dependent. A MMIO read of the SPU mailbox status register returns the status of the mailbox queue. The number of available queue positions in the SPU mailbox queue is indicated in the SPU_In_Mbox_Count field of the SPU mailbox status register (ie, SPU_Mbox_Stat [SPU_In_Mbox_Count]).

  The software checks the SPU mailbox status register before writing to SPU_In_Mbox to avoid SPU mailbox overruns. A MMIO write to the SPU inbound mailbox register sets a pending SPU mailbox event. If enabled (ie, SPU_WrEventMask [Mbox] = “1”), the SPU read event status channel is updated and its channel count is set to “1”, which sets the SPU inbound mailbox available event cause.

  The SPU mailbox status register contains the current state of the mailbox queue between the SPU and the PPE in the corresponding SPE. Reading this register has no effect on mailbox queue status.

SPU Mailbox Channel As noted above, the mailbox functions provided by MFC include multiple, including SPU write outbound mailbox channels, SPU write outbound interrupt mailbox channels, and SPU read inbound mailbox channels. Includes SPU mailbox channels. These SPU mailbox channels are defined as blocking, that is, stop the SPU when the channel is full (write blocking) or when data is unavailable (read blocking). Channel blocking methods are very useful for labor saving when the application has no other work to do. In essence, the processor can be placed in a low power state until space is freed or data is available.

  These channels are blocking and thus benefit from saving power, but accessing these channels may cause the SPU to stop for an indefinite period of time. The software can avoid SPU outages by using the SPU event function as discussed below or by reading the channel count associated with the mailbox channel.

SPU Write Outbound Mailbox Channel FIG. 33 shows details of an SPU write outbound mailbox channel according to an exemplary embodiment of the invention. A write channel instruction (wrch) sent to this channel writes data to the SPU write outbound mailbox queue. Data written to this channel by the SPU is available for MMIO reading of the SPU outbound mailbox register. The write channel (wrch) to this channel also decrements the associated channel count by “1”. When writing to a full SPU write outbound mailbox queue, the SPU execution is stopped until the SPU outbound mailbox register is read and the position in the SPU write outbound mailbox queue is released.

  To avoid a stop condition, before issuing a channel write, the channel count associated with this channel can be read to ensure that a slot exists in the SPU write outbound mailbox queue. Alternatively, if it is determined that it is full, the SPU outbound mailbox availability event can be used to signal the availability of slots in the SPU write outbound mailbox queue.

  Reading the channel count associated with this channel when the SPU write outbound mailbox queue is full returns a value of "0". A non-zero value indicates the number of free 32-bit words in the SPU write outbound mailbox queue.

  The privileged software initializes the SPU write outbound mailbox channel count to the number of entries in the SPU write outbound mailbox queue. This channel is write blocking. The maximum count for this channel is implementation dependent and must be the number of entries in the SPU write outbound mailbox queue (ie, the number of available slots).

SPU Write Outbound Interrupt Mailbox Channel FIG. 34 shows details of an SPU write outbound interrupt mailbox channel according to an exemplary embodiment of the invention. A write channel (wrch) instruction to this channel writes data to the SPU write outbound interrupt mailbox queue. Data written to this channel by the SPU will be available for MMIO reads of the SPU outbound interrupt mailbox register.

  Also, the write channel (wrch) command to the SPU write outbound mailbox channel decrements the associated count by “1”. When writing to a full SPU write outbound interrupt mailbox queue, the SPU outbound interrupt mailbox register is read and SPU execution is stopped until the position in the SPU write outbound interrupt mailbox queue is released.

  To avoid a stop condition, before issuing a channel write, the channel count associated with this channel can be read to ensure that there is a slot in the SPU write outbound interrupt mailbox queue. Alternatively, if it was previously full, the SPU Outbound Interrupt Mailbox Enable event can be used to signal the availability of slots in the SPU Write Outbound Interrupt Mailbox queue. An interrupt is also sent to the processor or other device by a write channel (wrch) instruction to the SPU write outbound interrupt mailbox channel. There is no ordering of interrupts and previously issued MFC commands.

  Reading the channel count associated with this channel when the SPU write outbound interrupt mailbox queue is full returns a value of "0". A non-zero count value has the number of free 32-bit words in this queue.

  The privileged software initializes this channel count to the number of entries in the SPU write outbound interrupt mailbox queue. This channel is write blocking. The maximum count for this channel is implementation dependent and must be the number of entries in the SPU write outbound interrupt mailbox queue (ie, the number of available slots).

SPU Read Inbound Mailbox Channel FIG. 35 shows details of an SPU read inbound mailbox channel according to an exemplary embodiment of the invention. Reading from this channel returns the next data in the SPU read inbound mailbox queue. Data is placed in the SPU read inbound mailbox queue by a processor or device that issues a write to the SPU inbound mailbox register.

  Reading from this SPU read inbound mailbox channel decrements the associated count by “1”. When reading from an empty mailbox, the SPU inbound mailbox register is written and SPU execution is stopped until a data item is placed in the SPU read inbound mailbox queue. To avoid a stop condition, before issuing a channel read, the channel count associated with this channel can be read to ensure that data is present in the SPU read inbound mailbox queue. Alternatively, the SPU inbound mailbox availability event can be used to signal the availability of data in the SPU read inbound mailbox queue.

  If the mailbox is empty, reading the channel count (rchcnt) returns a value of “0”. If the rchcnt result is non-zero, the mailbox contains information that was written by the PPE but not read by the SPU.

  The channel count of the SPU read inbound mailbox channel is initialized to “0” by privileged software. The maximum count is implementation dependent. This channel is read blocking.

SPU Signal Notification Function The MFC provides an SPU signal notification function that is used to send signals such as buffer completion flags from other processors and devices in the system to the SPU. This signal notification function can be provided, for example, in the MFC register unit 250 of FIG.

  BPA provides two independent signal notification functions, SPU signal notification 1 and SPU signal notification 2. Each function is composed of one register and one channel, an SPU signal notification 1 register and an SPU signal notification 1 channel, an SPU signal notification 2 register and an SPU signal notification 2 channel.

  A signal is issued by the SPU using a set of transmit signal commands having the effective address of the signal notification register associated with the SPU to which the signal is transmitted. PPE and other devices that do not support transmit signal commands simulate the transmission of signal commands by performing an MMIO write to the SPU signal notification register associated with the SPU to which the signal is to be transmitted.

  Each of the signaling functions can be programmed according to either an overwrite mode useful in a one-to-one signaling environment or an OR mode useful in a many-to-one signaling environment. The mode for each channel is set in the SPU configuration register.

  Executing either a transmit signal command or MMIO targeting a signaling register programmed according to the overwrite mode sets the contents of the associated channel to the data of the signaling operation. It also sets the corresponding channel count to “1”. In the OR mode, the signaling operation data is ORed with the current contents of the channel, and the corresponding count is set to a value of “1”.

  In addition, the signal notification register is used as the effective address of the image when performing an isolated load. In these cases, the SPU signal notification 1 register contains the upper 32 bits of the 64-bit effective address, and the SPU signal notification 2 register contains the least significant 32 bits. The software must have an SPU signal notification function in overwrite mode before setting the effective address for proper operation of the separate load request.

SPU signaling channel The SPU signaling channel is the PPE part of the SPU signaling function. This channel is used to read signals from other processors and other devices in the system. The signaling channel is configured as read blocking with a maximum count of “1”. When a read channel (rdch) instruction is sent to one of these channels and the associated channel count is “1”, the current contents of that channel and associated count are reset to “0”. When a read channel (rdch) instruction is sent to one of these channels and the channel count is “0”, the SPU stops until the processor or device performs an MMIO write to the associated register.

SPU Signal Notification Channel FIG. 36 shows details of an SPU signal notification channel according to an exemplary embodiment of the present invention. The signaling channel can be SPU signaling 1 or 2 channels. A read channel (rdch) instruction sent to the SPU signaling channel returns the 32-bit value of signal control word 1 and resets any bits set when read to an atomic expression. If no signal is pending, reading from this channel stops the SPU until a signal is issued. If no signal is pending, the read channel count (rchcnt) instruction sent to this channel returns “0”. If an unread signal is pending, it returns “1”.

  The privileged software initializes the count for this channel to a value of “0”. This channel is enabled for read blocking and the maximum count is “1”.

SPU decrementer Each SPU includes a 32-bit decrementer. If available in the MFC control register, MFC_CNTL [Dh] is set to “0” and written. The SPU decrementer is started when a write channel (wrch) instruction is issued to the SPU write decrementer channel. The decrementer stops when the program sequence described below is followed or when the MFC_CNTL [Dh] is set to “1” and the MFC control register is written. The current execution status of the decrementer is available in the MFC control register (ie, MFC_CNTL [Ds]). A decrementer event need not be pending to stop the decrementer.

  Two channels are allocated to manage the decrementer, one for setting the decrementer value and one for reading the current contents of the decrementer. When the most significant bit (bit 0) changes from “0” to “1”, a decrementer event occurs.

SPU Write Decrementer Channel FIG. 37 shows details of an SPU write decrementer channel according to an exemplary embodiment of the invention. The SPU write decrementer channel is used to load a 32-bit value into the decrementer. The value loaded into the decrementer determines the elapsed time between the write channel (wrch) instruction and the decrementer event. When the most significant bit (msb) of the decrementer changes from “0” to “1”, an event occurs. If the value loaded into the decrementer causes a change from “0” to “1” in msb, the event is notified immediately. Setting the decrementer to a value of “0” causes an event to occur after a single decrementer interval.

To properly save and restore the decrementer state, the decrementer must stop before changing the decrementer value. The following sequence outlines the procedure for setting a new decrementer value.
1. Write to the SPU write event mask channel to disable the decrementer event.
2. Write to the SPU Write Event Acknowledgment channel to acknowledge any pending events and stop the decrementer. Since the decrementer event is disabled in step 1, the decrementer stops.
3. Write to the SPU write decrementer channel to set a new decrementer count value. (Note: Since the decrementer was stopped in step 2, the decrementer is started.)
4). Write to the SPU write event mask channel to enable the decrementer event.
5. Wait for the timer to expire.

  This channel is non-blocking and has no associated count. When a read channel count (rchcnt) instruction is sent to this channel, the count is always returned as "1".

SPU Read Decrementer Channel FIG. 38 shows details of an SPU read decrementer channel according to an exemplary embodiment of the invention. The SPU read decrementer channel is used to read the current value of the 32-bit decrementer. Reading the decrementer count has no effect on the accuracy of the decrementer. Reading the decrementer continuously returns the same value.

  This channel is non-blocking and has no associated count. When a read channel count (rchcnt) instruction is sent to this channel, the count is always returned as "1".

SPU state management channel In addition to the above, an SPU state management channel is provided. These SPU state management channels include one SPU read machine status channel and two interrupt related status channels. The interrupt-related state channels include an SPU write state storage / restoration channel and an SPU read state storage / restoration channel.

SPU Read Machine Status Channel FIG. 39 shows details of the SPU read machine status channel according to an exemplary embodiment of the invention. The SPU read machine status channel contains current SPU machine status information. This channel contains two status bits: isolation status and SPU interrupt status. This separation situation reflects the current operating state of the SPU, separated or non-isolated.

  The SPU interrupt enable status reflects the current state of SPU interrupt enable. If available, an SPU interrupt is generated if there are any available SPU events.

  This channel is non-blocking and has no associated count. When a read channel count (rchcnt) instruction is sent to this channel, the count is always returned as "1".

SPU Write State Save / Restore Channel FIG. 40 shows details of an SPU write state save / restore channel according to an exemplary embodiment of the invention. By writing to this channel, the contents of the state save / restore register 0 (SRR0) in the SPU are updated. This channel write is typically used to restore interrupt state information when nested interrupts are supported.

  Do not write to this channel when SPU interrupts are enabled. When executed in this way, the contents of SRR0 become indeterminate. The channel form of the synchronous instruction must be issued after writing this channel and before executing instructions that depend on the contents of SRR0.

  This channel is non-blocking and has no associated count. When a read channel count (rchcnt) instruction is sent to this channel, the count is always returned as "1".

SPU Read State Save / Restore Channel FIG. 41 shows details of the SPU read state save / restore channel. Reading this channel returns the contents of state save / restore register 0 (SRR0) in the SPU. This channel read is typically used to store interrupt state information when nested interrupts are supported.

  This channel is non-blocking and has no associated count. When a read channel count (rchcnt) instruction is sent to this channel, the count is always returned as "1".

SPU Event Function FIG. 42 is an exemplary block diagram illustrating a logical representation of the SPU event function. As shown in FIG. 42, an edge-triggered event sets the corresponding bit in the SPU pending event register 2110 to “1”. The event in the SPU pending event register 2110 is acknowledged by writing a “1” to the corresponding bit in the SPU write event acknowledge channel 2120 using the channel instruction.

  The SPU pending event register (Pend_Event) 2110 is an internal register. The SPU pending event register 2110 can be read using the SPU channel access function.

  Reading the SPU read event status channel 2130 with a read channel (rdch) instruction returns the value in the SPU pending event register that is logically ANDed with the value in the SPU write event mask channel 2140. This feature provides only the status of available events to the SPU program, and the SPU pending event register 2110 allows privileged software to acknowledge all events as they occur. Access to all events is required for the SPU context save and restore operation.

  The contents of the SPU read event status channel 2130 change when a new value is written to the SPU write event mask channel 2140 or when a new event is recorded in the SPU pending event register 2110. When the bit in SPU read event status channel 2130 changes from “0” to “1”, the SPU read event status channel count is incremented by “1”. This count is also incremented if an event is still set in the SPU read event status channel 2130 after a write is sent to the SPU write event acknowledgment channel 2120. This count is decremented by “1” when the SPU read event status channel 2130 is read using a channel read (rdch) instruction. This count is saturated at a value of “1” and is not decremented below a value of “0”. If the SPU read event status channel count is non-zero, an interrupt condition is sent to the SPU if available.

SPU Event Channel An SPU program can monitor events using several SPU event channels. These SPU event channels include an SPU read event status channel, an SPU write event mask channel, an SPU read event mask channel, and an SPU write event acknowledge channel. The SPU read event status channel contains the status of all events available in the SPU write event mask channel. The SPU write event acknowledgment channel is used to reset the status of the event, which is usually an indication that the event has been processed or recorded by the SPU program. If there are no events available, reading from the SPU read event status channel stops the SPU program.

  If an event does not occur when an individual event has a similar method for stopping the SPU program, the SPU event function looks for multiple events and a method for generating an interrupt for the SPU program To the software.

SPU Read Event Status Channel FIG. 43 shows details of an SPU read event status channel according to an exemplary embodiment of the invention. The SPU read event status channel contains the current status of all events available by the SPU write event mask channel when this channel is read. If the SPU write event mask channel specifies that an event is not part of the query, the corresponding position will be “0” in the reported situation.

Reading from an SPU read event status channel with a channel count of “0” causes an SPU stop, thereby providing an “event wait” function. Reading from this channel with a channel count of “1” returns the status of any available and pending events and sets the channel count to “0”. The channel count is set to “1” under the following conditions.
An event occurs and the corresponding mask is “1” in the SPU write event mask channel.
• A “1” in the bit position corresponding to “1” in the SPU pending event register is written to the SPU write event mask channel.
• An available event is pending after writing the SPU Write Event Acknowledgment channel.
• The privileged software sets the channel count to “1” using the SPU channel access function.

  If no event has occurred, the read channel count (rchcnt) instruction of the SPU read event status channel returns zero. A read channel count (rchcnt) instruction can be used to avoid stopping the SPU when reading event status from the SPU read event status channel.

  The privileged software must initialize the count value of the SPU read event status channel to “0”. The channel count is initialized using the SPU channel count register in the SPU channel access function. If SPU interrupts are enabled (SPU_RdMachStat [IE] is set to “1”), an interrupt is issued to the SPU if the SPU read event status channel count is non-zero.

Note that in the following two cases the software can trigger a phantom event.
1. If the software acknowledges or masks the event after the event increments the SPU read event status channel count before reading the event status from the SPU read event status channel. In this case, reading the SPU read event status channel returns data indicating that the event no longer exists or is unavailable.
2. The software resets an interrupt condition for an available event (such as a read from a mailbox) before reading the SPU read event status channel and before confirming the event. In this case, reading the event status register returns data indicating that the event is still pending, even if the condition that generated the event no longer exists. In this case, the event must still be acknowledged.

To avoid generating phantom events, events must be handled as follows:
Read the SPU read event status channel.
For all events to be processed, acknowledge the event by writing the corresponding bit into the SPU write event acknowledge channel.
Process the event (eg, read the mailbox, reset or stop the timer, or read the signal notification register).

SPU Write Event Mask Channel FIG. 44 shows details of an SPU write event mask channel according to an exemplary embodiment of the invention. The SPU write event mask channel selects which pending events affect the state of the SPU read event status channel. The contents of this channel are preserved until a subsequent channel write or SPU channel access occurs. The current contents of this channel can be accessed by reading the SPU read event mask channel.

  Regardless of the SPU event mask setting, all events are recorded in the SPU pending event registry. The event remains pending until cleared by a write channel (wrch) instruction to the SPU Write Event Acknowledgment Channel, or the privileged software uses the SPU channel access function to put a new value in the SPU Pending Event Register Load it. A pending event is cleared even if it is unavailable.

  Pending events that are disabled and subsequently cleared are not reflected in the SPU read event status channel. Enabling the pending event updates the SPU read event status channel, and if it is enabled, an SPU interrupt is generated.

  This channel is non-blocking and has no associated count. The read channel count (rchcnt) instruction for this channel always returns “1”.

SPU Read Event Mask Channel FIG. 45 shows details of an SPU read event mask channel according to an exemplary embodiment of the invention. The SPU read event mask channel is used to read the current value of the event status mask. Reading this channel always returns the last data written by the SPU write event mask channel. This channel can be used to avoid software shadow copying of event status masks, as well as for SPU context save and restore operations. This channel is non-blocking and has no associated count. When a read channel count (rchcnt) instruction is sent to this channel, the count is always returned as "1".

SPU Write Event Acknowledgment Channel FIG. 46 shows details of an SPU write event acknowledgment channel according to an exemplary embodiment of the invention. Writing to the SPU Write Event Acknowledgment channel with a specific event bit set confirms that the corresponding event is being processed by software. Confirmed events are reset and re-extracted. Events that are reported but not acknowledged continue to be reported until acknowledged or cleared by privileged software using the SPU channel access function.

  The unavailable event is not reported on the SPU read event status channel, but is held as pending until cleared by writing a “1” to the corresponding bit in the SPU write event acknowledgment channel. Acknowledging an unusable event clears the event even if it has not been reported. Clearing the event before it occurs causes a software-induced deadlock.

  This channel is non-blocking and has no associated count. When a read channel count (rchcnt) instruction is sent to this channel, the count is always returned as "1".

SPU event The hardware determines the event by detecting the appropriate channel count, decrementer count, or SPU channel access operation. Several different types of events are supported by the BPA described above. For example, an MFC tag group status update event is set when the count for an MFC read tag group status channel changes from 0 to a non-zero value. The MFC DMA list command stop notification event is set when the count for the MFC read list stop notification tag status channel changes from 0 to a non-zero value. The MFC SPU command queue enable event is set when the count for the standby MFC command instruction code register changes from 0 (full) to a non-zero value (not full). The SPU inbound mailbox enable event is set when the count for the SPU read inbound mailbox channel changes from 0 to a non-zero value.

  Similarly, the SPU decrementer event is set when the most significant bit of the decrementer count changes from 0 to 1. If the most significant bit changes from 0 to 1 due to the value loaded into the decrementer, the event is notified immediately. Setting the decrementer value to 0 causes an event to occur after a single decrementer interval.

  In addition, the SPU Outbound Mailbox Enable event is set when the SPU Write Outbound Interrupt Mailbox Channel Count changes from 0 to a non-zero value. The SPU signal notification 1 or 2 availability event is set when the count for the corresponding SPU signal notification channel changes from 0 to a non-zero value. A lock line reservation event is set when an atomic reservation disappears (see the section "Lock Line Reservation Lost Event" below). A privileged attention event is set when the attention event request bit is set to 1 and written to the SPU privilege control register (see “Privileged Attention Event” section below). A multi-source sync event is set when the MFC write multi-source sync request channel count changes from a value of 0 to a value of 1. Next, these events will be described in more detail.

MFC tag group status update event An MFC tag group status update event is read without stopping the SPU when one or more tag groups are complete, the MFC read tag group status channel is updated. It is used to notify the SPU program that it can (see the section on “MFC Tag Group Status Channel” above). This event occurs when the channel count for the MFC read tag group status channel changes from “0” to “1”. When this event occurs, Pend_Event [Tg] is set to “1”. If this event is available (ie, SPU_RdEventStat [Tg] is set to “1”), the count for the SPU event status channel is set to “1”.

  The Pend_Event [Tg] bit is used when privileged software is used when a channel write (wrch) is issued to the SPU pending event register or using the SPU channel access function with the corresponding bit set to '0'. Set to "0" when the SPU pending event register is updated. This event must be cleared before issuing any command for one or more tag groups.

MFC DMA list command stop notification event The MFC DMA list command stop notification event indicates that the list element in the MFC DMA list command has been completed, the MFC read list stop notification tag status channel has been updated, and the SPU Used to notify the SPU program that it can read without stopping. This event occurs when the channel count for the MFC read list stop notification tag status channel changes from “0” to “1”.

  This count is set to “1” when all transfers of list elements with the stop notification flag set as well as transfers for all previous list elements in the MFC DMA list command have been completed for the associated SPU. Is done. When this event occurs, Pend_Event [Sn] is set to “1”. If this event is available (ie, SPU_RdEventStat [Sn] is set to “1”), the count for the SPU read event status channel is set to “1”. The Pend_Event [Sn] bit is set when a channel write (wrch) is issued to the SPU write event acknowledgment channel with the tag bit set to “1” (SPU_WrEventAck [Sn]) or the corresponding bit is “ Set to “0” when privileged software updates the SPU pending event register using the SPU channel access function set to “0”.

  An overview of the procedure for processing an MFC DMA list command stop notification event is shown in FIG. As shown in FIG. 47, the procedure begins by executing a read channel (rdch) instruction for the SPU read event mask channel and storing the data in a “mask” (step 2310). The event is masked by issuing a write channel instruction to the SPU write event mask channel with SPU_WrEvent Mask [Sn] set to “0” (step 2320). The event is confirmed by executing a write channel (wrch) command to the SPU write event acknowledge channel with SPU_WrEventAck [Sn] set to 1 (step 2330).

  Next, a read channel (rdch) command is transmitted to the MFC read list stop notification tag status channel MFC_StallStat [gn] (step 2340). The returned information is used to determine which tag group or groups have the DMA list element in the stop notification state (step 2350). Next, application-specific actions are performed for each tag group having a stop DMA list element (step 2360).

  Each stopped DMA list is issued by issuing a write channel (wrch) command to the list stop notification tag confirmation response channel MFC_StallAck [MFC Tag], which is the coded tag ID of the tag group to be restarted by the supplied MFC tag. The command is confirmed and resumed (step 2370). Next, the DMA list stop notification handler ends (step 2380). Note that if the application software does not verify all stop tag groups indicated in the MFC_StallStat [gn] channel, a second stop notification event will not occur for the unconfirmed tag group.

  The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 2390). Next, the general event handler ends (step 2395).

  When a DMA list includes a plurality of list elements with a stop notification flag set and / or when a tag group has a plurality of DMA list commands queued with an element with a stop notification flag set Note that the application software initializes the tag group specific stop counter to 0 before the DMA list command is queued for that tag group. In addition, when multiple DMA list commands are queued for a tag group with a stop notification element, ordering is performed by tag-specific fences, barriers, or command barriers. Each time a stop notification status is indicated for a tag group, the corresponding counter must be incremented. The application software can then use this counter to determine at which point in the list the outage occurred.

  The application software uses the stop notification to update the list element address and transfer size according to the list element that has stopped due to dynamically changing conditions. A list element after a stop list element can be skipped by setting its transfer size to zero. However, the number of list elements in the waiting DMA list command cannot be changed.

MFC SPU command queue enable event The MFC SPU command queue enable event indicates that an entry in the MFC SPU command queue is available and can be written to the MFC command opcode channel without stopping the SPU. Used to notify the SPU program. This event occurs when the channel count for the MFC command instruction code channel changes from “0” (full) to a non-zero (not full) value.

  This count is set to “1” when one or more MFC DMA commands in the MFC SPU command queue are completed. When this event occurs, Pend_Event [Qv] is set to “1”. If this event is enabled (ie, SPU_RdEventMask [Qv] is set to “1”), SPU_RdEventStat [Qv] is set to “1” and the count for the SPU read event status channel is set to “1”. Is set. The Pend_Event [Qv] bit is set when a channel write (wrch) is issued to the SPU write event acknowledgment channel (ie, SPU_WrEventAck [Qv] is set to “1”) or the corresponding bit is “0”. Set to "0" when privileged software updates the SPU pending event register using the SPU channel access function set to "".

  An overview of the procedure for handling MFC SPU command queue available events is shown in FIG. As shown in FIG. 48, the procedure begins by sending a read channel (rdch) command to the SPU read event mask channel and the data in the “mask” is saved (step 2410). The event is masked by issuing a write channel instruction to the SPU write event mask channel with SPU_WrEventMask [Qv] set to “0” (step 2420). The event is confirmed by executing a write channel (wrch) command to the SPU write event acknowledge channel with SPU_WrEventAck [Qv] set to 1 (step 2430).

  A channel count is obtained by issuing a read channel count (rchcnt) instruction to the MFC command instruction code channel (MFC_CMD) (step 2440). A determination is made as to whether the channel count is “0” (step 2450). If not "0", the DMA command is enqueued into the MFC command queue (step 2460). Next, a determination is made as to whether additional commands remain in the queue (step 2470). If so, the procedure returns to step 2430. If there are no additional commands left or the channel count is “0”, the SPU command queue handler ends (step 2480). Next, the mask is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel (step 2490). Next, the general event handler ends (step 2495).

SPU Inbound Mailbox Enable Event The SPU Inbound Mailbox Enable Event is a PPE or other device that writes to an empty SPU mailbox and reads the SPU read inbound mailbox channel (page 124) without stopping the SPU. Used to notify the SPU program that it can be read. If this event is available (ie, SPU_RdEventStat [Mb] is “1”), the count for the SPU read event status channel is set to “1”.

  This event occurs when the channel count for the SPU read inbound mailbox channel changes from “0” (empty) to a non-zero (non-empty) value. When this event occurs, Pend_Event [Mb] is set to “1”. The Pend_Event [Mb] bit is used when a channel write (wrch) is issued to the SPU write event acknowledgment channel (that is, SPU_WrEventAck [Mb] is set to “1”) or the corresponding bit is “ Set to “0” when privileged software updates the SPU pending event register using the SPU channel access function set to “0”.

  An overview of the procedure for handling SPU inbound mailbox availability events is shown in FIG. As shown in FIG. 49, the procedure begins by sending a read channel (rdch) instruction to the SPU read event mask channel and storing the data in a “mask” (step 2510). Next, the event is masked by issuing a write channel instruction to the SPU write event mask channel with SPU_WrEvent [Masking] set to “0” (step 2520). The event is confirmed by executing a write channel (wrch) command to the SPU write event acknowledge channel with SPU_WrEventAck [Sn] set to 1 (step 2530).

  The channel count is obtained by issuing a read channel count (rchcnt) instruction to the SPU read inbound mailbox channel (step 2540). A determination is made as to whether the channel count is “0” (step 2550). If not "0", the next mailbox data item is read by issuing a read channel (rdch) instruction to the SPU read inbound mailbox channel (SPU_RdInMbox) (step 2560). The procedure then returns to step 2530.

  If the channel count is “0”, the SPU inbound mailbox handler ends (step 2570). The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 2580). Next, the general event handler ends (step 2590).

SPU decrementer event The SPU decrementer event is used to notify the SPU program that the decrementer has reached "0". If this event is enabled (ie, SPU_RdEventStat [Tm] is set to “1”) and the count for the SPU read event status channel is set to “1”, the most significant bit of the decrementer is “0”. This event occurs when the value changes from “1” (negative) value. When this event occurs, Pend_Event [Tm] is set to “1”. The Pend_Event [Tm] bit is set when the channel write (wrch) is issued to the SPU write event acknowledgment channel (SPU_WrEventAck [Tm] is set to “1”) or the corresponding bit is set to “0”. Set to “0” when privileged software updates the SPU pending event register using the configured SPU channel access function.

  An overview of the procedure for handling SPU decrementer events is shown in FIG. As shown in FIG. 50, the procedure begins by executing a read channel (rdch) instruction for the SPU read event mask channel and storing the data in a “mask” (step 2610). The event is masked by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [Tm] set to “0” (step 2620). An event is confirmed by issuing a write channel (wrch) command to the SPU write event confirmation response channel (SPU_WrEventAck [Tm] is set to 1) (step 2630).

  The decrementer value is read by issuing a read channel (rdch) instruction to the SPU read decrementer channel (step 2640). If this value is negative, this can be used to determine how much additional time has elapsed since the desired interval. A determination is made as to whether a new timer event is desired (step 2650). If a new timer event is desired, a new decrementer value is written (wrch) to the SPU write decrementer channel (step 2660). Thereafter, or if a new timer event is not desired, the SPU decrementer event handler ends (step 2670). The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 2680). Next, the general event handler ends (step 2690).

SPU Outbound Interrupt Mailbox Enable Event The SPU Outbound Interrupt Mailbox Enable event is read from the SPU Outbound Interrupt Mailbox Register that is full by the PPE or other device, and the SPU Write Outbound Interrupt Mailbox Channel without stopping the SPU Used to notify the SPU program that it can be written to. If this event is enabled (ie, SPU_RdEventStat [Me] is set to “1”) and the count for the SPU read event status channel is set to “1”, then the SPU write outbound interrupt mailbox channel This event occurs when the channel count changes from “0” (full) to a non-zero (not full) value. With this event, Pend_Event [Me] is set to “1”. The Pend_Event [Me] bit is set when a channel write (wrch) is issued to the SPU write event acknowledgment channel with the Me bit set to “1” (ie, SPU_WrEventAck [Me] is set to “1”). Or set to “0” when privileged software updates the SPU pending event register using an SPU channel access function with the corresponding bit set to “0”.

  An overview of the procedure for handling SPU outbound interrupt mailbox available events is shown in FIG. As shown in FIG. 51, the procedure begins by sending a read channel (rdch) command to the SPU read event mask channel and storing the data in a “mask” (step 2710). An event is masked by issuing a write channel (wrch) instruction to an SPU write event mask channel with SPU_WrEventMask [Me] set to “0” (step 2720). The event is confirmed by executing a write channel (wrch) command for the SPU write event acknowledgment channel with SPU_WrEventAck [Me] set to 1 (step 2730).

  The channel count is obtained by issuing a read channel (rchcnt) instruction to the SPU write outbound interrupt mailbox channel (step 2740). A determination is made as to whether the channel count is “0” (step 2750). If the channel count is not “0”, a new mailbox data item is written by issuing a write channel (wrch) instruction to the SPU write outbound interrupt mailbox channel (step 2760). If the channel count is “0”, the channel count is read again (step 2740). Thereafter, the SPU outbound interrupt mailbox available handler ends (step 2770). The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 2780). Next, the general event handler ends (step 2790).

SPU Outbound Mailbox Enable Event The SPU Outbound Mailbox Enable event is read from either a processor or other device's full SPU Outbound Mailbox register and SPU write outbound without stopping the SPU. Used to notify the SPU program that it can write to the mailbox channel. This event occurs when the channel count for the SPU write outbound mailbox channel changes from “0” (full) to a non-zero (not full) value. When this event occurs, Pend_Event [Le] is set to “1”. If this event is available (ie, SPU_RdEventStat [Le] is set to “1”), the count for the SPU read event status channel is set to “1”. The Pend_Event [Le] bit is set when a channel write (wrch) is issued to an SPU write event acknowledgment channel (see page 144) with the Le bit set to “1” (ie, SPU_WrEventAck [Le]). Set to “0” when privileged software updates the SPU pending event register using an SPU channel access function with the corresponding bit set to “0” Is done.

  An overview of the procedure for handling SPU outbound mailbox availability events is shown in FIG. As shown in FIG. 52, the procedure begins by sending a read channel (rdch) instruction to the SPU read event mask channel and storing the data in a “mask” (step 2810). By issuing a write channel instruction to an SPU write event mask channel with SPU_WrEventMask [Le] set to “0”, the event is masked. The event is confirmed by executing a write channel (wrch) command for the SPU write event acknowledge channel with SPU_WrEventAck [Le] set to 1 (step 2830).

  The channel count is obtained by issuing a read channel count (rchcnt) instruction to the SPU write outbound mailbox channel (step 2840). Next, a determination is made as to whether the channel count is “0” (step 2850). If the channel count is not “0”, a new mailbox data item is written by issuing a write channel (wrch) instruction to the SPU write outbound mailbox channel (step 2860). If the channel count is “0”, the channel count is read again (step 2840). Thereafter, the SPU outbound mailbox handler ends (step 2870). The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 2880). Next, the general event handler ends (step 2890).

SPU signal notification 2 enabled event The SPU signal notification 2 enabled event tells the SPU program that another processor or device can write to an empty SPU signal notification 2 register and read the SPU signal notification 2 channel without stopping the SPU. Used for notification. This event occurs when the channel count for the SPU signal notification 2 channel changes from “0” (empty) to “1” (valid) value. If this event is available (ie, SPU_RdEventStat [S2] is “1”) and the count for the SPU read event status channel is set to “1”, this event causes Pend_Event [S2] to be “1”. "Is set. The Pend_Event [S2] bit is set when the channel write (wrch) is issued to the SPU write event acknowledgment channel with the S2 bit set to “1” (SPU_WrEventAck [S2]) or the corresponding bit is “0”. Set to "0" when privileged software updates the SPU pending event register using the SPU channel access function set to "".

  An overview of the procedure for processing the SPU signal notification 2 enabled event is shown in FIG. As shown in FIG. 53, the procedure begins by sending a read channel (rdch) command to the SPU read event mask channel and storing the data in a “mask” (step 2910). The event is masked by issuing a write channel instruction to the SPU write event mask channel with SPU_WrEventMask [S2] set to “0” (step 2920). The event is confirmed by executing a write channel (wrch) instruction for the SPU write event acknowledge channel with SPU_WrEventAck [S2] set to 1 (step 2930).

  The channel count is obtained by issuing a read channel count (rchcnt) instruction to the SPU signaling 2 channel (step 2940). A determination is made as to whether the channel count is “0” (step 2950). If the channel count is not “0”, the signal data is read by issuing a read channel command to the SPU signal notification 2 channel (step 2960). Thereafter, or when the channel count is “0”, the signal notification 2 handler ends (step 2970). The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 2980). Next, the general event handler ends (step 2990).

SPU signal notification 1 enable event The SPU signal notification 1 enable event tells the SPU program that another processor or device can write to an empty SPU signal notification 1 register and read the SPU signal notification 1 channel without stopping the SPU. Used for notification. This event occurs when the channel count for the SPU signal notification 1 channel changes from “0” (empty) to “1” (valid) value. If this event is available (ie, SPU_RdEventStat [S1] is “1”) and the count for the SPU read event status channel is set to “1”, this event causes Pend_Event [S1] to be “1”. "Is set. The Pend_Event [S1] bit is set when the channel write (wrch) is issued to the SPU write event acknowledgment channel with the S1 bit set to “1” (SPU_WrEventAck [S1]) or the corresponding bit is “0”. Set to "0" when privileged software updates the SPU pending event register using the SPU channel access function set to "".

  An overview of the procedure for processing the SPU signal notification 1 enabled event is shown in FIG. As shown in FIG. 54, the procedure begins by sending a read channel (rdch) instruction to the SPU read event mask channel and storing the data in a “mask” (step 3010). The event is masked by issuing a write channel instruction to the SPU write event mask channel with SPU_WrEventMask [S1] set to “0” (step 3020). The event is confirmed by executing a write channel (wrch) command for the SPU write event acknowledgment channel with SPU_WrEventAck [S1] set to 1 (step 3030).

  A channel count is obtained by issuing a read channel count (rchcnt) instruction to the SPU signal notification 1 channel (step 3040). A determination is made as to whether the channel count is “0” (step 3050).

  If the channel count is not “0”, the signal data is read by issuing a read channel command to the SPU signal notification 1 channel (step 3060). Thereafter, or when the channel count is “0”, the signal notification 1 handler ends (step 3070). The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 3080). Next, the general event handler ends (step 3090).

Lock Line Reservation Lost Event The Lock Line Reservation Lost Event is used to notify the SPU program about bus actions that result in the loss of reservation on the cache line. A reservation is acquired by the SPU program by issuing a lock line reservation acquisition (getllar) command. If another processor or device changes a reserved cache line, the reservation is lost.

  The reservation can also be lost when privileged software writes a flash bit into the MFC atomic flash register (MFC_Atomic_Flush [F] is set to “1”). This event occurs when the reservation is lost. When this event occurs, Pend_Event [Lr] is set to “1”. If this event is available (ie, SPU_RdEventStat [Lr] is set to “1”), the count for the SPU read event status channel is set to “1”. The Pend_Event [Lr] bit is set when the channel write (wrch) is issued to the SPU write event acknowledgment channel with the Lr bit set to “1” (SPU_WrEventAck [Lr]) or the corresponding bit is “0”. Set to "0" when privileged software updates the SPU pending event register using the SPU channel access function set to "".

  An overview of the procedure for handling a lock line reservation lost event is shown in FIG. As shown in FIG. 55, this operation begins by issuing a read channel (rdch) instruction to the SPU read event mask channel and storing the data in a “mask” (step 3110). The event is masked by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [Lr] set to “0” (step 3120). The event is confirmed by executing a write channel (wrch) instruction for the SPU write event acknowledge channel with SPU_WrEventAck [Lr] set to 1 (step 3130).

  In response to the system change of data in the lock line area, application specific functions are performed (step 3140). This is usually initiated by checking the software structure in memory to determine if the lock line is still being monitored. If still "waiting" for it, the next step is usually to get new data and then issue a getllar command to the same lock line area that has been modified to act on that data Will be composed of.

  Next, the lock line reservation disappearance event handler ends (step 3150). The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 3160). Next, the general event handler ends (step 3170) and the procedure ends.

Privileged attention event The privileged attention event is used to notify the SPU program that the privileged software is requesting attention from the SPU program. The privileged software requests attention by writing “1” to the attention event request bit in the SPU privilege control register (that is, SPU_PrivCntl [A] is set to “1”). If this event is available (ie, SPU_RdEventStat [A] is “1”) and the count for the SPU read event status channel is set to “1”, this event causes Pend_Event [A] to be “1”. "Is set. The Pend_Event [A] bit corresponds when a channel write (wrch) is issued to the SPU write event acknowledgment channel with the A bit set (ie, SPU_WrEventAck [A] is “1”) or Set to "0" when privileged software updates the SPU pending event register using the SPU channel access function with the bit set to "0".

  An overview of the procedure for handling privileged attention events is shown in FIG. As shown in FIG. 56, the procedure begins by issuing a read channel (rdch) instruction to the SPU read event mask channel and storing the data in a “mask” (step 3210). The event is masked by issuing a write channel instruction to the SPU write event mask channel with SPU_WrEventMask [A] set to “0” (step 3220). The event is confirmed by executing a write channel (wrch) instruction for the SPU write event acknowledge channel with SPU_WrEventAck [A] set to 1 (step 3230).

  In response to the privileged attention event, application specific functions are performed (step 3240). This can be used, for example, to notify that the SPU yield is required or for some other action. Application or operating system specific responses to privileged attention events include stop and signal, SPU inbound mailbox write, SPU outbound interrupt mailbox write, or status update in system or I / O memory space Must be issued as

  The privileged attention event handler ends (step 3250). The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 3260). Next, the general event handler ends (step 3270).

Multi-source synchronization event The multi-source synchronization event is used to notify the SPU program that a multi-source synchronization request has been completed. Multi-source synchronization is requested by writing to the MFC write multi-source synchronization request channel (MFC_WrMSSyncReq). This event occurs when the channel count for the MFC write multi-source synchronization request channel (MFC_WrMSSyncReq) changes from “0” to “1”. If this event is available (ie, SPU_RdEventStat [Ms] is “1”) and the count for the SPU read event status channel is set to “1”, this event causes Pend_Event [Ms] to be “1”. "Is set. The Pend_Event [Ms] bit is used when a channel write (wrch) is issued to the SPU write event acknowledgment channel with the Ms bit set (ie, SPU_WrEventAck [Ms] is set to “1”). Or set to “0” when privileged software updates the SPU pending event register using the SPU channel access function with the corresponding bit set to “0”. Multi-source synchronization events must be cleared before issuing a multi-source synchronization request.

  An overview of the procedure for handling multi-source synchronization events is shown in FIG. As shown in FIG. 57, the procedure begins by sending a read channel (rdch) command to the SPU read event mask channel and storing the data in a “mask” (step 3310). The event is masked by issuing a write channel instruction to the SPU write event mask channel with SPU_WrEventMask [Tm] set to “0” (step 3320). The event is confirmed by executing a write channel (wrch) instruction for the SPU write event acknowledgment channel with SPU_WrEventAck [Ms] set to 1 (step 3330).

  In response to completing the pending multi-source synchronization operation, application-specific functions are performed (step 3340). This will typically be an indication, for example, that the data in a particular buffer has been completely updated or that the buffer area is no longer in use. The multi-source synchronous event handler ends (step 3350). The “mask” is restored by issuing a write channel (wrch) instruction to the SPU write event mask channel with SPU_WrEventMask [mask] (step 3360). Next, the general event handler ends (step 3370).

  In summary, the present invention reduces the burden on local storage and allows the processor to remain in a low power state when waiting for data, free space, or events to occur. A mechanism is provided for facilitating communication between the processor and an external device. The mechanism of the present invention provides multiple channels to communicate with various functions of the processor, memory flow controller, machine state register, and external processor interrupt function. These channels provide instructions, instruction parameters, interprocessor information, signal notification, machine isolation information, machine interrupt status information, generated events, and can be used to perform event processing.

  Although the present invention has been described in the context of a fully functional data processing system, one of ordinary skill in the art can distribute the processes of the present invention in the form of a computer readable medium consisting of multiple instructions and in various formats, It is important to note that the present invention applies equally regardless of the particular type of signal transmission medium actually used to perform the distribution. Examples of computer readable media include recordable type media such as flexible disk, hard disk, RAM, CD-ROM, DVD-ROM, and digital and digital formats that use transmission formats such as radio wave and light wave transmission, for example. Transmission type media such as analog communication links, wired or wireless communication links. The computer readable medium may take the form of a coded format that is decoded for actual use in a particular data processing system.

  The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to practitioners skilled in this art. In order to best illustrate the principles of the invention, practical applications, and to enable others skilled in the art to understand the invention with respect to various embodiments, including various modifications suitable for the particular intended use. For this reason, embodiments have been selected and described.

FIG. 2 is an exemplary block diagram of a broadband processor architecture (BPA) according to an exemplary embodiment of the present invention. FIG. 3 is an exemplary block diagram of an exemplary MFC 200 according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating parameter mnemonics for MFC commands according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of a DMA list command according to an exemplary embodiment of the present invention. FIG. 2 is an exemplary diagram illustrating the placement of SPU issue control logic and data flow for a channel circuit for a pair of channels in accordance with the mechanism described in US Patent Application Publication No. 2004/0264445. 5 is a flow diagram illustrating an exemplary operation overview of a channel interface according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating a method in which channels are used according to one embodiment of the present invention. FIG. 4 is an exemplary diagram listing an SPU channel map according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram listing an SPU channel map according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an MFC command instruction code channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an MFC class ID channel according to an exemplary embodiment of the present invention. FIG. 6 depicts an exemplary RMT entry for an 8-Way set associative cache according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an MFC command tag identification channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an MFC transfer size or list size channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an MFC local storage address channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an MFC effective address row or list address channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an MFC effective address high channel according to an exemplary embodiment of the present invention. 3 is a flowchart illustrating an exemplary operation overview for writing MFC command parameters according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an MFC write tag group query mask channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an MFC read tag group query mask channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an MFC write tag status update request channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an MFC read tag group status channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an MFC read list stop notification tag status channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an MFC write list stop notification tag acknowledgment channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an MFC read atomic command status channel according to an exemplary embodiment of the present invention. 6 is a flow diagram illustrating an overview of an exemplary operation for polling for MFC command completion or MFC command group completion, according to an exemplary embodiment of the invention. 6 is a flow diagram illustrating an overview of an exemplary operation for waiting for a tag group update or waiting for an event (one or more tag group completions) according to an exemplary embodiment of the present invention. FIG. 6 is a flow diagram illustrating an exemplary operation for using the SPU event function as an alternative to waiting for a conditional tag event or polling for a conditional tag event according to an exemplary embodiment of the present invention. is there. FIG. 5 is a flow diagram illustrating an overview of exemplary operations for polling to determine if an MFC DMA list command has reached a list element with a stop notification flag set according to an exemplary embodiment of the present invention. is there. 6 is a flow diagram outlining an exemplary operation for waiting for an MFC DMA list command to reach a list element with a stop notification flag set according to an exemplary embodiment of the present invention. Exemplary Operational Overview for Using SPU Event Function as an Alternative to Waiting for List Stop Notification Tag Group Status or Polling for List Stop Notification Tag Group Status In accordance with an exemplary embodiment of the present invention It is a flowchart which shows. FIG. 6 is an exemplary diagram illustrating details of an MFC write multi-source synchronization request channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an SPU write outbound mailbox channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an SPU write outbound interrupt mailbox channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an SPU read inbound mailbox channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an SPU signaling channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an SPU write decrementer channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an SPU read decrementer channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an SPU read machine status channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an SPU write state save and restore channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an SPU read state save and restore channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary block diagram illustrating a logical representation of SPU event functionality according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an SPU read event status channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an SPU write event mask channel according to an exemplary embodiment of the present invention. FIG. 6 is an exemplary diagram illustrating details of an SPU read event mask channel according to an exemplary embodiment of the present invention. FIG. 4 is an exemplary diagram illustrating details of an SPU write event acknowledgment channel according to an exemplary embodiment of the present invention. 6 is a flow diagram illustrating an overview of an exemplary operation for processing an MFC DMA list command stop notification event according to an embodiment of the present invention. 4 is a flowchart illustrating an overview of an exemplary operation for processing an MFC SPU command queue available event according to an embodiment of the present invention. 6 is a flowchart illustrating an overview of an exemplary operation for processing an SPU inbound mailbox availability event according to an embodiment of the present invention. 4 is a flowchart illustrating an overview of an exemplary operation for processing an SPU decrementer event according to an embodiment of the present invention. 4 is a flow diagram illustrating an overview of an exemplary operation for handling an SPU outbound interrupt mailbox enable event according to an embodiment of the present invention. 6 is a flow diagram illustrating an overview of an exemplary operation for processing an SPU outbound mailbox availability event according to an embodiment of the present invention. 4 is a flow diagram illustrating an overview of an exemplary operation for processing an SPU signal notification 2 enabled event according to an embodiment of the present invention. 4 is a flow diagram illustrating an overview of an exemplary operation for processing an SPU signal notification 1 enable event according to an embodiment of the present invention. 6 is a flow diagram illustrating an overview of an exemplary operation for processing a lock line reservation loss event according to an exemplary embodiment of the present invention. 5 is a flow diagram illustrating an overview of an exemplary operation for handling privileged attention events according to an exemplary embodiment of the present invention. 4 is a flow diagram illustrating an overview of an exemplary operation for processing a multi-source synchronization event according to an embodiment of the present invention.

Claims (16)

A method for communicating instructions and data related to events in a processor within a data processing system comprising:
Establishing one or more channels having the event function of the processor to convey event data, wherein the one or more channels are specified by a channel ID in a channel map list. Including steps, and
Receiving a data through the one or more channels,
Storing the data in one or more registers associated with the one or more channels;
Look including the steps of: processing one or more events based on the data stored in said one or more registers,
The event function includes a pending event register, an edge triggered event sets a bit in the pending event register corresponding to the edge triggered event;
The event is acknowledged by a bit in the pending event register by writing a value to the corresponding bit in the write event acknowledge channel hardware,
Issuing a read channel instruction to the read event status channel hardware returns the value in the pending event register that is ANDed with the value in the write event mask channel hardware, Thereby providing event status information relating only to available events identified within the write event mask channel hardware;
When a new value is written to the write event mask channel hardware or when a new event is recorded in the pending event register, the content of the read event status channel hardware is changed,
By changing a bit in the read event status channel hardware, the read event status channel count value stored in the read event status channel hardware is incremented by one;
After a write channel instruction is sent to the write event acknowledge channel hardware, when an event is set in the read event status channel hardware, the read event status channel count value is incremented by one;
The read event status channel count value is decremented by one when data in the read event status channel hardware is read using a channel read instruction ;
The method wherein an interrupt is sent to the processor when the read event status channel count value is non-zero .   The one or more channels include processor read event status channel hardware, and the processor read event status channel hardware is enabled by a value stored in the processor write event mask channel hardware The method of claim 1 including a bit identifying the current status of all events that have become. The processor halts by issuing a read channel instruction to the processor read event status channel hardware if a channel count value associated with the processor read event status channel hardware is zero. Item 3. The method according to Item 2 . If an event occurs and the corresponding bit for the event in the processor write event mask channel hardware is 1, the 1 in the bit position corresponding to 1 in the processor pending event register is the processor write event mask When written to channel hardware, after a write channel instruction is sent to the processor write event acknowledge channel hardware, an available event is pending, or using the processor channel access function The method of claim 2 , wherein if privileged software sets the channel count to 1, the channel count associated with the processor read event status channel hardware is set to 1. Said step of processing one or more events comprises:
Issuing a read channel instruction to the processor read event status channel hardware to identify an event that has occurred;
Issuing a write channel instruction to write corresponding bits in the processor write event acknowledge channel hardware for all events to be processed;
Comprising the steps of: processing said event The method of claim 2. The one or more channels include processor write event mask channel hardware;
The processor write event mask channel hardware includes a processor event mask that identifies events that affect the state of the processor read event status channel;
A write channel instruction issued to the processor write event mask channel hardware enables the corresponding event in the processor event mask and updates the processor read event status channel hardware status. The method of claim 1, wherein: The one or more channels comprise processor read event mask channel hardware used to read the current value of the event status mask;
The method of claim 1, wherein a read channel instruction issued to the processor read event mask channel hardware returns data last written to processor write event mask channel hardware. . The one or more channels comprise processor write event acknowledge channel hardware used to acknowledge the event that occurred;
The corresponding event is confirmed as being processed by software by issuing a write channel instruction to the processor write event acknowledge channel hardware with a particular event bit set. The method described. Processing the one or more events based on the data stored in the one or more registers;
Identifying an event by at least one of detecting a channel count associated with the one or more channels, a decrementer count associated with a decrementer of the processor, or a processor channel access operation. Item 2. The method according to Item 1. MFC tag group status update event is set when the channel count for memory flow controller (MFC) read tag group status channel hardware changes from 0 to a non-zero value, and the tag group processes The MFC tag group status update that has been completed and the MFC read tag group status channel hardware has been updated so that the MFC read tag group status channel hardware can be read without stopping the processor The method of claim 9 , wherein an event notifies a program running on the processor. Memory flow controller (MFC) read list stop notification tag status When the channel count for channel hardware changes from 0 to a non-zero value, an MFC direct memory access (DMA) list command stop notification event The MFC read list stop notification tag status channel that is set and the list element in the MFC DMA list command is complete and the MFC read list stop notification tag status channel hardware can be read without stopping the processor 10. The method of claim 9 , wherein the MFC DMA list command stop notification event notifies a program running on the processor that hardware has been updated. When the channel count for the standby memory flow control (MFC) command instruction code register changes from 0 to a non-zero value, an MFC processor command queue available event is set and in the MFC processor command queue The MFC processor command queue enable event on the processor, indicating that the processor is not stopped by a write channel instruction sent to the MFC command instruction code channel hardware. The method of claim 9 , wherein a notification is made to a running program. A processor inbound mailbox enable event is set when the channel count for processor read inbound mailbox channel hardware changes from 0 to a non-zero value,
The processor inbound state that the external device has written to an empty processor mailbox register and that the processor is not stopped by a read channel instruction issued to the processor read inbound mailbox channel hardware. A mailbox availability event notifies a program running on the processor;
A processor outbound interrupt mailbox enable event is set when the processor write outbound interrupt mailbox channel count changes from 0 to a non-zero value,
The processor outbound interrupt that the external device has read from a full processor outbound interrupt mailbox register and that the processor does not stop due to a write channel instruction sent to the processor write outbound interrupt mailbox channel hardware The method of claim 9 , wherein a mailbox event notifies a program running on the processor. A processor signal notification enable event is set when the channel count for the corresponding processor signal notification channel hardware changes from 0 to a non-zero value, and the external device writes to an empty processor signal notification register; the processor signaling the available event notifies a program running on the processor that the processor by a read channel instruction issued to the processor signaling channel hardware does not stop, according to claim 9 Method. A lock line reservation event is set when an atomic reservation is lost, and the lock line reservation event notifies the program running on the processor that the reservation on the cache line has been lost as a result of a bus action. The method according to claim 9 . A processor outbound mailbox enable event is set when the processor write outbound mailbox channel count changes from 0 to a non-zero value,
The processor outbound--that the external device has read from the full processor outbound mailbox register and that the processor does not stop due to a write channel instruction sent to the processor write outbound mailbox channel hardware. The method of claim 9 , wherein a mailbox event notifies a program running on the processor.

Images