WO2012068475A2 - Method and apparatus for moving data from a simd register file to general purpose register file - Google Patents

Abstract

A method for moving data from a first register file in a computational unit (808i) to a second register file in a processor (1410) is provided. The state of a signal on a data movement lead (risc is mfwr) is changed to indicate the data movement instruction from a first register file in a computational unit to a second register file in a processor (1410). A lane address from the processor to the computational unit is provided over a first address lead (risc is ua). A read address from the processor to the computational unit is provided over a second address lead (risc is ra), and data is transferred from the first register file in the computational unit to the second register file in the processor over a data interface lead (node regf rd).

Description

METHOD AND APPARATUS FOR MOVING DATA FROM A SIMD

REGISTER FILE TO GENERAL PURPOSE REGISTER FILE

[0001] The disclosure relates generally to a processor and, more particularly, to a processing cluster.

BACKGROUND

[0002] FIG. 1 is a graph that depicts speed-up in execution rate versus parallel overhead for a multi-core systems (ranging from 2 to 16 cores), where speed-up is the single-processor execution time divided by the parallel-processor execution time. As can be seen, the parallel overhead has to be close to zero to obtain a significant benefit from large number of cores. But, since the overhead tends to be very high if there is any interaction between parallel programs, it is normally very difficult to efficiently use more than one or two processors for anything but completely decoupled programs. Thus, there is a need for an improved processing cluster.

SUMMARY

[0003] An embodiment of the present disclosure, accordingly, provides a method. The method is characterized by: changing the state of a signal on a data movement lead (risc is mfwr) to indicate the data movement instruction from a first register file (4358-1 to 4358-8, 7902) in a computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) to a second register file (5206) in a processor (4322, 7614); providing a lane address from the processor (4322, 7614) to the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) over a first address lead (risc is ua); providing a read address from the processor (4322, 7614) to the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) over a second address lead (risc is ra); and transferring data from the first register file (4358-1 to 4358-8, 7902) in the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) to the second register file (5206) in the processor (4322, 7614) over a data interface lead (node regf rd).

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 is a graph of multicore speed-up parameters; [0005] FIG. 2 is a diagram of a system in accordance with an embodiment of the present disclosure;

[0006] FIG. 3 is a diagram of the SOC n accordance with an embodiment of the present disclosure;

[0007] FIG. 4 is a diagram of a parallel processing cluster in accordance with an embodiment of the present disclosure;

[0008] FIGS. 5 and 6 are diagram of a portion of a node or computing element in the processing cluster;

[0009] FIG. 7 is a block diagram of shared function-memory;

[0010] FIG. 8 is a diagram of the SIMD data paths for the shared function-memory;

[0011] FIG. 9 is a diagram of a portion of one SIMD data path;

[0012] FIG. 10 is a more detailed diagram of a node processor or RISC processor; and

[0013] FIGS. 11 and 12 are diagrams of examples of portions of a pipeline for a node processor or RISC processor.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0014] An example of application for an SOC that performs parallel processing can be seen in FIG. 2. In this example, an imaging device 1250 is shown, and this imaging device 1250 (which can, for example, be a mobile phone or camera) generally comprises an image sensor 1252, an SOC 1300, a dynamic random access memory (DRAM) 1254, a flash memory 1256, display 1526, and power management integrated circuit (PMIC) 1260. In operation, the image sensor 1252 is able to capture image information (which can be a still image or video) that can be processed by the SOC 1300 and DRAM 1254 and stored in a nonvolatile memory (namely, the flash memory 1256). Additionally, image information stored in the flash memory 1256 can be displayed to the use over the display 1258 by use of the SOC 1300 and DRAM 1254. Also, imaging devices 1250 are oftentimes portable and include a battery as a power supply; the PMIC 1260 (which can be controlled by the SOC 1300) can assist in regulating power use to extend battery life.

[0015] In FIG. 3, an example of a system-on-chip or SOC 1300 is depicted in accordance with an embodiment of the present disclosure. This SOC 1300 (which is typically an integrated circuit or IC, such as an OMAP™) generally comprises a processing cluster 1400 (which generally performs the parallel processing described above) and a host processor 1316 that provides the hosted environment (described and referenced above). The host processor 1316 can be wide (i.e., 32 bits, 64 bits, etc.) RISC processor (such as an ARM Cortex-A9) and that communicates with the bus arbitrator 1310, buffer 1306, bus bridge 1320 (which allows the host processor 1316 to access the peripheral interface 1324 over interface bus or Ibus 1330), hardware application programming interface (API) 1308, and interrupt controller 1322 over the host processor bus or HP bus 1328. Processing cluster 1400 typically communicates with functional circuitry 1302 (which can, for example, be a charged coupled device or CCD interface and which can communicate with off-chip devices), buffer 1306, bus arbitrator 1310, and peripheral interface 1324 over the processing cluster bus or PC bus 1326. With this configuration, the host processor 1316 is able to provide information (i.e., configure the processing cluster 1400 to conform to a desired parallel implementation) through API 1308, while both the processing cluster 1400 and host processor 1316 can directly access the flash memory 1256 (through flash interface 1312) and DRAM 1254 (through memory controller 1304). Additionally, test and boundary scan can be performed through Joint Test Action Group (JTAG) interface 1318.

