Coprocessor extension architecture built using a novel split-instruction transaction model

A processor architecture supports an electrical interface for coupling the processor core to one or more coprocessor extension units executing computational instructions, with a split-instruction transaction employed to provide operands and instructions to an extension unit and retrieve results from the extension unit. The generic instructions for sending an operation and data to the extension unit and/or retrieving data from the extension unit allow new computational instructions to be introduced without regeneration of the processor architecture. Support for multiple extension units and/or multiple execution pipes within each extension unit, multi-cycle execution latencies and different execution latencies between or within extension units, extension unit instruction predicates, and for handling processor core stalls and result save/restore on interrupt is included.

TECHNICAL FIELD OF THE INVENTION

The present invention is directed, in general, to processor instruction set architectures (ISAs) and, more specifically, to extending or altering processor instruction set architectures.

BACKGROUND OF THE INVENTION

Processor instruction set requirements generally evolve with changing application domains. In particular, digital signal processing applications can be made to perform better with special instructions. However, the particular instructions needed to achieve such performance improvement typically change over time.

Current methods for accommodating the instruction set requirements of new application domains include either extending the instruction set, which leads to instruction set bloating and increasingly complex processor designs, or regeneration of a tailored processor from a processor core with sub-optimal (slow core) baseline performance. Current approaches to quick regeneration require the new instruction(s) to be simple enough to fit within the existing execution pipeline, and thereby limits the complexity of new instructions in terms of latency and resource usage. Accordingly, the current methods cannot accommodate the needs of new instructions that require a complex data path (more pipeline stages), an additional internal state (e.g., a private register file) or many-cycle execution latency with optionally pipelined operation.

There is, therefore, a need in the art for an architecture providing good performance for native instructions while supporting new single or multi-cycle instructions which may include complex data paths, an additional internal state, and optionally pipelined operation, with latencies known to the compiler and used for instruction scheduling.

SUMMARY OF THE INVENTION

To address the above-discussed deficiencies of the prior art, it is a primary object of the present invention to provide, for use in a processor architecture, an electrical interface for coupling the processor core to one or more coprocessor (core extension) units executing computational (user-defined) instructions, with a split-instruction transaction model employed to provide an instruction and the instruction's operands to the extension unit and to retrieve results from the extension unit. The generic core-extension instructions allow for new computational instructions to be introduced, together with the capability to send data to an extension unit and/or retrieve a result from the extension unit, without regeneration of the processor architecture. Support is included for multiple extension units and/or multiple execution pipelines within each extension unit, multi-cycle execution latencies and different execution latencies between or within extension units, extension unit instruction predicates, processor core stalls and result save/restore on interrupt.

The foregoing has outlined rather broadly the features and technical advantages of the present invention so that those skilled in the art may better understand the detailed description of the invention that follows. Additional features and advantages of the invention will be described hereinafter that form the subject of the claims of the invention. Those skilled in the art will appreciate that they may readily use the conception and the specific embodiment disclosed as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. Those skilled in the art will also realize that such equivalent constructions do not depart from the spirit and scope of the invention in its broadest form.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1depicts a processor architecture including a split transaction model coprocessor extension interface according to one embodiment of the present invention. As an alternative to extending instruction sets for changing application domains through regeneration, the present invention defines a flexible alternative for a high-performance digital signal processor that includes a customizable coprocessor extension architecture with a well-defined coprocessor interface supporting multiple coprocessors. This architecture allows for easy integration of the coprocessor with a core hard macro for SOC (System On Chip) designs.

Processor architecture100comprises a core101including a program memory controller PMC with program memory (not explicitly shown), a control unit CU, two data unit pipelines DU-0and DU-1working with a data register file DRF, a data memory banks X and Y. Each data unit includes a data operand fetch pipeline stage (DOF) where source operands Rn, Rp are retrieved (fetched) from the DRF; two execute pipeline stages EX1and EX2where standard core instructions execute; and a write-back (WB) stage where instruction result Rm is written into the DRF. Coupled to one data unit pipeline DU-0is a coprocessor extension electrical interface102comprising a five bit extension strobe bus x_strobe, a twenty-nine bit extension instruction bus x_inst, a thirty-two bit coprocessor extension first operand bus x_opa, a thirty-two bit coprocessor extension second operand bus x_opb, and a forty bit coprocessor extension result bus x_result.

