Source: http://www.google.com/patents/US8006204?dq=U.S.+Patent+%23+5,723,324
Timestamp: 2016-10-23 01:59:39
Document Index: 747134726

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

Patent US8006204 - Automated processor generation system for designing a configurable processor ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsAn automated processor design tool uses a description of customized processor instruction set extensions in a standardized language to develop a configurable definition of a target instruction set, a Hardware Description Language description of circuitry necessary to implement the instruction set, and...http://www.google.com/patents/US8006204?utm_source=gb-gplus-sharePatent US8006204 - Automated processor generation system for designing a configurable processor and method for the sameAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS8006204 B2Publication typeGrantApplication numberUS 11/391,773Publication dateAug 23, 2011Filing dateMar 27, 2006Priority dateFeb 5, 1999Fee statusPaidAlso published asUS6477683, US6760888, US7020854, US8875068, US8924898, US20030208723, US20040250231, US20060259878, US20080244471, US20080244506Publication number11391773, 391773, US 8006204 B2, US 8006204B2, US-B2-8006204, US8006204 B2, US8006204B2InventorsEarl A. Killian, Ricardo E. Gonzalez, Ashish B. Dixit, Monica Lam, Walter D. Lichtenstein, Christopher Rowen, John C. Ruttenberg, Robert P. Wilson, Albert Ren-Rui Wang, Dror Eliezer MaydanOriginal AssigneeTensilica, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (28), Non-Patent Citations (31), Referenced by (40), Classifications (20), Legal Events (1) External Links: USPTO, USPTO Assignment, EspacenetAutomated processor generation system for designing a configurable processor and method for the same
US 8006204 B2Abstract
1. A method of designing configurable processors comprising the steps of:
selecting, through a graphical user interface of a computer system, processor functionality for a first processor, including selecting at least one extended processor instruction that provides additional processor functionality, wherein the processor functionality, including the at least one extended processor instruction, is selected from configuration options;
inputting the selected processor functionality into the computer system, including the at least one of selected extended processor instruction that provides the additional processor functionality; and
automatically building, using the computer system, based upon the selected processor functionality including the at least one extended processor instruction that provides the additional processor functionality, a first processor design, the first processor design including (1) a description of a hardware implementation of the first processor, and (2) software development tools specific to the hardware implementation.
selecting, through the graphical user interface of the computer system, processor functionality for a second processor, including selecting at least one other extended processor instruction that provides other additional processor functionality different from the at least one extended processor instruction that provides the additional processor functionality and different from the functionality for the first processor, from the configuration options;
inputting the selected processor functionality into the computer system, including the selected at least one other extended processor instruction that provides the other additional processor functionality; and
building, using the computer system, based upon the selected processor functionality including the at least one other extended processor instruction that provides the other additional processor functionality, a second processor design that is different from the first processor design, the second processor design including (1) a second description of a second hardware implementation of the second processor, the second hardware implementation being different than the first hardware implementation, and (2) second software development tools specific to the second hardware implementation, the second software development tools being different than the first software development tools due at least in part to the at least one other extended processor instruction that provides the other additional processor functionality.
3. The method according to claim 2 further comprising the step of deleting one of the first and second processor designs using the graphical user interface of the computer system.
4. The method according to claim 2 further comprising the step of editing one of the first and second processor designs using the graphical user interface of the computer system.
5. The method of claim 1, wherein the software development tools include a compiler, tailored to the configuration specification, for compiling an application into code executable by the processor.
6. The method of claim 1, wherein the software development tools include an assembler, tailored to the configuration specification, for assembling an application into code executable by the processor.
7. The method of claim 1, wherein the software development tools include a linker, tailored to the configuration specification, for linking code executable by the processor.
8. The method of claim 1, wherein the software development tools include a disassembler, tailored to the configuration specification, for disassembling code executable by the processor.
9. The method of claim 1, wherein the software development tools include a debugger, tailored to the configuration specification, for debugging code executable by the processor.
10. The method of claim 9, wherein the debugger has a common interface and configuration for instruction set simulator and hardware implementations.
11. The method of claim 1, wherein the software development tools include an instruction set simulator, tailored to the configuration specification, for simulating code executable by the processor.
12. The method of claim 11, wherein the instruction set simulator is to model execution of code being simulated to measure key performance criteria including cycles of execution.
13. The method of claim 12, wherein the performance criteria are based on specific microarchitectural features selected through the graphical user interface.
14. The method of claim 10, wherein the instruction set simulator is to profile execution of the program being simulated to record standard profiling statistics, including a number of cycles executed in each simulated function.
15. The method of claim 1, wherein the selected processor functionality includes a data cache.
16. The method of claim 15, wherein the selected processor functionality specifies the size of the cache.
17. The method of claim 15, wherein the selected processor functionality specifies the line size of the cache.
18. The method of claim 15, wherein the selected processor functionality specifies the set associativity of the cache.
19. The method of claim 1, wherein the selecting step includes a binary selection of whether or not to include the selected processor functionality in the first processor. Description
This is a continuation of application Ser. No. 10/884,590 filed Jul. 2, 2004, (issuing as U.S. Pat. No. 7,020,854 on Mar. 28, 2006), which is a continuation of application Ser. No. 10/286,496 filed Nov. 1, 2002, now U.S. Pat. No. 6,760,888 issued Jul. 6, 2004, which is a continuation of U.S. application Ser. No. 09/246,047 filed Feb. 5, 1999, now U.S. Pat. No. 6,477,683 issued Nov. 5, 2002.
To better understand the difficulty in making a prior art processor configurable, consider its development. First, the instruction set architecture (ISA) is developed. This is a step which is essentially done once and used for decades by many systems. For example, the Intel Pentium� processor can trace the legacy of its instruction set back to the 8008 and 8080 microprocessors introduced in the mid-1970's. In this process, based on predetermined ISA design criteria, the ISA instructions, syntax, etc. are developed, and software development tools for that ISA such as assemblers, debuggers, compilers and the like are developed. Then, a simulator for that particular ISA is developed and various benchmarks are run to evaluate the effectiveness of the ISA and the ISA is revised according to the results of the evaluation. At some point, the ISA will be considered satisfactory, and the ISA process will end with a fully developed ISA specification, an ISA simulator, an ISA verification suite and a development suite including, e.g., an assembler, debugger, compiler, etc.
where the most significant eight bits in the result are the decoded value and the least significant eight bits are the length. In contrast to the previously described software implementation, a direct hardware implementation of the Huffman decode is quite simple—the logic to decode the instruction represents roughly thirty gates for just the combinatorial logic function exclusive of instruction decode, etc., or less than 0.1% of a typical processor's gate count, and can be computed by a special-purpose processor instruction in a single cycle, thus representing an improvement factor of 4-20 over using general-purpose instructions only.
Of the above, the Synopsys DW8051 includes a binary compatible implementation of an existing processor architecture; and a small number of synthesis parameters, e.g., 128 or 256 bytes of internal RAM, a ROM address range determined by a parameter rom_addr_size, an optional interval timer, a variable number (0-2) of serial ports, and an interrupt unit which supports either six or thirteen sources. Although the DW8051 architecture can be varied somewhat, no changes in its instruction set architecture are possible.
The ARC configurable RISC core has a user interface with on-the-fly-gate count estimation based on target technology and clock speed, instruction cache configuration, instruction set extensions, a timer option, a scratch-pad memory option, and memory controller options; an instruction set with selectable options such as local scratchpad RAM with block move to memory, special registers, up to sixteen extra condition code choices, a 32�32 bit scoreboarded multiply block, a single cycle 32 bit barrel shifter/rotate block, a normalize (find first bit) instruction, writing results directly to a command buffer (not to the register file), a 16 bit MULIMAC block and 36 bit accumulator, and sliding pointer access to local SRAM using linear arithmetic; and user instructions defined by manual editing of VHDL source code. The ARC design has no facility for implementing an instruction set description language, nor does it generate software tools specific to the configured processor.
In addition, once the processor is designed and verified it is not particularly useful if it cannot be programmed easily. Processors are generally programmed with the aid of extensive software tools, including compilers, assemblers, linkers, debuggers, simulators and profilers. When the processor changes, the software tools must change as well. It does no good to add an instruction if that instruction cannot be compiled, assembled, simulated or debugged. The cost of software changes associated with processor modifications and enhancements has been a major impediment to flexible processor design in the prior art.
Technology for Estimation
Target ASIC technology: 0.18, 0.25, 0.35 micron Target operating condition: typical, worst-case Implementation Goals
Target speed: arbitrary Gate count: arbitrary Target power: arbitrary Goal prioritization: speed, area power; speed, power, area
MAC 16 with 40-bit accumulator: yes, no 16-bit multiplier: yes, no Exception Options
Number of interrupts: 0-32 High priority interrupt levels: 0-14 Enable Debugging: yes, no Number of Timers: 0-3 Other
Byte Ordering: little endian, big endian Number of registers available for call windows: 32, 64
Processor Cache & Memory
Processor interface read width (bits): 32, 64, 128 Write-buffer entries (address/value pairs): 4, 8, 16, 32 Processor Cache
Instruction/Data cache size (kB): 1, 2, 4, 8, 16 Instruction/Data cache line size (kB): 16, 32, 64
Timer interrupt numbers Timer interrupt levels
Number of instruction address breakpoint registers: 0-2 Number of data address breakpoint registers: 0-2 Debug interrupt level Trace port: yes, no On-chip debug module: yes, no Full scan: yes. no
Source: external, software Priority level
System Memory Addresses
Vector and address calculation method: XTOS, manual Configuration Parameters
RAM size, start address: arbitrary ROM size, start address: arbitrary XTOS: arbitrary Configuration Specific Addresses
User exception vector: arbitrary Kernel Exception vector: arbitrary Register window over/underflow vector base: arbitrary Reset vector: arbitrary XTOS start address: arbitrary Application start address: arbitrary
(define ISA extensions)
Target CAD Environment
Verilog™: yes, no Synthesis
Design Compiler™: yes, no Place & Route
Apollo™: yes, no
Additionally, the system 10 may provide options for adding other functional units such as a 32-bit integer multiply/divide unit or a floating point arithmetic unit; a memory management unit; on-chip RAM and ROM options; cache associativity; enhanced DSP and coprocessor instruction set; a write-back cache; multiprocessor synchronization; compiler-directed speculation; and support for additional CAD packages. Whatever configuration options are available for a given configurable processor, they are preferably listed in a definition file (such as the one shown in Appendix A) which the system 10 uses for syntax checking and the like once the user has selected appropriate options.
The system 10 provides separate configuration options for the interrupt (implementing level 1 interrupts) and the high-priority interrupt option (implementing level 2-15 interrupts and non maskable interrupts) because each high-priority interrupt level requires three special registers, and these are thus more expensive.
field x inst[11:8] field y inst[15:12] field xy {x, y} defines two 4-bit fields, x and y, as sub-fields (bits 8-11 and 12-15, respectively) of a highest-level field inst and an 8-bit field xy as the concatenation of the x and y fields.
opcode acs op2 = 4′b0000 CUST0 opcode adsel Op2 = 4′b0001 CUST0 defines two new opcodes, acs and adsel, based on the previously-defined opcode CUST0 (4′ b0000 denotes a four bit-long binary constant 0000). The TIE specification of the preferred core ISA has the statements
field op0 Inst[3:0] field op1 Inst[19:16] field opt Inst[23:20] opcode QRST op0 = 4′b0000 opcode CUST0 opl=4′b0100 QRST as part of its base definitions. Thus, the definitions of acs and adsel cause the TIE compiler to generate instruction decoding logic respectively represented by the following:
field offset inst[23:6] operand offests4 offset { assign offsets4 = {{14{offset[17]}}, offset} <<2; }{ wire [31:0] t; assign t = offsets4>>2; assign offset = t[17:0]; defines an 18-bit field named offset which holds a signed number and an operand of fsets4 which is four times the number stored in the offset field. The last part of the operand statement actually describes the circuitry used to perform the computations in a subset of the Verilog™ HDL for describing combinatorial circuits, as will be apparent to those skilled in the art.
Here, the wire statement defines a set of logical wires named t thirty-two bits wide. The first assign statement after the wire statement specifies that the logical signals driving the logical wires are the of fsets4 constant shifted to the right, and the second assign statement specifies that the lower eighteen bits of t are put into the offset field. The very first assign statement directly specifies the value of the of fsets4 operand as a concatenation of offset and fourteen replications of its sign bit (bit 17) followed by a shift left of two bits.
table prime 16 { 2, 3, 5, 7, 9, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53 } operand prime _s s { assign prime _s = prime[s]; } { assign s = prime _s == prime[0] ? 4′b0000 prime _s == prime[1] ? 4′b0001 prime _s == prime[2] ? 4′b0010 prime _s == prime[3] ? 4′b0011 prime _s == prime[4] ? 4′b0100 prime _s == prime[5] ? 4′b0101 prime _s == prime[6] ? 4′b0110 prime _s == prime[7] ? 4′b0111 prime _s == prime[8] ? 4′b1000 prime _s == prime[9] ? 4′b1001 prime _s == prime[10] ? 4′b1010 prime _s == prime[11] ? 4′b1011 prime _s == prime[12] ? 4′b1100 prime _s == prime[13] ? 4′b1101 prime _s == prime[14] ? 4′b1110 4′b1111; } makes use of the table statement to define an array prime of constants (the number following the table name being the number of elements in the table) and uses the operand s as an index into the table prime to encode a value for the operand prime_s (note the use of Verilog™ statements in defining the indexing).
operand art t {assign art = AR[t];} { } operand ars s {assign ars = AR{s};} { } operand arr r {assign AR[r] = arr;} { } use the operand statement to define three register operands art, ars and arr (again note the use of Verilog™ statements in the definition). Then, the iclass statement
iclass viterbi {adsel, acs} {out arr, in art, in ars} specifies that the operands adsel and acs belong to a common class of instructions viterbi which take two register operands art and ars as input and writes output to a register operand arr.
op2=4′b0000 CUST0
op2=4′b0001 CUST0
semantic add _min
assign arr = (({32{{ADD8_4}}}) & (add)) I (({32{{MIN16_2}}}) & (min));
instruction decode logic of the processor 60;
illegal instruction detection logic for the processor 60;
the ISA-specific portion of the assembler 110;
the ISA-specific support routines for the compiler 108;
the ISA-specific portion of the disassembler 100 (used by the debugger); and
the ISA-specific portion of the simulator 112.
It is valuable to generate these things automatically because an important configuration capability is to specify the inclusion of packages of instructions. For some things, it would be possible to implement this with conditionalized code in each of the tools to handle the instruction if it has been configured, but this is awkward; more importantly, it does not allow the system designer to easily add instructions for his system.
opcode NAME FIELD = VALUE declaration to the HDL statement
assign NAME = FIELD == VALUE; and the
opcode NAME FIELD = VALUE PARENTNAME [FIELD2 =
VALUE2] to
assign illegalinst = !(INST1 | INST2... | INSTn);
The instruction decode signals and the illegal instruction signal are available as outputs of the decode module and as inputs to the hand written processor logic.
; $endian = config_get_value (“IsaMemoryOrder”) where config_get_value is the TPP function used to query the configuration specification 100, IsaMemoryOrder is a flag set in the configuration specification 100, and $endian is a TPP variable to be used later in generating the Verilog™ code.
A TPP conditional expression might be
; if (config_get_value(“IsaMemoryOrder”) eq “LittleEndian”) ; {do Verilog ™ code for little endian ordering} ; else ; {do Verilog ™ code for big endian ordering} Iterative loops can be implemented by TPP constructs such as
; for {$i=0; $i<$ninterrupts; $i++} ; {do Verilog ™ code for each of 1..N interrupts} where $i is a TPP loop index variable and $ninterrupts is the number of interrupts specified for the processor 60 (obtained from the configuration specification 100 using config_get_value).
Finally, TPP code can be embedded into Verilog™ expressions such as
wire [‘$ninterrupts−1’:0] srInterruptEn; xtscenflop #(‘$ninterrupts’) srintrenreg (srInterruptEn, srDataIn_W[‘$ninterrupts−1’:0], srIntrEnWEn, !cReset,CLK); where:
; # Timer Interrupt ; if ($IsaUseTimer) { wire [‘$width−1’:0] srCCount; wire ccountWEn; //-------------------------------------------------------------- // CCOUNT Register //-------------------------------------------------------------- assign ccountWEn = srWEn_W && (srWrAdr_W =_ ‘SRCCOUNT); xtflop #(‘$width’) srccntreg (srCCount, (ccountWEn ? srDataIn_W srCCount+1),CLK); ; for ($i=0; $i<$TimerNumber; $i++) { //-------------------------------------------------------------- // CCOMPARE Register //-------------------------------------------------------------- wire [‘$width 1’:0] srCCompare‘$i’; wire ccompWEn‘$i’; assign ccompWEn‘$i’ = srWEn_W && (srWrAdr_W == ‘SRCCOMPARE‘$i’); xtenflop #(‘$width’) srccmp‘$i’reg (srCCompare‘$i’,srDataIn_W,ccompWEn‘$i’,CLK); assign setCCompIntr‘$i’ = (srCCompare‘$i’ == srCCount); assign c1rCCompIntr‘$i’ = ccompWEn‘$i’; ; } ; } ## IsaUseTimer and the declarations
$IsaUseTimer = 1 $TimerNumber = 2 $width = 32 TPP generates
wire [31:0] srCCount; wire ccountWEn; //-------------------------------------------------------------- // CCOUNT Register //-------------------------------------------------------------- assign ccountWEn = srWEn_W && (srWrAdr_W == ‘SRCCOUNT); xtflop #(32) srccntreg (srCCount, (ccountWEn ? srDataIn_W : srCCount+1),CLK); //-------------------------------------------------------------- // CCOMPARE Register //-------------------------------------------------------------- wire [31:0] srCCompare0; wire ccompWEn0; assign ccompWEn0 = srWEn_W && (srWrAdr_W == ‘SRCCOMPARE0); xtenflop #(32) srccmp0reg (srCCompare0,srDataIn_W,ccompWEn0,CLK); assign setCCompIntr0 = (srCCompare0 == srCCount); assign c1rCCompIntr0 = ccompWEn0; //-------------------------------------------------------------- // CCOMPARE Register //-------------------------------------------------------------- wire [31:0] srCCompare1; wire ccompWEn1; assign ccompWEn1 = srWEn_W && (srWrAdr_W == ‘SRCCOMPARE1); xtenflop #(32) srccmp1reg (srCCompare1,srDataIn_W, ccompWEn1,CLK); assign setCCompIntr1 = (srCCompare1 == srCCount); assign c1rCCompIntr1 = ccompWEn1; The HDL description 114 thus generated is used to synthesize hardware for processor implementation using, e.g., the DesignCompiler™ manufactured by Synopsys Corporation in block 122. The result is then placed and routed using, e.g., Silicon Ensemble™ by Cadence Corporation or Apollo™ by Avant! Corporation in block 128. Once the components have been routed, the result can be used for wire back-annotation and timing verification in block 132 using, e.g., PrimeTime™ by Synopsys. The product of this process is a hardware profile 134 which can be used by the user to provide further input to the configuration capture routine 20 for further configuration iterations.
The second level of support for designer-defined instructions is provided by having the compiler automatically recognize opportunities for using the instructions. These TIE instructions could be directly defined by the user or created automatically during the configuration process. Prior to compiling the user application, the TIE code is automatically examined and converted into C equivalent functions. This is the same step used to allow fast simulation of TIE instructions. The C equivalent functions are partially compiled into a tree-based intermediate representation used by the compiler. The representation for each TIE instruction is stored in a database. When the user application is compiled, part of the compilation process is a pattern matcher. The user application is compiled into the tree-based intermediate representation. The pattern matcher walks bottom-up every tree in the user program. At each step of the walk, the pattern matcher checks if the intermediate representation rooted at the current point matches any of the TIE instructions in the database. If there is a match, the match is noted. After finishing to walk each tree, the set of maximally sized matches are selected. Each maximal match in the tree is replaced with the equivalent TIE instruction.
The configuration specification is also used to configure a simulator called the ISS
126 shown in FIG. 13. The ISS 126 is a software application that models the functional behavior of the configurable processor instruction set. Unlike its counterpart processor hardware model simulators such as Synopsys VCS and Cadence Verilog XL and NC simulators, the ISS HDL model is an abstraction of the CPU during its instruction execution. The ISS 126 can run much faster than a hardware simulation because it does not need to model every signal transition for every gate and register in the complete processor design.
a scriptable interface which allows very detailed debugging and performance analysis. In particular, this interface may be used to compare application behavior on different configurations. For example, at any breakpoint the state from a run on one configuration may be compared with or transferred to the state from a run on another configuration.
Motion estimation is an important component of many image compression algorithms, including MPEG video and H263 conference applications. Video image compression attempts to use the similarities from one frame to the next to reduce the amount of storage required for each frame. In the simplest case, each block of an image to be compressed can be compared to the corresponding block (the same X,Y location) of the reference image (one that closely precedes or follows the image being compressed). The compression of the image differences between frames is generally more bit-efficient than compression of the individual images. In video sequences, the distinctive image features often move from frame to frame, so the closest correspondence between blocks in different frames is often not at exactly the same X,Y location, but at some offset. If significant parts of the image are moving between frames, it may be necessary to identify and compensate for the movement, before computing the difference. This fact means that the densest representation can be achieved by encoding the difference between successive images, including, for distinctive features, an X, Y offset in the sub-images used in the computed difference. The offset in the location used for computing the image difference is called the motion vector.
The following example shows a simple form of a motion estimation algorithm, then optimizes the algorithm using TIE for a small application-specific functional unit. This optimization yields a speed-up of more than a factor of 10, making processor-based compression feasible for many video applications. It illustrates the power of a configurable processor that combines the ease of programming in a high-level language with the efficiency of special-purpose hardware.
unsigned char O1dB[NX][NY];
unsigned char NewB[NX][NY];
unsigned short VectX[NX/BLOCKX][NY/BLOCKY];
/* X motion
unsigned short VectY[NX/BLOCKX][NY/BLOCKY];
/* Y motion
unsigned short VectB[NX/BLOCKX][NY/BLOCKY];
unsigned short BaseX[NX/BLOCKX][NY/BLOCKY];
unsigned short BaseY[NX/BLOCKX][NY/BLOCKY];
unsigned short BaseB[NX/BLOCKX][NY/BLOCKY];
#define ABSD(x,y)
/********************************************************************** Reference software implementation ***********************************************************************/ void motion_estimate_base( ) { int bx, by, cx, Cyr x, y; int startx, starty, endx, endy; unsigned cliff, best, bestx, best y; for(bx = 0; bx < NX/BLOCKX; bx++) { for (by = 0; by < NY/BLOCKY; by++) { best = bestx = besty = UINT_MAX; startx = MAX(0, bx*BLOCKX − SEARCHX); starty = MAX(0, by*BLOCKY − SEARCHY); endx = MIN(NX−BLOCKX, bx*BLOCKX + SEARCHX); endy = MIN (NY−BLOCKY, by*BLOCKY + SEARCHY); for(cx = startx: cx < endx; cx++) { for(cy = starty; cy < endy; cy++) { diff = 0; for(x = 0; x < BLOCKX; x++) { for(y = 0; y < BLOCKY; y++) { diff += ABSD(O1dB[cx+x][cy+y], NewB[bx*BLOCKX+x][by*BLOCKY+y]); } } if (diff < best) { best = cliff; bestx = cx; besty = cy; } } } BaseX[bx][by] = bestx; BaseY[bx][by] = besty; BaseB[bx][by] = best; } } } While the basic implementation is simple, it fails to exploit much of the intrinsic parallelism of this block to block comparison. The configurable processor architecture provides two key tools to allow significant speed-up of this application.
O = (unsigned *) &(O1dB[cx+x][cy]);
N += NY/4;.
VectX[bx][by] = bestx;
VectY[bx][by] = besty;
VectB[bx][by] = best;
return ABSD(ars >> 24, art >> 24) +
opcode SAD opt=4′b0000 CUSTO
wire (7:0) diffOr, diff1r, diff2r, diff3r;
assign diff31 = art[31:24] − ars[31:24];
assign diffOr = ars[7:0] − art[7:0];
(diff01[8] ? diffOr : diff01) +
(diff31[8] ? diff3r : diff31);
opcode QRST op0=4′b0000 opcode CUST0 op1=4′b0100 QRST It is easy to see that QRST is the top-level opcode. CUST0 is a sub-opcode of QRST and SAD in turn a sub-opcode of CUST0. This hierarchical organization of opcodes allow logical grouping and management of the opcode spaces. One important thing to remember is that CUST0 (and CUST1) are defined as reserved opcode space for users to add new instructions. It is preferred that users stay within this allocated opcode space to ensure future re-usability of TIE descriptions.
From the two reports one can see that roughly a 4� speedup has occurred. Notice that the configurable processor instruction set simulator can provide much other useful information.
Thus, the incorporation of a simple sum-of-absolute-differences instruction adds just a few hundred gates, yet improves motion estimation performance by more than a factor of ten. This acceleration represents significant improvements in cost and power efficiency of the final system. Moreover, the seamless extension of the software development tools to include the new motion estimation instruction allows for rapid prototyping, performance analysis and release of the complete software application solution. The solution of the present invention makes application-specific processor configuration simple, reliable and complete, and offers dramatic enhancement of the cost, performance, functionality and power-efficiency of the final system product.
function memory(Select,A1,A2,DI1,DI2,W1,W2,DO1,D02) ; $B1 = config get value(“width_of_port_1”); $B2 = config_get_value(“width_of_port 2”); ; $Bytes = config_get_value(“size_of_memory”); ; $Max = max($B1,$B2); $Min = min($B1,$B2); ; $Banks = $Max/$Min; ; $Wide1 = ($Max == $B1); $Wide2 = ($Max == $B2); ; Depth = $Bytes/(log2($Banks)*log2($Max)); wire [‘$Max’*8−1:0] Data1 = ‘$Wide1’?DI1:{‘$Banks’{DI1}}; wire [‘$Max’*8−1:0] Data2 = ‘$Wide1’?DI2:{‘$Banks’{DI2}}); wire [‘$Max’*8−1:0] D = Select ? Data1 : Data2: wire Wide = Select ? Wide1: Wide2; wire [log2(‘$Bytes’)−1:0] A = Select? A1 : A2; wire [log2(‘$Bytes’)−1:0] Address = A[log2(‘$Bytes’)−1:log2(‘$Banks’)]: wire [log2(‘$Banks’)−1:0] Lane = A[log2(‘$Banks’)−1:0]: ; for ($i=0; $i<$Banks; $i++) { wire WrEnable{i} = Wide | (Lane == {i}); wire [log2(‘$Min’)−1:0] WrData‘$i’ = D[({i}+1)*‘$Min’*8−1:{i}*‘$Min’*8] ram(RdData‘$i’,Depth,Address,WrData‘$i’,WrEnable‘$i’); ;} wire [‘$Max’*8−1:0] RdData = { ;for ($i=0; $i<$Banks; $i++) { RdData‘$i’, ;} } wire [‘$B1’*8−1:0] DO1 = Wide1?RdData:RdData[(Lane+1)*B1*8−1:Lane*B1*8]; wire [‘$B2’*8−1:0] D02 = Wide2?RdData:RdData[(Lane+1)*B2*8−1:Lane*B2*8]; where $Bytes is the total memory size accessed either as width B1 bytes at byte address A1 with data bus D1 under control of write signal W1, or using corresponding parameters B2, A2, D2 and W2. Only one set of signals, defined by Select, is active in a given cycle. The TPP code implements the memory as a collection of memory banks. The width of each bank is given by the minimum access width and the number of banks by the ratio of the maximum and minimum access widths. A for loop is used to instantiate each memory bank and its associated write signals, i.e., write enable and write data. A second for loop is used to gather the data read from all the banks into a single bus.
input ADD8_4, MIN16 _2, SHIFTI6_2;
assign min[31:16] = art[31:16] < ars[31:16] ? Art[31:16] : ars[31:16]:
assign shift[31:16] = art[31:16] << ars[31:16];
assign shift[15:0] = art[15:0] << ars[15:0];
{32{SHIFTI6 2}} & shift; }
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5450586Apr 30, 1992Sep 12, 1995Hewlett-Packard CompanySystem for analyzing and debugging embedded software through dynamic and interactive use of code markersUS5535331Feb 3, 1992Jul 9, 1996Texas Instruments IncorporatedProcessor condition sensing circuits, systems and methodsUS5563987 *Oct 28, 1994Oct 8, 1996International Business Machines CorporationPagemap memory representation in RISC processor printersUS5748875Jun 12, 1996May 5, 1998Simpod, Inc.Digital logic simulation/emulation systemUS5781763 *May 22, 1997Jul 14, 1998International Business Machines CorporationIndependent control of DMA and I/O resources for mixed-endian computing systemsUS5819050Feb 29, 1996Oct 6, 1998The Foxboro CompanyAutomatically configurable multi-purpose distributed control processor card for an industrial control systemUS5854929Nov 18, 1996Dec 29, 1998Interuniversitair Micro-Elektronica Centrum (Imec Vzw)Method of generating code for programmable processors, code generator and application thereofUS5867399 *Apr 21, 1997Feb 2, 1999Lsi Logic CorporationSystem and method for creating and validating structural description of electronic system from higher-level and behavior-oriented descriptionUS5867400 *May 17, 1995Feb 2, 1999International Business Machines CorporationApplication specific processor and design method for sameUS5870588Oct 23, 1996Feb 9, 1999Interuniversitair Micro-Elektronica Centrum(Imec Vzw)Design environment and a design method for hardware/software co-designUS5896521 *Oct 2, 1996Apr 20, 1999Mitsubishi Denki Kabushiki KaishaProcessor synthesis system and processor synthesis methodUS5918035May 15, 1995Jun 29, 1999Imec VzwMethod for processor modeling in code generation and instruction set simulationUS5964861Dec 17, 1996Oct 12, 1999Nokia Mobile Phones LimitedMethod for writing a program to control processors using any instructions selected from original instructions and defining the instructions used as a new instruction setUS5999734Oct 21, 1997Dec 7, 1999Ftl Systems, Inc.Compiler-oriented apparatus for parallel compilation, simulation and execution of computer programs and hardware modelsUS6006022Nov 15, 1996Dec 21, 1999Microsystem Synthesis, Inc.Cross-linked development and deployment apparatus and methodUS6052518Apr 30, 1998Apr 18, 2000Kabushiki Kaisha ToshibaLogical circuit automatical design method and system, and computer readable medium for storing a program for performing automatically designing process thereinUS6101592 *Dec 18, 1998Aug 8, 2000Billions Of Operations Per Second, Inc.Methods and apparatus for scalable instruction set architecture with dynamic compact instructionsUS6115034 *Jan 29, 1998Sep 5, 2000Canon Kabushiki KaishaStep managing apparatus and methodUS6148374 *Jul 2, 1998Nov 14, 2000Micron Technology, Inc.Multi-way cache expansion circuit architectureUS6166728 *Jun 7, 1993Dec 26, 2000Scientific-Atlanta, Inc.Display system with programmable display parametersUS6182206Feb 26, 1998Jan 30, 2001Ricoh CorporationDynamically reconfigurable computing using a processing unit having changeable internal hardware organizationUS6195593Jul 22, 1998Feb 27, 2001Seiko Epson CorporationReusable modules for complex integrated circuit devicesUS6477683Feb 5, 1999Nov 5, 2002Tensilica, Inc.Automated processor generation system for designing a configurable processor and method for the sameUS6618854 *Feb 18, 1997Sep 9, 2003Advanced Micro Devices, Inc.Remotely accessible integrated debug environmentUS6839889Mar 1, 2001Jan 4, 2005Realtek Semiconductor Corp.Mixed hardware/software architecture and method for processing xDSL communicationsEP0743599A2Apr 1, 1996Nov 20, 1996Interuniversitair Micro-Elektronica Centrum VzwMethod of generating code for programmable processor, code generator and application thereofJPH10187484A Title not availableWO1999000731A1Jun 29, 1998Jan 7, 1999Chameleon Systems, Inc.Method for compiling high level programming languages* Cited by examinerNon-Patent CitationsReference1Akaboshi, et al., "Study on Design Support for Computer Architecture", Design Automation, 68-7, 13 pages (Oct. 28, 1993).2Clucas, R., "Designing with a Customisable Microprocessor Core", Electronic Engineering, vol. 71, No. 865, Feb. 1, 1999, p. 35.3Fauth et al. Describing instruction set processors using nML (Proc. Euro. Design & Test Conf. Paris Mar. 1995, IEEE 1995, 5 pp.).4Fauth et al., "Generation of hardware machine models from instruction set descriptions,"VLSI Signal Processing VI, 1993, Workshop on Veldhoven, Netherlands, 20-22, Oct. 1993, New York NY, USA, IEEE Oct. 20, 1993 pp. 242-250.5Fauth, A., et al., "Describing Instruction Set Processors Using nML," IEEE, p. 503-507, (1995).6Fauth, et al., "Describing Instruction Set Processors Using nML", Proc. EP Design and Test Conf., Parish, Mar. 1995, 5 pages.7Freericks, "The nML Machine Description Formalism" (Bericht 1991/15 pp. 3-41).8Hadjiyiannis et al. "ISDL: an instruction set description language for retargetability" DAC '97, Anaheim California, 1997 ACM 0-89791-920-3/97/06.9Hadjiyiannis, G., et al., "ISDL: An Instruction Set Description Language for Retargetability", Jun. 9, 1997, 4 pages.10Hakata, et al., "A Software Development Took Generator for ASIC CPU", Design Automation, 62-25, May 18, 1992, pp. 144-147.11Hartoog et al. "Generation of Software Tools from Processor Descriptions for Hardware/Software Codesign" (ACM, Jun. 1997, pp. 303-306.12Hartoog, Mark R., et al., "Generation of Software Tools from Processor Descriptions for Hardware/Software Co-design," 34th Design Automation Conference (DAC), p. 1-4, (1997).13Hikichi, et al.,, "Compilers for Embedded System", Tech. Report of IEICE, Apr. 1998, 13 pages.14Internet Publication http://www.lexra.com/product.html (11 pp. undated).15Internet Publication http://www.retarget.com/brfchschk.html (19 pp. undated).16Internet Publication http://www.risccores.com/html/body-aboutarc.htm (13 pp. undated).17Internet Publication http://www.risccores.com/html/body—aboutarc.htm (13 pp. undated).18Internet Publication http://www.synopsys.com/oruducts/designware/dwpci-ds.html (16 pp. undated).19Internet Publication http://www.synopsys.com/oruducts/designware/dwpci—ds.html (16 pp. undated).20Internet Publication http://www.synopsys.com/products/designware/8051-ds.html (8pp. undated).21Internet Publication http://www.synopsys.com/products/designware/8051—ds.html (8pp. undated).22Leupers et al. "Retargetable Code Generation Based on Structural Processor Descriptions" (Design Automation for Embedded Systems, vol. 3, No. 1, Jan. 1998, pp. 1-36.23Nurprasetyo, et al., "Soft-Core Processor Architecture for Embedded System Design", IEICE Trans. on Electronics, Electronics Soc., vol. E81-C, No. 9, Sep. 1, 1998, pp. 1416-1423.24Ohtsuki, et al., "HW/SW Co-Design System PEAS-II for VLIW Processor", DA Symposium, Jul. 1998, 7 pages.25Sato, et al., "Implementation and Evaluation of PEAS: Practical Environment for ASIP Development", Design Automation, 64-11, Oct. 23, 1992, pp. 79-86.26Sato, et al., "PEAS-1: A hardware/Software Codesign System for ASIP Development", IEICE Trans. on Fundamentals of Electronics, Communications and Computer Sciences, Engineering Sciences Soc., vol. E77-A, No. 3, Mar. 1, 1994, pp. 483-491.27Shackleford, et al., "Satsuki: An Integrated Processor Synthesis and Compiler Generation System", IEICE Trans. on Information and Systems, Information and Society; vol. E79-D, No. 10, Oct. 1, 1996, pp. 1373-1381.28Shiomi, et al., "Proposal of Co-Design Workbench PEAS-III for ASIP Design", Design Automation, 76-10, Jul. 20, 1995, pp. 73-80.29Tensilica "Xtensa" Instruction Set Architecture (ISA) Ref. Manual. Rev. 1.0, Tensilica, Inc.30Yang, et al., "MetaCore: An Application specific DSP Development System", Design Automation Conf., 1998, Proc. San Francisco, CA , Jun. 15-19, 1998, IEEE, Jun. 15, 1998, pp. 800-803.31Zivojnovic et al. "DSP Processor/Compiler Co-Design: a quantitative approach" (9th Int'l Symposium on System Synthesis (ISSS '96), Nov. 6-8, 1996, San Diego, CA.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS8132157 *Jan 17, 2008Mar 6, 2012International Business Machines CorporationMethod of automatic regression testingUS8180919 *Jul 30, 2004May 15, 2012Xilinx, Inc.Integrated circuit and method of employing a processor in an integrated circuitUS8261243 *Aug 12, 2008Sep 4, 2012International Business Machines CorporationSelective execution of trace mechanisms for applications having different bit structuresUS8271928 *Sep 18, 2012Mentor Graphics CorporationAutomating power domains in electronic design automationUS8276120 *Sep 25, 2012Coreworks, S.A.Reconfigurable coprocessor architecture template for nested loops and programming toolUS8281296 *Oct 2, 2012Oracle America, Inc.Cross-ISA inlining in a system virtual machineUS8332822 *Mar 7, 2011Dec 11, 2012Microsoft CorporationTechnologies for code failure proneness estimationUS8352924 *Oct 13, 2009Jan 8, 2013National Tsing Hua UniversityMethod and device for multi-core instruction-set simulationUS8365151 *Jan 29, 2013Sony Computer Entertainment Inc.Multiple stage program recompiler using information flow determinationUS8423343 *Jan 24, 2011Apr 16, 2013National Tsing Hua UniversityHigh-parallelism synchronization approach for multi-core instruction-set simulationUS8464235 *Jun 11, 2013Stmicroelectronics Ltd.Adaptive production of assemblerUS8656376 *Sep 1, 2011Feb 18, 2014National Tsing Hua UniversityCompiler for providing intrinsic supports for VLIW PAC processors with distributed register files and method thereofUS8812285 *Aug 31, 2011Aug 19, 2014The Regents Of The University Of CaliforniaDesigning digital processors using a flexibility metricUS8918678Dec 12, 2013Dec 23, 2014International Business Machines CorporationFunctional testing of a processor designUS8938700 *Feb 7, 2013Jan 20, 2015Xilinx, Inc.Data-driven pattern matching in synthesis of circuit designsUS8965923Mar 5, 2012Feb 24, 2015Asurion, LlcMethod and apparatus for identifying and resolving conflicting data recordsUS8966416 *Mar 5, 2014Feb 24, 2015Cadence Design Systems, Inc.Finite-state machine encoding during design synthesisUS9003339Mar 7, 2014Apr 7, 2015Cadence Design Systems, Inc.Synthesis of clock gated circuitUS9043759 *Aug 9, 2011May 26, 2015Trimble Navigation LimitedSystem and method for generating software unit tests simultaneously with API documentationUS9235670 *Feb 18, 2014Jan 12, 2016CODASIP, s.r.o.Method and an apparatus for automatic generation of verification environment for processor design and verificationUS9268665Jul 26, 2011Feb 23, 2016Trimble Navigation LimitedSystem and method for identifying fault prone computer code filesUS9280442Aug 24, 2011Mar 8, 2016Trimble Navigation LimitedSystem and method for generating coverage reports for software unit testsUS20090113405 *Oct 8, 2008Apr 30, 2009Jose Teixeira De SousaReconfigurable coprocessor architecture template for nested loops and programming toolUS20090187788 *Jul 23, 2009International Business Machines CorporationMethod of automatic regression testingUS20090276742 *Nov 5, 2009John WilsonAutomating power domains in electronic design automationUS20100042977 *Feb 18, 2010International Business Machines CorporationSelective Execution of Trace Mechanisms for Applications Having Different Bit StructuresUS20100042983 *Aug 12, 2008Feb 18, 2010Sun Microsystems, Inc.Cross-isa inlining in a system virtual machineUS20100070951 *Mar 18, 2010Horizon Semiconductors Ltd.Generic assemblerUS20100115498 *Jan 13, 2010May 6, 2010Stmicroelectronics LimitedAdaptive production of assemblerUS20100223603 *Sep 2, 2010Sony Computer Entertainment Inc.Multiple stage program recompiler using information flow determinationUS20100269103 *Oct 21, 2010National Tsing Hua UniversityMethod and device for multi-core instruction-set simulationUS20110161932 *Jun 30, 2011Microsoft CorporationTechnologies for code failure proneness estimationUS20120017184 *Apr 15, 2009Jan 19, 2012Michiko TsukamotoSystem for creating layout pattern for manufacturing mask rom, mask rom manufactured using the system, and method for creating mask patternUS20120065956 *Aug 31, 2011Mar 15, 2012The Regents Of The University Of CaliforniaDigital processorsUS20120191441 *Jan 24, 2011Jul 26, 2012National Tsing Hua UniversityHigh-Parallelism Synchronization Approach for Multi-Core Instruction-Set SimulationUS20130061022 *Mar 7, 2013National Tsing Hua UniversityCompiler for providing intrinsic supports for vliw pac processors with distributed register files and method thereofUS20130191689 *Jan 20, 2012Jul 25, 2013International Business Machines CorporationFunctional testing of a processor designUS20140258947 *Mar 5, 2014Sep 11, 2014Cadence Design Systems, Inc.Finite-state machine encoding during design synthesisUS20150234966 *Feb 18, 2014Aug 20, 2015Codasip S.R.O.Method and an apparatus for automatic generation of verification environment for processor design and verificationUS20150301983 *Apr 22, 2015Oct 22, 2015Hyperion Core Inc.Optimization of loops and data flow sections in multi-core processor environment* Cited by examinerClassifications U.S. Classification716/100, 700/200, 717/140, 716/132, 717/139, 717/124, 716/133, 716/116, 700/220, 700/1, 716/117, 716/139International ClassificationG06F17/50Cooperative ClassificationG06F8/53, G06F8/41, G06F8/20, G06F17/5045, G06F2217/04, G06F2217/68European ClassificationG06F17/50DLegal EventsDateCodeEventDescriptionFeb 23, 2015FPAYFee paymentYear of fee payment: 4RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services