[0016] Turning to FIG. 4, an example of the parallel processing cluster 1400 is depicted in accordance with an embodiment of the present disclosure. Typically, processing cluster 1400 corresponds to hardware 722. Processing cluster 1400 generally comprises partitions 1402-1 to 1402-R which include nodes 808-1 to 808-N, node wrappers 810-1 to 810-N, instruction memories 1404-1 to 1404-R, and bus interface units or (BIUs) 4710-1 to 4710-R (which are discussed in detail below). Nodes 808-1 to 808-N are each coupled to data interconnect 814 (through its respectively BIU 4710-1 to 4710-R and the data bus 1422), and the controls or messages for the partitions 1402-1 to 1402-R are provided from the control node 1406 through the message 1420. The global load/store (GLS) unit 1408 and shared function-memory 1410 also provide additional functionality for data movement (as described below). Additionally, a level 3 or L3 cache 1412, peripherals 1414 (which are generally not included within the IC), memory 1416 (which is typically flash memory 1256 and/or DRAM 1254 as well as other memory that is not included within the SOC 1300), and hardware accelerators (HWA) unit 1418 are used with processing cluster 1400. An interface 1405 is also provided so as to communicate data and addresses to control node 1406.

[0017] Processing cluster 1400 generally uses a "push" model for data transfers. The transfers generally appear as posted writes, rather than request-response types of accesses. This has the benefit of reducing occupation on global interconnect (i.e., data interconnect 814) by a factor of two compared to request-response accesses because data transfer is one-way. There is generally no desire to route a request through the interconnect 814, followed by routing the response to the requestor, resulting in two transitions over the interconnect 814. The push model generates a single transfer. This is important for scalability because network latency increases as network size increases, and this invariably reduces the performance of request-response transactions.

[0018] The push model, along with the dataflow protocol (i.e., 812-1 to 812-N), generally minimize global data traffic to that used for correctness, while also generally minimizing the effect of global dataflow on local node utilization. There is normally little to no impact on node (i.e., 808-i) performance even with a large amount of global traffic. Sources write data into global output buffers (discussed below) and continue without requiring an acknowledgement of transfer success. The dataflow protocol (i.e., 812-1 to 812-N) generally ensures that the transfer succeeds on the first attempt to move data to the destination, with a single transfer over interconnect 814. The global output buffers (which are discussed below) can hold up to 16 outputs (for example), making it very unlikely that a node (i.e., 808-i) stalls because of insufficient instantaneous global bandwidth for output. Furthermore, the instantaneous bandwidth is not impacted by request-response transactions or replaying of unsuccessful transfers.

[0019] Finally, the push model more closely matches the programming model, namely programs do not "fetch" their own data. Instead, their input variables and/or parameters are written before being invoked. In the programming environment, initialization of input variables appears as writes into memory by the source program. In the processing cluster 1400, these writes are converted into posted writes that populate the values of variables in node contexts.

[0020] The global input buffers (which are discussed below) are used to receive data from source nodes. Since the data memory for each node 808-1 to 808-N is single-ported, the write of input data might conflict with a read by the local Single Input Multiple Data (SIMD). This contention is avoided by accepting input data into the global input buffer, where it can wait for an open data memory cycle (that is, there is no bank conflict with the SIMD access). The data memory can have 32 banks (for example), so it is very likely that the buffer is freed quickly. However, the node (i.e., 808-i) should have a free buffer entry because there is no handshaking to acknowledge the transfer. If desired, the global input buffer can stall the local node (i.e., 808- i) and force a write into the data memory to free a buffer location, but this event should be extremely rare. Typically, the global input buffer is implemented as two separate random access memories (RAMs), so that one can be in a state to write global data while the other is in a state to be read into the data memory. The messaging interconnect is separate from the global data interconnect but also uses a push model.

[0021] At the system level, nodes 808-1 to 808-N are replicated in processing cluster 1400 analogous to SMP or symmetric multi-processing with the number of nodes scaled to the desired throughput. The processing cluster 1400 can scale to a very large number of nodes. Nodes 808- 1 to 808-N are grouped into partitions 1402-1 to 1402-R, with each having one or more nodes . Partitions 1402-1 to 1402-R assist scalability by increasing local communication between nodes, and by allowing larger programs to compute larger amounts of output data, making it more likely to meet desired throughput requirements. Within a partition (i.e., 1402-i), nodes communicate using local interconnect, and do not require global resources. The nodes within a partition (i.e., 1404-i) also can share instruction memory (i.e., 1404-i), with any granularity: from each node using an exclusive instruction memory to all nodes using common instruction memory. For example, three nodes can share three banks of instruction memory, with a fourth node having an exclusive bank of instruction memory. When nodes share instruction memory (i.e., 1404-i), the nodes generally execute the same program synchronously.

[0022] The processing cluster 1400 also can support a very large number of nodes (i.e., 808-i) and partitions (i.e., 1402-i). The number of nodes per partition, however, is usually limited to 4 because having more than 4 nodes per partition generally resembles a non-uniform memory access (NUMA) architecture. In this case, partitions are connected through one (or more) crossbars (which are described below with respect to interconnect 814) that have a generally constant cross-sectional bandwidth. Processing cluster 1400 is currently architected to transfer one node's width of data (for example, 64, 16-bit pixels) every cycle, segmented into 4 transfers of 16 pixels per cycle over 4 cycles. The processing cluster 1400 is generally latency-tolerant, and node buffering generally prevents node stalls even when the interconnect 814 is nearly saturated (note that this condition is very difficult to achieve except by synthetic programs).

[0023] Typically, processing cluster 1400 includes global resources that are shared between partitions: (1) Control Node 1406, which implements the system- wide messaging interconnect (over message bus 1420), event processing and scheduling, and interface to the host processor and debugger (all of which is described in detail below).