The extension interface102couples the core101to one or more coprocessor extension units103a-103d, each optionally including a first-in, first-out (FIFO) output buffer104a-104d. In the exemplary embodiment, the coprocessor extension units103a-103dare addressed utilizing a two bit identifier, which implies support for up-to four coprocessor extension units. However, the present invention may be readily limited or extended to fewer or more coprocessor extension units.

The x_strobe signals comprise information from different pipeline stages of the core101, including a one bit coprocessor extension instruction valid x_valid signal, a one bit signal x_schedule indicating that the valid coprocessor extension instruction is scheduled and is in the execute stage1(EX1) pipe-stage, a two bit coprocessor extension instruction predicate value signal x_guard, and a one bit write back signal x_wb indicating that the coprocessor extension instruction is expected to produce a result.

TABLE I below summarizes the signals within the coprocessor extension interface102, where “type” refers to whether the signal is an input or output for the processor core:

FIGS. 2A through 2Care timing diagrams illustrating the operation of split transaction execution with pipelined and non-pipelined operation and with and without a result queue for split transaction coprocessor extensions according to various embodiments of the present invention. In the simplest form, the coprocessor extension includes an application specific function having a latency of L cycles and a throughput of T cycles used in pipelined fashion. The coprocessor extension instructions follow a split-transaction model where a minimum of two coprocessor extension instructions are required to execute an operation in the coprocessor and retrieve the operation result from the coprocessor. By contrast, a single transaction model needs only a single coprocessor instruction to initiate the operation and provide an internal core destination. This model may also be employed in the present invention in the case where the operation result is stored inside the coprocessor, either as an internal state or in a coprocessor register file.

In the case of the split-transaction model, the first core-extension instruction provides the operands and operation to the coprocessor and the second core-extension instruction retrieves the result generated by the previous instruction (and optionally also sends another operation with associated operands, to be explained later). This split-transaction model allows user-defined latencies of coprocessor extension functions, and takes a minimum of L cycles.

The first core-extension instruction that sends a user-defined operation and operand(s) to a coprocessor extension unit103a-103dis represented in the instruction set architecture (ISA) for the processor core101as:

XSDRn, Rp, #xspc11// XSD (StoreData to eXtension)// Data to store: registers Rn, Rp of DRF// #xspc11 specifies 11 user-defined bits
where xspc is an extensionspecific instruction field that specifies the (user-defined) coprocessor operation. The second core-extension instruction that sends an operation and retrieves a result is represented in the core ISA as:

XLDRm, #xspc15// XLD (LoadData from eXtension)// Retrieved data is written to register Rm of DRF// #xspc15 specifies 15 user-defined bits
The pipeline diagram ofFIG. 2Aillustrates the split-transaction for a latency L=3 for non-pipelined operation, with optimal scheduling of the load data instruction XLD three cycles behind the XSD instruction. The upper portion201aofFIG. 2Aillustrates the operations within the processor core101, while the lower (italicized) portion201billustrates the corresponding operations within the coprocessor extension interface102. The corresponding assembly code for the instruction sequence illustrated inFIG. 2Ais shown below in TABLE II:

TABLE IIPC [31:0]DU Instruction(GP32 Mode)Slot 1Slot 00x100DU-OPGx? XSD Rn, Rp, #xspc110x108DU-OPDU-OP0x110DU-OPDU-OP0x118DU-OPGx? XLD Rm, #xspc150x120DU-OPGy? XSD Rn, Rp, #xspc110x128DU-OPDU-OP0x130DU-OPDU-OP0x138DU-OPGy? XLD Rm, #xspc15
where the program counter (PC) value presumes that the processor core101is executing in a mode utilizing a comprehensive 32-bit general purpose instruction set (GP32). The line diagram ofFIG. 2Aillustrates that with optimal scheduling, the load data instruction XLD is three cycles behind the store data instruction XSD, equal to the latency of the coprocessor extension unit.

