Source: http://www.google.com/patents/US6760888?dq=7,177,838
Timestamp: 2015-05-23 01:43:47
Document Index: 313442574

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

Patent US6760888 - Automated processor generation system for designing a configurable processor ... - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsAn 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/US6760888?utm_source=gb-gplus-sharePatent US6760888 - Automated processor generation system for designing a configurable processor and method for the sameAdvanced Patent SearchPublication numberUS6760888 B2Publication typeGrantApplication numberUS 10/286,496Publication dateJul 6, 2004Filing dateNov 1, 2002Priority dateFeb 5, 1999Fee statusPaidAlso published asUS6477683, US7020854, US8006204, US8875068, US8924898, US20030208723, US20040250231, US20060259878, US20080244471, US20080244506Publication number10286496, 286496, US 6760888 B2, US 6760888B2, US-B2-6760888, US6760888 B2, US6760888B2InventorsEarl 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, D{grave over (r)}or Eliezer MaydanOriginal AssigneeTensilica, Inc.Export CitationBiBTeX, EndNote, RefManPatent Citations (14), Non-Patent Citations (16), Referenced by (75), Classifications (14), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetAutomated processor generation system for designing a configurable processor and method for the same
US 6760888 B2Abstract
What is claimed is: 1. A computer-based method for creating a processor design: the processor design, when implemented in hardware as a processor, being adapted to execute an object code program, the method comprising the steps of:
accepting a configuration specification, the configuration specification including a base instruction set with a plurality of instructions and a plurality of extensible features, wherein at lease one of the plurality of extensible features is an additional instruction; generating a hardware implementation description of the processor design using the configuration specification; generating an assembler program, tailored to the configuration specification, for assembling the plurality of instructions into code executable by the processor; the assembler program capable of: accepting a symbolic representation of each of the plurality of instructions, and producing an object code representation of each of the plurality of instructions; generating an instruction set simulator program based upon the configuration specification, wherein the instruction set simulator program is adapted to accept and operate upon the plurality of instructions in a same manner as the processor; generating a debugger program, based upon the configuration specification, that is adapted to interoperate with the instruction set simulator program; evaluating performance of the hardware implementation description by running the object code program on the instruction set simulator program; and updating the configuration specification based upon the step of evaluating to created an updated configuration specification. 2. The method according to claim 1 further including the step of generating a profiler based upon the configuration specification, and
wherein the step of evaluating uses the profiler to collect information on time spent at certain ones of the instructions in the object code program. 3. The method according to claim 1 wherein the configuration specification accepted in the step of accepting includes a memory feature, and wherein one of the plurality of extensible features relates to the memory feature.
4. The method according to claim 3 wherein the one extensible feature that relates to the memory feature is whether to include cache memory.
5. The method according to claim 3 wherein the one extensible feature that relates to the memory feature is to select a cache memory size.
6. The method according to claim 1 wherein the configuration specification accepted in the step of accepting includes a memory feature, and wherein one of the plurality of extensible features relates to the memory feature.
7. The method according to claim 6 wherein the one extensible feature that relates to the memory feature is whether to include cache memory.
8. The method according to claim 6 wherein the one extensible feature that relates to the memory feature is to select a cache memory size.
This is a continuation of application Ser. No. 09/246,047 filed Feb. 5, 1999, now U.S. Pat. No. 6,477,683.
The present invention is directed to systems and techniques for designing programmable processing elements such as microprocessors and the like. More particularly, the invention is directed to the design of an application solution containing one or more processors where the processors in the system are configured and enhanced at the time of their design to improve their suitability to a particular application.
Then, given the chosen processor, ISA and foundry and the simulation, verification and development tools previously developed (as well as a standard cell library for the chosen foundry), an HDL implementation of the system is designed, a verification suite is developed for the system HDL implementation and the implementation is verified. Next, the system circuitry is synthesized, placed and routed on circuit boards, and the layout and timing are re-optimized. Finally, the boards are designed and laid out, the chips are fabricated and the boards are assembled.
In the communication channel application example, the protocol might require encryption, error-correction, or compression/decompression processing. Such processing often operates on individual bits rather than a processor's larger words. The circuitry for a computation may be rather modest, but the need for the processor to extract each bit, sequentially process it and then repack the bits adds considerable overhead. As a very specific example, consider a Huffman decode using the rules shown in TABLE I (a similar encoding is used in the MPEG compression standard). Both the value and the
length must be computed, so that length bits can be shifted off to find the start of the next element to be decoded in the stream.
Flexibility may be improved by configuration choices with finer gradation. The processor might, for example, allow the system designer to specify the number of registers in the register file, memory width, the cache size, cache associativity, etc. However, these options still do not reach the level of customizability desired by system designers. For example, in the above Huffman decoding example, although not known in the prior art the system designer might like to include a specific instruction to perform the decode, e.g.,
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 Lexra LX-4080 processor has a configurable variant of the standard MIPS architecture and has no software support for instruction set extensions. Its options include a custom engine interface which allows extension of MIPS ALU opcodes with application-specific operations; an internal hardware interface which includes a register source and a register or 16 bit-wide immediate source, and destination and stall signals; a simple memory management unit option; three MIPS coprocessor interfaces; a flexible local memory interface to cache, scratchpad RAM or ROM; a bus controller to connect peripheral functions and memories to the processor's own local bus; and a write buffer of configurable depth.
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 MUL/MAC 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.
The second category of prior art work in the area of configurable processor generation, i.e., automatic retargetting of compilers and assemblers) encompasses a rich area of academic research; see, e.g., Hanono et al., “Instruction Selection, Resource Allocation and Scheduling in the AVIV Retargetable Code Generator” (representation of machine instructions used for automatic creation of code generators); Fauth et al., “Describing Instruction Set Processors Using nML”; Ramsey et al., “Machine Descriptions to Build Tools for Embedded Systems”; Aho et al, “Code Generation Using Tree Matching and Dynamic Programming” (algorithms to match up transformations associated with each machine instruction, e.g., add, load, store, branch, etc., with a sequence of program operations represented by some machine-independent intermediate form using methods such as pattern matching); and Cattell, “Formalization and Automatic Derivation of Code Generators” (abstract descriptions of machine architectures used for compiler research).
Along with these software aspects of the process, the system attends to hardware aspects by developing a configurable processor. Then, using system goals such as cost, performance, power and functionality and information on available processor fabs, the system designs an overall system architecture which takes configurable ISA options, extensions and processor feature selection into account. Using the overall system architecture, development software, simulator, configurable instruction set architecture and processor HDL implementation, the processor ISA, HDL implementation, software and simulator are configured by the system and system HDL is designed for system-on-a-chip designs. Also, based on the system architecture and specifications of chip foundries, a chip foundry is chosen based on an evaluation of foundry capabilities with respect to the system HDL (not related to processor selection as in the prior art). Finally, using the foundry's standard cell library, the configuration system synthesizes circuitry, places and routes it, and provides the ability to re-optimize the layout and timing. Then, circuit board layouts are designed if the design is not of the single-chip type, chips are fabricated, and the boards are assembled.
The second technique is to provide a single description of the changes and automatically generate the modifications or extensions to all affected components. Processors designed with prior art techniques have not done this because it is often cheaper to do something once manually than to write a tool to do it automatically and use the tool once. The advantage of automation applies when the task is repeated many times.
All of the techniques above are employed to add application-specific instructions. The input is constrained to input and output operands and the logic to evaluate them. The changes are described in one place and all hardware and software modifications are derived from that description. This facility shows how a single input can be used to enhance multiple components.
FIGS. 14 and 15 are diagrams showing the addition of user-defined functional units in the architecture of FIG. 8.
In the preferred embodiment, the basis for processor configuration is the architecture 60 shown in FIG. 2. A number of elements of the architecture are basic features which cannot be directly modified by the user. These include the processor controls section 62, the align and decode section 64 (although parts of this section are based on the user-specified configuration), the ALU and address generation section 66, the branch logic and instruction fetch, 68 and the processor interface 70. Other units are part of the basic processor but are user-configurable. These include the interrupt control section 72, the data and instruction address watch sections 74 and 76, the window register file 78, the data and instruction cache and tags sections 80, the write buffers 82 and the timers 84. The remaining sections shown in FIG. 2 are optionally included by the user.
Creating a new configuration or editing an existing one brings up the configuration editor 88 shown in FIG. 4. The configuration editor 88 has an “Options” section menu on the left showing the various general aspects of the processor 60 which can be configured and extended. When an option section is selected, a screen with the configuration options for that section appears on the right, and these options can be set with pull-down menus, memo boxes, check boxes, radio buttons and the like as is known in the art. Although the user can select options and enter data at random, preferably data is entered into each sequentially, since there are logical dependencies between the sections; for example, to properly display options in the “Interrupts” section, the number of interrupts must have been chosen in the “ISA Options” section.
Target ASIC technology: 0.18, 0.25, 0.35 micron
Target operating condition: typical, worst-case
Target speed: arbitrary
Gate count: arbitrary
Target power: arbitrary
Goal prioritization: speed, area power; speed, power, area
MAC16 with 40-bit accumulator: yes, no
16-bit multiplier: yes, no
Number of interrupts: 0-32
High priority interrupt levels: 0-14
Enable Debugging: yes, no
Number of Timers: 0-3
Byte Ordering: little endian, big endian
Number of registers available for call windows: 32, 64
Processor interface read width (bits): 32, 64, 128
Write-buffer entries (address/value pairs): 4, 8, 16, 32
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
Vector and address calculation method: XTOS, manual
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
Verilog™: yes, no
Design Compiler™: yes, no
From the above, one can see that the automated processor configuration system 10 provides two broad types of configurability 300 to the user as shown in FIG. 5: extensibility 302, which permits the user to define arbitrary functions and structures from scratch, and modifiability 304, which permits the user to select from a predetermined, constrained set of options. Within modifiability the system permits binary selection 306 of certain features, e.g., whether a MAC16 or a DSP should be added to the processor 60) and parametric specification 308 of other processor features, e.g., number of interrupts and cache size.
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.
The MAC16 with 40-bit accumulator option (shown at 90 in FIG. 2) adds a 16-bit multiplier/add function with a 40-bit accumulator, eight 16-bit operand registers and a set of compound instructions that combine multiply, accumulate, operand load and address update instructions. The operand registers can be loaded with pairs of 16-bit values from memory in parallel with multiply/accumulate operations. This unit can sustain algorithms with two loads and a multiply/accumulate per cycle.
Up to three 32-bit counter/timers 84 may be configured. This entails the use of a 32-bit register which increments each clock cycle, as well as (for each configured timer) a compare register and a comparator which compares the compare register contents with the current clocked register count, for use with interrupts and similar features. The counter/timers can be configured as edge-triggered and can generate normal or high-priority internal interrupts.
Perhaps most significantly among the configuration options are the TIE instruction definitions from which the designer-defined instruction execution unit 96 is built. The TIE™ (Tensilica Instruction Set Extensions) language developed by Tensilica Corporation of Santa Clara, Calif. allows the user to describe custom functions for his applications in the form of extensions and new instructions to augment the base ISA. Additionally, due to TIE's flexibility it may be used to describe portions of the ISA which cannot be changed by the user; in this way, the entire ISA can be used to generate the software development tools 30 and hardware implementation description 40 uniformly. A TIE description uses a number of building blocks to delineate the attributes of new instructions as follows:
inst[11:8]
inst[15:12]
op2 = 4′b0000
op2 = 4′b0001
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
inst[3:0]
inst[19:16]
inst[23:20]
inst[23:0]=0000 0110 xxxx xxxx xxxx 0000
inst[23:0]=0001 0110 xxxx xxxx xxxx 0000
inst[23:6]
offset = t[17:0];
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 offsets4 constant shifted to the right, and the second assign statement specifies that the lower eighteen bits oft are put into the offset field. The very first assign statement directly specifies the value of the offsets4 operand as a concatenation of offset and fourteen replications of its sign bit (bit 17) followed by a shift-left of two bits.
prime_s
prime_s == prime[0]
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;
{assign art = AR[t];} { }
{assign ars = AR{s};} { }
{assign AR[r] = arr;} { }
{adsel, acs} {out arr, in art, in ars}
For example, TIE code defining a new instruction ADD8—4 which performs additions of four 8-bit operands in a 32-bit word with respective 8-bit operands in another 32-bit word and a new instruction MIN16—2 which performs minimum selections between two 16-bit operands in a 32-bit word and respective 16-bit operands in another 32-bit word might read:
opcode ADD8_4 op2=4'b0000 CUST0
opcode MIN16_2 op2=4'b0001 CUST0
iclass add_min {ADD8_4, MIN16_2} {out arr, in ars, in
semantic add_min {ADD8_4, MIN16_2} {
assign min1 = art[31:16] < ars[31:16] ? art[31:16] :
ars[31:16];
assign min0 = art[15:0] < ars[15:0] ? art[15:0] :
ars[15:0];
assign min = {min1, min0};
assign arr = (({32{{ADD8_4}}}) & (add)) | (({32{{MIN16_2}}})
& (min));
IsaUseDebug
IsaUseInterrupt
IsaUseHighPriorityInterrupt
IsaUseException
indicates that the processor will include the on-chip debugging module 92, interrupt facilities 72 and exception handling, but not high-priority interrupt facilities.
A very different sort of algorithm for determining the configuration from goals and the design database is based on simulated annealing. A random initial set of parameters is used as the starting point, and then changes of individual parameters are accepted or rejected by evaluating a global utility function. Improvements in the utility function are always accepted while negative changes are accepted probabilistically based on a threshold that declines as the optimization proceeds. In this system the utility function is constructed from the input goals. For example, given the goals Performance>200, Power<100, Area<4, with the priority of Power, Area, and Performance, the following utility function could be used: Max  ( ( 1 - Power / 100 ) * 0.5 , 0 ) + ( max  ( ( 1 - Area / 4 ) * 0.3 , 0 ) * ( if   Power < 100   then   1   else   ( 1 - Power / 100 ) ** 2 ) ) + ( max  ( Performance / 200 * 0.2 , 0 ) * ( if   Power < 100   then   1   else   ( 1 - Power / 100 ) ** 2 ) ) * ( if   Area < 4   then   1   else   ( 1 - area / 4 ) ** 2 ) ) which rewards decreases in power consumption until it is below 100 and then is neutral, rewards decreases in area until it is below 4, and then is neutral, and rewards increases in performance until it is above 200, and then is neutral. There are also components that reduce the area usage when power is out of spec and that reduce the performance usage when power or area are out of spec.
In addition to selecting preconfigured characteristics of the processors 60, the search algorithms can also be used to automatically select or suggest to the users possible TIE extensions. Given the input goals and given examples of user programs written perhaps in the C programming language, these algorithms would suggest potential TIE extensions. For TIE extensions without state, compiler-like tools can be embodied with pattern matchers. These pattern matchers walk expression nodes in a bottom up fashion searching for multiple instruction patterns that could be replaced with a single instruction. For example, say that the user C program contains the following statements.
Similar but more powerful algorithms are used to discover potential TIE instructions with state. Several different algorithms are used to detect different types of opportunities. One algorithm uses a compiler-like tool to scan the user program and detect if the user program requires more registers than are available on the hardware. As known to practitioners in the art, this can be detected by counting the number of register spills and restores in the compiled version of the user code. The compiler-like tool suggests to the search engine a coprocessor with additional hardware registers 98 but supporting only the operations used in the portions of the user's code that has many spills and restores. The tool is responsible for informing the database used by the search engine 106 of an estimate of the hardware cost of the coprocessor as well as an estimate of how the user's algorithm performance is improved. The search engine 106, as described before, makes a global decision of whether or not the suggested coprocessor 98 leads to a better configuration.
Alternatively or in conjunction therewith, a compiler-like tool checks if the user program uses bit-mask operations to insure that certain variables are never larger than certain limits. In this situation, the tool suggests to the search engine 106 a co-processor 98 using data types conforming to the user limits (for example, 12 bit or 20 bit or any other size integers). In a third algorithm used in another embodiment, used for user programs in C++, a compiler-like tool discovers that much time is spent operating on user defined abstract data types. If all the operations on the data type are suitable for TIE, the algorithm proposes to the search engine 106 implementing all the operations on the data type with a TIE coprocessor.
opcode NAME FIELD=VALUE
assign NAME=FIELD==VALUE;
opcode NAME FIELD=VALUE PARENTNAME [FIELD2=VALUE2]
assign NAME=PARENTNAME & (FIELD==VALUE)
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.
To generate other processor features, the preferred embodiment uses a Verilog™ description of the configurable processor 60 enhanced with a Perl-based preprocessor language. Perl is a full-featured language including complex control structures, subroutines, and I/O facilities. The preprocessor, which in a preferred embodiment of the present invention is called TPP (as shown in the source listing in Appendix B, TPP is itself a Perl program), scans its input, identifies certain lines as preprocessor code (those prefixed by a semicolon for TPP) written in the preprocessor language (Perl for TPP), and constructs a program consisting of the extracted lines and statements to generate the text of the other lines. The non-preprocessor lines may have embedded expressions in whose place expressions generated as a result of the TPP processing are substituted. The resultant program is then executed to produce the source code, i.e., Verilog™ code for describing the detailed processor logic 40 (as will be seen below, TPP is also used to configure the software development tools 30).
When used in this context, TPP is a powerful preprocessing language because it permits the inclusion of constructs such as configuration specification queries, conditional expressions and iterative structures in the Verilog™ code, as well as implementing embedded expressions dependent on the configuration specification 100 in the Verilog™ code as noted above. For example, a TPP assignment based on a database query might look like
; $endian=config_get_value (“IsaMemoryOrder”)
if (config_get_value(“IsaMemoryOrder”) eq “LittleEndian”)
{do Verilog ™ code for little endian ordering}
{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).
wire [‘$ninterrupts-1’:0] srInterruptEn;
xtscenflop #(‘$ninterrupts’) srintrenreg (srInterruptEn,
srDataIn_W[‘$ninterrupts-1’:0], srIntrEnWEn,!cReset,CLK);
$ninterrupts defines the number of interrupts and determines the width (in terms of bits) of the xtscenflop module (a flip-flop primitive module);
srInterruptEn is the output of the flip-flop, defined to be a wire of appropriate number of bits;
srDataIn_W is the input to the flip-flop, but only relevant bits are input based on number of interrupts;
srIntrEnWEn is the write enable of the flip-flop;
cReset is the clear input to the flip-flop; and
CLK is the input clock to the flip-flop.
; # 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 clrCCompIntr‘$i’ = ccompWEn‘$i’;
; } ## IsaUseTimer
and the declarations
$IsaUseTimer = 1
$TimerNumber = 2
$width = 32
TPP generates
wire [31:0] srCCount;
xtflop #(32) srccntreg (srCCount, (ccountWEn ? srDataIn_W :
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 clrCCompIntr0 = ccompWEn0;
wire [31:0] srCCompare1;
wire ccompWEn1;
assign ccompWEn1 = srWEn_W && (srWrAdr_W == ‘SRCCOMPARE1);
xtenflop #(32) srccmplreg (srCCompare1, srDataIn_W, ccompWEn1, CLK);
assign setCCompIntr1 = (srCCompare1 == srCCount);
assign clrCCompIntr1 = 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.
Scripts are used in other phases of processor configuration as well. For example, once the HDL model of the processor 60 has been written, a simulator can be used to verify the correct operation of the processor 60 as described above in connection with block 132. This is often accomplished by running many test programs, or diagnostics, on the simulated processor 60. Running a test program on the simulated processor 60 can require many steps such as generating an executable image of the test program, generating a representation of this executable image which can be read by the simulator 112, creating a temporary place where the results of the simulation can be gathered for future analysis, analyzing the results of the simulation, and so on. In the prior art this was done with a number of throw-away scripts. These scripts had some built-in knowledge of the simulation environment, such as which HDL files should be included, where those files could be found in the directory structure, which files are required for the test bench, and so on. In the current design the preferred mechanism is to write a script template which is configured by parameter substitution. The configuration mechanism also uses TPP to generate a list of the files that are required for simulation.
Furthermore, in the verification process of block 132 it is often necessary to write other scripts which allow designers to run a series of test programs. This is often used to run regression suites that give a designer confidence that a given change in the HDL model does not introduce new bugs. These regression scripts were also often throw-away as they had many built-in assumptions about files names, locations, etc. As described above for the creation of a run script for a single test program the regression script is written as a template. This template is configured by substituting parameters for actual values at configuration time.
Even more sophisticated scripts can be used that allow for example a more sophisticated clock tree. One common optimization done to reduce power dissipation is to gate the clock signal. However, this makes clock tree synthesis a much harder problem since it is more difficult to balance the delay of all branches. The configuration interface could ask the user for the correct cells to use for the clock tree and the perform part, or all, of the clock tree synthesis. It would do this by having some knowledge of where the gated clocks are located in the design and estimating the delay form the qualifying gate to the clock input of the flip-flops. It would than give a constraint to the clock tree synthesis tool to match the delay of the clock buffer with the delay of the gating cells. In the current implementation this is done by a general purpose Perl script. This script reads gated clock information produced by the configuration agent based on which options are selected. The Perl script is run once the design has been placed and routed but before final clock tree synthesis is done.
The first step in this process is to partition the set of all configuration options into groups of orthogonal options such that effect of an option in a group on the hardware profile is independent of options in any other group. For example, the impact of MAC16 unit to the hardware profile is independent of any other options. So, an option group with only the MAC16 option is formed. A more complicated example is an option group containing interrupt options, high-level interrupt options and timer options, since the impact on the hardware profile is determined by the particular combination of these options.
The quick evaluation system can be easily extended to provide the user with suggestions on how to modify a configuration to further optimize the processor. One such example is to associate each configuration option with a set of numbers representing the incremental impact of the option on various cost metrics such as area, delay and power. Computing the incremental cost impact for a given option is made easy with the quick evaluation system. It simply involves two calls to the evaluation system, with and without the option. The difference in the costs for the two evaluations represents the incremental impact of the option. For example, the incremental area impact of the MAC16 option is computed by evaluating the area cost of two configurations, with and without the MAC16 option. The difference is then displayed with the MAC16 option in the interactive configuration system. Such a system can guide the user toward an optimal solution through a series of single-step improvements.
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 library also provides a function to decode the opcode in a binary instruction (decodeInstruction). This function is generated as a sequence of nested switch statements, where the outermost switch tests the subopcode field at the top of the opcode hierarchy, and the nested switch statements test the subopcode fields progressively lower in the opcode hierarchy. The generated code for this function thus has the same structure as the opcode hierarchy itself.
AssembleInstruction (String mnemonic, int arguments[ ])
opcode = stringToOpcode (mnemonic);
for i = 0, numArgs-1 do
instructionAddress += instructionLength (opcode);
if (i != 0) print “,”; // Comma separate operands
Preferably, the system also configures a verification suite for the configured processor 60. Most verification of complex designs like microprocessors consists of a flow as follows:
This example uses two matrices, OldB and NewB, to respectively represent the old and new images. The size of the image is determined by NX and NY. The block size is determined by BLOCKX and BLOCKY. Therefore, the image is composed of NX/BLOCKX by NY/BLOCKY blocks. The search region around a block is determined by SEARCHX and SEARCHY. The best motion vectors and values are stored in VectX, VectY, and VectB. The best motion vectors and values computed by the base (reference) implementation are stored in BaseX, BaseY, and BaseB. These values are used to check against the vectors computed by the implementation using instruction extensions. These basic definitions are captured in the following C-code segment:
unsigned short VectX[NX/BLOCKX]
[NY/BLOCKY];
unsigned short VectY[NX/BLOCKX]
unsigned short VectB[NX/BLOCKX]
unsigned short BaseX[NX/BLOCKX]
unsigned short BaseY[NX/BLOCKX]
/* Base Y motion
unsigned short BaseB[NX/BLOCKX]
#define MIN(x,y)
#define MAX(x,y)
Reference software implementation
motion_estimate_base( )
int bx, by, cx, cy, x, y;
unsigned diff, best, bestx, besty;
endx = MIN(NX-BLOCKX, bx*BLOCKX + SEARCHX);
endy = MIN(NY-BLOCKY, by*BLOCKY + SEARCHY);
for(cy = starty; cy < endy; cy++) {
for(y = 0; y < BLOCKY; y++) {
diff += ABSD(OldB[cx+x] [cy+y],
NewB[bx*BLOCKX+x]
[by*BLOCKY+y]);
if (diff < best) {
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.
The presence of this instruction allows such improvement in the inner loop pixel difference computation that loop unrolling becomes attractive as well. The C code for the inner loop is rewritten to take advantage of the new sum-of-absolute-differences instruction and the efficient shifting. Part of four overlapping blocks of the reference image can then be compared in the same loop. SAD(x, y) is the new intrinsic function corresponding to the added instruction. SRC(x, y) performs a right shift of the concatenation of x and y by the shift amount stored in the SAR register.
unsigned *N, N1, N2, N3, N4, *O, A,B,C,D,E;
endy = MIN (NY-BLOCKY, by*BLOCKY + SEARCHY);
for(cy = starty; cy < endy; cy += sizeof (long)) {
N = (unsigned *) & (NewB [bx*BLOCKX+x]
D = O[3];
E = O[4];
diff0 += SAD (A, N1) + SAD(B, N2) +
SAD(C, N3) + SAD(D, N4);
SSAI(8);
printf(“Block = (%d,%d), Search = (%d,%d), size = (%d,%d)\n”,
motion_estimate_base( );
motion_estimate_tie( );
opcode SAD op2 = 4'b0000 CUST0
iclass sad {SAD} {out arr, in ars, in art}
semantic sad_logic {SAD} {
wire [7:0] diff0r, diff1r, diff2r, diff3r;
assign diff0r = ars[7:0] − art[7:0];
It is easy to see that QRST is the top-level opcode. CUST0 is a sub-opcode of QRST and SAD in turn is 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.
Block = (16,16), Search = (4,4), size = (32,32)
( 100.00 ) Unconditional taken branches
( 0.20 )
( 16.44 ) Taken
( 11.92 ) Not taken
( 4.51 )
( 6.84 )
( 5.33 )
( 1.51 )
( 0.04 )
From the two reports one can see that roughly a 4�speedup has occurred. Notice that the 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,DO2)
; $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 = {
RdData‘$i‘,
wire [‘$B1‘*8-1:0] DO1 =
Wide1?RdData:RdData[(Lane+1)*B1*8-1:Lane*B1*8];
wire [‘$B2‘*8-1:0] DO2 =
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.
FIG. 12 shows another example of implementation of a user-defined unit under this system. The functional unit shown in the Figure, an {fraction (8/16)} parallel data unit extension of the ALU, is generated from the following ISA code:
op2 = 0000
MIN16_2
op2 = 0001
op2 = 0002
4ADD8,2MIN16,SHIFT16_2
;a<t,a<s,a>t
input ADD8_4, MIN16_2, SHIFT16_2;
assign add = {art[31:24] + ars[31:24], art[23:16] + art[23:16], art[15:8]
+ art[15:8], art[7:0] + art[7:0]};
assign min[31:16] = art[31:16] < ars[31:16] ? Art[31:16] : ars [31:16];
assign arr = {32{ADD8_4}} & add | {32{MIN16_2}} & min | {32{SHIFT16_2}} &
Modifications and variations of the preferred embodiment will be readily apparent to those skilled in the art. Such variations are within the scope of the present invention as defined by the appended claims. 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 methodsUS5748875Jun 12, 1996May 5, 1998Simpod, Inc.Digital logic simulation/emulation systemUS5819050Feb 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 thereofUS5870588Oct 23, 1996Feb 9, 1999Interuniversitair Micro-Elektronica Centrum(Imec Vzw)Design environment and a design method for hardware/software co-designUS5896521Oct 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 simulationUS5999734Oct 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 methodUS6182206Feb 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 devicesUS6477683 *Feb 5, 1999Nov 5, 2002Tensilica, Inc.Automated processor generation system for designing a configurable processor and method for the sameEP0743599A2Apr 1, 1996Nov 20, 1996Interuniversitair Micro-Elektronica Centrum VzwMethod of generating code for programmable processor, code generator and application thereof* Cited by examinerNon-Patent CitationsReference1Fauth et al. Describing instruction set processos using nML (Proc. Euro. Design & Test Conf. Paris Mar. 1995, IEEE 1995, 5 pp.).2Fauth et al., "Describing Instruction Set Processors Using nML," ED&TC 1995, Proceedings, Paris, France Mar. 6-9, 1995, Los Alamitos, CA, USA, IEEE Comput. Soc. US, Mar. 6, 1995, pp. 503-507.3Fauth et al., "Generation of Hardware Machine Models from Instruction Set Descriptions," VLSI Signal Processing, VI, 1993, Workshop on Veldhoven, Netherlands, Oct. 20-22, 1993, New York, NY, USA, IEEE, Oct. 20, 1993, pp. 242-250.4Freericks, "The nML Machine Description Formalism" (Bericht 1991/15 pp. 3-41).5Hadjiyiannis et al., "ISDL: An Instruction Set Description Language for Retargetability," DAC '97, Anaheim California, 1997 ACM 0-89791-920-3/97/06.6Hartoog et al. "Generation of Software Tools from Processor Descriptions for Hardware/Software Codesign" (ACM, Jun. 1997, pp. 303-306.7Hartoog et al., "Generation of Software Tools from Processor Descriptions for Hardware/Software Codesign," Proceedings of the Design Automation Conference, Anahelm, CA, USA, Jun 9-13, 1997, pp. 303-306.8Internet Publication http://www.lexra.com/product.html (11 pp. undated).9Internet Publication http://www.retarget.com/brfchschk.html (19 pp. undated).10Internet Publication http://www.risccores.com/html/body_aboutarc.htm (13 pp. undated).11Internet Publication http://www.synopsys.com/oruducts/designware/dwpci_ds.html (16 pp. undated).12Internet Publication http://www.synopsys.com/products/designware/8051_ds.html (8pp. undated).13Leupers et al., "Retargetable Code Generation Based on Structural Processor Descriptions," Design Automation for Embedded Systems, vol. 3, No. 1, Jan. 1998, pp. 1-36.14Tensilica "Xtensa" Instruction Set Architecture (ISA) Ref. Manual. Rev. 1.0, Tensilica, Inc.15Zivojnovic et al., "DSP Processor/Compiler Co-Design: A Quantitative Approach," 9<th >Int'l Smposium on System Synthesis (ISSS'96), Nov. 06-08, 1996, San Diego, California.16Zivojnovic et al., "DSP Processor/Compiler Co-Design: A Quantitative Approach," 9th Int'l Smposium on System Synthesis (ISSS'96), Nov. 06-08, 1996, San Diego, California.Referenced byCiting PatentFiling datePublication dateApplicantTitleUS6928638 *Aug 7, 2001Aug 9, 2005Intel CorporationTool for generating a re-generative functional testUS6931612 *May 15, 2002Aug 16, 2005Lsi Logic CorporationDesign and optimization methods for integrated circuitsUS6981232 *May 23, 2003Dec 27, 2005Xilinx, Inc.Method and system for integrating a program and a processor into an application specific processorUS7051189Mar 14, 2001May 23, 2006Arc InternationalMethod and apparatus for processor code optimization using code compressionUS7062724 *Dec 27, 2002Jun 13, 2006Nec Electronics CorporationMethod for designing a system LSIUS7076770 *Jan 20, 2004Jul 11, 2006Computer Associates Think, Inc.Apparatus and method for modifying a kernel module to run on multiple kernel versionsUS7096461 *Nov 17, 2000Aug 22, 2006Sony CorporationMethod and apparatus for digital signal processing and method of providing extension functionUS7155690 *Jan 30, 2004Dec 26, 2006Seiko Epson CorporationMethod for co-verifying hardware and software for a semiconductor deviceUS7188331 *Oct 14, 2003Mar 6, 2007Hewlett-Packard Development Company, L.P.Firmware development within a framework from different design centers depositing component(s) with related contextual and genealogy information in an accessible repositoryUS7237234 *Dec 12, 2002Jun 26, 2007Texas Instruments IncorporatedMethod for selective solicitation of user assistance in the performance tuning processUS7277902 *Apr 18, 2005Oct 2, 2007Altera CorporationMethod and apparatus for comparing and synchronizing programmable logic device user configuration dataset versionsUS7278137Dec 26, 2002Oct 2, 2007Arc InternationalMethods and apparatus for compiling instructions for a data processorUS7302670Dec 5, 2002Nov 27, 2007Bryan Darrell BowyerInteractive interface resource allocation in a behavioral synthesis toolUS7305332 *Jan 14, 2004Dec 4, 2007Adaptec, Inc.System and method for automatic extraction of testing information from a functional specificationUS7310787 *Mar 7, 2003Dec 18, 2007Shiv PrakashArray transformation in a behavioral synthesis toolUS7334201 *Jul 2, 2004Feb 19, 2008Tensilica, Inc.Method and apparatus to measure hardware cost of adding complex instruction extensions to a processorUS7353163 *Apr 6, 2001Apr 1, 2008Transitive LimitedException handling method and apparatus for use in program code conversionUS7363097 *Mar 27, 2006Apr 22, 2008Kabushiki Kaisha ToshibaAutomatic design apparatus, automatic design method, and automatic design program of digital circuitUS7373631 *Aug 11, 2004May 13, 2008Altera CorporationMethods of producing application-specific integrated circuit equivalents of programmable logicUS7415700 *Oct 14, 2003Aug 19, 2008Hewlett-Packard Development Company, L.P.Runtime quality verification of execution unitsUS7444610 *Aug 3, 2005Oct 28, 2008Xilinx, Inc.Visualizing hardware cost in high level modeling systemsUS7451070Apr 8, 2005Nov 11, 2008International Business MachinesOptimal bus operation performance in a logic simulation environmentUS7475000Apr 25, 2003Jan 6, 2009Arc International, PlcApparatus and method for managing integrated circuit designsUS7478351May 1, 2006Jan 13, 2009Nec Electronics CorporationDesigning system and method for designing a system LSIUS7493470Dec 6, 2002Feb 17, 2009Arc International, PlcProcessor apparatus and methods optimized for control applicationsUS7500228 *Mar 16, 2004Mar 3, 2009Agere Systems Inc.System and method for automatically generating a hierarchical register consolidation structureUS7502725 *Apr 29, 2004Mar 10, 2009International Business Machines CorporationMethod, system and computer program product for register management in a simulation environmentUS7506279 *Aug 19, 2004Mar 17, 2009Ricoh Company, LtdDesign supporting apparatus capable of checking functional description of large-scale integrated circuit to detect fault in said circuitUS7529764 *Jan 12, 2004May 5, 2009Hitachi Global Storage Technologies Netherlands B.V.GUI for data pipelineUS7584460 *Dec 1, 2003Sep 1, 2009Lsi CorporationProcess and apparatus for abstracting IC design filesUS7613599 *Jun 1, 2001Nov 3, 2009Synopsys, Inc.Method and system for virtual prototypingUS7617012 *Feb 25, 2005Nov 10, 2009Yamaha CorporationAudio signal processing systemUS7673117 *Jan 30, 2006Mar 2, 2010Sony CorporationOperation apparatusUS7676784Oct 21, 2005Mar 9, 2010Altera CorporationMethods and apparatus for implementing parameterizable processors and peripheralsUS7711933Apr 9, 2007May 4, 2010Xilinx, Inc.Exploiting unused configuration memory cellsUS7720669Jun 30, 2008May 18, 2010International Business Machines CorporationMethod, system and computer program product for register management in a simulation environmentUS7735050Jun 13, 2006Jun 8, 2010Henry YuManaging and controlling the use of hardware resources on integrated circuitsUS7756973Apr 27, 2006Jul 13, 2010International Business Machines CorporationIdentifying a configuration for an application in a production environmentUS7765018 *Jun 28, 2005Jul 27, 2010Yamaha CorporationControl device for controlling audio signal processing deviceUS7774768May 22, 2006Aug 10, 2010Arc International, PlcMethod and apparatus for processor code optimization using code compressionUS7805690Oct 1, 2007Sep 28, 2010Ftl Systems, Inc.Method for generating compiler, simulation, synthesis and test suite from a common processor specificationUS7831938Nov 21, 2007Nov 9, 2010Mentor Graphics CorporationInteractive interface resource allocation in a behavioral synthesis toolUS7886255 *Jan 22, 2008Feb 8, 2011Texas Instruments IncorporatedMethod for design of programmable data processorsUS7913217Sep 18, 2008Mar 22, 2011Xilinx, Inc.Visualizing hardware cost in high level modeling systemsUS7941771Jun 4, 2008May 10, 2011Bull S.A.Method for functional verification of an integrated circuit model for constituting a verification platform, equipment emulator and verification platformUS7970596Sep 24, 2009Jun 28, 2011Synopsys, Inc.Method and system for virtual prototypingUS7971132Jan 5, 2007Jun 28, 2011Dialogic CorporationUniversal multimedia engine and method for producing the sameUS7996801 *Aug 8, 2008Aug 9, 2011International Business Machines CorporationMethods and systems for on-the-fly chip verificationUS8006069 *Oct 5, 2007Aug 23, 2011Synopsys, Inc.Inter-processor communication methodUS8009176Apr 5, 2011Aug 30, 2011Apple Inc.System and method for processing graphics operations with graphics processing unitUS8037434Aug 20, 2007Oct 11, 2011Altera CorporationMethods and apparatus for implementing parameterizable processors and peripheralsUS8040353Oct 15, 2010Oct 18, 2011Apple Inc.System for emulating graphics operationsUS8040359Oct 15, 2010Oct 18, 2011Apple Inc.System for emulating graphics operationsUS8044963Oct 15, 2010Oct 25, 2011Apple Inc.System for emulating graphics operationsUS8091056 *May 29, 2009Jan 3, 2012Xilinx, Inc.Apparatus and method for automated determination of timing constraintsUS8132132Mar 10, 2006Mar 6, 2012Altera CorporationMethods and apparatus for implementing parameterizable processors and peripheralsUS8134561Apr 16, 2004Mar 13, 2012Apple Inc.System for optimizing graphics operationsUS8140314Aug 14, 2008Mar 20, 2012International Business Machines CorporationOptimal bus operation performance in a logic simulation environmentUS8144159May 19, 2011Mar 27, 2012Apple Inc.Partial display updates in a windowing system using a programmable graphics processing unitUS8156455Oct 21, 2005Apr 10, 2012Altera CorporatonMethods and apparatus for implementing parameterizable processors and peripheralsUS8166450Oct 1, 2007Apr 24, 2012Synopsys, Inc.Methods and apparatus for compiling instructions for a data processorUS8286108 *Dec 31, 2009Oct 9, 2012Cadence Design Systems, Inc.System and method for synthesis reuseUS8326448 *Nov 10, 2008Dec 4, 2012Siemens AktiengesellschaftMethod and device for operating a machine toolUS8386972Dec 16, 2009Feb 26, 2013Synopsys, Inc.Method and apparatus for managing the configuration and functionality of a semiconductor designUS8446416Feb 11, 2011May 21, 2013Apple Inc.System for optimizing graphics operationsUS8462850 *Jan 20, 2005Jun 11, 2013Qualcomm IncorporatedMotion estimation in video compression systemsUS8464235 *Jan 13, 2010Jun 11, 2013Stmicroelectronics Ltd.Adaptive production of assemblerUS8520021Jul 13, 2011Aug 27, 2013Apple Inc.System and method for processing graphics operations with graphics processing unitUS8704837Apr 16, 2004Apr 22, 2014Apple Inc.High-level program interface for graphics operationsUS8726204Jun 3, 2010May 13, 2014Mentor Graphics CorporationManaging and controlling the use of hardware resources on integrated circuitsUS8910103 *Dec 28, 2009Dec 9, 2014Stmicroelectronics S.R.L.Method of designing a high performance application specific integrated circuit acceleratorUS20060002473 *Jan 20, 2005Jan 5, 2006Sumit MohanMotion estimation in video compression systemsUS20100115498 *Jan 13, 2010May 6, 2010Stmicroelectronics LimitedAdaptive production of assemblerUS20100162189 *Dec 31, 2009Jun 24, 2010Cadence Design Systems, Inc.System and method for synthesis reuseUS20100169857 *Dec 28, 2009Jul 1, 2010Stmicroelectronics S.R.I.Method for designing a high performance asic (application-specific integrated circuit) accelerator* Cited by examinerClassifications U.S. Classification716/102, 712/200, 712/36, 712/35, 712/32, 712/1, 716/104, 716/106, 716/117International ClassificationG06F17/50Cooperative ClassificationG06F17/5045, G06F2217/04, G06F2217/68European ClassificationG06F17/50DLegal EventsDateCodeEventDescriptionJan 6, 2012FPAYFee paymentYear of fee payment: 8Jan 14, 2008REMIMaintenance fee reminder mailedJan 7, 2008FPAYFee paymentYear of fee payment: 4Sep 12, 2006CCCertificate of correctionRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services