(2) GLS unit 1408, which contains a programmable reduced instruction set (RISC) processor, enabling system data movement that can be described by C++ programs that can be compiled directly as GLS data-movement threads. This enables system code to execute in cross-hosted environments without modifying source code, and is much more general than direct memory access because it can move from any set of addresses (variables) in the system or SIMD data memory (described below) to any other set of addresses (variables). It is multi-threaded, with (for example) 0-cycle context switch, supporting up to 16 threads, for example.

(3) Shared Function-Memory 1410, which is a large shared memory that provides a general lookup table (LUT) and statistics-collection facility (histogram). It also can support pixel processing using the large shared memory that is not well supported by the node SIMD (for cost reasons), such as resampling and distortion correction. This processing uses (for example) a six- issue RISC processor (i.e., SFM processor 7614, which is described in detail below), implementing scalar, vector, and 2D arrays as native types.

(4) Hardware Accelerators 1418, which can be incorporated for functions that do not require programmability, or to optimize power and/or area. Accelerators appear to the subsystem as other nodes in the system, participate in the control and data flow, can create events and be scheduled, and are visible to the debugger. (Hardware accelerators can have dedicated LUT and statistics gathering, where applicable.)

(5) Data Interconnect 814 and System Open Core Protocol (OCP) L3 connection 1412. These manage the movement of data between node partitions, hardware accelerators, and system memories and peripherals on the data bus 1422. (Hardware accelerators can have private connections to L3 also.)

(6) Debug interfaces. These are not shown on the diagram but are described in this document.

[0024] Turning to FIG. 5, an example of a node 808-i can be seen in greater detail. Node 808-i is the computing element in processing cluster 1400, while the basic element for addressing and program flow-control is RISC processor or node processor 4322. Typically, this node processor 4322 can have a 32-bit data path with 20-bit instructions (with the possibility of a 20-bit immediate field in a 40-bit instruction). Pixel operations, for example, are performed in a set of 32 pixel functional units, in a SIMD organization, in parallel with four loads (for example) to, and two stores (for example) from, SIMD registers from/to SIMD data memory (the instruction- set architecture of node processor 4322 is described in section 7 below). An instruction packet describes (for example) one RISC processor core instruction, four SIMD loads, and two SIMD stores, in parallel with a 3-issue SIMD instruction that is executed by all SIMD functional units 4308-1 to 4308-M.

[0025] Typically, loads and stores (from load store unit 4318-i) move data between SIMD data-memory locations and SIMD local registers, which can, for example, represent up to 64, 16- bit pixels. SIMD loads and stores use shared registers 4320-i for indirect addressing (direct addressing is also supported), but SIMD addressing operations read these registers: addressing context is managed by the core 4320. The core 4320 has a local memory 4328 for register spill/fill, addressing context, and input parameters. There is a partition instruction memory 1404-i provided per node, where it is possible for multiple nodes to share partition instruction memory 1404-i, to execute larger programs on datasets that span multiple nodes.

[0026] Node 808-i also incorporates several features to support parallelism. The global input buffer 4316-i and global output buffer 4310-i (which in conjunction with Lf and Rt buffers 4314- i and 4312-i generally comprise input/output (IO) circuitry for node 808-i) decouple node 808-i input and output from instruction execution, making it very unlikely that the node stalls because of system IO. Inputs are normally received well in advance of processing (by SIMD data memory 4306-1 to 4306-M and functional units 4308-1 to 4308-M), and are stored in SIMD data memory 4306-1 to 4306-M using spare cycles (which are very common). SIMD output data is written to the global output buffer 4210-i and routed through the processing cluster 1400 from there, making it unlikely that a node (i.e., 808-i) can stalls even if the system bandwidth approaches its limit (which is also unlikely). SIMD data memories 4308-1 to 4306-M and the corresponding SIMD functional unit 4306-1 to 4306-M are each collectively referred as a "SIMD units"

[0027] SIMD data memory 4306-1 to 4306-M is organized into non-overlapping contexts, of variable size, allocated either to related or unrelated tasks. Contexts are fully shareable in both horizontal and vertical directions. Sharing in the horizontal direction uses read-only memories 4330-i and 4332-i, which are typically read-only for the program but writeable by the write buffers 4302-i and 4304-i, load/store (LS) unit 4318-i, or other hardware. These memories 4330- i and 4332-i can also be about 512x2 bits in size. Generally, these memories 4330-i and 4332-i correspond to pixel locations to the left and right relative to the central pixel locations operated on. These memories 4330-i and 4332-i use a write-buffering mechanism (i.e. write buffers 4302- i and 4304-i) to schedule writes, where side-context writes are usually not synchronized with local access. The buffer 4302-i generally maintains coherence with adjacent pixel (for example) contexts that operate concurrently. Sharing in the vertical direction uses circular buffers within the SIMD data memory 4306-1 to 4306-M; circular addressing is a mode supported by the load and store instructions applied by the LS unit 4318-i. Shared data is generally kept coherent using system-level dependency protocols described above.

[0028] Context allocation and sharing is specified by SIMD data memory 4306-1 to 4306-M context descriptors, in context-state memory 4326, which is associated with the node processor 4322. This memory 4326 can, for example, 16x16x32 bit or 2x16x256 bit RAM. These descriptors also specify how data is shared between contexts in a fully general manner, and retain information to handle data dependencies between contexts. The Context Save/Restore memory 4324 is used to support 0-cycle task switching (which is described above), by permitting registers 4320-i to be saved and restored in parallel. SIMD data memory 4306-1 to 4306-M and processor data memory 4328 contexts are preserved using independent context areas for each task.