Obviously, if the coprocessor extension is operated in a pipelined manner, one result may be produced from the coprocessor extension unit every cycle. However, the definition of the coprocessor extension architecture is limited in this embodiment to issuing only one coprocessor instruction per cycle. Given that constraint, the coprocessor extension cannot be operated in a pipelined manner for code sequences including an XSD followed by an XLD. Therefore, an instruction of the form send data and load data XSDLD is needed that implies sending the operation and operand(s) to the extension and concurrently loading a result from the extension. The pipeline diagram ofFIG. 2Billustrates the split-transaction for latency L=3 operated in a pipelined manner, with the corresponding assembly code shown below in TABLE III:

TABLE IIIPC [31:0]DU Instruction(GP32 Mode)Slot 1Slot 00x100DU-OPXSD Rn, Rp, #xspc11 (1)0x108DU-OPXSD Rn, Rp, #xspc11 (2)0x110DU-OPXSD Rn, Rp, #xspc11 (3)0x118DU-OPXSDLD Rm, Rn, Rp #xspc7 (4) (1)0x120DU-OPXSDLD Rm, Rn, Rp #xspc7 (5) (2)0x128DU-OPXLD Rm, #xspc15 (3)0x130DU-OPXLD Rm, #xspc15 (4)0x138DU-OPXLD Rm, #xspc15 (5)
The coprocessor extension instructions are tagged with an identifier in parentheses indicating the load data instruction XLD that matches with each send data instruction XSD. In the case of the send data and load data instruction XSDLD, a pair of identifiers in parentheses is used with the first corresponding to the send data part and the second corresponding to the instruction whose result the load data part retrieves (Rm: destination operand register; Rn, Rp: source operand registers).

FIG. 2Billustrates pipelining of coprocessor extension operations assuming that the result is retrieved using either the load data instruction XLD or the load data component of the combined instruction XSDLD, if performed optimally. However, if the processor core101either stalls (the coprocessor is not aware of core stalls) or switches threads due to an interrupt, and is therefore unable to pick up the result in an optimal manner, a clear possibility exists of losing the coprocessor result in the absence of temporary storage for that result.

To solve this problem, a FIFO result queue (RQ) structure104a-104dis needed for each coprocessor extension unit103a-103dto hold the spill over, enabling the coprocessor extension pipeline to run independently of the processor core101without being influenced by core stall conditions (since the coprocessor extension unit103a-103ddoes not stall when the processor core101stalls). The presence of a result queue implies that the load data instruction (or the load data component of a combined instruction) will always retrieve the result from the bottom of the FIFO structure.

Each FIFO result queue104a-104dhas at least a depth D that is a function of both the coprocessor latency L and the coprocessor throughput 1/T (1 result every T cycles), and given by the formula:
D=Ceiling (L/T).
Extra entries within a FIFO result queue104a-104dcan ease instruction scheduling.

In the exemplary embodiment, up to four coprocessor extension units103a-103dmay be connected to the processor core101, each of which should have a FIFO result queue104a-104d. Since latency and throughput are parameters of the individual coprocessor extension units103a-103dand may be different for different coprocessors, the depths of the respective FIFO result queues104a-104dmay also differ.

While the internal state of a coprocessor extension unit103a-103dis updated only if the instruction predicate (the predicate status arriving during the data unit execute stage2DU-EXb2) is true, coprocessor results will be written into the respective FIFO result queue and the FIFO valid counter updated, always irrespective of the predicate state. XLD or corresponding instruction components always read from the FIFO result queue and update the FIFO status with regard for the predicate status, which removes timing constraints due to late arrival of the predicate in the DU-EX2stage.

FIG. 2Cillustrates pipelining of a simple coprocessor extension implemented without FIFO result queue, with the corresponding assembly code given in TABLE IV:

