U.S. patent application number 11/204555 was filed with the patent office on 2005-12-08 for programmable logic configuration for instruction extensions.
This patent application is currently assigned to Stretch, Inc.. Invention is credited to Arnold, Jeffrey Mark, Banta, Gareld Howard, Johnson, Scott Daniel, Wang, Albert R..
Application Number | 20050273581 11/204555 |
Document ID | / |
Family ID | 34103868 |
Filed Date | 2005-12-08 |
United States Patent
Application |
20050273581 |
Kind Code |
A1 |
Arnold, Jeffrey Mark ; et
al. |
December 8, 2005 |
Programmable logic configuration for instruction extensions
Abstract
A processing system with reconfigurable instruction extensions
includes a processor, programmable logic, a register file, and a
load/store module. The processor executes a computer program
comprising a set of computational instructions and at least one
instruction extension. The programmable logic receives
configuration information to configure the programmable logic for
the instruction extension and executes the instruction extension.
The register file is coupled to the programmable logic and stores
data. The load/store module transfers the data directly between the
register file and a system memory.
Inventors: |
Arnold, Jeffrey Mark; (San
Diego, CA) ; Banta, Gareld Howard; (Atherton, CA)
; Johnson, Scott Daniel; (Mountain View, CA) ;
Wang, Albert R.; (Los Altos, CA) |
Correspondence
Address: |
CARR & FERRELL LLP
2200 GENG ROAD
PALO ALTO
CA
94303
US
|
Assignee: |
Stretch, Inc.
|
Family ID: |
34103868 |
Appl. No.: |
11/204555 |
Filed: |
August 15, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11204555 |
Aug 15, 2005 |
|
|
|
10732392 |
Dec 9, 2003 |
|
|
|
6954845 |
|
|
|
|
10732392 |
Dec 9, 2003 |
|
|
|
10630542 |
Jul 29, 2003 |
|
|
|
Current U.S.
Class: |
712/226 ;
712/E9.033; 712/E9.047 |
Current CPC
Class: |
G06F 9/3816 20130101;
G06F 9/383 20130101; G06F 9/30043 20130101 |
Class at
Publication: |
712/226 |
International
Class: |
G06F 015/00 |
Claims
1. A processing system with reconfigurable instruction extensions,
the system comprising: a processor operable to execute a computer
program comprising a set of computational instructions and at least
one instruction extension; programmable logic operable to receive
configuration information to configure the programmable logic for
the instruction extension and operable to execute the instruction
extension; a register file coupled to the programmable logic and
operable to store data; and a load/store module operable to
transfer the data directly between the register file and a system
memory.
2. The processing system of claim 1 further comprising an extension
adapter coupled to the processor and operable to detect whether the
instruction extension is not resident in the processor.
3. The processing system of claim 2 wherein the extension adapter
is operable to generate an exception to load the configuration
information into the programmable logic.
4. The processing system of claim 2 wherein the extension adapter
is operable to load the configuration information into the
programmable logic.
5. The processing system of claim 4 wherein the extension adapter
is operable to load the configuration information into the
programmable logic based on a fault condition of the instruction
extension.
6. The processing system of claim 4 wherein the extension adapter
is operable to load the configuration information into the
programmable logic concurrently with the execution of the computer
program using direct memory access.
7. The processing system of claim 2 wherein the extension adapter
is operable to detect whether the programmable logic is busy
executing another instruction extension and wait until the
programmable logic is finished executing another instruction
extension.
8. The processing system of claim 2 wherein the extension adapter
is operable to determine whether a stored state exists for the
instruction extension and restore the stored state in the
programmable logic for the instruction extension.
9. The processing system of claim 7 wherein the extension adapter
is operable to store the stored state for the instruction
extension.
10. The processing system of claim 1 further comprising
configuration memory operable to store configuration information
for the programmable logic.
11. The processing system of claim 1 wherein the processor is
operable to load the configuration information into the
programmable logic.
12. The processing system of claim 1 wherein the computer program
initiates to load the configuration information into the
programmable logic.
13. The processing system of claim 12 wherein the computer program
initiates to load the configuration information into the
programmable logic by using a system call.
14. A method for operating a processing system with reconfigurable
instruction extensions, the method comprising: executing a computer
program comprising a set of computational instructions and at least
one instruction extension; receiving configuration information into
programmable logic to configure the programmable logic for the
instruction extension; executing the instruction extension in the
programmable logic; storing data in a register file coupled to the
programmable logic; and transferring the data directly between the
register file and a system memory using a load/store module.
15. The method of claim 14 further comprising detecting in an
extension adapter whether the instruction extension is not resident
in the processor.
16. The method of claim 15 further comprising generating an
exception in the extension adapter to load the configuration
information into the programmable logic.
17. The method of claim 15 further comprising loading the
configuration information into the programmable logic using the
extension adapter.
18. The method of claim 17 wherein loading the configuration
information into the programmable logic using the extension adapter
is based on a fault condition of the instruction extension.
19. The method of claim 17 wherein loading the configuration
information into the programmable logic using the extension adapter
occurs concurrently with the execution of the computer program
using direct memory access.
20. The method of claim 15 further comprising: in the extension
adapter, detecting whether the programmable logic is busy executing
another instruction extension; and in the extension adapter,
waiting until the programmable logic is finished executing another
instruction extension.
21. The method of claim 14 further comprising: determining whether
a stored state exists for the instruction extension; and restoring
the stored state in the programmable logic for the instruction
extension.
22. The method of claim 21 further comprising storing the stored
state for the instruction extension.
23. The method of claim 14 further comprising storing configuration
information for the programmable logic in configuration memory.
24. The method of claim 14 further comprising loading the
configuration information into the programmable logic using the
processor.
25. The method of claim 14 wherein the computer program initiates
to load the configuration information into the programmable
logic.
26. The method of claim 14 wherein the computer program initiates
to load the configuration information into the programmable logic
by using a system call.
27. A processing system with reconfigurable instruction extensions,
the processing system comprising: means for executing a computer
program comprising a set of computational instructions and at least
one instruction extension; means for receiving configuration
information into programmable logic to configure the programmable
logic for the instruction extension and for executing the
instruction extension in the programmable logic; means for storing
data in a register file coupled to the programmable logic; and
means for transferring the data directly between the register file
and a system memory using a load/store module.
28. The processing system of claim 27 further comprising means for
detecting whether the instruction extension is not resident in the
processor.
29. The processing system of claim 27 further comprising means for
generating an exception to load the configuration information into
the programmable logic.
30. The processing system of claim 27 further comprising means for
loading the configuration information into the programmable
logic.
31. The processing system of claim 30 wherein the means for loading
the configuration information into the programmable logic is based
on a fault condition of the instruction extension.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation of U.S. application Ser.
No. 10/732,392 filed on Dec. 9, 2003 and entitled "Reconfigurable
Instruction Set Computing," which is a continuation-in-part of U.S.
application Ser. No. 10/630,542 filed on Jul. 29, 2003 and entitled
"Defining Instruction Extensions in a Standard Programming
Language", which are both hereby incorporated by reference. The
subject matter of this application is related to U.S. application
Ser. No. 10/404,706 filed on Mar. 31, 2003 and titled "Extension
Adapter", which is incorporated herein by reference.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The present invention relates generally to the field of
programmable computer processors, and more particularly to
programmable logic configuration for instruction extensions.
[0004] 2. Description of the Prior Art
[0005] Computer processors can generally be sorted into two
classes: general purpose processors that can be adapted to a
multitude of applications; and application-specific processors that
are optimized to serve specific applications. General purpose
processors are designed to run a general instruction set, namely a
set of instructions that the processor will recognize and execute.
Such general instruction sets tend to include a large number of
instructions in order to support a wide variety of programs.
[0006] Application-specific processors are designed to run a more
limited instruction set, where the instructions are more tailored
or specific to the particular application. While an
application-specific processor can enable certain programs to
execute much faster than when run on a general purpose processor,
they are by definition more limited in functionality due to the
limited instruction sets they run.
[0007] Before the application-specific processor is manufactured,
instructions may be added to extend the application-specific
processor's instruction set. In one example, instructions may be
added using a Tensilica Instruction Extension (TIE) language and a
TIE compiler from Tensilica, Inc. of Santa Clara, Calif. A designer
defines the new instruction in the TIE language by specifying the
characteristics of the instruction such as the field, the opcode,
and the operands. A TIE compiler then compiles the source code in
the TIE language for the new instruction for simulation,
verification, and creation of the necessary files such as dynamic
linked libraries.
[0008] One problem with the TIE language and the TIE compiler is
that instructions can only be added prior to the fabrication of the
processor. This time period before fabrication is also known as
"pre-silicon." The time period after fabrication is known as
"post-silicon." One problem with the TIE language and the TIE
compiler is the instruction set of the processor cannot be extended
to include new instructions during this post-silicon period.
Furthermore, another problem with the TIE language and the TIE
compiler is during this post-silicon period, the characteristics of
the instructions cannot be changed or modified. Therefore, during
this post-silicon period, the processor is limited only to a finite
set of instructions defined in the pre-silicon period and limited
to the characteristics of the instructions defined in the
pre-silicon period.
[0009] Some systems have used programmable logic devices (PLD) with
processors. One example of a programmable logic device is a
field-programmable gate array (FPGA). One prior art system called
Garp includes a MIPS processor with reconfigurable hardware that
are both located on the same die. This Garp system uses a
co-processor model of communication between the processor and the
reconfigurable array. The reconfigurable hardware in this Garp
system is an FPGA that acts as a slave computational unit to the
MIPS processor, where the MIPS processor would explicitly hand
control to the reconfigurable array and wait until the array task
is completed. Although the reconfigurable array and the MIPS
processor share a common path to a cache and memory, there is no
direct connection between the processor's data path and the array.
This Garp system is described in a publication entitled "Garp: A
MIPS Processor with a Reconfigurable Coprocessor" by John R. Hauser
and John Wawrzynek.
[0010] One example of an FPGA is manufactured by Altera in San
Jose, Calif. Another example of an FPGA is a Virtex-II Pro (V2Pro)
FPGA manufactured by Xilinx in San Jose, Calif. This V2Pro FPGA
uses a more loosely coupled model of communication in which the
FPGA appears as a memory mapped peripheral to the processor(s).
[0011] One problem with the Garp system and the V2Pro FPGA is the
cost of initiating a computation in the programmable fabric. In
both the Garp system and the V2Pro FPGA, the processor must execute
several instructions to initiate a co-processor computation, which
adds overhead to initiate an extension instruction. Also, the
processor must wait for the co-processor computation to complete,
which prevents other instructions from being executed.
[0012] Accordingly, what is desired is the ability to write a
program in a convenient programming language and to extend an
instruction set of a computer processor with instructions tailored
to that program so that the program can execute on that computer
processor more efficiently.
SUMMARY OF THE INVENTION
[0013] A processing system with reconfigurable instruction
extensions includes a processor, programmable logic, a register
file, and a load/store module. The processor executes a computer
program comprising a set of computational instructions and at least
one instruction extension. The programmable logic receives
configuration information to configure the programmable logic for
the instruction extension and executes the instruction extension.
The register file is coupled to the programmable logic and stores
data. The load/store module transfers the data directly between the
register file and a system memory.
[0014] Configuring the programmable logic may be by means of:
static configuration by the compiler before execution of the
computer program in the processor; explicit configuration while the
application executes; or implicit configuration wherein an
extension adapter detects instruction extensions and configures the
programmable logic. The extension adapter determines whether the
programmable logic device is already configured to execute the
instruction extension, obviating unneeded reconfiguration.
[0015] A method for operating a processing system with
reconfigurable instruction extensions includes executing a computer
program comprising a set of computational instructions and at least
one instruction extension and receiving configuration information
into programmable logic to configure the programmable logic for the
instruction extension. The method also includes executing the
instruction extension in the programmable logic. The method further
includes storing data in a register file coupled to the
programmable logic and transferring the data directly between the
register file and a system memory using a load/store module.
[0016] A further understanding of the nature and advantages of the
inventions herein may be realized by reference to the remaining
portions of the specification and the attached drawings.
BRIEF DESCRIPTION OF DRAWINGS
[0017] FIG. 1 is a schematic diagram of an exemplary extensible
processor system of the present invention;
[0018] FIG. 2 is a schematic diagram of an Instruction Set
Extension Fabric (ISEF) in accordance with the schematic of FIG.
1;
[0019] FIG. 3 illustrates an example of the cluster block
implementation illustrated in FIG. 2;
[0020] FIG. 4 is a schematic diagram illustrating details of the
extension adapter of FIG. 1, in accordance with an embodiment of
the present invention;
[0021] FIG. 5 is a schematic diagram illustrating an operation
involving the reading of data in accordance with the extension
adapter of FIG. 4;
[0022] FIG. 6 is a flow chart illustrating the compiling of an
application of the present invention;
[0023] FIG. 7 is a flow chart further detailing the method of the
compilation illustrated in FIG. 6;
[0024] FIG. 8(a) and 8(b) illustrate a preferred process for
executing an instruction extension in the implicit reconfiguration
embodiment of the present invention;
[0025] FIG. 9 is a block diagram illustrating the alternating
configuration of two ISEF's in accordance with an embodiment of the
present invention;
[0026] FIG. 10 is a timing diagram showing the various time phases
during alternating configuration of the two ISEF's of FIG. 9;
and
[0027] FIG. 11 is a block diagram illustrating partial Instruction
Set Extension Fabric reconfiguration in accordance with the present
invention.
DETAILED DESCRIPTION OF THE INVENTION
[0028] The present invention provides a method for extending a
processor instruction set to include new, extended instructions and
for replacing a critical code segment of a computer program with a
function that causes the new instruction to execute. As general
purpose processors typically do not have programmable instruction
sets, the present invention will be described with reference to the
programmable processing hardware of FIG. 1, though it will be
appreciated that the invention is not so limited and can be used in
conjunction with other suitable programmable processing
hardware.
[0029] FIG. 1 is a schematic drawing of an exemplary programmable
processing system 110 in an exemplary implementation of the
invention. The programmable processing system includes a processor
core 120, an Instruction Set Extension Fabric (ISEF) 130, and an
extension adapter 140 that couples the ISEF 130 to the processor
core 120. The processor core 120 can include optional features such
as coprocessors, write buffers, exception handling features, debug
handling features, read only memory (ROM), etc. In some
embodiments, the processor core 120 can include multiple processor
cores. The processor core 120 provides standard processing
capabilities such as a standard (native) instruction set that
provides a set of instructions that the processor core 120 is
designed to recognize and execute. Typical instructions include
arithmetic functions such as add, subtract, and multiply, as well
as load instructions, store instructions, and so forth. These
instructions are hard-coded into the silicon and cannot be
modified. One example of a suitable processor core 120 is the
Xtensa.RTM. V (T1050) processor, from Tensilica, Inc., of Santa
Clara, Calif.
[0030] Instruction Set Extension Fabric (ISEF) 130 includes
programmable logic for enabling application-specific instructions
("instruction extensions") to be stored and executed. The
Instruction Set Extension Fabric 130 is a type of programmable
logic device. Because it is programmable, the instruction set of
Instruction Set Extension Fabric 130 can be readily configured to
include instruction extensions that are tailored to a specific
application. In some embodiments the programmable logic device
(ISEF) 130 runs at a slower clock speed than processor core 120. In
these embodiments the cycle length of the programmable logic device
130 can be a multiple of the clock cycle of the processor core
120.
[0031] Extension adapter 140 provides an interface between the
Instruction Set Extension Fabric 130 and the processor core 120.
Extension adapter 140 receives instructions and determines whether
the instructions should be directed to the Instruction Set
Extension Fabric 130 or the processor core 120. In some embodiments
extension adapter 140 provides an interface between a plurality of
Instruction Set Extension Fabrics 130 and processor cores 120.
Extension adapter 140 can be implemented, for example, in
Application Specific Integrated Circuit (ASIC) logic. In some
embodiments, extension adapter 140 may be integrated within
processor core 120 or ISEF 130.
[0032] Extension adapter 140 in combination with ISEF 130 provide
logic that allows users to extend the native instruction set
defined by the processor core 120. It is noteworthy that the
extended instruction execution itself is implemented in one or more
of Instruction Set Extension Fabrics 130. Extension adapter 140
interfaces one or more Instruction Set Extension Fabrics 130 to one
or more processor core 120 and controls dataflow.
[0033] Instruction Set Extension Fabric
[0034] FIG. 2 illustrates one embodiment of an Instruction Set
Extension Fabric (ISEF)130. As shown, ISEF 130 includes a plurality
of cluster blocks 202 arranged in rows and columns. Data is
communicated between cluster blocks 202 by means of a global
interconnect 204. As shown, the global interconnect 204 also
communicates data and dynamic configuration information used or
output by ISEF 130 with other devices including extension adapter
140, which data and dynamic configuration information will be
described in more detail below. Although generically shown as
permitting any two cluster blocks 202 in ISEF 130 to communicate
directly with each other via global interconnect 204, such
interconnections need not be so limited. For example, only cluster
blocks 202 can additionally or alternatively have interconnections
such that blocks in adjacent rows and/or columns communicate
directly with each other.
[0035] Although not necessarily part of ISEF 130, and preferably
separately provided, also shown is configuration memory 206.
Configuration memory 206 stores static configurations for ISEF 130.
The term "memory" is not intended to be construed as limiting.
Rather, configuration memory 206 can have various implementations
including CMOS static random access memory (SRAM), fused links and
slow speed electrically erasable read only memory (EEPROM).
[0036] FIG. 3 illustrates a cluster block arrangement that can be
used to implement cluster block 202 in FIG. 2. As shown, it
includes a plurality of ALU controller (AC) blocks 302 and function
cells 304. The AC blocks 302 provide configuration signals for a
respective column 310 of function cells 304. In one example of the
invention, cluster block 202 includes four columns of four function
cells 304, each column including one AC block 302.
[0037] FIG. 3 shows paths for sharing data and dynamic
configuration information between vertically or horizontally
adjacent function cells 304 within cluster block 202, and with
other cluster blocks via global interconnect 204. Also shown are
horizontal word lines 308 and vertical word lines 306, by which
certain or all of the interior function cells 304 may communicate
data with other cluster blocks 202, which word lines partially
implement global interconnect 204.
[0038] One example of the Instruction Set Extension Fabric 130 is
described in more detail in U.S. Patent Publication Number US
2001/0049816, which is incorporated herein by reference. A suitable
Instruction Set Extension Fabric 130 is available from Stretch,
Inc., of Mountain View, Calif.
[0039] Extension Adapter
[0040] Referring to FIG. 4, extension adapter 140 is shown in
greater detail. In one embodiment, extension adapter 140 comprises
load/store module 410 and adapter controller 412. In another
embodiment, processor core 120, and not extension adapter 140,
comprises load/store module 410.
[0041] Load/store module 410 can be created via a compiler, such
as, for example, the Tensilica Instruction Extension (TIE)
compiler, which can be obtained from Tensilica, Inc., of Santa
Clara, Calif. TIE is a language that allows a user to describe the
functionality of new extended instructions. A designer uses TIE to
create a standard set of functions that extend the normal
functionality of processor core 120. The TIE code that a designer
writes describes the functionality of a series of resources that
aid in the interface between processor core 120 and extension
adapter 140. Extension adapter 140 functions such that processor
core 120 treats user-defined post-silicon, extended instructions as
if they were native instructions to the processor core 120. In some
embodiments, the extended instruction includes at least one new
instruction added post-silicon and a set of pre-silicon
instructions.
[0042] Load/store module 410 interfaces with processor core 120 via
interface 414. Register file 420 is coupled to interface 414 via
processor control and data interface 421 and via ISEF control and
data interface 423. Adapter controller 412 interfaces with
processor core 120 via interface 416. Adapter controller 412
interfaces with ISEF 130 via interface 418.
[0043] In an exemplary embodiment according to the present
invention, load/store module 410 comprises register file 420.
Register file 420 is a register file, or collections of registers,
that is added by using, for example, the TIE compiler. Register
file 420 interfaces with adapter controller 412 via interface 424.
In one embodiment, register file 420 is 128 bits wide. In another
embodiment, register file 420 is 64 bits wide. However, register
file 420 can be of varying widths. It is contemplated that the
system can comprise one or more than one register file 420. Adapter
controller 412 accesses register file 420. Adapter controller 412
is then used to interface with ISEF 130.
[0044] Load/store module 410 provides fixed instruction
functionality. A set of fixed instructions includes instructions
for moving data to and from external memory (not shown), into and
out of register file 420. This collection of functionality is
defined in one embodiment in the TIE language, and is implemented
through Tensilica's TIE compiler. It is contemplated that languages
other than TIE can be used with the present system. Load/store
module 410 contains one or more register files 420 and a set of
fixed instructions that give register files 420 access to external
memory via load and store instructions. Again, these instructions
will be fixed once the silicon is created, and are fully
implemented using the standard TIE flow. It is a function of the
extension adapter 140 to encapsulate the fixed functionality and
manage it with the configurable interface logic.
[0045] A purpose of load/store module 410 includes defining the
functionality of register file 420, which is temporary storage for
data that is going to be transferred between processor core 120 and
ISEF 130. Load/store module 410 defines not only register file 420,
but also defines how to load and store generic instructions (e.g.,
Tensilica instructions) of processor core 120 into register file
420. Adapter controller 412 performs the function of interfacing
with register file 420. Adapter controller 412 also receives the
data from register file 420 and interfaces register file 420 with
ISEF 130.
[0046] In one exemplary methodology, standard load and store
instructions are used to move data to and from register file 420.
Load instructions issued by the extension adapter 140 retrieve data
from memory into register file 420. ISEF 130 instructions operate
under the control of extension adapter 140 to retrieve stored data
from register file 420 to ISEF 130 for use in ISEF 130 computations
or other functional execution. Data resulting from ISEF 130
instruction execution is then returned to register file 420, where
store instructions move data from register file 420 to memory via
interface 414.
[0047] ISEF 130 and adapter controller 412 allow a user to add new
instructions that change with software on different implementations
of the same silicon. For example, a user can add specialized
instructions to perform video or audio encoding/decoding. These
instructions are not hard-wired into processor core 120, but rather
are implemented using the programmably configurable logic of ISEF
130. Extension adapter 140 operates as a data and control interface
between processor core 120 and ISEF 130 by routing extended
instructions (i.e., those instructions not part of the original
processor core 120 native instruction set) to ISEF 130 for
execution. Since the logic of ISEF 130 is configurable, it is
entirely within the scope of the present invention that the
configuration of ISEF 130 can be changed as frequently as needed to
accommodate the inclusion of various extended instructions in
application programs being run on the processor core 120.
[0048] In one embodiment of the present invention, the inputs and
outputs to the extended instruction, as executed in ISEF 130, are
limited to data transfers between a named register file 420. In
some embodiments, the ISEF 130 can access a register file in the
processor core 120 to allow both reading and writing. In another
embodiment, in addition to the data transfers between the named
register file 420, the data transfers are between an alternative
source indicative of a processor state. One example of this
alternative source is a special purpose register. In such an
embodiment, the number of register file 420 inputs to the ISEF 130
computation is a finite number such as three (3), and the number of
special purpose register inputs is eight (8) 128-bit registers.
[0049] In some embodiments, the outputs of the ISEF 130
computations are directed to register file 420, to equivalent
special purpose registers, and/or by-passed to processor core 120
for use in execution of the subsequent instruction. In the above
embodiment, the number of register file 420 outputs is two (2) and
the number is a 128-bit special purpose register outputs is up to
eight (8). The extended instruction of such an embodiment does not
have direct access to data and instruction memories and caches of
the processor core 120. Any data residing in the data and
instruction memories or caches of processor core 120 is first
brought into the register file 420 using load instructions, before
being used by the extended instruction as executed in ISEF 130. In
some embodiments, the data residing in the data and instruction
memories or caches of processor core 120 are brought into
equivalent special purpose registers in addition to the register
file 420 using load instructions. Such a restriction in the I/O of
the extended instruction of this embodiment enables compiler
optimization and improved performance. The exact input and output
dependencies of the extended instructions are programmed into the C
compiler (discussed with reference to FIG. 7) used in scheduling
the extended instruction and in allocating the associated register
files 420.
[0050] It is noteworthy that extension adapter 140 handles the
multiplexing of data among register file(s) 420 and ISEF 130.
Extension adapter 140 manages the timing relationships between
register reads and register writes, which are functions of
instruction execution length.
[0051] It is also noteworthy that the processing system 110
comprises means for ensuring the proper configuration of ISEF 130
prior to the execution of a specific extended instruction in the
ISEF 130. In one example, if the system tries to execute an
instruction not included in the instruction set of processor core
120 that is not currently configured in ISEF 130, an exception is
generated by the extension adapter 140, resulting in either the
proper configuration signals being sent to ISEF 130, or in an
alternative process, being initiated to deal with the missing
configuration.
[0052] In keeping with some embodiments according to the present
invention, FIG. 5 illustrates an operation involving the reading of
data. Resident instruction table 510 has a description of what
extended instructions are adapted to do with respect to the
interface to processor core 120. For any instruction that a user
creates, those instructions should control processor core 120 in
such a way that processor core 120 executes those instructions in
similar fashion to native instructions included in the original
processor core 120 instruction set. Resident instruction table 510
receives instruction description data 512 (from interface 414 of
FIG. 4) as a sequence of binary numbers (e.g., a 24-bit sequence)
that is decoded by resident instruction table 510 and converted
into an address that points to a location in resident instruction
table 510.
[0053] If the instruction description data 512 describes a normal
add, subtract, etc. contained in the native instruction set of
processor core 120, then resident instruction table 510 does not do
anything with the instruction. However, if the instruction
description data 512 describes an extended instruction that ISEF
130 is to execute, then resident instruction table 510 returns
configuration information 514 back to processor core 120 to
indicate this is a valid instruction. Extension adapter 140 will
thereafter operate on the extended instruction in cooperation with
ISEF 130 so that to processor core 120 it appears that the extended
instruction is identical in form to a native instruction of
processor core 120.
[0054] Configuration information 514 is a sequence of data from
resident instruction table 510, some of which goes to processor
core 120 via interface 516. Some of configuration information 514
is transmitted to the ReadAddr 518 (read address) input of register
file 420 via interface 424. Data from ReadData 520 (read data) of
register file 220 is also carried on interface 424. In this
example, configuration information 514 includes the address within
register file 420 that an extended instruction needs to be sent to
ISEF 130 via interface 418.
[0055] Compiler
[0056] FIG. 6 is a flow chart illustrating an exemplary embodiment
600 of the method of the invention. The method begins by defining a
program in step 610. The program can be defined in a standard
programming language that is familiar to computer programmers such
as C++.
[0057] Thereafter, in step 620, the program is compiled to convert
the program from the programming language in which it was written
into a machine language that is recognizable by the processor core
120 (FIG. 1). It will be appreciated that the present method is
intended to be iterative, as can be seen from FIG. 6, and that
successive iterations initially return to step 620. Whereas in the
first pass through step 620 a standard compiler, such as a C++
compiler, compiles the program, in successive iterations an
additional extension compiler is also employed, as is discussed
elsewhere herein. One skilled in the art can appreciate that the
extension compiler can be implemented as a separate program or may
be part of the compilation phase or linking phase of a standard
compiler to perform the operations of the extension compiler as
described herein.
[0058] Next, in step 630 the compiled program is profiled.
Profiling includes executing the compiled program with
representative or sample data and determining how much time would
be expended executing each of the various operations of the
program. Profiling in step 630 is preferably performed using a
software simulation tool (not shown) that mimics the operation of
the processor core 120. Such processor simulators are well known in
the art, and each simulator is unique to the processor core 120
being simulated. Alternatively, profiling 630 can occur using a
hardware emulator (not shown) or some combination of hardware and
software. Hardware emulation is particularly useful in applications
where specific timing issues are of concern to the designer.
[0059] As in step 620, because the method is iterative, the first
pass through step 630 is different than in successive iterations.
In the first pass through step 630 the compiled program is executed
or simulated solely on the processor core 120 to provide a baseline
against which improvements in successive iterations can be
measured. It should be noted that some of the more time consuming
operations that are typically identified by profiling involve
nested loops. In some embodiments, successive programs can take
advantage of the existing profiled programs by not performing step
630. Further, in some embodiments, a cache can store pre-existing
blocks of code, which when matched with the compiled code, results
in bypassing step 630.
[0060] In step 640 a determination is made as to the acceptability
of the performance of the program. If the performance is acceptable
then the method ends. Otherwise, the method continues to step 650.
Generally, in the first pass through step 640 the performance will
not be acceptable since no effort has yet been made to optimize the
program. In successive iterations, performance can be judged
against either subjective or objective standards. In some instances
the program needs to be optimized so that it can return data
according to the timing requirements of other programs with which
it interfaces. In other instances merely a faster processing speed
is desired from the program. In these latter instances, at each
iteration the performance is compared to the performance from the
prior iteration to determine whether the most recent iteration
returned a further improvement. If no further improvement is
achieved by a successive iteration, or if the improvement is
sufficiently trivial, the performance is deemed to be acceptable
and the method ends.
[0061] In step 650 one or more critical code segments are
identified by reviewing the results of the profiling performed in
step 630. A critical code segment is a portion of the program's
code that took excessive time to execute or failed to meet timing
requirements specified for a program in step 630. Typically, those
code segments that took the longest time to execute are considered
to be the most critical and are addressed first by the method. As
noted elsewhere, nested loops are frequently identified as critical
code segments. If addressing the most critical code segments does
not produce acceptable performance in step 640, then in successive
iterations the next most critical code segments are identified in
step 650.
[0062] Next, in step 660, the critical code segment identified in
step 650 is preferably rewritten as a separate function. An example
is illustrative of this process. The following original code
segment written in C++ includes a nested loop as the critical code
segment:
[0063] a=0
[0064] for (i=0; i<100; i ++)
[0065] {for (j=0;j<8;j ++)
[0066] {a+=x[i+j]* y[j];}
[0067] z[i]=a>>k;}
[0068] The critical code segment can be rewritten as a function,
which in the following example is given the name "inner":
[0069] int inner (short*x, short*y)
[0070] {for (j=0; j<8; j ++)
[0071] {a+=x[j]* y[j];}
[0072] return a>>k;}
[0073] Advantageously, the function can be written using the same
programming language as before. In some embodiments the function
does not have to be written from scratch but can instead be
selected from a class library (not shown) of pre-defined functions.
A class library of pre-defined functions can include functions that
might be particularly useful in a certain type of application, such
as functions for working with pixel data in video processing
applications.
[0074] In an alternative embodiment, in step 660, markers (in C
programming, such markers are conventionally referred to as
PRAGMAS) are used to demark the beginning and ending of a section
of code to be rewritten. Once identified, the demarked section of
code is replaced by one, or alternatively, multiple instructions.
It should be apparent to those of ordinary skill in the art that
the rewriting step of 660 can be performed either manually, or by
using an automated conversion tool. Such a conversion tool would be
similar to a decompiler; rather than compiling a high level
instruction into multiple lower level instructions as in a
compiler, the automated conversion tool would convert multiple
lower level instructions of the processor core 120 instruction set
into one or more complex extended instructions for implementation
in ISEF 130.
[0075] Once the critical code segment has been rewritten as a
function in step 660, in step 670 the program is revised. The
revision includes two operations, designating the function as a
code segment to be compiled by an extension compiler and replacing
the critical code segment with a statement that calls the function.
In some embodiments the function is placed into an extensions file,
separate from the program file, that contains the code meant to be
compiled by the extension compiler. In other embodiments the
function is placed in the program file and demarked in such a way
that it can be recognized as intended for the extension compiler so
that the standard compiler will ignore it. Demarking the function
in this way can be achieved by a flag before the instruction (e.g.,
# pragma stretch begin) and a flag after the function (e.g., #
pragma stretch end).
[0076] As noted, revising the program also includes replacing the
critical code segment with a statement that calls the function.
Continuing with the prior example, the original code segment that
includes the critical code segment can be rewritten by replacing
the critical code segment with the statement {z[i]=inner (x+i, y);}
as follows:
[0077] a=0
[0078] for (i=0; i<100; i ++)
[0079] {z[i]=inner (x+i, y);}
[0080] Once the program has been revised in step 670 the method
returns to step 620 and the program is again compiled. In those
embodiments in which the function has been placed in the program
file and demarked from the remaining code, a pre-processing tool
first finds the function and copies it out to an extensions
file.
[0081] FIG. 7 illustrates an exemplary sequence of events that
occurs during step 620 to compile an extensions file 700 and a
program file 710. Initially, the code in the extensions file 700 is
compiled by the extension compiler 720. An example of an extension
compiler 720 is Stretch C, available from Stretch, Inc. of Mountain
View, Calif. The extension compiler 720 produces two outputs: a
header file 730 and an intermediate file 740 written in a hardware
description language such as Verilog HDL. The header file 730
declares a prototype for a specific function used to execute an
extended instruction called out by the extension compiler 720
during compilation of the extensions file 700. The header file 730
is a conventional C file that provides instruction information,
such as the file name, inputs required, outputs written, and other
required instruction parameters. The intermediate file 740
describes how to implement an instruction in the Instruction Set
Extension Fabric 130 (FIG. 1) that corresponds to the function.
Next, an implementation tool 750 maps the intermediate file 740 to
the Instruction Set Extension Fabric 130. More specifically, the
implementation tool 750 converts the contents of the intermediate
file 740 to ISEF configuration file 760. Implementation tool 750
generates ISEF configuration file 760 consisting of a bit stream
that is compiled with program file 710 and header file 730 in
standard compiler 770 and incorporated in the executable file 780.
This ISEF configuration file 760 contains the data that is used by
the executable file 780 to configure ISEF 130 in much the same way
that a Field Programmable Gate Array (FPGA) is programmed.
[0082] When the extension adapter 140 encounters a processor core
120 instruction that is not part of the native set, but is rather
an extended instruction generated by extension compiler 720, the
processor core 120 sends a configuration bit stream to the ISEF 130
to appropriately configure the ISEF 130 to execute the extended
instruction. Thus, the executable file 780 can call the function
and the Instruction Set Extension Fabric 130 contains an
instruction that can perform the function.
[0083] Thereafter, in step 630 the program is again profiled. In
this and subsequent iterations of the method, in contrast to the
first pass through step 630, the extension adapter 140 (FIG. 1)
directs the Instruction Set Extension Fabric 130 to execute the
instruction corresponding to the function when the function is
called as the executable file 780 runs. Accordingly, the program
executes more efficiently, as will be represented by the profile.
Next, in step 640 the performance is again evaluated, and if
acceptable the method ends, otherwise it begins a new iteration at
step 650.
[0084] Returning to step 660, a critical code segment can
alternatively be rewritten by selecting a pre-defined function from
a class library. The following example is illustrative of
pre-defined functions that might be found in a class library
according to an embodiment of the present invention, and of an
instruction that would be defined from these functions. Typical
graphics applications define a pixel by an 8-bit integer for each
of three colors such as red, green, and blue. According to the
present invention, a class library for graphics applications can
include a pre-defined function for red, for example, that defines
an unsigned 8-bit declared integer, R, by the function
se_uint<8>R; and another pre-defined function would define
for the pixel an unsigned 24-bit declared integer, P, by the
function se_uint<24>P=(B, G, R); where B and G correspond to
blue and green, respectively. In the C++ programming language
integers are generally limited to standard bit lengths such as 8,
16, 32 and 64. Accordingly, the ability to create a 24-bit integer,
or any integer with a non-standard number of bits, is a beneficial
feature of the present invention. Without the ability to define a
pixel as a 24-bit integer, one would have to define the pixel as a
32-bit integer, but at the expense of having to carry 8 unused
bits.
[0085] The advantage of not having to carry unused bits can be
further seen when a number of pixels are assigned to a register
with a pre-defined width. For instance, a register, W, that has a
128-bit width can accommodate four 32-bit pixels, but the same
register can handle five 24-bit pixels. Expressed as an instruction
for a programmable logic device 130, assigning five 24-bit pixels
to register W would be expressed as WR W=(P4, P3, P2, P1, P0).
[0086] ISEF Reconfiguration
[0087] In some embodiments for ISEF reconfiguration, the processing
system 110 uses extended instructions that can be configured into
the Instruction Set Extension Fabric 130 to accelerate an executing
application program. ISEF reconfiguration advantageously can add
extension instructions or modify characteristics of existing
extension instructions after fabrication of the processor. In some
embodiments, there are no finite limitations on the processing
system 110 instruction set, since new instruction extensions can be
generated by the compiler and configured in the ISEF 130 prior to
or during execution of the application. Therefore, the embodiments
relating to the configuration of the ISEF 130 to execute
non-resident instructions in an application can be thought of as
creating a virtual instruction set of the processing system 110.
The finite set of instructions can be extended to an unlimited,
virtual set of instructions through reconfiguring the ISEF 130 to
add new extended instructions. It should be noted that except where
reconfiguration does not occur, the term configured and
reconfigured are used interchangeably; and that conventionally, the
ISEF 130 is initially configured then subsequently reconfigured as
explained herein.
[0088] Several different modes of ISEF 130 configuration are
contemplated as varying embodiments. The most basic of these
embodiments is static configuration, where the instruction
extension is loaded with the executable file 780, and the ISEF 130
is configured once prior to application execution. In the static
configuration embodiment, the processor core 120 executes all
native instructions, and the instruction extensions are directed to
the preconfigured ISEF 130 by the extension adapter 140 for
execution. The ISEF 130 does not reconfigure during application
execution in this static configuration embodiment.
[0089] A second embodiment of ISEF 130 configuration is explicit
reconfiguration. Explicit reconfiguration is a configuration or
reconfiguration of the ISEF 130 in which the executing application
program directly initiates the loading of the ISEF 130
configuration memory 206 with instruction extension data in the
form of a system call or similar invocation. In one explicit
reconfiguration embodiment, the application preferably prefetches
instruction groups before they are required to optimize application
execution performance. In the explicit reconfiguration embodiments,
the programmer of the application explicitly adds code to the
application to load instruction extension data into the ISEF 130
configuration memory 206. The added coded includes the system call
or similar invocation to initiate the loading of the ISEF 130
configuration memory with the instruction extension data.
Alternative embodiments featuring explicit reconfiguration permit
direct memory access (DMA), allowing the prefetch to take place
concurrently with the application execution. In an embodiment where
multiple ISEF's 130 are used, this DMA capability enables the
application to be executing from one ISEF instruction group, while
the next group of instructions are being loaded into a second
ISEF.
[0090] A third embodiment for configuring the ISEF 130 is that of
implicit reconfiguration. Implicit reconfiguration occurs when the
running application program issues an instruction, which is not
part of the resident instruction set. When a nonresident
instruction is issued in this embodiment, the extension adapter 140
detects this instruction fault condition and passes the instruction
extension to the ISEF 130 for reconfiguration and execution. This
model of reconfiguration is referred to as implicit, because the
processing system 110 relies on the extension adapter 140 to detect
and process the need for the ISEF 130 operation. Programmers of the
applications therefore do not need to be aware of the
reconfiguration of the ISEF 130 because the reconfiguration does
not depend on the programmer-inserted code in the program for
reconfiguration. Instead, the reconfiguration of the ISEF 130
occurs when the extension adapter 140 detects the instruction fault
condition.
[0091] Referring now to FIGS. 8(a) and 8(b), a preferred process is
described for executing an instruction extension in the implicit
reconfiguration embodiment of the present invention. The process of
FIGS. 8(a) and 8(b) begins in step 805 with the execution of a
programmed application in the processing system 110. During
processing, the extension adapter (XAD) 140 receives 810 an
instruction extension, i.e. an instruction that is not native to
processor core 120. In step 815, the XAD 140 checks to determine
whether the received instruction extension from step 810 is in fact
already resident in the ISEF 130. If the instruction extension is
resident, that is currently loaded into ISEF 130, the ISEF 130 then
executes the instruction extension. If the received instruction
extension from step 810 is not resident, the XAD 140 signals 820
processor core 120 that the instruction extension is not resident.
Upon receiving the signal in step 820 from the XAD 140, processor
core 120 issues 825 an instruction fault to the processing system
110 operating system. The processing system 110 operating system
then takes steps to appropriately configure the ISEF 130 to execute
the received instruction extension in step 810.
[0092] Referring now to FIG. 8(b), once the operating system
receives the instruction fault from processor core 120 in step 825,
the XAD 140 is instructed to check 830 whether the ISEF 130 is
currently busy executing an instruction. If in fact the ISEF 130 is
executing another instruction, then the XAD 140 waits until the
ISEF instruction is completed. After any ISEF instruction currently
executing completes, then the instruction pipe is flushed 835 and
the instruction state is saved in step 840 by the extension adapter
XAD 140. The XAD 140 then loads 845 a new configuration into ISEF
130 and then checks 850 to determine whether a stored state exists
relating to the new ISEF 130 configuration of step 845. If in fact
a stored state does exist in step 850 then the XAD 140 restores 855
the state relating to the new ISEF 130 configuration. After any
previously stored state is restored, then the XAD 140 reissues 860
the instruction from the application to the ISEF 130, and the
instruction extension executes on the ISEF 130. Subsequently,
application processing resumes in step 865.
[0093] Referring now to FIG. 9, a fourth embodiment of ISEF 130
reconfiguration is shown in which two or more ISEF's are
alternately configured by an extension adapter 140. Extension
adapter 140 is connected to ISEF1 910 through interconnect 930.
Extension adapter 140, likewise is connected to ISEF2 920 through
interconnect 940. In the alternating reconfiguration model,
multiple groups of instructions may be accelerated and mapped to
two or more ISEF's 130: In this alternating reconfiguration mode,
ISEF1 910, for example, can be executing a set of instruction
extensions, while ISEF2 920 is contemporaneously loading a new
reconfiguration file in preparation for a set of instruction
extensions to be later executed. In this way, configuration of one
ISEF 130 may overlap execution on the processor core 120, of
another ISEF 130. Execution of instruction extensions may be
predicted and speculatively loaded into a ISEF 130 while the
application is executing on the processor core 120 or in another
ISEF 130. A significant benefit of alternating reconfiguration is
that the processing system 110 is able to reduce or avoid delays
that might be encountered in ISEF 130 configuration by loading, for
example, ISEF2 920 while the processing system 110 is using ISEF1
910 for executing an instruction extension. Once the used ISEF1 910
configuration is completed, processing may then switch to the
preconfigured ISEF2 920 while the contents of ISEF1 910 are flushed
and reprogrammed.
[0094] Referring now to FIG. 10, a timing diagram is illustrated
showing the various timing phases of the processor core 120 and the
ISEF's 910 and 920. During phase 1, the processor core 120 is
loading 1010 the application within the processing system 110. In
phase 2 of FIG. 10, the application begins execution 1020 on the
processor core 120 and starts loading 1025 the first instruction
extension into ISEF1 910. During phase 3, the first instruction
extension begins executing 1030 on ISEF1 910. The application also
predicts the next instruction extension to execute, and
speculatively loads 1035 the configuration ISEF2 920. The first
instruction extension executing in ISEF1 910 completes 1045
execution and control returns 1040 to the processor core 120 in
phase 4. In phase 5, the second instruction begins execution 1055
on ISEF2 920 while the next extension instruction is speculatively
loaded 1052 into ISEF1 910. The configuration of ISEF1 910 runs
longer than the execution 1055 of the second instruction extension
in ISEF2 920 in the subsequent instruction extension computation on
the processor core 120, so the application stalls 1060 waiting for
the completion of the configuration 1060 at the end of phase 5. In
phase 6, the third instruction extension begins execution 1062 on
ISEF1 910 while the fourth extension instruction is predicted and
loaded 1065 in ISEF2 920. At the beginning of phase 7, the previous
prediction is determined 1060 to be incorrect and a new
configuration is loaded 1070 into ISEF2 920. Once the correct
configuration is complete the final loop is executed 1080 on ISEF2.
In phase 8, the application finishes 1090 on the processor core 120
in phase 9.
[0095] Referring now to FIG. 11, a graphic is shown of ISEF 130
containing two Instruction Set Extension Fabrics ISEF1 110 and
ISEF2 1120. A fifth embodiment of ISEF1 130 reconfiguration is a
mode in which ISEF 130 is partially configured into two or more
Instruction Set Extension Fabrics of equal or differing sizes. In
this reconfiguration embodiment, ISEF1 1110 may be sized
appropriately as needed by a specific instruction extension, and
the remainder of ISEF 130 is available for use in the creation and
configuration of additional partial ISEF's. These partial ISEF's
are preferably available for use in the alternating reconfiguration
model explained with reference to FIGS. 9 and 10. Although FIG. 11
shows ISEF 130 divided into two partial ISEF's of equal size, ISEF
130 shown in FIG. 11 could readily be subdivided into any number of
sizes and partitions for use in operating with one or more
processor cores 120.
[0096] It will be obvious to those skilled in this art that the
operation of the XAD 140 and the ISEF 130 is similar with respect
to instructions as the handling of data in virtual memory.
[0097] In the foregoing specification, the invention is described
with reference to specific embodiments thereof, but those skilled
in the art will recognize that the invention is not limited
thereto. Various features and aspects of the above-described
invention may be used individually or jointly. Further, the
invention can be utilized in any number of environments and
applications beyond those described herein without departing from
the broader spirit and scope of the specification. Accordingly, the
specification and drawings are to be regarded as illustrative
rather than restrictive.
* * * * *