Configurable Reduced Instruction Set Core

A processor may be built with cores that only execute some partial set of the instructions needed to be fully backwards compliant. Thus, in some embodiments power consumption may be reduced by providing partial cores that only execute certain instructions and not other instructions. The instructions not supported may be handled in other, more energy efficient ways, so that, the overall processor, including the partial core, may be fully backwards compliant.

DETAILED DESCRIPTION

In accordance with some embodiments, a processor may be built with a partial core that only executes a partial set of the total instructions, by eliminating some instructions needed to be fully backwards compliant. Thus, in some embodiments power consumption may be reduced by providing partial cores that only execute certain instructions and not other instructions needed to be backwards compliant. The instructions not supported may be handled in other, more energy efficient ways, so that, the overall processor, including the partial core, may be fully backwards compliant. But the processor core may operate on the bulk of the instructions that are used in current generations of processors without having to support legacy instructions. This may mean that in some cases, the partial core processors may be more energy efficient.

For example, a partial core may eliminate a variety of different instructions. In one embodiment, a partial core may eliminate microcode read-only memory dependencies. In such case, the partial core instructions are implemented as a single operation instruction. Thus, the instructions get directly translated in hardware without needing to fetch corresponding micro-operations from the microcode read-only memory as is commonly done with complete or non-partial processors. This may save a significant amount of microcode read-only memory space.

In addition, only a subset of those instructions that are available on complete cores are actually used by modern compilers. As a result of architecture evolution over the last couple of decades, commercial instruction set architectures have many obsolete or non-useful instructions that can be eliminated for efficiency but at the cost of some lack of backwards compatibility.

Features from previous generations like 16-bit real mode from the Microsoft Disk Operating System (DOS) days and segmentation based memory protection architecture, local and global descriptor tables are being carried forward for backward compatibility reasons. But most modern operating systems do not need or use these features anymore. Thus, in some embodiments these features may simply be eliminated from partial cores.

Thus, in one embodiment, the partial core may be legacy-free or non-backwards compliant. This may make the core more energy efficient and particularly suitable for embedded applications. Other examples may include reducing the number of floating point and single-instruction multiple data instructions as well as support for caches. Only integer and scalar instructions set architecture subsets may be implemented in one embodiment of a partial core. The same idea can be extended to floating point and vector (single instruction multiple data) instruction sets as well as to features typically implemented by full cores. The partial core is simply an implementation of a subset architecture that in some embodiments may be targeted to embedded applications. Other implementations of a subset architecture include different numbers of pipelined stages and other performance features like out-of-order, super scalar caches to make these partial cores suitable for particular market segments such as personal computers, tablets or servers.

Thus referring toFIG. 1, an instruction memory12provides instructions to an instructions fetch unit14in a pipeline10. Those instructions are then decoded at the decode unit16. Operand fetch18fetches operands from a data memory24for execution at execute unit20. And the data is written back to the data memory24at write-back22.

In order to achieve full backwards compatibility, unsupported instructions may be handled in different ways. According to one embodiment, shown inFIG. 2, a full decoder16may be provided in the pipeline10. This decoder, at the time of full instruction decoding, detects unimplemented instructions and invokes prebuilt handlers34in execution unit20for those instructions. These pre-built handlers are dedicated designs that handle a particular instruction or instruction type. These pre-built handlers can be software or hardware based.

This approach may use a full-blown or complete decoder that speeds up detection of unsupported instructions and execution of execution handles. These pre-built handlers can be software or hardware based.

This full blown decoder speeds up detection of unsupported instructions and execution of execution handlers. The decoder may be divided into two parts. One part decodes commonly executed instructions and the second part decodes less frequently used instructions.

Thus referring toFIG. 2, the instructions are received by decode unit16. In this embodiment, the decode unit16may include an instruction parser26that detects which instructions are supported by the partial core32(which may be described as commonly executed instructions) and which instructions are not supported (which may be called less commonly or uncommonly executed instructions). The instructions that are supported by the partial core are decoded by a commonly executed decoder28and passed to the partial core32. Instructions that are uncommonly executed or unsupported are decoded by the decoder30and handled by pre-built handlers34in the execute unit20in one embodiment.

In some embodiments, a sequence36shown inFIG. 3, may be implemented in software, firmware and/or hardware. In software and firmware embodiments the sequence may be implemented by computer executed instructions stored in a non-transitory computer readable medium such as an optical, semiconductor or magnetic storage.

The sequence36, shown inFIG. 3begins by parsing the instructions as indicated in block38. Namely the instructions may be parsed based on identifying instructions that are supported by the partial core and instructions that are not supported by the partial core. In one embodiment the supported instructions are the commonly executed instructions. In other embodiments, particular instructions may be parsed out because they are ones that are supported by the partial core.

As indicated in block40the instructions of one type are sent to the first (commonly executed) decoder28and instructions of the second type are sent to the second41(uncommonly executed) decoder30. Then the decoded instructions of the first type are sent to the partial core and the decoded instructions of the second type are sent to the prebuilt handlers34as shown in block42.

According to another embodiment, a core may generate an undefined instruction exception. This may be an existing exception or a newly defined special exception. The exception may be generated when an instruction is encountered that is unsupported by the partial core. Then a software or binary translation layer may get control of execution or resolve the exception. For example, in one embodiment the binary translation layer may execute a handler program that emulates the unsupported instruction.