TABLE IVPC [31:0]DU Instruction(GP32 Mode)Slot 1Slot 0Comments0x100DU-OPXSD CR0, Rn,CR0 = xfn(Rn, Rp)Rp, xfn (1)0x108DU-OPXSD CR1, Rn,CR1 = xfn(Rn, Rp)Rp, xfn (2)0x110DU-OPXLD Rm, CR0,Rm = CR0xfn_nop (3)0x118DU-OPXLD Rm, CR1,Rm = CR1xfn_nop (4)
Any coprocessor extension unit203a-203dwithout a FIFO result queue should include a result register coupled to the coprocessor extension result bus x_result. In the exemplary embodiment CR0 and CR1 are each assumed to represent either an internal state or register identifiers for a coprocessor-specific register file, while xfn indicates a coprocessor function specified using the #xspc field of the instruction.

In terms of pipeline timing, the critical coprocessor pipeline stage inFIG. 2Cis the “Read Internal State & Write Result_Register of Extension.”

Implementations without a FIFO result queue are well suited for short latency coprocessor solutions, although careful consideration must be paid to the fact that the predicates are available only in the DU-EX2stage. Coprocessor extensions with FIFO result queues are efficient when the compiler employs loop pipelining. However, certain coprocessor solutions may not warrant the added complexity of saving and restoring the FIFO result queue.

In addition to the XSD, XLD, and XSDLD coprocessor extension instructions, an additional instruction form where only an operation but no operands are sent to the coprocessor and no result is retrieved is desirable:

where the instruction includes nineteen user-defined bits. This format enables the coprocessor extension unit to perform an internal operation using either an immediate or internal state and to update an internal state (although internal state updating is not limited to XOP).

The architecture described above may be implemented in an ST120 processor, available from STMICROELECTRONICS, INC., with four versions of the XSD instruction, identical in encoding and differing only in the primary operation code (opcode) description. Similarly, two versions of the XLD instruction, four versions of the XSDLD instruction, and two versions of the XOP instruction may be implemented. The bitwise arrangement of the instructions is given below in TABLE V:

TABLE V[31:28][27:24][23:22][21][20:17][16:11][10:7][6:0]GaxspcExt# [1:0]xspcRbxspcRcXSD[10:7][6]Source[5:0]Source(4opcodes)GaRaExt# [1:0]xspcRbxspcRcXSDLDDest.[6]Source[5:0]Source(4opcodes)GaRaExt# [1:0]XpscXLDDest.[14:0](2opcodes)GaxspcExt# [1:0]XpscXOP[10:7][14:0](2opcodes)
The instruction set encoding includes a 2-bit field Ext#[1:0] that allows addressing of up to four coprocessor extension units.

The semantics and syntax for GP32 instructions within a processor conforming to the ST120 architecture is shown in TABLE VI below, where xfn refers to the coprocessor extension function, “Xa” refers to the FIFO result queue and “a” is the 2-bit coprocessor extension number:

TABLE VIxfn FieldMnemonic SyntaxGP32 SemanticsWidthGx? XSD<I>a,Gx?xspc[10:0]Rn, Rp, #xspc11[Xa=]xfn (Rn,Rp)Gx? XSDLD<i>a,Gx?xspc[6:0]Rm, Rn, Rp, #xspc7Rm=Xa∥xfn(Rn,Rp)Gx? XLD<I>a,Gx?xspc[14:0]Rm, #xspc15Rm=Xa, xfnGx? XOP<I>a,Gx?xspc[18:0]#xspc19[Xa=]xfn
On the left hand side of the equations in the second column of TABLE VI, “Xa” refers to writing into the FIFO result queue while, on the right hand side, “Xa” refers to reading out of the FIFO result queue. In addition, <I> indicates the forms of the instruction (e.g., XSD1, XSD2, XSD3 or XSD4). All coprocessor instructions have an extension specific field xspc with the width, in bits, indicated by the appended number.