[0029] SIMD data memory 4306-1 to 4306-M and processor data memory 4328 are partitioned into a variable number of contexts, of variable size. Data in the vertical frame direction is retained and re-used within the context itself. Data in the horizontal frame direction is shared by linking contexts together into a horizontal group. It is important to note that the context organization is mostly independent of the number of nodes involved in a computation and how they interact with each other. The primary purpose of contexts is to retain, share, and re -use image data, regardless of the organization of nodes that operate on this data.

[0030] Typically, SIMD data memory 4306-1 to 4306-M contains (for example) pixel and intermediate context operated on by the functional units 4308-1 top 4308-M. SIMD data memory 4306-1 to 4306-M is generally partitioned into (for example) up to 16 disjoint context areas, each with a programmable base address, with a common area accessible from all contexts that is used by the compiler for register spill/fill. The processor data memory 4328 contains input parameters, addressing context, and a spill/fill area for registers 4320-i. Processor data memory 4328 can have (for example) up to 16 disjoint local context areas that correspond to SIMD data memory 4306-1 to 4306-M contexts, each with a programmable base address.

[0031] Typically, the nodes (i.e., node 808-i), for example, have three configurations: 8 SIMD registers (first configuration); 32 SIMD registers (second configuration); and 32 SIMD registers plus three extra execution units in each of the smaller functional unit (third configuration).

[0032] As an example, FIG. 6 shown an example of SIMD unit (namely, SIMD data memory 4306-1 and SIMD functional unit 4308-1), node processor 4322, and LS unit 4318-i in greater detail can be seen. As shown in this example, SIMD functional unit 4308-i is generally comprised of eight, smaller functional units 4338-1 to 4338-8 uses the third configuration.

[0033] Looking first to the processor core, the node processor 4322 generally executes all the control related instructions and holds all the address register values and special register values for SIMD units shown in register files 4340 and 4342 (respectively). Up to six (for example) memory instructions can be calculated in a cycle. For address register values, the address source operands are sent to node processor 4322 from the SIMD unit shown, and the node processor 4322 sends back the register values, which are then used by SIMD unit for address calculation. Similarly, for special register values, the special register source operands are sent to node processor 4322 from the SIMD unit shown, and the node processor 4322 sends back the register values.

[0034] Node processor 4322 can have (for example) 15 read ports and six write ports for SIMD. Typically, the 15 read ports include (for example) 12 read ports that accommodate two operands (i.e., lssrc and lssrc2) for each of six memory instructions and three ports for special register file 4312. Typically, special register file 4342 include two registers named RCLIPMIN and RCLIPMAX, which should be provided together and which are generally restricted to the lower four registers of the 16 entry register file 4342. RCLIPMAX and RCLIPMIN registers are then specified directly in the instruction. The other special registers RND and SCL are specified by a 4-bit register identifier and can be located anywhere in the 16 entry register file 4342. Additionally, node processor 4322 includes a program counter execution unit 4344, which can update the instruction memory 1404-i.

[0035] Turning now to the LS unit 4318-i and SIMD unit, the general structure for each can be seen in FIG. 6. As shown, the LS unit 4318-i generally comprises LS decoder 4334, LS execution unit 4336, logic unit 4346, multiply unit 4348, right execution unit 4350, and LS data memory 4339; however the details regarding the data path for LS unit 4318-i are provided below. Each of the smaller functional units 4338-1 through 4338-8 generally (and respectively) comprises SIMD register files 4358-1 to 4358-8 (which can each include 32 registers, for example), left logic units 4352-1 to 4352-8, multiply units 4354-1 to 4354-8, and right logic units 4356-1 to 4356-8. These left logic units 4352-1 to 4352-8, multiply units 4354-1 to 4354-8, and right logic units 4356-1 to 4356-8 are generally duplications of left, middle, and right units 4346, 4348, and 4350, respectively. Additionally, similar to the LS unit 4318-i, the data path for each functional unit 4338-1 to 4338-8 is described below.

[0036] Additionally, for the three example configurations for a node (i.e., node 808-i), the sizes of some components (i.e., logic unit 4352-1) or the corresponding instruction may vary, while others may remain the same. The LS data memory 4339, lookup table, and histogram remain relatively the same. Preferably, the LS data memory 4339 can be about 512*32 bits with the first 16 locations holding the context base addresses and the remaining locations being accessible by the contexts. The lookup table or LUT (which is generally within the PC execution unit 4344) can have up to 12 tables with a memory size of 16Kb, wherein four bits can be used to select table and 14 bits can be used for addressing. Histograms (which are also generally located in the PC execution unit 4344) can have 4 tables, where the histogram shares the 4-bit ID with LUT to select a table and uses 8 bits for addressing. In Table 1 below, the instructions sizes for each of the three example configurations can be seen, which can correspond to the sizes of various components.

Table 1

F-^'ii-si ( on ll«'iii iii i»ii

, ,„„„„„, "XL, .'! iLH,,,,

4348) instruction

Logic unit (i.e., 4346) 16 bits 24 bits 24 bits

instruction

LS unit instructions 132 bits 160 bits 156 bits

Node processor 4322 O bits 20 bits for 20 bits

instruction

Context switch 2 bits for 2 bits 2 bits

indication

