Patent Application
20050160402
The present invention relates generally to microprocessors, and more particularly, to a method and apparatus for adding advanced instruction extensions to a microprocessor.
New application-focused system-on-chip platforms motivate new application-specific processors. Configurable and extensible processor architectures offer the efficiency of tuned logic solutions with the flexibility of standard high-level programming methodology. Automated extension of processors and the associated software tools (compilers, debuggers, simulators and real-time operating systems) enables the use of such configurable and extensible processors. At the same time, designing at the level of software and instruction set architecture significantly shortens the design cycle and reduces verification effort and risk.
U.S. Pat. No. 6,282,633, issued Aug. 28, 2001 and entitled, “High Data Density RISC Processor,” U.S. application Ser. No. 09/246,047, filed Feb. 5, 1999 and entitled “Automated Processor Generation System for Designing a Configurable Processor and Software,” U.S. application Ser. No. 09/322,735, filed May 28, 1999 and entitled “System for Adding Complex Instruction Extensions to a Microprocessor,” and U.S. application Ser. No. 09/506,502, filed Feb. 17, 2000 and entitled “Improved Automated Processor Generation System for Designing a Configurable Processor and Software,” all commonly owned by the present assignee and incorporated herein by reference, dramatically advanced the state of the art of microprocessor architecture and design.
More particularly, these previous patents and applications described in detail a high-performance RISC processor, as well as a system that is able to generate a customized version of such a high-performance RISC processor based on user specifications (e.g., number of interrupts, width of processor interface, size of instruction/data cache, inclusion of MAC or multiplier) and implementation goals (e.g., target ASIC technology, speed, gate count, power dissipation, prioritization). The system generates a Register Transfer Level (RTL) representation of the processor, along with the software tools for the processor (compiler, linker, assembler, debugger, simulator, profiler, etc.), and the set of synthesis and place and route scripts to transform the RTL representation into a manufacturable geometric representation. The system further includes evaluation tools that allow for processor extensions to provide hardware support for commonly used functions in the application to achieve an ideal trade-off between software flexibility and hardware performance.
Generally, as shown in
Although the above processor and generation system provided many advantages, the processor was limited by restricting an instruction to perform a single computational task, however complex it may be. Increasing the number of computational tasks which can be performed simultaneously is a key to further improve the performance of embedded systems. To achieve this goal, several prior art microprocessors (e.g., the Intel IA-64 architecture), typically called VLIW machines, were invented to allow multiple operations to be packed into a single instruction for concurrent execution. In such a microprocessor, an instruction contains multiple operational slots, each capable of performing a set of operations independent of the others. The concurrency is achieved by a C/C++ compiler detecting parallel computational operations and packing the operations into VLIW instructions for simultaneous execution, or by the programmer manually grouping operations into VLIW instructions. However, all these prior art VLIW machines are limited to have a fixed instruction set, and cannot be configured to support application-specific extensions.
The present invention is directed to a system for adding advanced instructions to a microprocessor. The system includes a language for formally capturing the new instructions and a method for generating hardware implementations and software tools for the extended processors. The extension language provides for additions of VLIW instructions, complex load/store instructions, more powerful description styles using functions, more powerful register operands, instructions which generate exceptions, and a new set of built-in modules. The method is capable of generating fully-pipelined micro-architectural implementations for the new instructions in the form of synthesizable HDL descriptions which can be processed by standard CAD tools. The method is also capable of generating software components for extending software development tools for the microprocessor with new instructions.
According to one aspect, the processor generation system described in this invention improves both the configurable and extensible aspects of the processor generation systems described in the prior patent and applications, as well as improves upon fixed instruction set VLIW machines, by allowing system designers to design a VLIW microprocessor customized for a specific application to achieve higher performance, lower hardware cost, and lower power consumption.
These and other aspects and features of the present invention will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures, wherein:
The present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples of the invention so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention. Moreover, where certain elements of the present invention can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. Further, the present invention encompasses present and future known equivalents to the known components referred to herein by way of illustration. The Tensilica Instruction Extension (TIE) Language Reference Manual forms part of the present disclosure, is attached as Appendix C hereto and is incorporated herein by reference.
This invention builds upon the technology described in the prior patent and applications, in which the basic TIE language and its compiler and other tools are described for generating a customized high performance processor, along with supporting hardware descriptions and software tools for the customized processor. This invention extends the TIE language with new constructs for generating additional processor hardware and associated tools, and this disclosure describes what the new language constructs are and how the TIE compiler supports these constructs. Accordingly, the contents of the prior disclosures are incorporated herein by reference, and details of only the new features of the invention will be provided. In sum, however, the combined disclosures will enable those skilled in the art to practice a method for generating both hardware implementations and software tools for the extended processors.
As set forth above, and as shown in
An example VLIW instruction 302 in accordance with the invention is illustrated in
In a VLIW instruction set according to one example of the invention, an operation (op) is a computational task to be performed by an execution unit. As shown in
As further shown in
Generally, the process of determining the set of operations for a VLIW instruction in a processor defined according to one example of the invention is shown in
The following sections describe the new TIE constructs for capturing VLIW instructions and for generating associated hardware descriptions and software tools.
An initial step in describing VLIW instruction extensions is to specify their length. In one example implementation, a new instruction length can be defined by the TIE statement:
When instruction length definitions have been included in the TIE program, the program is processed by the TIE compiler. The hardware logic and software tools generation functions in the TIE compiler share a common method. This method creates a length table mapping the min-terms in the length decoding fields to instruction lengths. Only the instruction bits referenced by the length expressions are relevant. The table contains an entry for every possible combination of values of these bits. These combinations of bit values are analogous to min-terms in a logic expression and they are treated as such by the TIE compiler. One way of generating the length table from TIE length statements is described in
The following length table will be generated:
Using the length table constructed above, the hardware decoding logic can be constructed by the process described in
Using the length table constructed above, the software decoding routine can be constructed by the process described in
It should be noted that in the above example, the decoding field is restricted to be 4-bits wide. This is a preferred embodiment that yields efficient hardware decoding logic. The general method, however, allows for any number of bits in the decoding logic, and the present invention includes such alternative embodiments.
It should be further noted that the above example puts restrictions on the decoding logic expression. Again, this is a preferred embodiment for efficient decoding logic. The general method allows for arbitrary specification of the decoding logic.
Another step in adding VLIW extensions is defining the format of such instructions. In one example implementation, the format of a new VLIW instruction can be defined using the following TIE statement:
A format table such as the following is created for length 164:
Using the format code table constructed above, the hardware format decoding logic can be constructed by the process described in
Using the format code table constructed above, the software format decoding routine can be constructed by the process described in
Another step in adding VLIW extensions is defining the format of an operation slot. In one example implementation, the format of a new operation slot for a VLIW instruction can be defined using the following TIE statement:
When a TIE program is created containing such slot statements, the hardware logic and software generation functions of the TIE compiler will generate logic capable of extracting the slots. For example, the TIE program can include the following statements:
In the hardware implementation, it is often convenient to use a variable to represent the contents of a slot. The value of the slot variable is derived directly from the definition. Using the above example, let slot_alu be the variable for the alu slot, the HDL statement would look like assign slot_alu={InstBuf[23:4], InstBuf[27:24]};
This HDL is produced from the TIE slot statement by simply replacing the format name (e.g., “f64”) with the instruction buffer (“InstBuf”).
In software tools, it is also useful to use one variable to represent the contents of a slot. Using the same example and letting slot_alu be the variable for the alu slot, the C statement would look like
A next step in adding VLIW extensions is defining fields for operation slots. In one example implementation, the format of a new operation slot for a VLIW instruction can include fields, and fields can be used in different slots. A new operation field can be defined using the following TIE statement:
When a TIE program is created containing such field statements, the hardware logic and software generation functions of the TIE compiler will generate logic capable of extracting the fields. In particular, the TIE compiler will determine the slot sets for each created field. The slot set for a field is the set of slots containing that field. For example, the TIE program can include the following statements:
The compiler will then generate the following slot sets:
Another step in adding VLIW extensions is defining opcodes. In one example implementation, a new opcode for a VLIW instruction can be used in different slots. A new opcode can be defined using the following TIE statement:
When a TIE program is created containing such opcode statements, the hardware logic and software generation functions of the TIE compiler will generate decoder logic capable of recognizing the opcodes. As one aspect of this, the TIE compiler will determine the slot sets for each created opcode, where the slot set for an opcode is the set of slots containing the fields that specify that opcode. For example, the TIE program can include the following statements:
The following slot sets will then be determined.
Instruction (operation) classes, which associate opcodes with operands, are defined with TIE iclass statements. The set of slots in which an iclass is defined is referred to as the slot-set of the iclass. Since an iclass is defined in terms of opcodes and operands, the slot set for the iclass may not be directly obvious. An example method for determining the slot-set of an iclass is determining the intersection of the slot-sets for all the opcodes and the slot sets of the fields used by operands in the iclass definition.
Given the slot set of each iclass, the method of generating the decode logic to identify the opcode in each slot is the same as the method described in the aforementioned applications. As with the TIE description in the afore-mentioned applications, the iclass, semantic and reference definitions for the opcode will determine the behavior of an instruction including the opcode, and thus the hardware and software associated with the execution unit for the VLIW slot-sets determined for the opcode.
Referring back to
Using the processor generation system of the prior patent and applications, a load instruction reads the entire word (multiple bytes) from the memory. There was no way to read a subset of bytes in the word without reading the rest. For certain memory-mapped devices, reading a value effectively removes the data from the device. For such devices, reading unwanted data (bytes) is very un-desirable and could cost a great deal of additional hardware to work around the problem. Likewise, a store instruction in the prior system always writes the entire word into the memory. Writing only a subset of bytes in the word was not possible. The present invention provides a general way for specifying the individual bytes to be read or written during a load or store operation, through the use of newly-provided LoadByteDisable and StoreByteDisable interface signals.
With this scheme, the byte-disable logic is implemented once in the load/store unit and shared among all load/store instructions, including all processor core 202 instructions as well as all user-defined TIE datapath 204 instructions.
In another example limitation of the prior system, the data read from the memory is rotated in a particular way, according to the low-order bits of the virtual address from which the data is read. The data written to the memory is not rotated at all. If a load or a store instruction requires the data to be rotated in some other way, additional logic must be used. The present invention provides a more general way of specifying the rotate amount for the read and write data, eliminating the need to have extra rotating logic in the individual instruction semantic logic and allowing multiple instructions to share the rotation logic.
This new capability is provided with the RotateAmount interface signal. With this scheme, the rotation logic is implemented once in the load/store unit and shared among all load/store instructions, including all processor core 202 instructions as well as all user-defined TIE instructions.
As another example, for many load instructions dealing with signed data, it is common to perform sign extension on the data read from the memory. Using the prior system, this can be done in the instruction semantics. However, the sign extension logic typically involves replicating the sign bit many times, therefore increases the output loading of the sign bit and potentially makes it the critical timing path in the semantic logic. Co-pending application Ser. No. ______ (TEN-015) describes a way to perform this sign extension by moving the operation off the critical timing path in the load/store unit. The present invention provides a way for user-defined instructions to use the sign-extension logic in the load/store unit instead of in the instruction semantics, avoiding potential timing problems in the design. To capture the sign-extension requirement, the present invention adds two new signals to the TIE language, SignExtendFrom and SignExtendTo. SignExtendFrom specifies the position of the byte containing the sign bit, which typically is the most significant of the load data. SignExtendTo specifies the position of the most significant byte in the sign-extended data. For example, if the read data is 8′b10001111, SignExtendFrom is 1 and SignExtendTo is 2, the extended data would be 16′b1111111110001111.
With this new capability, the user TIE instruction can load sign-extended data from memory without any extra hardware. The following is an example of how to use this feature:
This description specifies a sign-extended load instruction that reads 16-bit data from memory location specified by “ars+imm8”, sign-extended it to 32 bits, and put the sign-extended data to “art”.
In almost all applications, there are load/store operations performed only when certain conditions are met. Doing the conditional load/store operations using multiple instructions is often inefficient. For example, the following code sequence:
will typically result in several instructions: evaluating the condition, branch, and load. Further inefficiency comes from the extra delay associated with typical branch instructions. It is desirable to compute this task in a single instruction that can conditionally load the data. However, in the prior system, if a load or a store instruction is issued, there was no way to cancel the load or store operation, making it impossible to implement a conditional load/store instruction. The present invention makes this possible through the use of LoadByteDisable and StoreByteDisable interface signals described earlier. The definition of LoadByteDisable/StoreByteDisable specifies that if all bytes are disabled the associated load/store operations are canceled. The following example illustrates how to use this feature:
This description implements a load instruction that conditionally loads the data when the address is even.
Allowing multiple parallel operations performed by an instruction is a key to increasing the system performance. The VLIW architecture supported by this invention does this by providing multiple operation slots in an instruction as described above. This makes it possible to perform several memory operations concurrently. Co-pending application Ser. No. ______ (TEN-015) describes the implementation of multiple load/store units. The present invention adds additional capability in TIE for user to associate a load/store instruction with a specific load/store hardware unit. Furthermore, the present invention provides a method for specifying a load/store instruction independent of any particular load/store units and a method for automatically mapping the unit-independent operations to the available hardware load/store units.
For any load/store operations specified using unit-independent memory interfaces, an automatic procedure can be used to assign the operations with specific hardware load/store units to optimize certain criteria, such as the total number of units required, or the maximum application performance. One preferred embodiment is illustrated in
Referring back to
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:
The TIE function construct of the present invention is even useful to structure a single instruction semantics when it performs the same computations several times in parallel. In the following example, the instruction addsub4x8 performs two 8-bit additions or subtractions depending on the value of the state register “sub”.
Clearly, the 8-bit addsub unit is specified four times. Using the new TIE function construct of this invention, the same description can be made more structured and more understandable as:
The prior processor generation system allows for several instruction semantics to share common hardware. But in order to achieve the sharing, the user has to merge the description of the instructions into a single semantic section and specify the sharing manually. For example, let ADD2, ADD3, and ADD4 be three instructions which add two, three, or four numbers. Using prior art invention, the description would look like:
Using the shared function construct of this invention, the instruction semantics can be specified separately as
Unlike software, hardware description language does not offer a direct way for two different modules to share a logic block. This invention provides a process by which the TIE compiler can automatically generate the RTL implementation for multiple semantic modules to share a function. The process involves the following steps:
The shared function in the present invention provides TIE with the capability of describing an instruction that uses a hardware computational unit several times (thus the term iterative instruction). This was not possible in the prior generation system. With this feature, the computational hardware would have to be replicated multiple times, resulting in extra hardware cost. For example, if one wanted to implement an instruction that does two 16-bit multiplications, using the prior system, the only way to do this is to use two 16-bit multipliers, as illustrated in the following description:
Using TIE shared function construct of the present invention, the instruction can be described using:
With this description, the 16-bit multiplier is only implemented once in hardware and used twice during the single execution of the instruction MUL2. The RTL implementation of using a shared function several times in a single iterative instruction is very similar to using a shared function in several different instructions.
As set forth above in reference to
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.
An important aspect of increasing the amount of computation performed by an instruction is to increase the number of input and output data. However, due to the limited number of bits in an instruction, there is a limit as to how many register operands can be used by an instruction. This invention provides a way for a single register operand to specify multiple adjacent registers in the register file. This new capability is based on an enhanced register file and register operand description. An example description would be:
This example of TIE code declares a register file INT8 for holding 32 8-bit integers. When every two entries are grouped, the register file can be used to hold 8 16-bit integers. When every four entries are grouped, the register file can be used to hold 4 32-bit integers.
There are two ways of using this new capability to increase the computational efficiency of an instruction. The first is to group several adjacent registers together as a way of passing more data to and from the instruction semantics (the computational logic). This is illustrated with the following example:
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.
The second way of using the wide register file is to use the multiple register entries to represent wider data. For instance, a single-precision floating-point register file can also be viewed as a double-precision register file with half as many entries.
As another example, consider the following use of wide register operands for a cartesian point data type:
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:
There are multiple ways of implementing a register file with multiple groupings. A preferred way is to build it hierarchically and is outlined here:
In the RTL implementation, each input/output register operand is mapped to a read/write port of the corresponding register file. In the prior system, this mapping was done automatically by the TIE compiler. There was no way to override the outcome of the mapping procedure. Since the number of read and write ports of a register file effect both the silicon area and the clock speed of the implementation, it is desirable to be able to specify the operand to register-file port association manually in the TIE description when attempting to optimize certain aspect of the design. The present invention adds this new capability to TIE.
With multiple register operands mapped to a single physical register file port (read or write), additional muxing logic is needed to generate the read or write address. The data inputs to the mux come from each operand assigned to the port. The select signals to the mux are generated by the decoder.
In operand definition, the operand semantics is the logic for computing the actual register number from the value stored in an instruction field. In the prior system, the register operand semantics must be a simple identity function, that is the register number must be directly present in an instruction field. Even though this has the advantage of being simple, it is sometimes too restrictive. The present invention extends the TIE language to allow for arbitrary operand semantic description. The “operand” language construct is used to capture an operand semantics.
SYNTAX:
For example, consider defining an operand to access a subset of the registers in a register file. Given the limited number of bits in an instruction, it is some time desirable to reduce the number of bits dedicated to an register operand when only a subset of the registers need to be accessed. This is illustrated in the following TIE description:
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:
For example, the following operand description:
will result in a verilog module with
In the prior processor generation system, a register operand must be defined as a function of an instruction field. The present invention allows for the definition of a register operand to be independent of any instruction field. An operand not depending on any instruction field is called an “implicit” operand. The present invention adds the following construct to the TIE language to capture the implicit operand.
SYNTAX:
Consider the following example of defining implicit operands to access a register file:
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.
In the prior processor generation system, a TIE instruction cannot raise exceptions. For example, it was not possible to define a TIE instruction that performs a division and raise a divide-by-zero exception if the divisor is zero. Likewise, it was not possible for a TIE load instruction to raise an unaligned-load exception when the address is not aligned. The present invention adds this new capability. The process of defining an exception has two steps: defining an exception and specifying the conditions under which the exception is to be raise. They are described hereinbelow.
An processor exception can be defined using the TIE exception construct. An exception has semantics that is the logic to be evaluated when the exception is taken. An exception can be raised by an instruction in its semantic logic or operand logic. An exception can also be raised as the result of evaluating the semantics of another exception. Exceptions have priorities. If an instruction raises several exceptions, the one with the highest priority will be taken by the processor.
SYNTAX:
Consider an example of defining an overflow exception for an add instruction:
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.
To allow for an instruction to conditionally raise an exception, the TIE iclass construct has been extended to have an additional clause for specifying a list of exception names. With the iclass definition, the instruction semantics can assign values to the exception names. The list of exceptions in the iclass qualifies the exceptions that can ever be raised for the opcodes in the iclass. For example, if an add instruction can raise the overflow exception defined in the previous section, its iclass may look like:
With this iclass definition, the semantic logic can assign “add_overflow” with 1 when an overflow occurs during the addition.
Raising an exception in an operand semantics is allowed by this invention, and can be specified by assigning the exception with a logic expression. When the expression is evaluated to 1, and when the exception is included in the list of exceptions for the iclass of the opcode, the exception is raised. For example:
It raises the “last_exception” when an instruction attempts to access the last entry in the register file.
An exception raised by an instruction or operand semantics is called a primary exception. An exception raised by another exception is called a secondary exception. Raising a secondary exception in an exception semantics is also allowed by this invention, and can be specified by assigning the exception with a logic expression. When the expression is evaluated to 1, the exception is raised. For example:
When the exception “exc_p” is raised by an instruction, it will raise the exception “exc_s” if the state “COND” has value “4b1011”.
The example implementation described here handles primary and secondary exceptions. However, the method is general and handles any fixed depth of exception nesting. The extension from the example implementation is entirely straightforward and obvious to one skilled in the art.
When multiple primary exceptions are raised, the one with the highest priority is selected. Then, the semantics of that exception is evaluated. If the semantics raises one or more secondary exceptions, the highest priority one among the secondary exceptions will be taken. When there are no secondary exceptions, the selected primary exception is taken.
As mentioned above, another aspect of the invention is the addition of certain built-in modules. In this regard, it is noted that certain commonly used computations have no language-defined operators. However, using other language constructs is either very tedious to describe or very hard to implement efficiently. TIE provides a set of commonly used operators as built-in modules invoked in the similar way as function calls. The following are the rules common to all built-in modules: Each built-in module has its own definition of computed-width. The definition is not effected by the required-width of the context. The inputs to the built-in modules have no required-width. In the case where an input does not have enough bits as needed by the definition of the built-in module, it is 0-extended.
The following are descriptions of built-in modules according to a preferred implementation of the invention.
TIEadd:
TIEaddn
TIEcsa
TIEcmp
TIEmac
TIEmul
TIEmulpp
TIEmux
TIEpsel
TIEsel
Although the present invention has been particularly described with reference to the preferred embodiments thereof, it should be readily apparent to those of ordinary skill in the art that changes and modifications in the form and details may be made without departing from the spirit and scope of the invention. For example, those skilled in the art will understand that variations can be made in the number and order of processing steps illustrated in the above flow diagrams. It is intended that the appended claims include such changes and modifications.
The present application is related to U.S. application Ser. No. ______ (TEN-014; Atty. Dkt. 83818-293238), and U.S. application Ser. No. ______ (TEN-015; Atty. Dkt. 83818-293239), both filed concurrently herewith and commonly owned by the present assignee, the contents of which are incorporated herein by reference.