Every coprocessor instruction is predicated. Coprocessor extensions may be one of two types: coprocessors without any internal state or register file—i.e., a pure execution unit with a result queue (RQ) (Type A); and coprocessors with an internal state and/or register file, execution unit(s) and a result queue (Type B). The ST120 coprocessor instruction semantics with respect to usage of predicates for both types of coprocessors is shown in TABLE VII below:

TABLE VIIInstructionCoprocessor SemanticsCommentGx? XSD Rn, Rp,[RQ=]xfn(Rn,Rp)Write to RQ is not#xspc11predicatedGx? [Cn=]xfn(Rn,Rp)In case of internalregister, Cn is writtento only if Gx is trueGx? XLD Rm,x_result=RQRQ is always read from#xspc15Gx? Rm=x_resultRm written to if Gx istrueGx? xfn( )Guarded internaloperationGx? XSDLD[RQ=]xfn(Rn,Rp)Write to RQ is notRm, Rn,predicatedRp, #xspc7Gx? [Cn=] xfn(Rn,Rp)In case of internalregister, Cn is writtento only if Gx is truex_result=RQRQ is read from alwaysGx? Rm=x_resultRm written to if Gx istrueGx? XOP[RQ=]xfn( )Write to RQ is not#xspc19predicatedGx? [Cn=]xfn( )In case of internalregister, Cn is writtento only if Gx is true
“RQ” refers to the FIFO result queue, “Cn” refers to the coprocessor internal state (e.g., internal register), and “x_result” refers to the coprocessor result bus connecting to the core. Brackets (e.g., “{RQ=}”) indicate that the write (to the result queue or the internal register Cn) is optional based on the coprocessor solution. Alternatives referencing internal register Cn exist only when the coprocessor has an internal state (Type B).

In the case of Type A coprocessor extensions (without any internal state), the predicate usage is similar to that of the existing ST120, with the XSD operation or component part of XSDLD or XOP instruction executed speculatively and only the part of the XLD component that writes to the DRF being predicated. It is important to note that write to the result queue and reads from the result queue are not predicated, such that Type A coprocessor extensions do not require the predicate from the core.

In the case of Type B coprocessor extensions (with internal state), the internal state update and pure internal coprocessor operations are predicated. XSD and XLD components can be merged into one XSDLD only when both components employ the same predicate (which also holds for XOP and XLD). By way of example, typical cases are a “not predicated” code (Gx=G15 for both components) or a code block predicated by Gx (a complete set of instructions “if converted” using Gx) . When XSD and XLD components cannot hold the same predicate, XSDLD instructions are broken into two (XSD and XLD) instructions with their respective unique predicates as illustrated in the example given in TABLE VIII:

For both Type A and Type B coprocessor extensions, the FIFO result queue is written and updated irrespective of the predicate status of the instruction, and the FIFO result queue is read and the FIFO result queue pointers are updated on an XLD component irrespective of the predicate status of the instruction. For Type B coprocessor extensions, however, the coprocessor extension supplying the operands and extension specific opcode followed at a later time by another instruction retrieving the result of the corresponding earlier instruction should share the same predicate.

FIG. 3illustrates a scheme for handling non-uniform instruction latencies within split transaction coprocessor extension units according to one embodiment of the present invention. A coprocessor extension unit103may conceivably have several execution units301,302performing different types of instructions each with different execution latency. In order to optimally use the coprocessor and define rules for the compiler/optimizer to enforce, it should be remembered that the results of coprocessor instructions must be retrieved in program order. Assuming that two consecutive instructions i1,i2with latencies L1, L2are to be sent to the coprocessor (not necessarily in consecutive cycles), and that the execution units301,302performing these instructions write results to the FIFO result queue104via a single port303, two cases are presented:a) L2≧L1, which implies that the extension result queue will not be updated by instruction i2for (L2−L1)+1 cycles (note that in the present embodiment the “+1” is due to the fact that, in the best case, instructions i1and i2are issued in consecutive cycles), an acceptable circumstance since the instructions will not be competing for the result queue, which will be updated in order; andb) L2<L1, in which case potential conflict may occur with both execution units within the extension competing for the result queue, with the possibility that instruction i2might attempt to update the result queue before instruction i1, unless the core stalls issuance of instruction i2.