arrangement of Context : C : LS I : Context : C : LS I : Context : C : LS I : instruction line LS2 : LS3 : LS4 : LS5 : T20 : LS2 : LS3 : T20 : LS2 : LS3 : (Instruction Packet LS6 : LU : MU : RU LS4 : LS5 : LS6 : LS4 : LS5 : LS6 : Format) LU : MU : RU LU : MU : RU

[0037] Turning to FIG. 7, the shared function-memory 1410 can be seen. The shared function- memory 1410 is generally a large, centralized memory supporting operations that are not well- supported by the nodes (i.e., for cost reasons). The main component of the shared function- memory 1410 are the two large memories: the function-memory 7602 and the vector-memory

7603 (each of which has a configurable size between, for example 48 to 1024 Kbytes and organization). This function-memory 7602 implements a synchronous, instruction-driven implementation of high-bandwidth, vector-based lookup-tables (LUTs) and histograms. The vector-memory 7603 can support operations by (for example) a 6-issue processor (i.e., SFM processor 7614) that implies vector instructions (as detailed in section 8 above), which can, for example, be used for block-based pixel processing. Typically, this SFM processor 7614 can be accessed using the messaging interface 1420 and data bus 1422. The SFM processor 7614 can, for example, operate on wide pixel contexts (64 pixels) that can have a much more general organization and total memory size than SIMD data memory in the nodes, with much more general processing applied to the data. It supports scalar, vector, and array operations on standard C++ integer datatypes as well as operations on packed pixels that are compatible with various datatypes. For example and as shown, the SIMD data paths associated with the vector memory 7603 and function-memory 7602 generally include ports 7605-1 to 7605 -Q and functional units 7607-1 to 7607-P.

[0038] The function-memory 7602 and vector-memory 7603 are generally "shared" in the sense that all processing nodes (i.e., 808-i) can access function-memory 7602 and vector- memory 7603. Data provided to the function-memory 7602 can be accessed via the SFM wrapper (typically in a write-only manner). This sharing is also generally consistent with the context management described above for processing nodes (i.e., 808-i). Data I/O between processing nodes and shared function-memory 1410 also uses the dataflow protocol, and processing nodes, typically, cannot directly access vector-memory 7603. The shared function- memory 1410 can also write to the function-memory 7602, but not while it is being accessed by processing nodes. Processing nodes (i.e., 808-i) can read and write common locations in function-memory 7602, but (usually) either as read-only LUT operations or write-only histogram operations. It is also possible for a processing node to have read-write access to an function- memory 7602 region, but this should be exclusive for access by a given program.

[0039] Turing to FIG. 8, an example of the SIMD data paths 7800 for the shared function- memory 1410. For example, eight SIMD data paths (which can be partitioned into two, 16-bit halves because it can operate on 16-bit packed data) can be used. As shown, these SIMD data paths generally comprise set of banks 7802-1 to 7802-L, associated registers 7804-1 to 7804-L, and associated sets of functional units 7806-1 to 7806-L.

[0040] In FIG. 9, an example of a portion of one SIMD data path (namely and for example, a portion of one of the registers 7804-1 to 7804-L and a portion of one of the functional units 7806-1 to 7806-L) can be seen. As shown and for example, this SIMD data path can include includes a 16-entry, 32-bit register file 7902, two 16-bit multipliers 7904 and 7906, and a single, 32-bit arithmetic/logical unit 7908 that can also perform two, 16-bit packed operations in a cycle. Also, as an example, each SIMD data path can perform two, independent 16-bit operations, or a combined, 32-bit operation. For example, this can form a 32-bit multiply using the 16-bit multipliers combined with 32-bit adds. Additionally, the arithmetic/logical unit 7908 can be capable of performing addition, subtraction, logical operations (i.e., AND), comparisons, and conditional moves.

[0041] Turning back to FIG. 8, the SIMD data path registers 7804-1 to 7804-L can use a load/store interface to the vector memory 7603. These loads and stores can use features of the vector memory 7603 that are provided for parallel LUT and histogram access by nodes (i.e., 808- i): for nodes, each SIMD data path half can provide an index into function-memory 7602; and, similarly, each SIMD data path half in SFM processor 7614 can provide an independent vector memory 7603 address. Addressing is generally organized so that adjacent data paths can perform the same operation on multiple instances of datatypes such as scalars, vectors, and arrays of 8-, 16-, or 32-bit (for example) data: these are called vector-implied addressing modes (the vector is implied by the SIMD with linear vector memory 7603 addressing). Alternatively, each data path can operate on packed pixels from regions of a frame within banks 7608-1 to 7608-J: these are called vector-packed addressing modes (vectors of packed pixels are implied by the SIMD, with two-dimensional vector memory 7603 addressing). In both cases, as with the node processor 4322, the programming model can hide the width of the SIMD, and programs are written as if they operate on a single pixel or element of other datatype.

[0042] Vector-implied datatypes are generally SIMD-implemented vectors of either 8-bit chars, 16-bit halfwords, or 32-bit ints, operated on individually by each SIMD data path (i.e., FIG. 9). These vectors are not generally explicit in the program, but rather implied by hardware operation. These datatypes can also be structured as elements within explicit program vectors or arrays: the SIMD effectively adds a hidden second or third dimension to these program vectors or arrays. In effect, the programming view can be a single SIMD data path with a dedicated, 32- bit data memory, and this memory is accessed using conventional addressing modes. In the hardware, this view is mapped in a way that each of the 32 SIMD data paths has the appearance of a private data memory, but the implementation takes advantage of the wide, banked organization of vector memory 7603 to implement this functionality in the shared function- memory 1410.

