Source: http://www.google.com/patents/US7937559?ie=ISO-8859-1&dq=No.+6,411,949
Timestamp: 2014-07-14 07:49:36
Document Index: 342825494

Matched Legal Cases: ['art[7', 'art[7', 'art[15', 'art[15', 'art[23', 'art[23', 'art[31', 'art[31']

Patent US7937559 - System and method for generating a configurable processor supporting a user ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign in<nobr>Advanced Patent Search</nobr>PatentsA processor generation system includes the ability to describe processors with three instruction sizes. In one example implementation, instructions can be 16-, 24- and 64-bits. This enables a new range of architectures that can exploit parallelism in architectures. In particular, this enables the generation...http://www.google.com/patents/US7937559?utm_source=gb-gplus-sharePatent US7937559 - System and method for generating a configurable processor supporting a user-defined plurality of instruction sizesAdvanced Patent SearchPublication numberUS7937559 B1Publication typeGrantApplication numberUS 11/761,322Publication dateMay 3, 2011Filing dateJun 11, 2007Priority dateMay 13, 2002Publication number11761322, 761322, US 7937559 B1, US 7937559B1, US-B1-7937559, US7937559 B1, US7937559B1InventorsAkilesh Parameswar, James Alexander Stuart Fiske, Ricardo E. GonzalezOriginal AssigneeTensilica, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (32), Non-Patent Citations (8), Referenced by (10), Classifications (38) External Links: USPTO, USPTO Assignment, EspacenetSystem and method for generating a configurable processor supporting a user-defined plurality of instruction sizesUS 7937559 B1Abstract A processor generation system includes the ability to describe processors with three instruction sizes. In one example implementation, instructions can be 16-, 24- and 64-bits. This enables a new range of architectures that can exploit parallelism in architectures. In particular, this enables the generation of VLIW architectures. According to another aspect, the processor generator allows a designer to add a configurable number of load/store units to the processor. In order to accommodate multiple load/store units, local memories connected to the processor can have multiple read and write ports (one for each load/store unit). This further allows the local memories to be connected in any arbitrary connection topology. Connection box hardware is automatically generated that provides an interface between the load/store units and the local memories based on the configuration.
CROSS-REFERENCE TO RELATED APPLICATIONS This application is a divisional of U.S. application Ser. No. 10/146,651 filed May 13, 2002 now abandoned, entitled �Advanced Configurable and Extensible Microprocessor Architecture�, which is related to U.S. application Ser. No. 10/145,380 filed May 13, 2002, entitled �Vector Co-Processor for Configurable and Extensible Processor Architecture� and U.S. application Ser. No. 10/146,655 filed May 13, 2002, entitled �Method and Apparatus for Adding Advanced Instructions in an Extensible Processor Architecture,� the contents of which are incorporated herein by reference.
According to an aspect of the invention, therefore, the generation program allows the processor to have up to 3 load/store units 208. The actual maximum number of load/store units that can be provided is a design choice, but since they are expensive, three is considered sufficient for most applications. For each load/store unit, TIE will make available a complete set of interface signals (see co-pending application TEN-016, Ser. No. 10/146,655, excerpted below, for more details) that indicate what memory location to access and various properties�such as how many bytes are required, whether to read or write the data, whether the data should rotated, sign-extended or aligned, and so on. Thus a single instruction can access multiple memory locations with different attributes.
As further shown in FIG. 4, and as set forth above, the interface signals for each load/store unit (Sign, Rotate, Size, and Align) are derived from the user-specification, i.e. the TIE source code. The system of the prior patent and applications only allowed the user specification to control the operand size. If the instruction required sign-extension, rotation or alignment it had to be implemented by the user using TIE. By making these interface signals available it is now possible for user-defined instructions to share the core processor hardware. Furthermore, the core processor hardware can implement this functionality more efficiently. In the generated processors, load data can come one of several memories (DataRAM, DataROM, or a set-associative cache). This requires that the processor first detect a hit (i.e. determine which memory the access is to) and then select the appropriate data. In the case of a set-associative cache detecting a hit can take significant percentage of the cycle time as the processor must compare the tags of each way (a 20-bit comparison). One common trick used in processor design is to perform sign extension/rotate/alignment while the tag compare is going on. This requires that the sign-extend/rotate/alignment hardware be replicated for each memory (4 times in the case of a 4-way set-associative cache). Once the tag comparison is available the processor can select the final data rather than the raw data. This is a common feature in most processors. However, the system according to the invention is unique in allowing the user to directly control the sign-extend/rotate/alignment hardware using TIE. This not only saves hardware (as the user does not have to re-implement the same functionality) but also allows higher operating frequencies. An example implementation of how the aligner logic can be implemented in the load datapath is illustrated in FIG. 8, where each �way� corresponds to a different local memory. Those skilled in the art will understand how to implement the logic for the other load interfaces based on this example.
For processors with a connection topology such as FIG. 5A in which more than one load/store unit can be connected to the same memory, it is necessary to add additional read and/or write ports to the memory (whether the ports need to be read and/or write depends on the characteristics of the load/store units). For example, a system that connects two load/store units to a single memory will require two read/write ports for the memory. However, replicating memory ports is expensive�often adding one port will double the size of the memory. A cheaper way to mimic multiple ports is to use a banked memory system. In a banked memory system the memory is broken-up into smaller chunks (or banks). Which bank is activated depends on one (or more) bits of the address. Since each bank has one port it is possible to make multiple accesses in one cycle�as long as the accesses are to different banks. The hardware that maps between p port to b banks is connection box (CBox) 408.
According to one aspect of the present invention, the processor generation system can generate a CBox for an arbitrary number of ports and banks using any of the bits in the address to do the bank selection. Furthermore, the system can configure the CBox to support memory banks with single cycle or two cycle latency. The memory latency determines how many requests can be outstanding. In a banked memory system with 2 ports and two banks only one request can be pending. If the latency is 2 cycles, then there can be up to three pending requests. The finite state machines that sequence the requests need to be more sophisticated and this requires more buffering to be able to hold all the information for each request. An example of the Verilog code defining a CBox according to one possible implementation is attached as Appendix B. Lines starting with a semicolon (�;�) are interpreted by the pre-processor. Lines between =head1 or =head2 and =cut are documentation. As can be seen in this preferred example, the characteristics of the CBox are configurable on user selections such as number of connected load/store units, number and size of banks, bank select based on arbitrary bits of the memory address, and number and type (read, write or read/write) of bank ports.
In accordance with an aspect of the invention, co-processor 1204 includes a VLIW processor 1206. In one example, the VLIW processor executes a 64-bit wide instruction that can combine up to three operations per instruction. Further in accordance with the principles of the invention, co-processor 1204 is a Single Instruction Multiple Data (SIMD) processor, in which each operation operates on a �vector� data operand from vector registers 1208. The vector data operand can include a configurable number of scalar operands, all of which get processed by the same instruction. In one example implementation, a vector consists of eight scalar data elements. The combination of VLIW and SIMD processing techniques on this processor provides a significantly higher level of performance compared to DSP processors that use only one (or none) of these techniques.
The aspects of the alignment registers 1212 in accordance with the invention will now be described in more detail. In particular, a vector processing engine preferably includes means to efficiently load and store vectors of data from/to memory. In many cases, however, this is complicated by the fact that the data in memory is not aligned to the size of the vector. Loading and storing of such �unaligned� data from/to memory is generally inefficient. For example, in a memory comprised of a fixed word size, desired vector data of the fixed word size may exist at an offset from the word boundaries, such that the desired data exists in two adjacent locations in the memory. Thus, in order to load the desired vector from memory, first the data must be loaded from the two different memory locations into two different processor registers, then subsequent shift instructions must be performed on both registers to align the data in the two registers. Then another logical OR operation must be performed to merge the two data registers into a single register.
According to one aspect, the co-processor architecture of the present invention provides an efficient mechanism for accessing unaligned data in memory. This is done through the use of alignment registers 1212 and a set of load and store instructions that in the steady state provide a throughput of one unaligned load/store per instruction. The design of these unaligned load/store instructions is such that the same instruction sequence can be used to access the data, whether the data is aligned or unaligned (to the vector size) in memory. It is thus not necessary to check for alignment before initiating such load and store instructions. This reduces code size and improves runtime performance. Another very important advantage of this design is that it can be used in situations where the alignment of the data in memory is not known a priori�the code sequence works in either case.
Consider the problem of loading an unaligned vector from memory. As shown in FIG. 13, refer to elements E0-E7, E8-E15 etc., each of which represents a vector that is not aligned in memory. The following illustrates how an unaligned load operation is performed using the architecture of the present invention in a more optimal fashion. The processor initiates a vector load from the address corresponding to element E0. The memory will always read data from an aligned address, so it reads the values {E2, E1, E0, X4, X3, X2, X1, X0}. However, the load/store unit of processor core 1202 includes special logic in the load data path that detects the fact that the load was initiated on the address corresponding to E0, and not to the aligned address corresponding to X0. This logic then rotates the data so that the data coming into co-processor 1204 is now {X4, X3, X2, X1, X0, E2, E1, E0}. This data is loaded into the alignment register, which is a special �temporary store� for such data. In one embodiment of the current invention, the alignment registers are only 1112 bits wide, and hence the values {X3, X2, X1, X0, E2, E1, E0} are stored in the register while the value X4 is discarded. The next vector load is initiated from the address corresponding to element E8, which is the address of element E0 incremented by the vector size (16 bytes). This load reads the values {E10, E9, E8, E7, E6, E5, E4, E3} from memory, which gets rotated to become {E7, E6, E5, E4, E3, E10, E9, E8}. At this time, the logic in unit 1302 will combine the values E7-E3 of the load data bus, with values E2-E0 from the alignment register to form the vector {E7, E6, E5, E4, E3, E2, E1, E0} and load this value into vector register file 1208. At the same time, the alignment register is also updated with values {E6, E5, E4, E3, E10, E9, E8}. In the very next cycle, one could load E15-E11 from memory, combine it with E10-E8 from the alignment register and end up with E15-E8 in another vector register. Thus, if loading an array of vectors, one is able to perform an unaligned load every clock cycle. The only overhead was the very first load which is called the �priming load� since it is used to initialize the alignment register, or for �priming the pipeline.�
An aspect of the present invention is providing an innovative technique to address the above problem. Consider a special priming load instruction that is slightly different from the LVS16A.IU instruction described above. This instruction, LVS.P, takes only two input operands�an alignment register (u0, for example) and an address register (a3, for example). If the address in the address register is not aligned to a 16-byte boundary, the instruction serves the same purpose as the first LVS16A.IU instruction in the above code. It initializes the alignment register and increments the address register to point to the next vector in memory. If on the other hand the address is aligned to a 16-byte boundary, this instruction would do nothing�thus it would be the equivalent of branching over the LVS16A.IU instruction. The unaligned load code can now be rewritten as follows:
The next instruction to be executed is the unaligned store instruction, SVS16A.IU (an example TIE code implementation of which is provided in Appendix H). This instruction will take X4-X0 from the alignment register, combine it with E2′-E0′ from the vector register to form {X4, X3, X2, X1, X0, E2′, E1′, E0′}. This data is rotated on its way out (just as the load data was rotated on its way in), to become {E2′, E1′, E0′, X4, X3, X2, X1, X0} and this is what is written to memory. Note that the old values E2-E0 were updated with the new values E2′-E0′, while the values X4-X0 remain unchanged. Further, as part of the unaligned store operation, the alignment register gets updated with the value {E7′, E6′, E5′, E4′, E3′, E2′, E1′}, and the address register gets updated to point to the next vector in memory (starting at E3). Thus the next unaligned store instruction will combine E7′-E3′ from the alignment register with E10′-E8′ from the vector register to write the next vector to memory. From now on, there is a throughput of one unaligned store operation per instruction. At the very end, after the last unaligned store operation, there will be some elements left in the alignment register that need to be �flushed out� to memory. With reference to FIG. 13, this would be elements E63′-E59′. In one example of the present invention, a special instruction, SVA.F, known as the �store flush� instruction, is provided (an example TIE code implementation of which is attached in Appendix I). This instruction takes an alignment register and an address register as its input operand. If the address is not aligned to a 16-byte boundary, it does a partial store of the contents of the alignment register to memory�specifically in this case it will write elements E63′-E59′ to memory. If on the other hand the address is aligned to a 16-byte boundary, the store flush instruction does nothing. Based on the above discussion, the following code sequence is one example of how to do a series of unaligned stores to memory:
An improvisation over the above unaligned load/store implementation according to an alternative embodiment will now be described. Note in the above explanation of the unaligned store instruction that the two rightmost elements of the alignment register did not play any role in the execution of the instruction. Elements E2-E1 were loaded into these bits with the priming load, and were then overwritten by E2′-E1′ of the unaligned store instruction. These would subsequently be overwritten by E10′-E9′ and so on. Consider now that the alignment register is 128-bits wide instead of 112-bits. In this case, the three rightmost elements of the alignment register would not play any role in the execution of the unaligned store instruction�it would have contained elements E2-E0, E2′-E0′ etc. which are never used. Note also from the explanation of the unaligned load instruction that these three elements are precisely the ones that get used for the LVS16A.IU instruction. The unaligned load implementation on the other hand does not use the leftmost elements of the alignment register, and these are precisely the elements that get used by the unaligned store instruction SVS16A.IU. Thus for any unaligned address, the load and store instructions use a complimentary set of bits in the alignment register. This means that if the alignment register is designed to be 128-bits wide, and only the relevant bits of the alignment register are updated by the unaligned load and store instructions, then the same alignment register can be used to load as well as store an unaligned stream of data. If the alignment register can be shared, it means that the processor needs fewer alignment registers, which results in cost savings in hardware. The size of the alignment registers is increased from 112-bits to 128-bits in this alternative embodiment, but since this reduces the total number of alignment registers required in the design, it is a worthwhile tradeoff. An example code sequence is given below that can be used to perform a �read-modify-write� operation on an array of unaligned vectors.
Note that the store flush is a separate instruction that is executed once at the end of the instruction stream, and is outside the loop. What is needed now is that the store instruction, which is inside the loop, should behave differently during the first iteration of the loop (do a partial store) and in subsequent iterations of the loop (do a full store). One way to implement this behavior would be to �unroll� the first iteration of the loop, and create a special store instruction that has the desired behavior. In this case, the code would look as follows:
The present invention provides a unique implementation that does not require the unrolling of the loop and does a partial write in the first iteration of the loop, so as not to disturb the memory locations that should not be written. In this implementation, a �flag� bit is added and associated with each alignment register. Also, the priming instruction (for unaligned stores) is replaced with another instruction called ZALIGN (an example TIE code implementation of which is attached as Appendix J), which will set the alignment register contents along with the associated flag to 0. The new code sequence looks as follows:
Further aspects of the select registers 1214 in accordance with the invention will now be described. In this regard, it should be noted that while processing vector data in a SIMD fashion provides performance improvements, this approach also comes with its own unique challenges (as compared to scalar processing). One such challenge is that it is often necessary to rearrange the data in the vector register i.e. the order of the data elements in the register (after loading from memory) is not the order required for processing. Co-processor 1204 of the present invention thus provides �select� and �dual select� instructions to address this issue. The select instruction takes two vector registers as its input and generates a single vector register as its output. Each element of the output register can be independently selected to be any of the sixteen elements of the two input registers. Thus this instruction allows arbitrary rearrangement of the elements of the input vectors into the output vector. The dual select instruction takes two input vector registers and generates two output vector registers, again allowing each element of the output vector to be any element of the input vector. TIE code for implementing an example select instruction is provided in Appendix K.
The inventive aspects of MAC unit 1304 in accordance with the present invention will now be described in more detail. In this regard, it is first noted that most DSP algorithms perform a large number of �multiply-accumulate (MAC)� operations. This requires a multiplier, which is an expensive piece of hardware. Although each vector register 1208 holds eight scalar values, there are only four multipliers in hardware (only one multiplier is shown in FIG. 10 for ease of illustration). Thus, in order to multiply all eight data values, one would need to issue two multiply instructions. This is illustrated in the code below:
The present invention improves upon this situation by using an �iterative� multiply instruction. The ability to implement �iterative� instructions is described in more detail in the co-pending application TEN-016, Ser. No. 10/146,655 (see excerpt below). An iterative multiply instruction is a single instruction, that performs eight multiply operations over a period of two clock cycles, using four hardware multipliers. This instruction would be written as:
The sample code above thus illustrates that the presence of the iterative multiply instruction allows the processor to achieve a throughput of 4 MAC operations per instruction, which is the best that can be achieved with four multipliers in the hardware. It should be noted that the use of the DSEL instruction is just one example of how the �free� slot can be used. Since any non multiply instruction can be scheduled in this slot, the innovation allows for a vast array of DSP kernels to improve their MAC utilization by �hiding� some or all of their overhead processing in this slot. Referring back to FIG. 10, in one example implementation, the multiplier and multiplicand input operands of MAC unit 1304 are 18-bit wide, fixed-point data values. This generates a 36-bit product, which is accumulated in a 40-bit accumulator. Since the multiply operation results in eight 40-bit elements, they are stored in two adjacent vector registers addressed by bits [3:1] of the result operand field. According to an aspect of the invention, MAC unit 1304 provides four different �accumulation� options�no accumulation (multiply only), multiply/add, multiply/subtract, multiply and add ROUND register.
According to a preferred aspect of the invention, MAC unit 1304 provides even further support for �complex� number multiplication. Many DSP applications (such as the Fast Fourier Transform) operate on complex numbers; numbers that have �real� and �imaginary� components. A complex number is represented as {a+jb} where �a� and �b� represent the real and imaginary parts of the number respectively. The product of two complex numbers, {a+jb} and {c+jd} is defined as the complex number {(ac−bd)+j(ad+bc)}.
Another special instruction is the �butterfly add� instruction. The Fast Fourier Transform (FFT) is an algorithm very frequently implemented on DSP processors. This algorithm requires the repeated computation of the sum and difference of the input data elements i.e. the computation of (a+b) and (a−b). This would typically be computed by issuing two separate instructions�an ADD and a SUBTRACT instruction on the same operands. The butterfly add instruction is a special instruction that computes both the above values in a single cycle. This improves code density and the run time performance of the FFT kernel when implemented on co-processor 1204. The presence of this instruction also helps the FFT algorithm reach a higher number of �MAC operations per cycle�, which as explained earlier is an important measure of a DSP processors efficiency. TIE code for implementing an example of a butterfly add instruction is provided in Appendix O.
The �multiply sign� instruction is another possible special instruction (an example TIE code implementation of which is attached as Appendix P). It is modeled after the �copy sign� operation used in floating point data manipulations. The scalar operation corresponding to this instruction is illustrated by the pseudo-code below:
In addition, a preferred implementation of co-processor 1204 provides a number of different ALU and shift instructions. Most of these instructions come in two flavors�one that operates on the 20-bit narrow register type and the other that operates on the 40-bit wide register type.
While most of the core processor 1202 instructions read the register file in the R stage and execute the ALU operation in the E stage, the co-processor instructions have been �pushed� three cycles down in the pipeline stage. Thus co-processor 1204 ALU instructions read the register file in the M stage and do the computation in the W stage. In the modified pipeline data flow diagram below, note that when the NEG20 instruction is in the M stage (when it needs to read the input operand), the LVS16.I instruction is in the W stage and the result of the load is indeed available. As a result of this change, there are no stalls between the LVS16.I and the NEG20 instruction.
length l24 24 {InstBuf[3]==0}length l16a 16 {InstBuf[3:2]==2′b10}length l16b 16 {InstBuf[3:1]==3′b110}length l64 64 {InstBuf[3:1]==3′b111}
length�24=InstBuf[3:1]==3′b000|InstBuf[3:1]==3′b001|InstBuf[3:1]==3′b010|InstBuf[3:1]==3′b011;length�16=InstBuf[3:1]==3′b100|InstBuf[3:1]==3′b101|InstBuf[3:1]==3′b110;length�64=InstBuf[3:1]==3′b111;
format four_slots l64 {InstBuf[63]==1′b0}format three_slots l64 {InstBuf[63:62]==2′b10}format two_slots l64 {InstBuf[63:62]==2′b11}
format four_slots=(InstBuf[63:62]==2′b00|InstBuf[63:62]==2′b01) & l64;format three_slots=(InstBuf[63:62]==2′b10) & l64;format two_slots=(InstBuf[63:62]==2′b11) & l64;
The �Load� instruction loads 32 bits from memory and conditionally swap the bytes depending on the value of the state register �swap�. Likewise, the �Store� instruction stores 32 bits to memory before conditionally swap the bytes depending on the value of the state register �swap�. The byte swapping computation is present in both semantics, but have to be specified twice. Using TIE function construction, this description can be made more structured and understandable as follows:
wire [7:0] t0=ars[7:0]+(sub ?�art[7:0]:art[7:0])+sub;
wire [15:8] t1=ars[15:8]+(sub ?�art[15:8]:art[15:8])+sub;
wire [23:16] t2=ars[23:16]+(sub ?�art[23:16]:art[23:16])+sub;
wire [31:24] t3=ars[31:24]+(sub ?�art[31:24]:art[31:24])+sub;
assign addsub8=a+(sub ?�b:b)+sub;
This register operand definition specifies that the actual register number in the AR register file is the value stored in the instruction field �t�. The present invention provides a much more general way of specifying register operands.
The �regfile� statement defines a base register of 16 entries each of which is 32-bit wide. Because the 64-bit wide register only has 8 entries, it is accessed using 3-bit fields rd, sd, and td. Likewise, the 4-entry 128-bit wide register file is accessed using 2-bit fields rq, sq and tq. This description capability makes it possible to define the more efficient instruction ADDD and ADDQ which perform two and four additions respectively.
This example defines a 32-bit 16-entry base register file �SCALAR� and a �POINT� view that groups every two base registers into a wide register. It then declares a ctype �point� so that it can be used in an application code to declare the point data type. Since the wide register file �POINT� only has half as many registers (eight), it only needs 3 bits to address a register, thus the definition of field �sc�, �rc�, and �rt�. The wide operand �cs�, �cr�, and �cr� are defined using the field �sc�, �rc�, and �tc� to access the wide register file �POINT�. Finally, the cartesian point addition instruction �CADD� is defined. This description makes it possible to write application code like:
In this example, the register file XR can be accessed in many different ways. �xeven� can be used to access any even registers. �xhigh� can be used to access the upper half of the register file. �xfirst� can be used to access one of the first two registers. �xbanked� can be used to access the register in any one of the four banks of XR registers as specified by the state BANK. �xtracked� can access any one of the 16 registers, but has the side effect of keeping the number of times it is used in the state COUNT. The process of implementing hardware for a general register operand is outlined below:
This example defines two implicit operands. �x0� can be used to access the first register in the register file XR. �xr� can be used to access any register numbered by the state INDEX. Both of these operands are implicit because they do not depend on any instruction fields. The RTL implementation of the implicit operand is very similar to that of the general operand, with the exception that the field input to the operand module is omitted because implicit operands do not depend on any instruction field.
where �name� is an unique name of the exception. �higher-priority-list� is a list of exception names with higher priority. It is not necessary for an exception to be in the list if it has higher priority than at least one other exception in the list. For example, if exception A has higher priority than exception B which in turn has higher priority than exception C, it is sufficient to just put B in the higher-priority-list of C. �computation� specifies the logic to be evaluated when the exception is taken. It can read processor states and interface signals, and assign values to processor states and interface signals. Moreover, it can also raise another exception upon certain conditions. The exception semantic logic must contain an assignment to the processor interface signal �ExceptionVector�. Optionally, it can assign certain value to the processor state EXCCAUSE as a way of passing some information to the exception handler for the cause of the exception.
This example defines a new exception �add_overflow�. It has lower priority than the exception WindowOverflow4, WindowOverflow8, and WindowOverflow12. When this exception is taken, the processor will jump to location 32′h40000810 which should be loaded with the handler for this exception.
With this iclass definition, the semantic logic can assign �add_overflow� with 1 when an overflow occurs during the addition.
assign add_overflow=�ss & �st & sr|ss & st & �sr;
It raises the �last_exception� when an instruction attempts to access the last entry in the register file.
When the exception �exc_p� is raised by an instruction, it will raise the exception �exc_s� if the state �COND� has value �4′b1011�.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4236206Oct 25, 1978Nov 25, 1980Digital Equipment CorporationCentral processor unit for executing instructions of variable lengthUS5222225Aug 6, 1991Jun 22, 1993International Business Machines CorporationApparatus for processing character string moves in a data processing systemUS5598546Aug 31, 1994Jan 28, 1997Exponential Technology, Inc.Dual-architecture super-scalar pipelineUS5781750Jan 11, 1994Jul 14, 1998Exponential Technology, Inc.Dual-instruction-set architecture CPU with hidden software emulation modeUS5802556Jul 16, 1996Sep 1, 1998International Business Machines CorporationIn a microprocessorUS5812147Sep 20, 1996Sep 22, 1998Silicon Graphics, Inc.Instruction methods for performing data formatting while moving data between memory and a vector register fileUS5826071Aug 31, 1995Oct 20, 1998Advanced Micro Devices, Inc.Parallel mask decoder and method for generating said maskUS5896521Oct 2, 1996Apr 20, 1999Mitsubishi Denki Kabushiki KaishaProcessor synthesis system and processor synthesis methodUS5922066Feb 24, 1997Jul 13, 1999Samsung Electronics Co., Ltd.Multifunction data aligner in wide data width processorUS6023757Jan 30, 1997Feb 8, 2000Hitachi, Ltd.Data processorUS6026478Dec 23, 1997Feb 15, 2000Micron Technology, Inc.Split embedded DRAM processorUS6044450Mar 27, 1997Mar 28, 2000Hitachi, Ltd.Processor for VLIW instructionUS6058465Aug 19, 1996May 2, 2000Nguyen; Le TrongSingle-instruction-multiple-data processing in a multimedia signal processorUS6233596Sep 2, 1997May 15, 2001Seiko Epson CorporationMultiple sum-of-products circuit and its use in electronic equipment and microcomputersUS6272512Oct 12, 1998Aug 7, 2001Intel CorporationData manipulation instruction for enhancing value and efficiency of complex arithmeticUS6332186Aug 28, 1998Dec 18, 2001Arm LimitedVector register addressingUS6366998Oct 14, 1998Apr 2, 2002Conexant Systems, Inc.Reconfigurable functional units for implementing a hybrid VLIW-SIMD programming modelUS6477683Feb 5, 1999Nov 5, 2002Tensilica, Inc.Automated processor generation system for designing a configurable processor and method for the sameUS6496922Oct 31, 1994Dec 17, 2002Sun Microsystems, Inc.Method and apparatus for multiplatform stateless instruction set architecture (ISA) using ISA tags on-the-fly instruction translationUS6549999Jan 18, 2001Apr 15, 2003Matsushita Electric Industrial Co., Ltd.Data processorUS6704859Aug 4, 1998Mar 9, 2004Koninklijke Philips Electronics N.V.Compressed instruction format for use in a VLIW processorUS6721866Dec 21, 2001Apr 13, 2004Intel CorporationUnaligned memory operandsUS6820195Oct 1, 1999Nov 16, 2004Hitachi, Ltd.Aligning load/store data with big/little endian determined rotation distance controlUS6826679Nov 20, 2000Nov 30, 2004Texas Instruments IncorporatedProcessor with pointer tracking to eliminate redundant memory fetchesUS20010032305Feb 23, 2001Oct 18, 2001Barry Edwin F.Methods and apparatus for dual-use coprocessing/debug interfaceUS20030014457Jul 13, 2001Jan 16, 2003Motorola, Inc.Method and apparatus for vector processingJP2000298652A Title not availableJPH09251477A Title not availableJPH10134032A Title not availableWO2000046704A2Feb 4, 2000Aug 10, 2000Tensilica IncAutomated processor generation system and method for designing a configurable processorWO2001061576A2Feb 15, 2001Aug 23, 2001Tensilica IncAutomated processor generation system for designing a configurable processor and method for the sameWO2001073571A1Mar 16, 2001Oct 4, 2001Infineon Technologies AgMethod and apparatus for adding user-defined execution units to a processor using configurable long instruction word (cliw)Non-Patent CitationsReference1Berekovic, M., et al., "A Programmable Co-Processor for MPEG-4 Video," IEEE, p. 1021-1024, (2001).2Ercanli, E. et al., "A Register File and Scheduling Model for Application Specific Processor Synthesis", p. 35-40 (Jun. 1996).3 *Gonzalez; "Xtensa: A Configurable and Extensible Processor"; 2000; IEEE.4Iseli, C. et al., "Ac++ Compiler for FPGA Custom Execution Units Synthesis", Proc. of IEEE Symp on FPGAs for Custom Computing Machines, p. 173-179 (Apr. 1995).5Kondo, Y., et al., "A4 GOPS 3 Way-VLIW Image Recognition Processor Based on a Configurable Media-Processor," IEEE Int'l Solid State Circuits Conf., 3 pages, (2001).6Kondo, Y., et al., "A4 GOPS 3 Way�VLIW Image Recognition Processor Based on a Configurable Media-Processor," IEEE Int'l Solid State Circuits Conf., 3 pages, (2001).7Vert, William Dr., "An Essay on Endian Order," Dr. Bill's Notes on Little Endian vs. Big Endian, at website http://www.cs.umass.edu/~verts/cs32/endian.html, Apr. 19, 1996.8Vert, William Dr., "An Essay on Endian Order," Dr. Bill's Notes on Little Endian vs. Big Endian, at website http://www.cs.umass.edu/�verts/cs32/endian.html, Apr. 19, 1996.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS8108808 *Mar 20, 2009Jan 31, 2012Nec CorporationDescription processing device, description processing method, and recording mediumUS8422330 *Sep 23, 2011Apr 16, 2013Fujitsu LimitedMemory controller and memory controlling methodUS8447954 *Sep 4, 2009May 21, 2013International Business Machines CorporationParallel pipelined vector reduction in a data processing systemUS20100005338 *Sep 16, 2009Jan 7, 2010Jeffrey Mark ArnoldProgrammable Logic Configuration for Instruction ExtensionsUS20100106944 *Oct 14, 2009Apr 29, 2010Arm LimitedData processing apparatus and method for performing rearrangement operationsUS20110060891 *Sep 4, 2009Mar 10, 2011International Business Machines CorporationParallel pipelined vector reduction in a data processing systemUS20120163113 *Sep 23, 2011Jun 28, 2012Fujitsu Semiconductor LimitedMemory controller and memory controlling methodUS20120166511 *Dec 22, 2010Jun 28, 2012Hiremath Chetan DSystem, apparatus, and method for improved efficiency of execution in signal processing algorithmsWO2013095658A1 *Dec 23, 2011Jun 27, 2013Intel CorporationSystems, apparatuses, and methods for performing a horizontal add or subtract in response to a single instructionWO2013100893A1 *Dec 27, 2011Jul 4, 2013Intel CorporationSystems, apparatuses, and methods for generating a dependency vector based on two source writemask registers* Cited by examinerClassifications U.S. Classification712/37, 712/36International ClassificationG06F9/00Cooperative ClassificationG06F9/30032, G06F9/3816, G06F9/30014, G06F9/383, G06F9/3867, G06F9/30072, G06F9/3012, G06F9/3885, G06F9/30047, G06F9/30043, G06F9/30112, G06F9/3834, G06F9/30036, G06F9/3824, G06F9/3887, G06F9/3013, G06F9/30149European ClassificationG06F9/30T2, G06F9/38D, G06F9/38D4, G06F9/38T, G06F9/38P, G06F9/30A1A1, G06F9/30A2L, G06F9/30A1M, G06F9/30A5, G06F9/30A2P, G06F9/30R4C, G06F9/30A1P, G06F9/38T4, G06F9/38D2, G06F9/38S, G06F9/30R5, G06F9/30R5D, G06F9/38B9RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google