Therefore, special scheduling logic is required to detect and handle the indeterminate case of L2<L1. The scheduler must be aware of the respective latencies of consecutive (or closely spaced) instructions received for issuance to the same coprocessor extension and, in the case of L2<L1, should wait L1−L2cycles before dispatching the second instruction i2to the coprocessor extension. The scheduler need not wait to dispatch instruction i2when L2≧L1. The scheduler should apply these rules to optimally use the execution engines within the coprocessor extension.

FIG. 4illustrates one possible mechanism for connecting the result buses of multiple coprocessor extensions within split transaction coprocessor extension units according to one embodiment of the present invention. The exemplary embodiment described above allows for up to four different coprocessor extension units, with potentially different instruction latencies. If each extension unit has a FIFO result queue, the scheduling rules of each extension unit need to be respected.

When a coprocessor is intensively used, the coprocessor may start a new calculation and write a new result every cycle to the DRF. As a result, when an interrupt occurs, results produced by the coprocessor cannot be moved into the data unit during draining of the pipeline, and the results would be lost absent temporary storage. The FIFO result queue is thus placed between the last pipe stage of the coprocessor and the core data unit to hold these results produced by the coprocessor. The programmer must ensure that at any cycle the number of pending results is less than or equal to the FIFO result queue depth so that the FIFO result queue cannot overflow in the event of an interrupt or core stall condition.

The number of valid entries in the FIFO result queue is contained within a register FIFO Counter (not shown), with reads and writes to the FIFO result queue conforming to the following rules:when read, an empty FIFO result queue returns the last valid result already returned and the FIFO Counter remains unchanged at zero;when read, a non-empty FIFO result queue returns the oldest entry, then drops that entry and decrements FIFO Counter;when read and simultaneously written, an empty FIFO result queue returns back the last valid result previously returned, creates a new entry with the written data, and increments the FIFO Counter;when read and simultaneously written, a non-empty FIFO result queue returns the oldest result, drops that result, creates a new entry with the written data, and leaves the FIFO Counter unchanged;when read and simultaneously written, a full FIFO result queue works as just explained with the behavior guaranteed by the FIFO result queue microarchitecture or by implementing one more entry than required by the FIFO result queue theoretical size;when written, an empty FIFO result queue creates a new entry with the written data and increments the FIFO Counter (from 0 to 1);when written, a non-empty FIFO result queue creates a new entry with the written data and increments the FIFO Counter (from 0 to 1); andwhen written, a full FIFO result queue has undefined behavior.

To be able to save and restore the FIFO result queue upon the occurrence of an interrupt, some coprocessor instructions must be dedicated to this task as shown by Table IX below:

TABLE IXCoprocessor InstructionDescriptionXLD Rm, xfn_rdrqcntMove the FIFO into the DU register Rm andcopy the FIFO Counter value into the FIFO.If the FIFO Counter is 0, it is incremented;else it remains unchanged.XLD Rm, xfn_rdrqMove the FIFO into the DU register Rm.If the FIFO Counter is 0, it remainsunchanged; else it is decremented.XOP xfn_rstfifoReset FIFO CounterXSD Rn, Rp, xfn_wrrqDedicated to 32-bit FIFO:Move Rn[31:0] into the 32-bit FIFO (Rp[31:0]is lost).FIFO Counter is incremented by 1.Dedicated to 40-bit FIFO:Move the concatenation of Rp[23:16] andRn[31:0] into the 40-bit FIFO (Rp part in 8MSB and Rn part in 32 LSB).FIFO Counter is incremented by 1.XSD Rn, xfn_wrrqcntMove Rn[31:0] into the 32-bit FIFO Counter.
Note that the FIFO result queue width may be either 32 or 40 bits in the exemplary embodiment.