[0043] The SFM processor 7614 SIMD generally operates within vector memory 7603 contexts similar node processor 4322 contexts, with descriptors having a base address aligned to the sets of banks 7802-1, and sufficiently large to address the entire vector memory 7603 (i.e., 13 bits for the size of 1024 kB). Each half of the a SIMD data path is numbered with a 6-bit identifier (POSN), starting at 0 for the left-most data path. For vector-implied addressing, the LSB of this value is generally ignored, and the remaining five bits are used to align the vector memory 7603 addresses generated by the data path to the respective words in the vector memory 7603. [0044] Within processing cluster 1400, general-purpose RISC processors serve various purposes. For example, node processor 4322 (which can be a RISC processor) can be used for program flow control. Below examples of RISC architectures are described.

[0045] Turning to FIG. 10, a more detailed example of RISC processor 5200 (i.e., node processor 4322) can be seen. The pipeline used by processor 5200 generally provides support for general high level language (i.e., C/C++) execution in processing cluster 1400. In operation, processor 5200 employs a three stage pipeline of fetch, decode, and execute. Typically, context interface 5214 and LS port 5212 provide instructions to the program cache 508, and the instructions can be fetched from the program cache 5208 by instruction fetch 5204. The bus between the instruction fetch 5204 and the program cache 5208 can, for example, be 40 bits wide, allowing the processor 5200 to support dual issue instructions (i.e., instructions can be 40 bits or 20 bits wide). Generally, "A-side" and "B-side" functional units (within processing unit 5202) execute the smaller instructions (i.e., 20-bit instructions), while the "B-side" functional units execute the larger instructions (i.e., 40-bit instructions). To execution the instructions provided, processing unit can use register file 5206 as a "scratch pad"; this register file 5206 can be (for example) a 16-entry, 32-bit register file that is shared between the "A-side" and "B-side." Additionally, processor 5200 includes a control register file 5216 and a program counter 5218. Processor 5200 can also be access through boundary pins or leads; an example of each is described in Table 2 (with "z" denoting active low pins).

Table 2

Table 2

Gated with vec regf enz assertion. Table 2

Table 2