In some embodiments, a hybrid of this approach and the previously described approach, shown inFIGS. 2 and 3may be used. Thus referring toFIG. 4, a sequence44may be implemented in software, firmware and/or hardware. In software and firmware embodiments the sequence may be implemented by computer executed instructions stored on a non-transitory computer readable medium such as a magnetic, optical or semiconductor storage.

The sequence44begins by determining whether the instruction is supported as indicated in diamond46. If so, the instruction may be executed in the partial core as indicated in block48. Otherwise an exception is issued as indicated in block50.

In accordance with yet another embodiment, a processor may have one or two cores that include the full and complete instruction set and some number of partial cores that only implement a certain feature of the completed instruction set such as commonly executed features. Whenever a partial core comes across an unsupported instruction, the partial core transfers that task to one of the complete cores. The complete core in the mixed or heterogeneous environment can be hidden or exposed to operating systems. This approach does not involve any binary translation layer, either software or hardware in some embodiments, and differences in core features can be hidden from the operating system in other software layers.

Thus, referring toFIG. 5, the architecture may include at least one complete core51and at least one partial core52. Instructions are checked by the partial core52. If the instructions are unsupported then they are transferred to the complete core51. Other cases where instructions are transferred, may also be contemplated.

In accordance with one embodiment of a partial core processor, the following instructions may be supported:

The following instructions may not be supported in accordance with one embodiment:

In some embodiments, a configurable partial core may be produced with the appropriate circuit elements and software. In one embodiment, the user can enter selections in response to graphical user interfaces. Then the system automatically generates the register transfer level (RTL) and software to implement a partial core with those features. In some embodiments, the instructions set is predefined and further configurability may be offered. In other embodiments, a system may enable the user to manually implement configuration selections. As an example, one system may permit configuration of caches, branch predictors, pipeline bypasses, and multipliers.

For example, in one embodiment, a cache configuration may be set by default with tightly coupled data and instruction caches. Among the options that may be selected includes split data and instruction caches and selectable cache parameters, such as cache size, line size, associativity, and error correction code.

Branch predictors may be set by default using the always not-taken approach to conditional branching. Selectable options, in some embodiments, may include backwards taken and forwards not-taken, branch target buffers of two, four, eight or sixteen entries, full scale G-share based, or a predictor with a configurable number of entries.

A set of default pipeline bypasses may be selectively deactivated in one embodiment. Default bypasses allow users to trade off performance for higher frequency but at the expense of power. For example, a bypass called IF_IBUF allows data coming from the instruction memory/cache to go directly to the predecoder and decoder stages without first going into the instruction buffer. Similarly, there is another bypass in some embodiments that sends results from a compare instruction, to operand fetch and instruction stages for quickly determining if a jump instruction, that is the next compare instruction, results in jumping into a different location or not. Based on this information, the instruction fetch unit can start fetching instructions starting at the new address. This bypass reduces the penalty for conditional jump instructions. While these bypasses offer higher efficiency, they do so at the cost of frequency. If a particular application needs higher frequency, then these bypasses can be selectively turned off at design time.

Still another set of options relates to the multiplier. A default configuration in one embodiment may offer one, two or multiple cycle multipliers. The user can choose one of these three multipliers based on a user's requirements. The single cycle multiplier takes more area and may limit the design from reaching higher frequencies but only takes one cycle to execute 32×32 bit multiplication operations. The multi-cycle multiplier on the other hand takes about 2,000 gates versus 7,000 gates for a single cycle multiplier, but takes more than one cycle to execute 32×32 bit multiplier operations.

In some embodiments other configurable features including memory protection unit, memory management unit, write back buffer may be made available. It can also be extended to the floating point unit, single instruction multiple data, superscalar, and number of supported interrupts to mention some additional configurable features.

In some embodiments, some selectable features are performance oriented, as is the case by with bypasses, branch predictors and multipliers, and others are functionality or feature oriented such as those related to caches, memory protection units and memory management units.

Referring toFIG. 6, a core configuration sequence60may be implemented in software, hardware and/or firmware. In software and firmware embodiments it may be implemented by computer executed instructions stored in a non-transitory computer readable medium such as an optical, magnetic or semiconductor storage.

In one embodiment, the sequence60begin by displaying selectable cache options for a partial core design as indicated in block62. Once the user makes a selection, as indicated in diamond64, the option is set as indicated in block66, meaning that it will be recorded and ultimately be implemented into the necessary code without further user action in some embodiments. If a selection is not made, the flow simply awaits the selection.

Next branch prediction options may be displayed as indicated in block68followed by a selection check at diamond70and an option set stage at block72.

Thereafter, pipeline bypass options may be displayed (block74) followed by selection at diamond76and option setting at block78. Next, multiplier options may be displayed as indicated at block80. This may again be followed by a selection decision at diamond82and option setting at block84.

Finally, all the options that have been set or selected are collected and the appropriate RTL and software code is automatically generated as indicated in block86. Thus, based on the designer's selections, the necessary code to create the hardware and software configuration may be generated automatically in some embodiments.

Referring toFIG. 7, a system90for implementing one embodiment to the present invention may include a processor92coupled to a code database94, an RTL engine96, a display driver100and a software code generator98. Code database94stores the database of codes for the different selectable options. The RTL engine96includes the ability to generate RTL code in response to user selections. The software code generator generates the necessary software code to implement the user selections. The display driver100drives the display104and includes software for generating the graphical user interface (GUI)102in one embodiment that provides user selectability of various defined options.