Assuming either a 32-bit or 40-bit FIFO result queue with four entries, the pseudo-code for a FIFO saving routine is shown below:

Assuming a 32-bit FIFO result queue with four entries, the pseudo-code for a FIFO restoring routine is shown below:

Assuming a 40-bit FIFO result queue with four entries, the pseudo-code for a FIFO restoring routine is shown below:

. . .// code which restores R0-R3, R10-R13 and R4. . .// from the location used by the save routineG15? XOP xfn_rstfifo;// state 7 -> state 8G15? XSD R0, R10, xfn_wrrq;// state 8 -> state 9G15? XSD R1, R11, xfn_wrrq;// state 9-> state 10G15? XSD R2, R12, xfn_wrrq;// state 10 -> state 11G15? XSD R3, R13, xfn_wrrq;// state 11 -> state 12G15? XSD R4, xfn_wrrqcnt;// state 12 -> state 13
Note that clearing the FIFO Counter is not necessary if the FIFO result queue is empty before execution of the restore routine, which should be the normal case since consuming all results generated by the instructions issued to the coprocessor is a strongly recommended software practice.

FIG. 5is a timing diagram illustrating operation of an example Galois multiplier split transaction coprocessor extension unit according to one embodiment of the present invention. The exemplary Galois multiplier extension (GMX) unit takes two 32-bit operands and produces a 32-bit result performing a Galois multiply on four 8-bit fields. The extension unit is identified as GMX in the Ext# field, and is assumed to include a fully pipelined, two-cycle extension execution engine followed by a single cycle write to the result queue, such that the latency seen by the program on the core is 3 cycles. With software pipelining, one result can be produced and written to the DRF per cycle after the initial latency, as illustrated in the pseudo-code sequence below:

FIG. 5illustrates operation of the extension when operands must be retrieved from memory and the result of the extension instruction must be stored in memory. The numbers within the instructions correspond to the instructions in the pseudo-code above. In the example shown, a result is retrieved every other cycle, and the core only allows two memory address unit (AU) operations per cycle while each loop iteration requires three memory accesses (two loads, one store) . However, the coprocessor interface has the capability to produce a result every cycle. The FIFO result queue needs to be three deep to hold the results before returning them to the core, which becomes important when an interrupt occurs inside this loop or under stalling conditions. The interrupt handler should be able to retrieve, store and restore the results from the three-entry deep FIFO in case another thread requires use of this coprocessor.

In the present invention, use of a split transaction extension unit provides a flexible alternative for customizing high performance digital signal processors, allowing an execution unit with a special instruction to be added without complete redesign of the architecture. The coprocessor architecture is customizable with a well-defined interface supporting multiple coprocessors, allowing for easy integration of the coprocessor with a core hard-macro on a System On Chip (SOC) processor subsystem. The coprocessor architecture is based on a split-instruction transaction model tightly coupled to the core data unit to appear like another data unit. The architecture of the present invention accommodates multi-cycle latency extension execution and fully exploits decoupled architectures. A scalable FIFO result queue with associated save/restore instruction forms is defined to support efficient pipelining and static scheduling of coprocessor operations, and an additional internal state may be added at will.

The present invention supports multi-cycle latency execution extensions and generic coprocessor instructions to effectively pipeline multi-cycle execution operations. The scalable FIFO result queue removes register pressure and accommodates stalls in the core, allowing the coprocessor extension pipeline to operate independently with respect to the core. Instruction predicates are available to the coprocessor extension.

The architecture of the exemplary embodiment supports up to four coprocessor extension units and at least two types of connection (OR logic or tri-state) for result buses from the coprocessors. Non-uniform latencies in a coprocessor extension and multi-cycle are supported.

Although the present invention has been described in detail, those skilled in the art will understand that various changes, substitutions, variations, enhancements, nuances, gradations, lesser forms, alterations, revisions, improvements and knock-offs of the invention disclosed herein may be made without departing from the spirit and scope of the invention in its broadest form.