Piii Name W d(li Dir Purpose

processor 5200 is executing the second half of a non-parallel 20-bit instruction pair.

rise fmem addr 20 Output Vector implied load/store address bus

rise fmem bez 4 Output Vector implied load/store byte enables

risc vec opr 4 Output This bus represents the vector unit source register for vector implied stores, or the vector unit destination register for vector implied loads.

risc is vild 1 Output Vector implied signed load flag.

risc is vildu 1 Output Vector implied unsigned load flag.

risc_is_vist 1 Output Vector implied store flag

risc_hg_posn 8 Output Reflects the current contents of the processor 5200

HG POSN control register

rise regf ra[l :0] 4b:2 Input Register file read address ports. There are two ports. These pins are driven by lane 0 (left most) vector unit. Allows the vector unit to read one of the lower 4 registers in the GPR file.

risc_regf_rd[ 1 :0]z lb:2 Input When de-asserted gates off switching on the risc_regf_rdata0/l buses. Should be driven low to read valid data on rise regf rdata.

risc_regf_rdata[l :0] 32 3x2 Output Register file read data ports. There are two ports.

These pins are driven by lane 0 (left most) vector unit. These are the read data buses associated with rise regf ra.

risc_inc_hg_posn 1 Output Asserted in DO when a BHGNE instruction is decoded.

wrp_hgposn_ne_hgsize 1 Input Asserted by the SFM wrapper. Indicates whether the wrappers copy of HG POSN and HG SIZE are not equal. [0046] Turning to FIG. 11, the processor 5200 can be seen in greater detail shown with the pipeline 5300. Here, the instruction fetch 5204 (which corresponds to the fetch stage 5306) is divided into an A-side and B-side, where the A-side receives the first 20-bits (i.e, [19:0]) of a "fetch packet" (which can be a 40-bit wide instruction word having one 40-bit instruction or two 20-bit instructions) and the B-side receives the last 20-bits (i.e., [39:20]) of a fetch packet. Typically, the instruction fetch 5204 determines the structure and size of the instruction(s) in the fetch packet and dispatches the instruction(s) accordingly (which is discussed in section 7.3 below).

[0047] A decoder 5221 (which is part of the decode stage 5308 and processing unit 5202) decodes the instruction(s) from the instruction fetch 5204. The decoder 5221 generally includes a operator format circuit 5223-1 and 5223-2 (to generate intermediates) and a decode circuit 5225-1 and 5225-2 for the B-side and A-side, respectively. The output from the decoder 5221 is then received by the decode-to-execution unit 5220 (which is also part of the decode stage 5308 and processing unit 5202). The decode-to-execution unit 5220 generates command(s) for the execution unit 5227 that correspond to the instruction(s) received through the fetch packet.

[0048] The A-side and B-side of the execution unit 5227 is also subdivided. Each of the B- side and A-side of the execution unit 5227 respectively includes a multiply unit 5222-1/5222-2, a Boolean unit 5226-1/5226-2, an add/subtract unit 5228-1/5228-2, and a move unit 5330-1/5330- 2. The B-side of the execution unit 5227 also includes a load/store unit 5224 and a branches unit 5232. The multiply unit 5222-1/5222-2, a Boolean unit 5226-1/5226-2, a add/subtract unit 5228- 1/5228-2, and a move unit 5330-1/5330-2 can then, respectively, perform a multiply operation, a logical Boolean operation, add/subtract operation, and a data movement operation on data loaded into the general purpose register file 5206 (which also includes read addresses for each of the A- side and B-side). Move operations can also be performed in the control register file 5216.

[0049] A RISC processor with a vector processing module is generally used with shared function-memory 1410. This RISC processor is largely the same as the RISC processor used for processor 5200 but it includes a vector processing module to extend the computation and load/store bandwidth. This module can contain 16 vector units that are each capable of executing a 4-operation execute packet per cycle. A typical execute packet generally includes a data load from the vector memory array, two register-to-register operations, and a result store to the vector memory array. This type of RISC processor generally uses an instruction word that is 80 bits wide or 120 bits wide, which generally constitutes a "fetch packet" and which may include unaligned instructions. A fetch packet can contain a mixture of 40 bit and 20 bit instructions, which can include vector unit instructions and scalar instructions similar to those used by processor 5200. Typically, vector unit instructions can be 20 bits wide, while other instructions can be 20 bits or 40 bits wide (similar to processor 5200). Vector instructions can also be presented on all lanes of the instruction fetch bus, but, if the fetch packet contains both scalar and vector unit instructions the vector instructions are presented (for example) on instruction fetch bus bits [39:0] and the scalar instruction(s) are presented (for example) on instruction fetch bus bits [79:40]. Additionally, unused instruction fetch bus lanes are padded with NOPs.

[0050] An "execute packet" can then be formed from one or more fetch packets. Partial execute packets are held in the instruction queue until completed. Typically, complete execute packets are submitted to the execute stage (i.e., 5310). Four vector unit instructions (for example), two scalar instructions (for example), or a combination of 20-bit and 40-bit instructions (for example) may execute in a single cycle. Back-to-back 20-bit instructions may also be executed serially. If bit 19 of the current 20 bit instruction is set, this indicates that the current instruction, and the subsequent 20-bit instruction form an execute packet. Bit 19 can be generally referred to as the P-bit or parallel bit. If the P-bit is not set this indicates the end of an execute packet. Back-to-back 20 bit instructions with the P-bit not set cause serial execution of the 20 bit instructions. It should also be noted that this RISC processor (with a vector processing module) may include any of the following constraints:

(1) It is illegal for the P-bit to be set to 1 in a 40 bit instruction (for example);

(2) Load or store instructions should appear on the B-side of the instruction fetch bus (i.e., bits 79:40 for 40 bit loads and stores or on bits 79:60 of the fetch bus for 20 bit loads or stores);

(3) A single scalar load or store is legal;

(4) For the vector units both a single load and a single store can exist in a fetch packet;

(5) It is illegal for a 40 bit instruction to be preceded by a 20 bit instruction with a P-bit equal to 1; and

(6) No hardware is in place to detect these illegal conditions. These restrictions are expected to be enforced by the system programming tool 718.

[0051] Turning to FIG. 12, an example of a vector module can be seen. The vector module includes a detector decoder 5246, decode-to-execution unit 5250, and an execution unit 5251. The vector decoder includes slot decoders 5248-1 to 5248-4 that receive instructions from the instruction fetch 5204. Typically, slot decoders 5248-1 and 5248-2 operate in a similar manner to one another, while slot decoders 5248-3 and 5248-4 include load/store decoding circuitry. The decode-to-execution unit 5250 can then generate instructions for the execution unit 5251 based on the decoded output of vector decoder 5246. Each of the slot decoders can generate instruction that can be used by the multiply unit 5252, add/subtract unit 5254, move unit 5256, and Boolean unit 5258 (that each use data and addresses in the general purpose register 5206). Additionally slot decoders 5248-3 and 5248-4 can generate load and store instructions for load/store units 5260 and 5262.

[0052] The general purpose resister file 5206 can be a 16-entry by 32-bit general purpose register file. The widths of the general purpose registers (GPRs) can be parameterized. Generally, when processor 5200 is used for nodes (i.e., 808-i), there are 4+15 (15 are controlled by boundary pins) read ports and 4+6 (6 are controlled by boundary pins) write ports, while processor 5200 used for GLS unit 1408 has 4 read ports and 4 write ports.

[0053] Instructions that can move data between node processor 4322 and SIMD (i.e., SIMD unit including SIMD data memory 4306-1 and functional unit 4308-1) are indicated in Table 3

[0054] Table 4 below illustrates an example of an instruction set architecture for processor 5200, where: Unit designations .SA and .SB are used to distinguish in which issue slot a 20 bit instruction executes;

(2) 40 bit instructions are executed on the B-side (.SB) by convention;

(3) The basic form is <mnemonic> <unit> <comma separated operand list>;and Pseudo code has a C++ syntax and with the proper libraries can be directly included in

Table 4 vec_regf_enz._assert(0);

vec_regf_ra._assert(s2);

s3Save = s3.address();

initiate, live(true);

complete . live(vec_wdata_wrz . is(0)) ;

}

MFVVR .SB sl(R5), s2(R5), s3(R4)

void ISA::OPC_MFVVR_40b_264 (Vunit &sl, Vreg &s2,Gpr &s3)

{

Reg s3Save;

risc_is_mfwr._assert( 1 );

risc_vec_ua._assert(s 1 );

MOVE

risc_vec_ra._assert(s2);

VUNIT/VREG s3Save = s3.address();

GPR

initiate, live(true);

vec_risc_wa._assert(s3);

vec_risc_wd gets value of Vreg(risc_vec_ra);

complete . live(vec_risc_wrz . is(0)) ; //ditto

}

MTV .(SA,SB) sl(R4), s2(R5)

void ISA::OPC_MTV_20b_164 (Gpr &sl, Vreg &s2)

MOVE GPR

{

VREG,

Result rl;

REPLICATED

rl .clear();

(LOW VREG) rl = sl .range(0,15);

risc_is_mtv._assert(l); Table 4

Table 4

Table 4

[0055] Those skilled in the art to which the invention relates will appreciate that modifications may be made to the described embodiments and additional embodiments realized, without departing from the scope of the claimed invention.

Claims

CLAIMS What is claimed is:

1. An apparatus characterized by:

a computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) having a first register file

(4358-1 to 4358-8, 7902); and

a processor (4322, 7614) that is coupled to the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P), wherein the processor (4322, 7614) includes an instruction set having a data movement instruction (MFVVR) from the first register file (4358-1 to 4358-8, 7902), wherein the processor includes :

a second register file (5206);

a first address lead (risc is ua) for indicating a lane address for the first register file (4358-1 to 4358-8, 7902);

a second address lead (risc is ra) for indicating a read address for the first register file (4358-1 to 4358-8, 7902);

a data interface lead (node regf rd) for transferring data; and

a data movement lead (risc is mfwr) for indicating the data movement instruction (MFVVR) from the first register file (4358-1 to 4358-8, 7902) to the second register file (5206) when the state of a signal on the data movement lead is changed.

2. The apparatus of Claim 1, wherein the first address lead (risc is ua) is further characterized by a plurality of first address leads (risc is ua), and wherein the second address lead (risc is ra) is further characterized by a plurality of second address leads (risc is ra).

3. The apparatus of Claim 2, wherein the plurality of first address leads (risc is ua) and the plurality of second address leads (risc is ra) are each 5 bits wide.

4. The apparatus of Claims 1, 2, or 3, wherein the processor includes a halfword lead (risc is hwz) for indicating whether to perform an upper half write, an lower half write, a full write, or a read.

5. The apparatus of Claims 1, 2, 3, or 4, wherein the halfword lead (risc_is_hwz) is further characterized by a plurality of halfword leads (risc is hwz).

6. The apparatus of claim 5, wherein the plurality of halfword leads (risc is hwz) is 2 bits wide.

7. The apparatus of Claims 1, 2, 3, 4, 5, or 6, the data interface lead (node regf rd) is further characterized by a plurality of data interface leads (node regf rd).

8. The apparatus of Claims 1, 2, 3, 4, 5, 6, or 7, wherein the computational unit

(4308-1 to 4308-M, 7607-1 to 7607-P) is further characterized by a plurality of single input multiple data (SIMD) functional units (4308-1 to 4308-M)

9. The apparatus of Claims 1, 2, 3, 4, 5, 6, or 7, wherein the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) is further characterized by a plurality of vector units

(7607-1 to 7607-P).

10. A method characterized by:

changing the state of a signal on a data movement lead (risc is mfwr) to indicate a data movement instruction (MFVVR) from a first register file (4358-1 to 4358-8, 7902) in a computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) to a second register file (5206) in a processor (4322, 7614);

providing a lane address from the processor (4322, 7614) to the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) over a first address lead (risc is ua);

providing a read address from the processor (4322, 7614) to the computational unit

(4308-1 to 4308-M, 7607-1 to 7607-P) over a second address lead (risc is ra); and

transferring data from the first register file (4358-1 to 4358-8, 7902) in the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) to the second register file (5206) in the processor (4322, 7614) over a data interface lead (node regf rd).

11. The method of Claim 10, wherein the first address lead (risc is ua) is further characterized by a plurality of first address leads (risc is ua), and wherein the second address lead (risc is ra) is further characterized by a plurality of second address leads (risc is ra).

12. The method of Claims 10 or 11, wherein the method is further characterized by indicating whether to perform an upper half write, an lower half write, a full write, or a read over a halfword lead (risc is hwz).

13. The method of Claims 10, 11, or 12, wherein the halfword lead (risc is hwz) is further characterized by a plurality of halfword leads (risc is hwz).

14. The method of Claims 10, 11, 12, or 13, wherein the data interface lead (node regf rd) is further characterized by a plurality of data interface leads (node regf rd).

15. A system characterized by:

means for changing the state of a signal on a data movement lead (risc is mfwr) to indicate a data movement instruction (MFVVR) from a first register file (4358-1 to 4358-8, 7902) in a computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) to a second register file (5206) in a processor (4322, 7614);

means for providing a lane address from the processor (4322, 7614) to the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) over a first address lead (risc is ua);

means for providing a read address from the processor (4322, 7614) to the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) over a second address lead (risc is ra); and

means for transferring data from the first register file (4358-1 to 4358-8, 7902) in the computational unit (4308-1 to 4308-M, 7607-1 to 7607-P) to the second register file (5206) in the processor (4322, 7614) over a data interface lead (node regf rd).

16. The system of Claim 15, wherein the first address lead (risc is ua) is further characterized by a plurality of first address leads (risc is ua), and wherein the second address lead (risc is ra) is further characterized by a plurality of second address leads (risc is ra).

17. The system of Claims 15 or 16, wherein the system is further characterized by means for indicating whether to perform an upper half write, an lower half write, a full write, or a read over a halfword lead (risc is hwz).

18. The system of Claims 15, 16, or 17, wherein the halfword lead (risc_is_hwz) is further characterized by a plurality of halfword leads (risc is hwz).

19. The method of Claims 15, 16, 17, or 18, wherein the data interface lead (node regf rd) is further characterized by a plurality of data interface leads (node regf rd).