CN1382280B - Automatic processor generation system and method for designing configurable processors - Google Patents

Abstract

A configurable RISC processor implements a user-defined instruction set with high-performance fixed and variable length coding. The process of defining new instruction sets is supported by various tools that allow users to add new instructions and quickly evaluate them to maintain and switch between instruction sets. A standardized language is used to develop configurable definitions of target instruction sets and HDL descriptions of the hardware needed to implement the instruction sets, as well as various development tools for validation and application development, thereby achieving a high degree of automation in the design process.

Description

Automatic processor generation system and method for designing configurable processors

Background of the invention

1. Field of invention

The present invention relates to microprocessor systems, and more particularly, the present invention relates to the design of an application solution containing one or more processors, where the processors in the system are programmed during their design such that Configure and enhance to improve their suitability for a particular application. The present invention is also directed to a system in which application developers can rapidly develop instruction extensions, such as new instructions, including new instructions to control user-defined processor states, based on existing instruction set architectures, And immediately measure the impact of such extensions on application runtime as well as on processor cycle time.

2. Description of related technologies

Traditionally, designing and modifying processors has been difficult. For this reason, most systems containing processors use those (solutions) that are designed and proven once for general use, and then carried over to multiple applications. As such, their suitability for a particular application is not always ideal. It is often desirable to modify the processor to better execute the code of a particular application (eg, to run faster, consume less power, or cost less). However, even modifying the design of an existing processor is difficult, and thus time, cost, and risky, so high that it is typically not done.

To better understand the difficulties encountered in making a prior art processor configurable, let's consider its development. First, to develop its instruction set architecture (ISA). In essence, after this step is done once, it will be used by many systems for decades. For example, the instruction set used by the Intel Pentium ^(TM) processor may be a legacy of the 8008 and 8080 microprocessors introduced back in the mid-1970's. In this process, based on predetermined ISA design specifications, each ISA instruction, syntax, etc. are developed, and software development tools for the ISA, such as assembler, debugger, compiler, etc., are also developed. Subsequently, a simulation program for a specific ISA is developed, various benchmark programs are run to evaluate the effectiveness of the ISA, and according to the evaluation results, the ISA is modified. At some point, the ISA will be considered satisfactory, and along with a fully developed ISA specification, an ISA emulator, an ISA verification program suite, and a development program suite including e.g. assembler, debugger , the completion of the compilation program, etc., the ISA process is terminated. Then, the processor design begins. This process is performed infrequently because processors may have a useful life of many years—typically, a processor designed once is used by many systems for many years. As long as ISA, its verification program group, simulation program and various development targets of different processors are given, the microarchitecture of the processor can be designed, simulated and modified. Once the microarchitecture is finalized, it is incorporated into a hardware description language (HDL), and a microarchitecture verification suite is developed to verify the HDL implementation (mostly later). Then, an automated design tool can synthesize a circuit based on the HDL description, and place and route its components, as opposed to the manual process described for this point. The layout can then be modified to optimize chip area usage and timing. Alternatively, additional manual processing can be used to generate a floor plan based on the HDL description, convert the HDL to circuits, and then manually and automatically verify and layout the circuits. Finally, the layout is verified using an automated tool to verify that it matches the circuit, and each circuit is verified against the layout parameters.

After completing the processor development, the overall design of the system is carried out. Unlike the design of ISAs and processors, system design (which can include chip design, which now includes processors) is quite generic and typically continues to the system. Each system is used by a specific application for a relatively short period of time (1 or 2 years). Based on predetermined system goals, such as cost, performance, power, and functionality, pre-existing processor specification, chip form factor specification (usually in close contact with processor vendors), design the overall system architecture, select a process Make it match the design goals, and select the version of the processor (this is closely related to the processor selection).

Then, given the selected processor, ISA, version, and previously developed simulation programs, verification and development tools (and standard cell libraries for the selected version), an implementation of the system is designed for The HDL implementation of the system develops a set of verification programs and enables the implementation to be verified. Next, the circuit for the system is synthesized, placed and routed on the board, and the placement and timing are reoptimized. Finally, the boards are designed and laid out, the chips are fabricated, and the boards are assembled.

Another difficulty with prior art processor designs is that since any given application requires only a specific combination of features, it would be prohibitively expensive to have a processor with features not required for that application. , consumes more power, and is more difficult to manufacture, so simply designing a conventional processor with more features to cover all applications is inappropriate. Furthermore, when starting to design a processor, it is not possible to know all application targets. If the processor modification process could be automated and reliable, the system designer's ability to generate application solutions would be significantly enhanced.

As an example, consider a device designed to send and receive data over a channel using a complex protocol. Due to the complexity of the protocol, it is not possible to reasonably complete the processing using hard-wiring (such as combinational logic) at all. Instead, a programmable processor is introduced into the system for protocol processing. Programmability also allows error fixation and future protocol updates by loading new software into the instruction memory. However, a conventional processor may not have been designed for this particular application (and the application may not even have existed when the processor was designed), and it needs to perform operations that require several instructions To complete, and as long as in the additional processor logic, these operations can be completed with one or a few instructions.

The inability of processors to be easily improved has led many system designers to avoid this and instead choose to implement an inefficient software-only solution on an available processor. This inefficiency results in a solution that may be slower, or require more power, or be more expensive (for example, it may require a larger, more powerful processor to execute the program at sufficient speed ). Other designers choose to provide some of the processing requirements, such as a coprocessor, in special-purpose hardware they design for the application, and then have programmers code to access that special-purpose hardware at various points in the program. However, since only fairly large units of work are accelerated enough that the time saved by using dedicated hardware is greater than the additional time required to transfer data to and from dedicated hardware, in The time to transfer data between the processor and dedicated hardware limits the use of this approach for system optimization.

In the instance of a communication channel application, the protocol may require encryption, error correction, or compression/decompression processing. Such processing typically operates on individual bits rather than on larger words for the processor. The circuitry for a computation may be modest, but having the processor decimate each bit, process it sequentially, and then reload the bits adds considerable overhead.

As a very specific example, consider Huffman decoding using the rules shown in Table 1 (similar encoding is used in the MPEG compression standard).

pattern value Length 0 0 X X X X X X 0 2 0 1 X X X X X X 1 2 1 0 X X X X X X 2 2 1 1 0 X X X X X 3 3 1 1 1 0 X X X X 4 4 1 1 1 1 0 X X X 5 5 1 1 1 1 1 0 X X 6 6 1 1 1 1 1 1 0 X 7 7 1 1 1 1 1 1 1 0 8 8 1 1 1 1 1 1 1 1 9 8

Both the value and the length are computed, so in the codestream each length bit can be eliminated in order to find the start of the next element to be decoded.

There are multiple ways to code this for a conventional instruction set, but each software implementation would require multiple processors due to the many tests that need to be done and compared to the per-gate latency of combinatorial logic cycles, so they all require many instructions. For example, an efficient prior art implementation using the MIPS instruction set might require 6 logical operations, 6 conditional branches, 1 arithmetic operation, and associated register loads. Using an optimally designed instruction set results in better coding, but is still expensive in terms of time: 1 logical operation, 6 conditional branches, 1 arithmetic operation, and associated register loads.

The overhead, in terms of processor resources, is so great that a 256-line look-up table is typically used instead of encoding the process as a sequence of bit-by-bit comparisons. However, a 256-row lookup table takes up a lot of space, and accessing the table may take many cycles. For longer Huffman encodings, the table size becomes unusable, which results in more complex and slower codes.

In processors, a possible solution to the problem of catering to special application requirements is to use a configurable processor, which has an instruction set and architecture that can be easily modified and expanded, in order to improve the function of the processor and realize the customization of the function. Configurability allows designers to specify whether or how much additional functionality is required in their product. The simplest form of configurability is a binary choice: a feature is present or absent. For example, a processor may be provided with or without floating point hardware.

Flexibility is improved through configuration selection using a finer, incremental approach. For example, a processor may allow a system designer to specify the number of registers, memory width, cache size, cache associativity, etc. in a register file. However, these options still do not reach the level that system designers can customize to their liking. For example, in the Huffman decoding example above, although it is not known in the prior art that a system designer might like to incorporate a dedicated instruction to do the decoding, e.g.,

huff8 t1, t0

Here, the highest 8 bits of the result are the decoded value, while the lower 8 bits are the length. In contrast to the software implementation described above, the direct hardware implementation of the Huffman decoding is quite simple—in addition to instruction decoding, etc., the decoding logic for instructions for combinatorial logic functions has roughly 30 gates, or A typical processor has less than 0.1% of the number of gates and can be computed in a single cycle by a special purpose processor, thus improving by a factor of 4-20 compared to using only general purpose instructions.

Prior art efforts in configurable processor generation generally fall into two categories: logic synthesis used with parameterized hardware descriptions; and compiler and assembler retargeting from abstract machine descriptions. Synthesizable processor hardware designs belonging to category 1, such as Synopsys DW 8051 processor, ARM/Synopsys ARM7-S, LexraLX-4080, ARC configurable RISC core; and to some extent Synopsys synthesizable / Configurable PCI bus interface.

In the above example, the Synopsys DW 8051 includes a binary-compatible implementation of an existing processor architecture; and a small number of synthetic parameters, such as 128 or 256 bytes of internal RAM, the ROM address range determined by the parameter rom_addr_size, An optional interval timer, a variable number (0-2) of serial ports, and an interrupt unit supporting 6 or 13 sources. While some changes can be made to the DW 8051's architecture, no changes are possible in its instruction set architecture.

The ARM/Synopsys ARM7-S processor includes binary-compatible implementations of existing architectures and microarchitectures. It has two configurable parameters: selection of high-performance or low-performance multipliers, and inclusion of debugger and in-circuit emulation logic. While it is possible to make changes to the instruction set architecture of the ARM7-S, they are a subset of existing non-configurable processor implementations, so no new software is required.

The LX-4080 processor has a configurable variant of the standard MIPS architecture and does not provide software support for instruction set extensions. Its options include a custom engine interface that allows the opcodes of the MIPS arithmetic logic unit ALU to be extended with dedicated operations; an internal hardware interface that includes a register source and a register or 16-bit wide immediate source, and destination and suspend signals; a simple memory management unit option; three MIPS coprocessor interfaces; a flexible local memory interface to cache memory, scratch pad RAM, or ROM; a bus controller that connects external functions and memory connected to the processor's own local bus; and a write buffer of configurable depth.

ARC configurable RISC core with a user interface to on-the-fly gate count estimates based on target technology and clock speed, instruction cache configuration, instruction set extensions, a timer option, a scratch pad memory options, and memory controller options; an instruction set with selectable options such as local scratch-pad RAM with data blocks sent to memory, dedicated registers, up to 16 additional status code choices, a 32 x 32 Card multiplication block, a single-cycle 32-bit barrel-shifter/rotation block, a normalize (find 1st bit) instruction, write the result directly to the command buffer memory (not to the register file), a 16-bit MUL/MAC block and 36-bit accumulators, and sliding pointers to access local SRAM using linear arithmetic; and user instructions defined by hand-editing the VHDL source code. The ARC design has no means for implementing an instruction set description language, nor does it produce configurable processor-specific software tools.

Synopsys configurable PCI interface includes GUI or command-line interface for installation, configuration, and synthesis activities; checks at each step for necessary user actions to be taken; selected, configuration-based (e.g., Verilog to VHDL) designs File installation; optional configuration, such as parameter settings, and prompting the user for the values of each configuration with combined validity checks, generating HDL with user-updated HDL source code without editing the HDL source file; and synthesis Functionality, such as a user interface that analyzes technology libraries to select I/O buffers, technology-independent constraints and composition scripts, buffer insertion and hints for technology-specific buffers, and Transform irrelevant formulas into technology-dependent manuscripts. Since the configurable PCI bus interface realizes the consistency check of various parameters, configuration-based installation, and automatic modification of HDL files, such a bus interface is worth noting.

Furthermore, prior art synthesis techniques select different mappings based on user target specifications, allowing such mappings to be optimized for speed, power, area, or target components. At this point, in the prior art, it is not possible to obtain feedback on the effect of reconfiguring the processor in this way without going through the design through the entire mapping process. Such feedback can be used to guide further reconfiguration of the processor until the system design goals are met.

In the field of configurable processor generation, a class 2 prior art (i.e., automatic retargeting of compilers and assemblers) involves extensive academic research, see for example "Retargeting in AVIV" by Hanono et al. Instruction Selection, Resource Allocation, and Scheduling in Code Generators" (Representation of Auto-Generated Machine Instructions for Code Generators); Using nML to Describe Instruction Set Processors by Fauth et al.; Ramsey et al. "Machine Descriptions for Building Tools in Embedded Systems"; "Code Generation Using Tree Matching and Dynamic Programming" by Aho et al. , for example, add, load, store, branch, etc., with a sequence of program operations expressed as some machine-independent intermediate form, using various methods such as pattern matching); and "Code Generation by Cattell" Formalization and Automatic Derivation of Machines" (Abstract Description of Machine Architectures for Compiler Studies).

Once a processor has been designed, its operation should be verified. That is, processors typically execute instructions from a stored instruction using a pipeline, each stage of which is adapted to a stage of instruction execution. Thus, changing or adding an instruction or changing the configuration may require general changes in the processor's logic so that each of the multiple pipeline stages can perform the appropriate action on each such instruction. A processor's configuration requires it to be revalidated, and this validation applies to changes and additions. This is not an easy task. Processors of all kinds are complex logic devices with extensive internal data and control states, and the combination of control, data, and program makes processor verification a desirable technique. The added difficulty of processor verification is the difficulty in developing appropriate verification tools. Since verification is not automated in the prior art, its flexibility, speed and reliability are less than optimal.

Furthermore, once a processor has been designed and proven, it is not particularly useful if it cannot be easily programmed. Processors are usually programmed with the help of extensive software tools, including compilers, assemblers, linkers, debuggers, emulators, and tracers. When processors change, software tools must change with them. There is no benefit in adding an instruction if it cannot be compiled, assembled, emulated or debugged. In the prior art, software changes associated with processor modifications and improvements have been a major hurdle in advancing processor design.

Thus, it can be seen that prior art processor design suffers from a degree of difficulty since processors are typically not typically designed and modified for one particular application. Likewise, it can be seen that considerable improvements in system efficiency are possible if various processors can be configured and scaled for specific applications. Also, if feedback on implementation characteristics (eg, power consumption, speed, etc.) can be used to improve processor design, the efficiency and effectiveness of the design process can be enhanced. Moreover, in the prior art, once a processor is modified, a lot of effort is required to verify the correct operation of the modified processor. Finally, while prior art technologies offer limited processor configurability, they do not provide for tailoring of configured processors for production of software development tools.

A system that conforms to the above specification must be an improvement in the industry, and improvements can be made—for example, there is a need for a processor system that has access to information stored in special purpose registers (i.e., processor state) or Modified instructions that significantly limit the range of available instructions and thus limit the amount of performance improvement available.

Likewise, inventing new specialized instructions involves making complex trade-offs between reduced cycle counts, added hardware resources, and CPU cycle time impact. Another challenge is to obtain efficient hardware implementations for new instructions without involving application developers in the often intricate details of high-performance microprocessor implementation.

The system described above gives the user the flexibility to design a processor that is well suited to her application. But for the interactive development of hardware and software, it is still very troublesome. To understand this problem more fully, consider a typical scheme used by many software designers to tune the performance of their software applications. They will typically think of a possible improvement, modify their software to use that possible improvement, recompile their software sources to produce a runnable application with that possible improvement, and then review the possible Improvements are evaluated. Depending on the results of the evaluation, they can keep or discard these possible improvements. Typically, the entire process may be completed in only a few minutes. This gives users the freedom to experiment, to try things out quickly and decide to keep or discard ideas. In some cases, properly evaluating a possible idea is complicated. Users may need to test this idea in a variety of situations. In such cases, users typically keep multiple versions of the compiled application: an original version and another version with possible improvements. In some cases, the potential enhancements may be interactive, and the user may retain two or more copies of the application, each of which uses a different subset of the possible enhancements. By keeping multiple versions, users can easily repeatedly test different versions under different conditions.

Users of configurable processors like to interactively co-develop hardware and software in a manner similar to how software developers develop software on traditional processors. Consider the case where a user adds custom instructions to a configurable processor. Users like to interactively add every possible instruction to their processor, and to test and evaluate those instructions in their specific application. In prior art systems this is made difficult for 3 reasons.

First, after proposing a possible instruction, the user must wait more than an hour before obtaining a compiler and emulator that would benefit from the instruction.

Second, when a user wishes to experiment with many possible instructions, the user must generate and maintain a software development system for each instruction. Software development systems can be very large. Keeping many versions can become unmanageable.

Finally, the software development system is configured for the entire processor. This makes it difficult to break down the development process among different engineers. Consider an instance where two developers are working on a particular application at the same time. One developer may be responsible for determining the characteristics of the processor's cache memory, while another is responsible for adding custom instructions. When the work of the two developers is linked, each piece is sufficiently separable that each developer can perform her tasks in isolation from the other. The developer of the cache memory may propose a special configuration from the beginning. Another developer starts with this configuration and tries several instructions, building a software development system for each possible instruction. Now, the developers of the cache memory modify the proposed configuration of the cache memory. Another developer must now rebuild each of her configurations, since each of her configurations uses the original cache's configuration. With many developers working on a project at the same time, organizing different configurations together can quickly become unmanageable.

Brief description of the invention

The present invention overcomes these problems of the prior art, and it is an object of it to provide such a system. It automatically configures a processor by generating a description of the processor's hardware implementation and a set of software development tools for programming the processor from the same configuration description.

Another object of the present invention is to provide such a system which optimizes the hardware implementation and software development tools for different performance specifications.

Yet another object of the present invention is to provide such a system which gives processors different types of configurability, including scalability, binary selection and parameter modification.

It is a further object of the present invention to provide a system which describes the instruction set architecture of a processor in a language which can be easily embedded in hardware.

It is a further object of the present invention to provide such a system and method for developing and implementing instruction set extensions capable of modifying processor state.

Another object of the present invention is to provide such a system and method for developing and implementing an instruction set extension that modifies registers of a configurable processor.

Yet another object of the present invention is to allow a user to customize a processor configuration by adding new instructions and evaluate this feature within minutes.

The above objectives are achieved by providing an automatic processor generation system that uses custom processor instruction set options and extensions written in a standardized language to develop a configuration definition of a target instruction set for the implementation of the instruction set required A hardware description language description of the circuit, and various development tools, such as compilers, assemblers, debuggers, and simulators, can be used to generate software for and verify the processor. Implementations of processor circuits may be optimized for different specifications, such as area, power consumption, and speed. Once a processor configuration has been developed, it can be tested and imported into the system to be modified in order to iteratively optimize the processor implementation.

In order to develop an automatic processor generation system according to the present invention, it is necessary to define an instruction set architecture description language, and to develop various development tools such as assembler, linker, compiler and debugger. This is part of the development process because although most of the tools are standard, they should be modified to be automatically configured according to the ISA description. This part of the design process is typically performed by the designer or manufacturer of the automated processor design tool itself.

An automatic processor generation system according to the present invention operates as follows. A user, such as a system designer, develops a configurable instruction set architecture. That is, using ISA definitions and previously developed tools, a configurable instruction set architecture is developed that follows a certain ISA design goal. Then, configure the development tools and emulators for this configurable instruction set architecture. Using the configurable emulator, run benchmarks to evaluate the effectiveness of the configurable instruction set architecture and modify its core based on the evaluation results. Once the configurable instruction set architecture is in a satisfactory state, a verifier suite is developed for it.

While focusing on the software side of the process, the system also focuses on the hardware side by developing a configurable processor. Next, using system goals such as cost, performance, power, functionality, and information about available processor manufacturers, the system designs an overall system architecture that takes into account configurable ISA options, extensions, and processor features. Using the overall system architecture, development software, emulators, configurable instruction set architecture, and processor HDL implementations, the system configures the processor ISA, HDL implementations, software, and emulation programs, and the system HDL are designed for system-on-a-chip design. Also, based on a specification of the system architecture and chip version, the chip version is selected based on an evaluation of the version's capabilities relative to the system HDL (unlike in the prior art involving processor selection). Finally, using the version's standard cell library, the configuration system synthesizes the circuit, places and routes it, and provides the ability to re-optimize placement and timing. Then, if the design is not of the monolithic type, the board layout is designed, the chips are fabricated, and the boards are assembled.

As seen above, several techniques are used to facilitate wide-ranging automation of the processor design process. The first technique to solve these problems is to design and implement a dedicated mechanism, which is not as flexible as arbitrary modification or extension, but which still allows significant functional improvements. By limiting the arbitrariness of changes, the various problems associated with this are also constrained.

The second technique is to provide a single specification for each change and automatically produce modifications or extensions to all affected components. Since it is usually cheaper to do something by hand once than to write a tool to do it automatically and use the tool once, processors designed with the prior art cannot do this. a little. The benefits of automation can be seen when the task is repeated many times.

The third technique used is to build a database to assist in estimation and automatic configuration for subsequent user evaluations.

Finally, the fourth technique is to provide hardware and software in a form suitable for deployment. In one embodiment of the invention, some hardware and software are written not directly in standard hardware and software languages, but in a language that, by adding a preprocessor, allows querying of a configuration database, and the generation of standard hardware and software languages with permutation, conditional, copy, and other modification functions. The processor design is then completed with hooks that allow the improvements to be wired in.

To illustrate these techniques, consider adding each dedicated instruction. By restricting the method to instructions that have registers and constant operands and produce a register result, the operation of the instructions can be described using only combinational (stateless, feedback-free) logic. This input specifies the assignment of the opcode, instruction name, assembler syntax, and combinatorial logic for that instruction (from which various tools are generated):

- the processor's instruction decode logic to identify new opcodes;

— Add a functional unit to perform combinational logic functions on register operands;

— an input to the processor's instruction dispatch logic to confirm that an instruction is issued only if its operand is valid;

— Assembler modifications to accept new opcodes and their operands, and produce correct machine code;

—Modification of the compiler, adding new internal functions in order to access new instructions;

— modification of the disassembler/debugger to translate machine code into new instructions;

—Modification of the emulation program so that it accepts the new opcode and performs the specified logic function; and

- Diagnostic program generator, which generates direct and random code sequences to contain and check the results of the added instructions.

All of the above techniques are used to add various specialized instructions. Inputs are restricted to input and output operands and logic to evaluate them. Each change is described in one place, and all hardware and software modifications are derived from this description. This setup shows how a single input can be used to improve multiple components.

The result of this process is a system that outperforms current applications in meeting application requirements because of the various trade-offs that can be made between the processor and the rest of the system logic later in the design process. have technology. It outperforms various prior art solutions discussed above because its configuration can be applied to more representations. A single source can be used for all ISA codes, software tools and advanced simulations can be incorporated into a configuration package, and the process can be designed to iteratively find the best combination of configuration values. Also, the various methods described above only focus on hardware configuration or software configuration alone, without a separate user interface for control, or a redefined measurement system for user guidance, while the present invention will Full traffic allocation to processor hardware and software configuration, including results from hardware design and software performance, to help select the best configuration.

According to one aspect of the present invention, these objectives are achieved by providing an automated processor design tool that uses descriptions of custom processor instruction set extensions written in standardized languages to develop configurable The definition of the hardware description language description of the circuits required to implement the instruction set, and various development tools, such as compilers, assemblers, debuggers and emulators, which can be used to develop various applications for the processor , and validate it. Standardized languages can handle instruction set extensions that modify processor state or use configurable processors. By providing a restricted field of expansion and optimization, a higher degree of process automation can be achieved, thereby facilitating rapid and reliable development.

According to another aspect of the present invention, the above objects can be further achieved by providing a system in which the user can save sets of possible commands or states (hereinafter, possible configurable commands or states) combinations will be collectively referred to as "Processor Improvements"), and it is easy to switch between them when evaluating their application.

The user selects and builds a base processor using the methods described here. The user generates a new set of user-defined processor enhancements and puts them into a file directory. The user then enables a tool that processes the user improvements and converts them into a form that basic software development tools can use. This transition is quick since it involves only user-defined improvements and does not build a complete software system. The user then enables the basic software development tool, telling the tool to dynamically use each processor improvement generated in the new directory. Preferably, the location of this directory is given to each tool via a command line option or via an environment variable. To further simplify this process, users can use standard software makefiles. These enable users to modify their processor instructions, and then, via a single make command, process each improvement, and use basic software development tools to rebuild and evaluate their application in the name of the new processor improvement.

The present invention overcomes three limitations in the prior art solutions. Given a new set of possible improvements, users can evaluate each new improvement in a matter of minutes. By generating a new catalog for each set, the user can save multiple versions of each possible improvement. Since the catalog only contains descriptions of individual new improvements, and not of the entire software system, the required storage space is minimal. Finally, each new improvement is decoupled from the rest of the configuration. Once a user has generated a catalog with a possible set of new improvements, she can use that catalog with any base configuration.

Brief description of the drawings

These and other objects of the invention will become more apparent when the following detailed description is read in conjunction with the accompanying drawings in which:

Figure 1 is a block diagram representing a processor executing an instruction set according to a preferred embodiment of the present invention;

Fig. 2 is a block diagram showing a block diagram of a pipeline used in the processor according to this embodiment;

Fig. 3 shows a kind of configuration management program in the graphical user interface (GUI) according to the present embodiment;

Fig. 4 shows a configuration editing program in the graphical user interface (GUI) according to the present embodiment;

Figure 5 represents the different types of configurability according to the present embodiment;

Fig. 6 is a block diagram, represents the flow process of the processor configuration in this embodiment;

Fig. 7 is a block diagram showing an instruction set according to the present embodiment;

Figure 8 is a block diagram showing an emulation board for a processor configured in accordance with the present invention;

Fig. 9 is a block diagram showing the logical structure of the configurable processor according to the present embodiment;

Figure 10 is a block diagram showing the addition of a multiplier to the structure of Figure 9;

Figure 11 is a block diagram showing the addition of a multiply-accumulate unit to the structure of Figure 9;

These two figures of Fig. 12 and 13 represent the configuration of the memory in the present embodiment; And

The two figures of Figures 14 and 15 represent the addition of user-defined functional units in the structure of Figure 8;

Figure 16 is a block diagram showing the flow of information between various system components in another preferred embodiment;

Fig. 17 is a block diagram showing how, in the present embodiment, custom codes for various software development tools are generated;

Fig. 18 is a block diagram showing that in another preferred embodiment of the present invention, the various software modules used are generated;

Fig. 19 is a block diagram showing the structure of the pipeline in a configurable processor according to the present embodiment;

Fig. 20 is the implementation of the state register according to the present embodiment;

Figure 21 is a diagram showing the additional logic required to implement the status register in this embodiment;

Fig. 22 is a graph representing the combination of the next state output from a state of several semantic blocks, and selecting one of them to be input into a state register according to the present embodiment;

Figure 23 represents the logic corresponding to the semantic logic according to the present embodiment;

Figure 24 shows the logic for one bit of status when mapped to one bit of the user register in this embodiment.

Detailed description of each preferred embodiment

In general, the automatic processor generation process begins with a configurable processor definition and user-specified modifications to it, subject to the user-specified application for which the processor is configured. This information is used to generate a processor that is configurable to allow for user modifications, and to generate software development tools such as compilers, emulators, assemblers and disassemblers, etc. for it. Likewise, applications are recompiled using various new software development tools. The recompiled application is simulated using an emulator to generate a software profile that describes the performance of the configured processor running the application, with respect to silicon area utilization, power consumption, speed, etc. The configured processor is evaluated to generate a hardware profile that characterizes a processor circuit implementation. Software and hardware profiles are fed back and provided to the user for further iterative configuration to optimize the processor for that specific application.

The automatic processor generation system 10 according to a preferred embodiment of the present invention has 4 main components, as shown in FIG. 1 : a user configuration interface 20, through which user input for the design of the processor is desired, its configurability and extensibility performance options and other design constraints; a suite of software development tools 30 that can be customized to design a processor according to user-selected criteria; a parametric, extensible description of a hardware implementation of the processor 40; and a build system 50 which receives input data from the user interface, generates a custom, synthesizable hardware description of the required processor, and modifies various software development tools to suit the selected design. Preferably, build system 50 additionally generates diagnostic tools for verifying hardware and software designs and an evaluator for evaluating hardware and software characteristics.

As used herein and in the appended claims, a "hardware implementation description" refers to one or more descriptions that describe various aspects of the physical implementation of a processor design, and, individually Use or combine with one or more of the other descriptions to facilitate the production of each chip according to the design. Thus, parts of the hardware implementation description can be at different levels of abstraction, from fairly high levels such as hardware description languages, through netlists and microcode, to various mask descriptions. In this embodiment, the main part of the hardware implementation description is written in HDL, netlist and script.

Moreover, HDL as used herein and in the appended claims refers to a general-level hardware description language, which is used to describe microstructures and the like, and it is not intended to represent any special case.

In this embodiment, the processor configuration is based on the architecture 60 shown in FIG. 2 . Many elements of the structure are fundamental properties that cannot be directly modified by the user. These include processor control segment 62 , alignment and decode segment 64 (although some parts of this segment are based on user-specified configuration), ALU and address generation segment 66 , branch logic and instruction fetch segment 68 , and processor interface 70 . Every other unit is part of the base processor, but is user configurable. These include interrupt control segment 72 , data and instruction address monitoring segments 74 and 76 , window register file 78 , data and instruction cache and tag segment 80 , write buffer 82 and timer 84 . The remaining segments shown in Figure 2 can optionally be included by the user.

A central component of processor configuration system 10 is user configuration interface 20 . This is a module, which preferably provides the user with a graphical user interface (GUI), by means of which the user has the possibility to select options including compiler reconfiguration and assembler, disassembler and instruction set simulator (ISS) processor functions included; and prepare inputs for overall processor synthesis, place and route. It also allows users to benefit from quick assessments of processor area, power consumption, cycle time, application performance, and code size to further iterate and improve processor configurations. Preferably, the GUI also has access to a configuration database for default values based on user input and for error detection.

To design a processor 60 using the automatic processor generation system 10 according to the present embodiment, a user enters design parameters into the user configuration interface 20 . The automatic processor generation system 10 may be an isolated system running on a computer system under user control; however, it is preferably run primarily on a system under the control of the manufacturer of the automatic processor generation system 10 . In this way, user access can be provided over a communications network. For example, the GUI can be provided using a web browser with data entry screens written in HTML and Java languages. This has several benefits, such as keeping any proprietary back-end software confidential, simplifying maintenance and updating of the back-end software, and so on. In this case, in order to access the GUI, the user must first log in to the system 10 in order to prove his identity.

Once the user is granted access, the system will display a configuration administrator screen 86, as shown in FIG. The configuration administrator screen 86 is a directory listing all configurations accessible to the user. The configuration administrator screen 86 in FIG. 3 shows that the user has two configurations, "just intr" and "high prio", the former already established, ie finalized for production, and the latter yet to be established. From this screen 86 the user can create a selected configuration, delete it, edit it, generate a report stating which configuration and expansion options have been selected for that configuration, or create a new configuration. For those already established configurations, such as "just intr", a custom set of software development tools 30 can be downloaded.

FIG. 4 shows that the configuration editing program 88 shown in FIG. 4 is used to generate a new configuration or edit an existing configuration. The configuration editor 88 has an "options" selection menu on the left, representing various general aspects of the processor 60 that are configurable and expandable. When an options section is selected, a screen with configuration options for that section appears on the right, and these can be set as is well known in the industry using drop-down menus, note boxes, checkboxes, radio knobs, etc. options. Although users can randomly select options and enter data, due to logical dependencies between sections, it is best to enter data item by item in order; for example, in order to properly display the For each option, the number of interrupts should be the ones already selected in the "ISA Options" section.

In this example, for each part, the following configuration options are available:

Target

Techniques Used for Evaluation

Targeted ASIC technologies: .18, .25, .35 microns

Target Operating Conditions: Typical, Worst Case

Implementation plan goals

Target speed: any

Gate Count: Any

Target function: any

Target Prioritization: Speed, Area Function; Speed, Function, Area ISA Options

digital option

MAC16 with 40-bit accumulator: yes, no

16-bit multiplier: yes, no

Exclusion option

Number of interrupts: 0-32

High priority interrupt level: 0-14

Activate debugger: yes, no

Number of timers: 0-3

other

Byte order: LSB first, MSB first

Number of registers available for calling window: 32, 64

Processor Cache and Memory

Processor interface readout width (bits): 32, 64, 128

Write buffer rows (address/value pairs): 4, 8, 16, 32

processor cache memory

Instruction/Data Cache Size (kB): 1, 2, 4, 8, 16

Instruction/Data Cache Line Sizes (kB): 16, 32, 64

peripheral components

timer

Number of timer interrupts

Timer Interrupt Level

Debug support

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

to interrupt

Source: External, Software

Priority

system memory address

Vector and address calculation method: XTOS, manual

configuration parameters

RAM size, starting address: any

ROM size, starting address: any

XTOS: any

Configure private address

User Except Vector: Any

Excluded vector: any

Register window overflow/underflow vector base address: any

Reset vector: any

XTOS starting address: any

Application start address: any

TIE instruction

(Define various ISA extensions)

target CAD environment

simulation

^VerilogTM : Yes, No

synthesis

Design Compiler ^™ : Yes, No

place and route

^ApolloTM : Yes, No

In addition, system 10 provides the option to add 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 memory associativity; enhanced DSP and coprocessor instruction set; write-back cache memory; multiprocessor synchronization; compiler-guided inference; and support for additional CAD packages. The configuration options available for a given configurable processor are preferably listed in a definition file (such as the one shown in Appendix A) so that once the user selects the appropriate option, System 10 uses this for syntax checking and the like.

As can be seen from the above, the automated processor configuration system 10 provides users with two broad types of configurability 300, shown in Figure 5: extensibility 302, which allows users to define arbitrary functions and structures from a search , and modifiability 304, which allows the user to choose from a predetermined, constrained set of options. Within the scope of modifiability, the system allows binary selection 306 of certain characteristics, such as whether a MAC16 or a DSP should be added to the processor 60, and parameter specification 308 of other processor characteristics, such as the number of interrupts and high-speed The size of the buffer memory.

Many of the above configuration options are familiar to professionals; however, there are others that deserve attention. For example, RAM and ROM options allow designers to incorporate scratch pad memory or firmware into the processor itself. Processor 10 can fetch instructions or read and write data from these memories. The size and location of the memory is configurable. In this embodiment, each of these memories is accessed as an additional set in a set associative cache. A hit in memory can be detected by comparing to a single tag line.

Since each high-priority interrupt needs 3 dedicated registers, the overhead is large, so the system 10 is an interrupt (to realize various 1-level interrupts) and a high-priority interrupt option (to realize 2-15 level interrupts and various non-maskable interrupts) Provides independent configuration options.

The MAC16 with 40-bit accumulator option (90 shown in Figure 2) adds a 16-bit multiplier/adder function with a 40-bit accumulator, eight 16-bit operand registers, and a set of A compound instruction that combines multiply, accumulate, operand load, and address update instructions. Pairs of 16-bit numbers can be loaded from memory into operand registers in parallel with the multiply/accumulate operations. This unit is capable of supporting various algorithms with two loads and one multiply/accumulate per cycle.

An on-chip debug module (shown at 92 in FIG. 2 ) is used to access the internal, software-visible state of processor 60 via JTAG port 94 . Module 92 provides support for exception generation, causes processor 60 to enter debug mode; accesses all program-visible memory or memory locations, executes any instruction that processor 60 is configured to execute; modifies program counter PC to jump to and an application program that allows a return to normal operating mode, which is triggered from outside the processor 60 via the JTAG port 94.

Once processor 10 enters debug mode, it waits from the outside world for an indication that a valid instruction has been scanned in via JTAG port 94 . Once a hardware implementation of processor 10 has been produced, module 92 is used to debug the system. Execution of processor 10 may be controlled via a debugger running on a remote host computer. The debugger interfaces with the processor via the JTAG port 94 and uses the capabilities of the on-chip debug module 92 to determine and control the state of the processor 10 and to control the execution of instructions.

Up to three 32-bit counter/timers 84 can be configured. This enables the use of 32-bit registers to increase each clock cycle and (for each configured timer) the compare register by 1. The comparator compares the contents of the compare register with the count of the current clock register for interrupts. and similar functions. The counter/timer can be configured as edge-triggered and can generate normal and high-priority internal interrupts.

The infer option provides compilers with greater flexibility in scheduling by allowing loads to move on ad-hoc basis to control flow to places where they are not executed very often. Since loads may cause exceptions, such load moves may introduce exceptions into a valid program that were not present before. Adaptive loading avoids these exceptions when the load is performed, but provides an exception when data is needed. Instead of causing an exception for a load error, the ad hoc load resets the valid bit of the target register (new processor state associated with this option).

While core processor 60 preferably has some basic pipeline synchronization capability, when a system uses multiple processors, some kind of communication or synchronization between the processors is required. In some cases, self-synchronizing communication techniques such as input and output queues are used. In other cases, a shared memory model is used for communication, and since shared memory does not provide the required semantics, it is necessary to provide an instruction set that supports synchronization. For example, load and store instructions with acquire and release semantics (functions) can be added. This is useful for controlling the order of memory references in multiprocessor systems where different memory locations may be used for synchronization and data such that precise order must be maintained between synchronization references. Other instructions can be used to generate signals well known in the industry.

In some cases, a shared memory model is used for communication, and since shared memory does not provide the required semantics, it is necessary to provide an instruction set that supports synchronization. This is done through the multiprocessor synchronization option.

Of the configuration options, perhaps the most important is the definition of the TIE instruction, thereby creating a designer-defined instruction execution unit 96 . TIE ^TM (Tensilica Instruction Set Extension), developed by Tensilica Corporation of Santa Clara, California, allows users to describe custom functions for their applications in the form of extensions and new instructions to extend the basic ISA. Furthermore, due to TIE's flexibility, it can be used to describe parts of the ISA that cannot be changed by the user; thus, the entire ISA can be used to consistently generate software development tools 30 and hardware implementation descriptions 40 . TIE instructions use multiple building blocks, and the attributes of each new instruction are described as follows:

—Instruction field —Instruction class

— instruction opcode — instruction semantics

—Instruction operand —Constant table

The instruction field statement field is used to improve the readability of TIE code. Fields are subsets or concatenations of other fields that are grouped together and referenced by a name. In an instruction, the full set of each bit is the highest-level superset field inst, and this field can be divided into several smaller fields. For example,

field x inst[11:8]

field y inst [15:12]

field xy {x, y}

Define two 4-bit fields, x and y, as subfields of the highest-level field inst (bits 8-11 and 12-15, respectively), and define an 8-bit field xy as the subfield of both fields x and y chain.

The statement opcode defines each opcode for each encoding-specific field. Instruction fields intended to specify operands (such as registers or immediate constants) must first be defined with field statements and then with operand statements if they are to be used with opcodes thus defined.

For example,

opcode acs op2=4'b0000 CUST0

opcode adse1 op2=4'b0001 CUST0

Define two new sets of opcodes, acs and adse1, based on the previously defined opcode CUST0 (4'b0000 represents a set of 4-bit long binary constant 0000). The TIE specification for the preferred core ISA has the following statement

field op0 inst[3:0]

field op1 inst[19:16]

field op2 inst[23:20]

opcode QRST op0=4'b0000

opcode CUST0 op1=4'b1000 QRST

as part of its basic definition. Therefore, the definitions of acs and adse1 cause the TIE compiler to generate instruction decoding logic represented by the following statements, respectively:

inst[23:0]＝0000 0110 xxxx xxxx xxxx 0000

inst[23:0]＝0001 0110 xxxx xxxx xxxx 0000

The instruction operand statement operand identifies registers and immediate constants. However, before defining a field as an operand, it should have been previously defined as a field as described above. If the operand is an immediate constant, the value of the constant may be derived from the operand, or it may be taken from a table of previously defined constants as described below. For example, to encode an immediate operand, the TIE code

field offset inst[23:6]

operand offs4 offset{

assign offsets4 = {{14{offset[17]}}, offset}<<2;

}{

wire[31:0]t;

assign t = offsets4>>2;

assign offset = t[17:0];

Define an 18-bit field named offset that holds a signed number and an operand offsets4 that is four times the number stored in the offset field. The last part of the Operand statement actually describes the circuit used for computation in a subset of Verilog ^(TM) HDL, which is used to describe combinational circuits, as is well known to those skilled in the art.

Here, the wire statement defines a set of logical wires named t with a width of 32 bits. The first assign statement after the wire statement specifies that the logic signal driving the logic wire is the constant offsets4 shifted to the right, and the second assign statement specifies that the lower 18 bits of t are placed into the offset field. The first assign statement directly assigns the value of a concatenated operand offsets4 as offset, and 14 copies of its sign bit (bit 17) followed by a left shift of two bits.

For a constant table operand, the TIE code

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;

}

Use the table statement to define a constant array prime (the number following the table name is the number of each element in the table), and use the operand s as an index into the table prime to encode a value for the operand prime_s (note Use of Verilog ^TM statements when defining indexes).

The instruction class statement iclass associates opcodes with operands in a common format. All instructions defined in statement iclass have the same format and operand usage. Before defining an instruction class, its components should first be defined as fields and then as opcodes and operands. For example, to build on the code used in the previous example defining the operands acs and adse1, create the additional statement

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 the three register operands art, ars and arr (note again the use of Verilog ^TM statements in this definition). Subsequently, the iclass statement iclass viterbi {adse1, acs} {outarr, inart, inars} specifies that the operands adse1 and acs belong to the common class of the instruction viterbi, which takes two register operands art and ars as input and writes the output to into the register operand arr.

An instruction semantic statement semantic describes the behavior of one or more instructions using the same subset of Verilog ^TM (used to encode operands). By defining multiple instructions in a single semantic statement, some common expressions can be shared and hardware implementations can be made more efficient. The variables allowed in a semantic statement are the operands for the opcodes defined in the statement's opcode list, and a single-bit variable specified for each opcode in the opcode list. This variable has the same name as the opcode, and it evaluates to 1 when the opcode is checked out. It is used in the calculation part (Verilog ^TM subset part) to indicate the occurrence of the corresponding instruction.

For example, the TIE code defines a new instruction, ADD8_4, which adds four 8-bit operands in a 32-bit word to the corresponding four 8-bit operands in another 32-bit word; also defines another new instruction MIN16_2, which, in one 32-bit word, makes the selection of the minimum value of two 16-bit operands, and in another 32-bit word, the respective 16-bit operands can be read:

opcode ADD8_4 op2=4'b0000 CUST0

opcode MIN16_2 op2=4'b0001 CUST0

iclass add_min { ADD8_4, MIN16_2 } { outar r, inars, in art }

semantic add_min {ADD8_4, MIN16_2}{

wire[31:0] add,min;

wire[7:0] add3, add2, add1, add0;

wire[15:0] min1, min0;

assign add3 = art{31:24}+ars{31:24];

assign add2 = art[23:16]+ars[23:16];

assign add1 = art[15:8]+ars[15:8];

assign add0 = art{7:0]+ars[7:0];

assign add = {add3, add2, add1, add0};

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));

}

Here, op2, CUST0, arr, art, and ars are predefined operands as indicated above, and the opcode and iclass statements function as described above.

A Semantic statement specifies the computation to be performed by the new instruction. As is well known to professionals, line 2 of the Semantic statement specifies calculations by the new ADD84, lines 3 and 4 of which specify calculations by the new MIN16_2, and the last line of the block specifies Write the result to the arr register.

Returning to the discussion of the user input interface 20, once the user has entered her desired configuration and expansion options, the build system 50 proceeds next. As shown in FIG. 5 , the establishment system 50 receives a configuration specification composed of parameters set by the user and various features designed by the user to be extended, and combines them with various additional parameters defining the architecture of the core processor (for example, Features that cannot be modified by the user) are combined to generate a configuration specification 100 that describes the entire processor. For example, in addition to user-selected configuration settings 102, build system 50 may add parameters to specify the number of physical address bits for the processor's physical address space, the first instruction to be executed by processor 60 after reset ,etc.

To illustrate examples of instructions implemented as core instructions in a configurable processor and examples of instructions made available through selection of configuration options, the Xtensa ^TM Instruction Set Architecture (ISA) Reference Manual provided by Tensilica "(Revision 1.0) has been incorporated into this article as a reference.

The configuration specification 100 also includes an ISA package, including TIE language statements specifying the base ISA, any additional packages the user has selected, such as the coprocessor package 98 (see FIG. 2 ) or a DSP package, and any TIE provided by the user. expand. In addition, configuration specification 100 may also have various statements that set flags indicating whether certain structural features are yet to be incorporated into processor 60 . For example

IsaUseDebug 1

IsaUseInterrupt 1

IsaUseHighPriorityInterrupt0

IsaUseException 1

Indicates that the processor will include an on-chip debug module 92, an interrupt device 72 and exception management, but will not include a high-priority interrupt device.

Using the configuration specification 100 can automatically generate the following:

- the instruction decoding logic of the processor 60;

- Illegal instruction detection logic for processor 60;

- the ISA-specific portion of the assembler 110;

- the ISA-specific support program of the compiler 108;

- the ISA-specific portion of the disassembler 110 (used by the debugger); and

- The ISA-specific portion of the emulator 112.

Since an important configuration capability is the incorporation of packages specifying instructions, it is valuable to automatically generate these items. For some things, if the directive has been configured, it is possible in every tool to implement this step with conditional codes to manage the directive, but this is not easy to use; more importantly, it The system designer is not allowed to easily add instructions to his system.

Instead of having the configuration specification 100 as input from the designer, it is also possible to accept the targets and have the build system 50 determine the configuration automatically. A designer can specify various goals for processor 60 . For example, clock frequency, area, cost, typical power consumption, and maximum power consumption can all be targets. Since certain goals are contradictory (e.g., performance is often only increased by increasing area or power consumption, or both), build system 50 then consults search engine 106 to determine the set of configuration options available, and determines How to set each option from an algorithm that attempts to achieve each input goal at the same time.

Search engine 106 includes a database with rows describing the impact of various metrics. Lines can specify that a particular configuration setting has additive, multiplicative, or limiting effects on a metric. Lines can also be marked as requiring other configuration options as prerequisites, or as being incompatible with other options. For example, simple branch predicate options can specify multiplicative or additive effects, limits on clock frequency, additive effects on area, and additive effects on power for cycles per instruction (CPI—a determinant of performance) effects etc. It can be marked as incompatible with a preferred branching routine, and relies on setting the fetch queue size to at least two lines. The magnitude of these effects can be a function of a parameter such as the size of the branch decision table. In general, each row of the database is represented by various functions that can be evaluated.

Different algorithms may be used to find the configuration setting that most closely achieves each input goal. For example, a simple knapsack packing algorithm considers each option in the order of value divided by cost, and accepts any option specification that increases the value while keeping the cost below a specified limit. So, for example, to maximize performance while keeping power below a specified value, you can sort the options by performance divided by power, and accept every option that increases performance without exceeding the power limit. The more complex various knapsack algorithms provide some level of backtracking.

A very different class of algorithms for determining configurations from target and design databases is based on simulated annealing. A random initial set of parameters is used as a starting point, and changes to individual parameters are accepted or rejected by evaluating a global application function. Improvements in application function are generally accepted when negative changes are accepted probabilistically according to a threshold that decreases as optimization proceeds. In this system, application functions are built from various input objects. For example, given the goals of performance >200, power <100, and area <4, in order of priority for power, area, and performance, the following application functions can be used:

Max((1-Power/100)＊0.5,0)+(max((1-Area/4)＊0.3,0)＊(if Power<100 then1 else(1-Power/100)＊＊2)) +(max(Performance/200＊0.2,0)＊(if Power<100 then 1else(1-Power/100)＊＊2))＊(if Area<4 then 1 else(1-area/4)＊＊ 2))

It reports a reduction in power consumption until it's below 100, then neutral, a reduction in area until it's below 4, then neutral, and an increase in performance until it's above 200, then neutral. There are also components that reduce the use of area when power exceeds a specified value, and reduce the use of performance when power or area exceeds a specified value.

Both of these algorithms, as well as others, can be used to search for various configurations that satisfy specified goals. It is important that the design of a configurable processor is described in a design database with prerequisites and a description of each incompatibility option, and the impact of each configuration option on different metrics.

The examples we have given have used various hardware targets, which are generic and do not depend on a particular algorithm running on processor 60. The described algorithm can also be used to select a configuration that matches a particular user program. For example, a user program can be run on a precise emulator with caches to measure the number of different types of caches with different characteristics, such as different sizes, different line widths, and different The setting association. The results of these simulations may be added to the database used by the search algorithm 106 described to aid in the selection of hardware implementation specifications 40 .

Similarly, user algorithms can be modified for the presence of certain instructions, which can optionally be built into the hardware. For example, if a user's algorithm takes a significant amount of time to perform multiplications, the search engine 106 may automatically suggest incorporating a hardware multiplier. Such an algorithm need not be limited to considering one user algorithm. A user can feed a set of algorithms into the system, and the search engine 106 can choose a configuration that, on average, is useful for the user's set of programs.

In addition to selecting pre-configured features of processor 60, search algorithms may also be used to automatically select or suggest possible TIE extensions to the user. Given various input targets, and given examples of possible user programs written in the C programming language, the algorithms suggest possible TIE extensions. For stateless TIE extensions, pattern matching programs can be used to embed tools similar to compilers. These pattern matchers search the expression nodes for multi-byte instruction patterns that can be replaced by a single-word instruction in a bottom-up manner. For example, a user C program contains the following statements:

x=(y+z)<<2;

x2=(y2+z2)<<2;

The pattern matcher will find that the user added the two numbers in two different positions and shift the result left two places. The system adds to the database the possibility of generating a TIE instruction (adding two numbers and shifting the result left two places).

The build system 50 keeps track of a number of possible TIE instructions, along with a count of how many times they occur. Using a tracking tool, system 50 also tracks how often each instruction is executed throughout the execution of the algorithm. Using a hardware emulator, system 50 keeps track of how expensive the hardware is to implement each possible TIE instruction. These numbers are fed into a search heuristic algorithm to select a set of possible TIE instructions that maximize various input objectives; such as performance, code size, hardware complexity, and so on.

A similar but more powerful algorithm is used to find possible TIE instructions with state. Several different algorithms are used to detect different types of opportunities. An algorithm uses a compiler-like tool to scan the user program and detect if the user program requires more registers than the hardware can provide. As is well known to many practitioners in the industry, this condition can be detected by counting register overflows and recovered (fetched) in a compiled fashion in user code. A compiler-like tool suggests to the search engine a coprocessor with additional hardware registers 98, but it only supports operations for parts of the user code that have multiple overflows and restores. This tool is responsible for informing the database used by the search engine 106 that estimates about the hardware cost of the coprocessor and about how well the user's algorithms perform have improved. As noted above, the search engine 106 makes a global determination as to whether a suggested coprocessor 98 would result in a better configuration.

Alternatively, or in combination, a compiler-like tool checks whether the user program uses bit-masking operations to ensure that certain variables are never larger than certain limits. In this case, the tool suggests to the search engine 106 a coprocessor 98 that uses a data type consistent with user limits (eg, 12-bit or 20-bit or any other sized integer). In the third algorithm used in another embodiment, for user programs written in C++ language, tools like compiling programs find that a lot of time is consumed in operations on user-defined abstract data types. If all operations are based on a data type suitable for TIE, the algorithm proposes to the search engine to use a TIE coprocessor to implement all operations on this data type.

To generate instruction decode logic for processor 60, a set of signals is generated for each set of opcodes defined in the configuration specification. By simply adding the following statement

opcode NAME FIELD=VALUE

rewrite to HDL statement

assign NAME=FIELD=VALUE;

and will

opcode NAME FIELD=VALUE PARENTNAME[FIELD2=

VALUE2]

rewrite to

assign NAME=PARENTNAME & (FIELD==VALUE)

to generate the code.

The generation of register interlocks and pipeline signals has also been automated. This logic is also generated based on the information in the configuration specification. Based on the register usage information contained in the iclass statement and the latency of the instruction, the resulting logic inserts a hang (or bubble) when the source operand of the current instruction depends on the destination operand of a previous instruction that has not yet completed ). The mechanisms to implement this suspend functionality are implemented as part of the core hardware.

Illegal instruction detection logic is generated by ORing individual generated instruction signals and ANDing the results with their field constraints:

assign illegalinst=! (INST1|INST2...|INSTn);

Each instruction decode signal and the illegal instruction signal are available as output of the decode module and as input to the handwriting processor logic.

To generate additional processor features, the present embodiment uses a Verilog ^(TM) description of the configurable processor 60, augmented with a Perl-based preprocessor language. Perl is a full-featured language, including complex control structures, subroutines, and I/O devices. In one embodiment of the invention, a preprocessor called TPP (which itself is a Perl program, as shown in the source program listing in Appendix B), scans its input and identifies certain lines as using the preprocessor. preprocessor code (those prefixed with a semicolon for TPP) written in a processor language (Perl for TPP), and builds a program that includes lines and statements that have been extracted to produce text for other lines. Non-preprocessor lines may have embedded expressions in their places where expressions produced as a result of TPP processing are substituted. The resulting program is then executed to generate source code, ie, Verilog ^(TM) code to describe the detailed processor logic 40 (TPP is also used to configure the software development tool 30, as will be seen below).

When used in this context, since it allows constructs such as configuration specification queries, conditional expressions, and iterative constructs to be incorporated into Verilog ^TM code, and as noted earlier, ^allows Configuration instructions 100 implement embedded expressions, so TPP is a powerful preprocessing language. For example, a TPP assignment based on a database query like

; $endian = config_get_value("IsaMemoryOrder")

Here, config_get_value is a TPP function to query the configuration specification 100, IsaMemoryOrder is a flag set in the configuration specification 100, and $endian is a TPP variable that will be used to generate Verilog ^TM code later.

TPP conditional expressions can be

;if(config_get_value("IsaMemoryOrder") eq "LittleEndian")

; {execute Verilog ^TM code in little-endian order}

;otherwise

;{Execute Verilog ^TM code in big-endian order}

Iterative loops can be implemented using the TPP structure, for example

;for ($i=0; $i < $ninterrupts; $i++)

; {do Verilog ^TM code for each of 1...N interrupts}

Here, $i is a TPP loop index variable and $ninterrupts is the number of interrupts specified for processor 60 (obtained from configuration specification 100 using config_get_value).

Finally, TPP code can be embedded into Verilog ^TM expressions, such as

wire[`$ninterrupts-1`:0] srInterruptEn;

xtscenflop #(`$ninterrupts`) srintrenreg(srInterruptEn, srDataIn_W[`$ninterrupts-1`:0], srIntrEnWEn, !cReset, CLK);

Here, $ninterrupts defines the number of interrupts and determines the width (in bits) of the xtscenflop block (a flip-flop primitive block);

srInterruptEn is the output of the flip-flop, defined as a string of appropriate number of bits;

srDataIn_W is the input of the flip-flop, but only the relevant bits are input according to the number of interrupts;

srIntrEnWEn is the write enable signal of the flip-flop;

cReset is the clear input to the flip-flop; and

CLK is the input clock to the flip-flop.

For example, given the following input to TPP:

; # Timer Interrupt

; if (SIsaUseTimer) {

wire[`Swidth-1`:0] srCCount;

wire accountWEn;

//------------------------------------------------ --------------

// CCOUNT Register

//------------------------------------------------ ---------------

assign accountWEn = srWEn_W && (srWrAdr_W == `SRCCOUNT);

xtflop # (`Swidth`)srccntreg-(srCCount, (ccountWEn?srDataIn_W:

srCCount+1), CLK);

; for (Si=0; Si<STimerNumber; $i++){

//------------------------------------------------ --------------

// CCOMPARE Register

//------------------------------------------------ --------------

-

wire[`Swidth-1`:0] srCCompare`$i`;

wire ccompWEn `$i`;

assign ccompWEn`Si` = srWEn_W && (srWrAdr_W == `SRCCOMPARE`$i`);

xtenflop #(`Swidth`) srccmp`$i`reg

(srCCompare`$i`, srDataIn_W, ccompWEn`Si`, 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;

wire accountWEn;

//------------------------------------------------ --------------

// CCOUNT Register

//------------------------------------------------ --------------

assign accountWEn = srWEn_W && (srWrAdr_W == `SRCCOUNT);

xtflop #(32) srccntreg(srCCount, (ccountWEn? srDataIn_W:

srCCount+1), CLK);

//------------------------------------------------ --------------

// CCOMPARE Register

//------------------------------------------------ --------------

wire[31:0] srCCompareO;

wire ccompWEnO;

assign ccompWEnO = srWEn_W && (srWrAdr_W == SRCCOMPAREO);

xtenflop #(32) srccmpOreg

(srCCompareO, srDataIn_W, ccompWEnO, CLK);

assign setCCompIntrO = (srCCompareO == srCCount);

assign clrCCompIntrO = ccompWEnO;

//------------------------------------------------ --------------

// CCOMPARE Register

//------------------------------------------------ --------------

wire[31:0] srCComparel;

wire ccompWEnl;

assign ccompWEnl = srWEn_W && (srWrAdr_W == `SRCCOMPARE1);

xtenflop #(32) srccmplreg

(srCComparel, srDataIn_W, ccompWEnl, CLK);

assign setCCompIntrl = (srCComparel == srCCount);

assign clrCCompIntrl = ccompWEnl;

The HDL description 114 thus generated is used to synthesize the hardware for implementing the processor, for example in block 122 using DesignCompiler ^™ made by Synopsys Corporation. Then, in block 128 using, for example, the Silicon Ensemble ^™ provided by Cadence Corporation or by Avent! Apollo ^TM provided by the company places and routes the results. Once the components have been routed, the results are used in block 132 for back-annotation and timing verification of the wiring using, for example, PrimeTime ^(TM) provided by Synopsys, Inc. The product of this processing is a hardware profile 134, which can be used by the user to provide further input to the configuration capture program 20 for further configuration iterations.

As previously described in connection with logic synthesis section 122, one of the results of configuring processor 60 is a set of custom HDL files from which specific gate- level implementation. Design Compiler ^TM provided by Synopsys is such a tool. To ensure correct and high-performance gate-level implementation, this example provides the scripts needed to automate the synthesis process in a customer environment. In providing such a manuscript, the challenge is to support multiple synthetic methodologies and implementation goals of different users. In order to meet the first kind of challenge, the present embodiment divides the manuscript into smaller and functionally complete manuscripts. One such example is to provide a script that reads all the HDL files associated with a particular processor configuration 60, and a timing constraint script that sets the unique timing requirements in the processor 60, and a script book, which writes the synthesis results in a way that can be used for the placement and routing of gate-level netlists. In order to meet the second challenge, this embodiment provides a script for each implementation goal. One such example would be to provide a recipe for the fastest cycle time, a recipe for the smallest silicon area, and a recipe for the lowest power consumption.

These scripts are also used in other stages of processor configuration. For example, once the HDL model of processor 60 has been written, a simulation program can be used to verify correct operation of processor 60, as described above in connection with block 132. Typically, this is done by running various test programs or diagnostic programs on the emulated processor 60 . Running a test program in the emulated processor 60 may require many steps, such as generating an executable image of the test program, generating a representation of the executable image that can be read by the emulation program 112, generating a temporary layout to collect simulation results for later analysis, analyze simulation results, and so on. In the prior art, this is done using multiple discarded manuscripts. These scripts have built-in knowledge about the simulation environment, such as which HDL files should be included, where in the directory structure they can be found, which files are required in the test bench, and so on. In the current design, the preferred mechanism is to write a script template configured by parameter substitution. This configuration mechanism also uses TPP to generate a list of files needed in the simulation.

Moreover, during the verification process of program block 132, it is usually necessary to write other scripts to allow the designer to run a series of test programs. Often used to run regression suites, it assures the designer that a given change in the HDL model will not introduce new errors. Regression manuscripts are also often discarded due to their many embedded assumptions about filenames, locations, etc. As mentioned above, for a single test program, in order to generate an operation script, the regression script is written as a template. When configuring, configure the template by replacing various parameters with actual values.

The final step in the process of converting an RTL description to a hardware implementation is to use place and route (P&R) software to convert the abstract netlist into a geometric representation. The P&R software analyzes the connectivity of the netlist and determines the location of the cells. It then tries to draw connections between all units. Clock nets usually receive special attention and are routed as the last step. This process may be facilitated by providing certain information to the tools, such as which units are desired to be clustered together (called software clusters), the relative positions of the units, which nets are desired to have small propagation delays, and so on.

To make this process easier and to ensure compliance with desired performance goals—cycle time, area, power consumption—the configuration mechanism generates a set of scripts, or input files, for the P&R software. These scripts also contain information such as how many power and ground connections are required, how these connections should be distributed along the boundary, and so on. These scripts are generated by querying a database containing information on how many software clusters to generate, and which units should be included in them, which nets are important in timing, and so on. These parameters change depending on which options have been selected. These scripts must be configured according to the various tools to be used for place and route.

Optionally, the configuration mechanism can request further information from the user and send it to the P&R script. For example, the interface can ask the user the desired aspect ratio for the final layout, how many buffer stages should be inserted in the clock tree, which side the input and output pins should be placed on, the relative or absolute position of these pins, power and ground Width and location of bus bars, etc. These parameters will then be sent to the P&R script to produce the desired layout.

More complex scripts can be used, supporting eg more complex clock trees. A common optimization scheme to reduce power consumption is to gate the clock signal. However, since it is difficult to balance the delays of all branches, this makes clock tree synthesis a more difficult problem. The configuration interface will require the user to use the correct units for the clock tree, and perform partial or full clock tree synthesis. This can be done by knowing where each gated clock is located in the design and by evaluating the delay from the qualifying gate to the clock input of each flip-flop. It then places a constraint on the clock tree synthesis tool that the delays of the clock buffers match the delays of the individual gating cells. In the current embodiment, this is done by a generic Perl script. This script reads out clock gating information generated by the configuration agent based on which options are selected. Once the design has been placed and routed, and before the final clock tree synthesis is complete, the Perl script is run.

Further improvements can be made to the above-mentioned special processing procedure. In particular, we will describe a process by which users can obtain similar hardware feature information almost instantaneously, without having to spend hours running those CAD tools. This process has several steps.

The first step in this process is to divide the set of all configuration options into groups of orthogonal options such that the effect of an option in one group on hardware characteristics is independent of options in any other group. For example, the MAC16 unit has no effect on the hardware characteristics of any other option. In this way, an option group with only MAC16 options is formed. A more complex example would be an option group containing interrupt options, advanced interrupt options, and timer options, since the effect on hardware characteristics depends on the specific combination of these options.

The second step is to characterize the effect of each option group on the hardware characteristics. This characterization is achieved by obtaining the effect of various combinations of options within the set on hardware characteristics. For each combination, this characterization was obtained using a previously described procedure in which an actual implementation was derived and its hardware characteristics measured. Such information is stored in an assessment database.

The final step is to derive special formulas, using curve fitting and interpolation techniques, to calculate the impact of specific combinations of options in each option group on hardware characteristics. Depending on the nature of each option, different formulas are used. For example, since each additional interrupt vector adds roughly the same logic to the hardware, we use a linear function to simulate its effect on the hardware. In another example, there is a timer unit that requires advanced interrupt options, so the formula for the effect of the timer options on the hardware is a conditional formula involving several options.

It is useful to provide quick feedback on how the choice of architecture affects the runtime performance of the application as well as the size of the code. Several sets of benchmark programs from various application domains are selected. For each domain, a database is pre-built that evaluates how different architectural design decisions affect the runtime performance and code size of each application in that domain. As the user changes the design of the architecture, the database is queried for the application domain that the user is interested in or for multiple domains. The results of the evaluation are sent to the user, enabling her to obtain an estimate of the trade-off between software benefit and hardware cost.

The rapid evaluation system can be easily extended to make recommendations on how to modify a configuration to further optimize the processor. One such example is associating each configuration option with a set of numbers representing the option's incremental impact on various cost metrics such as area, latency, and power. Using the rapid assessment system makes it easy to calculate the incremental cost impact of a given option. It just involves two calls to the evaluation system, one with options and one without. The cost difference between these two assessments represents the impact of this option on increased costs. For example, the impact of the MAC16 option on increased area is calculated by evaluating the area cost of two configurations (with and without the MAC16 option). The difference when there is the MAC16 option is then displayed in the interactive configuration system. Such a system can guide the user through a series of single-step improvements to an optimized solution.

Turning now to the software side of the automatic processor configuration process, this embodiment of the invention configures the software development tools 30 so that they are specific to that processor. The configuration process begins with a software development tool 30 that can be generalized to a variety of different system and instruction set architectures. Such retargetable tools have been extensively researched and are well known in the industry. This embodiment uses the GNU family of tools, which is free software, including, for example, the GNU C compiler, the GNU assembler, the GNU debugger, the GNU linker, the GNU tracer, and various utilities. These tools 30 are then automatically configured by generating parts of the software directly from the ISA description, and by modifying parts of the handwritten software using TPP.

The GNU C compiler can be configured in several different ways. Given the core ISA description, much of the machine-dependent logic can be handwritten in assembler. This part of the compiler is common across the instruction sets of configurable processors, and manual retargeting allows fine-tuning for best results. However, even for this handwritten part of the compiler, some code is still automatically generated from the ISA description. In particular, the ISA description defines the set of constant values that can be used in the immediate fields of various instructions. For each immediate field, a judgment function is generated to check whether a specific constant value can be encoded in the field. These predicate functions are used by the compiler when generating code for the processor 60 . Automating this aspect of compiler configuration eliminates the chance of inconsistencies between ISA-based descriptions and compilers, and it enables constants in the ISA to be changed with minimal effort.

After preprocessing with TPP, several parts of the compiler are configured. For each configuration option controlled by parameter selection, the corresponding parameters in the compiler are all set via TPP. For example, the compiler has a flag variable indicating whether the target processor 60 uses big-endian or little-endian order, and this variable is automatically set using a TPP command that reads the order from the configuration specification 100 parameter. The TPP is also used to conditionally enable or disable the hand-coded portion of the compiler that generates packages for each of the optional ISAs, depending on whether the corresponding package is enabled in the configuration specification 100 . For example, if the configuration specification only includes option 90 of MAC16, only the codes for generating multiplication/accumulation instructions are included in the compiler.

The compiler is also configured to support designer-defined instructions specified via the TIE language. There are two levels of this support. At the lowest level, designer-defined directives can be used in macros, intrinsic functions, or inline (external) functions in the code being compiled. This embodiment of the invention produces a C-language header file that defines in-line functions as "in-line assembly" code (a standard feature of the GNU C compiler). After giving the TIE description of the opcode and its operands defined by the designer, the process of generating the header file is a straightforward process of converting to the online assembly syntax of the GNU C compiler. An alternative implementation generates a header file containing the C preprocessor's macros that specify instructions for in-line assembly. Yet another alternative uses TPP to add intrinsics directly to the compiler.

Provides Layer 2 support for designer-defined directives by letting the compiler automatically identify opportunities to use them. These TIE instructions can be defined directly by the user or generated automatically during configuration. TIE code is automatically inspected and converted to equivalent C language functions before compiling the user application. This step is also used to quickly simulate various TIE instructions. The equivalent C language function is partially compiled into a tree-based intermediate representation used by the compiled program. For each TIE instruction, this representation is stored in a database. When a user application is compiled, part of the compilation process is a pattern matching program. User applications are compiled to a tree-based intermediate representation. In the user program, the pattern matching program scans each tree from the bottom. At each step of the scan, the pattern matching routine checks whether the immediate representation rooted at the current point matches any TIE instructions in the database. If there is a match, the match is registered. After completing the scan of each tree, the maximum matching set is selected. In this tree, each maximum match is replaced by an equivalent TIE instruction.

The above algorithm will automatically identify opportunities to use stateless TIE instructions. Various additional schemes can also be used to automatically identify opportunities to use stateful TIE instructions. A previous section described an algorithm for automatically selecting possible TIE instructions with state. The same algorithm is used to automatically use TIE instructions in C or C++ applications. When a TIE coprocessor is defined to have more registers but only a limited set of operations, regions of the code are scanned to see if they are subject to register overflow and if those regions use only available operations collection. If such regions are found, the code in those regions will automatically be changed to use the coprocessor instructions and registers 98 . Switch operations are generated at the boundaries of the regions to move data into or out of coprocessor 98 . Similarly, if a TIE coprocessor has been defined to operate on integers of different sizes, each code region is checked to see if all data in that region is accessed because it is of a different size. For each region that matches, its code is converted and the glue code is added to the boundary. Similarly, if a TIE coprocessor has been defined to implement an abstract data type of the C++ language, all operations in that data type are replaced by instructions of the TIE coprocessor.

Note that both automatically suggesting TIE instructions and automatically using TIE instructions are independently useful. Via the internal mechanism, the user can manually use the suggested TIE instructions and apply the used algorithm to the manually designed TIE instructions or coprocessors 98 .

No matter how the designer-defined instructions are generated, either through various online functions or by means of automatic recognition, the compiler needs to know the potential side effects of the designer-defined instructions so that it can optimize these instructions and scheduling. To improve performance, conventional compilers optimize user code so that desired characteristics, such as runtime performance, code size, or power consumption, are optimized. As is well known to a skilled practitioner, such optimizations include such things as rearranging instructions, or replacing certain instructions with others that are semantically equivalent. In order to optimize well,

The compiler should know how each instruction affects different parts of the machine. Two instructions that read and write to different parts of the machine state can be freely reordered. Two instructions that access the same part of the machine state generally cannot be reordered. With conventional processors, state reads and/or writes are performed by various instructions through hardware wiring, sometimes through tables, into the compiler. In one embodiment of the present invention, the TIE instructions are conservatively set to read and write all states of processor 60 . This enables the compiler to generate correct code, but limits the ability of the compiler to optimize the code when a TIE instruction is present. In another embodiment of the invention, a tool automatically reads the TIE definition and finds for each TIE instruction which state is read or written by that instruction. The tool then modifies the tables used by the compiler's optimizer to accurately simulate the effect of each TIE instruction.

Like the compiler, the machine-dependent parts of the assembler 110 include automatically generated parts as well as hand-coded parts configured with TPP. Hand-written code supports certain characteristics common to all configurations. However, the main task of the assembler 110 is to encode machine instructions, and the encoding and decoding software for the instructions can be automatically generated from the ISA description.

Since the encoding and decoding of instructions is useful in several different software tools, this embodiment of the invention brings together the software to perform these tasks in a single software library. This library is automatically generated using the information in the ISA description. The library defines an enumeration for each opcode, a function that efficiently maps strings of opcode mnemonics to members of the enumeration (StringToOpcode), and tables specifying instruction lengths for each set of opcodes ( InstructionLength), number of operands, (numberOfOperands), operand field, operand type (ie, register or immediate) (operandType), binary encoding (encodeOpcode), and mnemonic string (opcodeName). For each operand field, the library provides accessor functions to encode (fieldSetFunction) and decode (fieldGetFunction) the corresponding bits in the instruction word. All of this information is readily available in the ISA description; generating the library software simply translates this information into executable C code. For example, the encoding of each instruction is recorded in a C array variable, where each row is the encoding for a particular instruction by setting each opcode field to the one specified for that instruction in the ISA description value to generate the above encoding; the encodeOpcode function returns the value of that array only for a given set of opcodes.

The library also provides a function to decode opcodes in binary instructions (decodeInstruction). This function is generated as a sequence of nested switch statements, where the outermost switch tests the sub-opcode field at the top level of the opcode hierarchy, and the nested switch statements test the sub-opcode fields at the top of the opcode hierarchy. Each sub-opcode field is tested at progressively lower levels. Therefore, the code generated for this function has the same structure as the opcode hierarchy itself.

Given this library for encoding and decoding, the implementation of assembler 110 is easy. For example, the instruction encoding logic in assembler is quite simple:

AssembleInstruction(String mnemonic, int arguments[])

begin

opcode = stringToOpcode(mnemonic);

if(opcode==UNDEFINED)

Error("Unknown opcode");

instruction = encodeOpcode(opcode);

numArgs = numberOfOperands(opcode);

for i=0, numArgs-1 do

begin

setFun = fieldSetFunction(opcode, i);

setFun(instruction, arguments[i]);

end

return instruction;

end

Implementing a disassembler 110 (which converts binary instructions into a readable form that tightly reassembles assembly code) is equally straightforward:

DisassembleInstruction(BinaryInstruction instruction)

begin

opcode = decodeInstruction(instruction);

instructionAddress+=instructionLength(opcode);

print opcodeName(opcode);

//Loop through the operands, disassembling each

numArgs = numberOfOperands(opcode);

for i=0, numArgs-1 do

begin

type = operandType(opcode, i);

getFun = fieldGetFunction(opcode, i);

value = getFun(opcode, i, instruction);

if(i!=O) print ",";//Commseparateoperands

//Print based on the type of the operand

switch(type)

case register:

printregisterPrefix(type), value;

case immediate:

print value;

case pc_relative_label:

print instructionAddress+value;

//etc. for more different operand types

end

end

This disassembler algorithm is used in a superior disassembler tool and is also used in debugger 130 to support debugging of machine code.

Compared to the compiler and assembler 110, the linker is less sensitive to configuration. Most linkers are standard, and even the machine-dependent parts are largely dependent on the core ISA description and can be hand-coded for a specific core ISA. Parameters such as sequence are set from configuration specification 100 using TPP. The memory map of the target processor 60 is one other aspect of configuration required by the linker. As before, use TPP to insert the parameters specifying the memory map into the linker. In this embodiment of the invention, the GNU linker is driven by a set of linker scripts, and it is these linker scripts that contain the memory map information. An advantage of this scheme is that if the memory map of the target system differs from that specified by the processor 60 at configuration time, additional linker scripts can be generated later without reconfiguring the processor 60 and without rebuilding the link program. Therefore, this embodiment includes a tool that configures a new linker script with different memory map parameters.

Debugger 130 provides various mechanisms for observing the state of the program during execution, stepping through an instruction over a period of time, introducing breakpoints, and performing other standard debugging tasks. The debugged program can run on the configured hardware implementation of the processor, or on the ISS126. In either case, the debugger presents the same interface to the user. When running the program on a hardware implementation, a small monitor program is incorporated into the target system to control the execution of the user program and communicate with the debugger via a serial port. When the program is run on the emulator 126, the emulator 126 itself performs those functions. Debugger 130 relies on configuration in several ways. It links with the instruction encoding/decoding library described above to support disassembly of machine code from the debugger 130 . The portion of the debugger 130 that displays the state of the registers of the processor, the monitor portion that provides information to the debugger 130 and the ISS 126 are generated by scanning the ISA description to find out which registers exist in the processor 60 .

Other software development tools 30 are standard and need not be changed for each processor configuration. Feature watchers and various applications fall into this category. These tools may need to be retargeted once run on the binary format files shared by all configurations of the processor 60, but they depend neither on the ISA description nor on other parameters in the configuration specification 100 .

The configuration specification is also used to configure a section of the simulation program shown in FIG. 13 called ISS126. The ISS126 is a software application that emulates the functional behavior of a configurable processor instruction set. Unlike opposed processor hardware models such as Synopsys' VCS and Cadence's Verilog XL and NC simulators, the ISS HDL model is an abstraction of the CPU executing instructions. Because it does not need to simulate every state change of every gate and register in the entire processor design, the ISS126 can run faster than hardware emulation.

ISS 126 allows programs generated for configured processors 60 to be executed on a host computer. It accurately reproduces the processor's reset and interrupt behavior, which allows the development of low-level programs such as device drivers and initialization code. This is especially useful when converting native code to embedded applications.

ISS126 can be used to identify potential problems, such as architectural assumptions, memory ordering considerations, etc., without downloading code to the actual embedded target.

In this embodiment, a C-like language is used to express ISS semantics pedagogically to build C operator building blocks, which translate instructions into functions. This language can be used to simulate the basic functions of interrupts, such as interrupt registers, bit settings, interrupt levels, vectors, etc.

The configurable ISS126 is used for the following 4 purposes or objectives as part of the system design and verification process:

— debugging software applications before hardware becomes available;

— Debugging system software (e.g. compilers and operating system components);

—Comparison with HDL simulation for hardware design verification. The ISS is used as a reference implementation of the ISA—during processor design verification, the ISS and processor HDL are run for diagnostics and applications, and traces from both are compared; and

- Analysis of software application performance (this may be part of the configuration process, or it may be used for further application tuning after the configuration of the processor has been selected).

All targets require the ISS 126 to be able to load and decode programs generated with the configurable assembler 110 and linker. They also require that the ISS's execution of instructions be semantically equivalent to the corresponding hardware execution and to the expectations of the compiled program. For these reasons, the ISS 126 derives its decoding and execution behavior from the same ISA files used to define the hardware and system software.

For the first and last goals listed above, it is important for the ISS126 to achieve the required accuracy as quickly as possible. Thus, ISS126 allows dynamic control over the level of detail of the simulation. For example, details of the cache memory are not emulated unless requested, and the emulation of the cache memory can be turned off or on dynamically. Furthermore, components of ISS 126 (eg, cache memory and pipeline models) are configured before ISS 126 is compiled such that at runtime, ISS 126 makes few configuration-dependent behavioral choices. In this way, all configurable behavior of the ISS is derived from well-defined sources involving other parts of the system.

With respect to goals 1 and 3 listed above, it is important for ISS126 to provide operating system services to applications when the operating system OS is not already serving the system (target) under design. It is also important for these services that they are provided by the target OS when this is a relevant part of the debugging process. In this way, the system provides a design for the flexible delivery of these services between the ISS host and the simulation target. The current design relies on a combination of ISS dynamic control (the trap SYSCALL instruction can be turned on and off) and the use of a dedicated SIMCALL instruction to request host operating system services.

The last goal requires ISS126 to emulate certain aspects of processor and system behavior below the level specified by the ISA. In particular, the cache model of the ISS is constructed by generating C code for the model from a Perl script that extracts parameters from the configuration database 100 . In addition, details of the pipeline behavior of individual instructions, such as interlocks based on register usage and functional unit validity requirements, are also derived from the configuration database 100 . In the current embodiment, a dedicated pipeline description file specifies this information in a syntax similar to the LISP language.

The third goal requires precise control over interrupt behavior. For this purpose, a special non-architectural register in the ISS126 is used to suppress various interrupt enables.

ISS126 provides several interfaces to support different targets for its use:

— a batch command or command line mode (usually used in conjunction with the first and last targets);

— a command loop mode that provides non-symbolic debugging capabilities, e.g., breakpoints, watchpoints, steps, etc. — frequently used for all 4 targets; and

- A socket interface that allows the ISS126 to be used by a software debugger as an execution backend (this should be configured to read and write register states for a particular configuration selected).

— A scriptable interface that allows very detailed debugging and performance analysis. In particular, this interface can be used to compare the behavior of applications with different configurations. For example, at any breakpoint, the running state from one configuration can be compared to, or transitioned to, the running state from another configuration.

The simulation program 126 also has both hand-coded and automatically generated parts. The hand-coded parts are conventional, except for instruction decoding and execution, both of which are generated from tables produced by the ISA description language. These tables decode the instruction by starting with the base opcode found in the instruction word to be executed, indexing into a table with the value of the field, and continuing until a leaf opcode is found (i.e., one without opcodes defined in the pattern of other opcodes) until. The table then gives a pointer to the code converted from the TIE code specified according to the semantic specification for the instruction. This set of code is executed to emulate the instruction.

ISS 126 can optionally trace the execution of the simulated program. This tracking uses a program counter (PC) sampling technique well known in the industry. At regular intervals, emulator 126 samples the program counter of the processor being emulated. It builds a histogram based on the number of samples per code region. The emulator 126 also counts the number of times each edge in the call graph is executed by incrementing the counter when a call instruction is emulated. When the simulation process is complete, the simulator 126 writes an output file, including histograms and call graph edge counts, in a format that can be read by a standard trace watcher. Since the simulated program 118 does not need to be modified in an instrumental manner (as in a standard tracing technique), the tracing overhead does not affect the simulation results, and the tracing is completely non-destructive.

Preferably, the system performs effective hardware processor emulation as well as software processor emulation. For this purpose, this embodiment provides a dummy board. As shown in FIG. 6 , the emulation board 200 uses a composite programmable logic device 202 . For example, Altera Flex 10K200E emulates processor configuration 60 from the hardware. Once programmed with the processor netlist generated by the system, the CPLD device is functionally equivalent to the final ASIC product. It provides the benefit that a physical implementation of the processor 60 is feasible, runs faster than other simulation methods such as ISS or HDL, and is cycle accurate. However, it cannot achieve the high-frequency goals that the final ASIC can achieve.

The board enables designers to evaluate various processor configuration options and begin software development and debugging earlier in the design cycle. It can also be used for functional verification of this processor configuration.

The emulation board 200 has several resources on it that make development, debugging and verification of software easy. These include the CPLD device 202 itself, EPROM 204 , SRAM 206 , synchronous SRAM 208 , flash memory 210 and two RS232 serial channels 212 . Serial channel 212 provides a communications link to a UNIX or PC host for downloading and debugging user programs. The configuration of processor 60, in the form of a CPLD netlist, is downloaded to CPLD 202 via a dedicated serial link to the device's configuration port 214, or via dedicated configuration ROMs 216.

The resources available on board 200 are also configurable to a certain extent. Since the mapping is done by an easily changeable programmable logic device (PLD) 217, the memory map of the various storage elements on the board can be easily changed. Likewise, by using larger (capacity) memory devices and properly sizing tag buses 222 and 224 (connected to caches 218 and 228), the caches 218 and 228 used by the processor core can be made smaller. for extensibility.

Using this board to evaluate a specific processor configuration involves several steps. The first step is to obtain a set of RTL files describing a specific configuration of the processor. The next step is to synthesize a gate-level netlist from the RTL description using any of a variety of commercially available synthesis tools. One such example is the FPGA EXPRESS from Synopsys. A gate-level netlist is then used to obtain a CPLD implementation using tools typically provided by distributors. One such tool is Maxplus2 from Altera Corporation. The final step is to download the implementation to the CPLD chip on the emulation board, using the programmer again provided by the CPLD distributor.

Since one of the purposes of the emulation board is to support rapid prototyping implementations for debugging purposes, it is important that the CPLD implementation process outlined in the previous paragraphs be automated. To achieve this goal, the various files presented to the user are customized by grouping all related files into a single directory. Subsequently, a fully customized synthesis script is provided that synthesizes the specific processor configuration into the specific FPGA device selected by the customer. Completely customized implementation scripts used by the dealer's various tools are also generated at the same time. Such syntheses and implementation scripts functionally ensure the correct implementation with optimal performance. By including appropriate commands in the script to read in all RTL files associated with a particular processor configuration, by including appropriate commands to assign chip pins based on the I/O signals in the processor configuration Functional correctness is achieved by including commands to obtain specialized logic implementations for certain important parts of the processor logic, such as clock gating. The manuscript also improves the performance of this implementation by assigning detailed timing constraints to all processor I/O signals, and by special handling of some important signals. An example of a timing constraint is assigning a specific input delay to a signal by taking into account the delay of that signal on the board. An example of important signal processing is distributing clock signals to dedicated global wires in order to obtain low clock delay variation across CPLD chips.

Preferably, the system also configures a set of verification programs for configured processors 60 . Verification of most composite designs like microprocessors involves the following flow:

- Build a test bench to simulate the design and compare the outputs, either within the test bench or using an external model like the ISS126;

— write diagnostic procedures to generate stimuli;

- Use a scheme like row coverage of finite state machines to measure the coverage of verification, including covering HDL, reducing error rate, number of vectors run on the design, etc.; and

- If coverage is insufficient - write more diagnostics and use various tools to generate diagnostics to further practice the design.

The present invention uses a flow somewhat similar to this, but all components of the flow are modified to allow for the configurability of the design. This methodology includes the following steps:

- Build a test bench for a specific configuration. The configuration of the test bench uses a scheme similar to that described for HDL and supports all options and extensions supported therein, i.e. cache (capacity) size, bus interface, clocks, interrupt generation, etc.;

- Runs self-test diagnostics on a specific configuration of HDL. The diagnostics themselves are configurable so that they are tailored to a specific piece of hardware. Which segment of the diagnostic program is chosen to run also depends on the configuration;

— run diagnostics generated in a pseudo-random manner and compare the processor state to the ISS 126 after each instruction is executed; and

- Coverage for measurement verification - Coverage tools using measurement functions and line coverage. Likewise, monitoring programs and checking programs are run along with diagnostic programs to monitor illegal states and conditions. All of these are configurable for a particular configuration specification.

All verification components are verifiable. Use TPP for configurability.

The test bench is a Verilog ^(TM) model of the system with the processor 60 configured therein. In the case of the present invention, the test bench consists of:

- cache memory, bus interface, external memory;

— external interrupt and bus error generation; and

— Clock generation.

Since nearly all of the above features are configurable, the testbench itself needs to support configurability. In this way, for example, the size and width of the cache memory, and the number of external interrupts are automatically adjusted according to the configuration.

The test bench provides stimuli to the device under test, the processor 60 . It does this by providing assembly-level instructions preloaded into memory. It also generates various signals used to control the behavior of processor 60, such as various interrupts. Again, the frequency and timing of these signals are controlled and automatically generated by the test bench.

Diagnostics have two types of configurability. First, the diagnostic program uses the TPP to determine what to test. For example, a diagnostic program has been written to test for software interrupts. This diagnostic needs to know how many software interrupts there are in order to generate the correct assembly code.

Next, processor configuration system 10 should determine which diagnostics are appropriate for the configuration. For example, a diagnostic program written to test a MAC unit would not work on a processor 60 that does not contain such a unit. In this embodiment, this is accomplished by using a database containing information about each diagnostic procedure. The database can include the following information for each diagnostic procedure:

— use this diagnostic procedure, if an option has been selected;

- if the diagnostic program cannot be run with various interrupts;

— If the diagnostic program is running, various special libraries or various handles are required; and

- If the diagnostic program cannot be run under the condition of co-simulation with ISS126.

Preferably, the processor hardware description includes 3 types of test tools: test generator tools, monitor and coverage tools (or checkers), and a co-simulation mechanism. Test generator tools are tools that intelligently generate a sequence of processor instructions. They are sequences of various pseudo-random test generators. This embodiment uses two types internally - a specially developed one called RTPG and another based on an external tool called VERA (VSG). Both have configurability built around them. Based on the effective commands for a configuration, they will generate a sequence of commands. These tools will also be able to handle newly defined instructions from TIE - such that these newly defined instructions are randomly generated for testing purposes. This embodiment includes monitoring procedures and checking procedures to measure the coverage of design verification.

Monitors and coverage tools are run with a regression run. The coverage tool monitors what the diagnostic program is doing, as well as the functions and logic of the HDL being practiced. All this information is collected throughout the regression run and analyzed later to get hints as to which parts of that logic need further testing. This embodiment uses several configurable functional coverage tools. For example, for a particular finite state machine, it does not include all states according to a configuration. So, for that configuration, the functional coverage tool doesn't need to try to check those states or transitions. This is done by enabling the tool to be configured with TPP.

Similarly, there are also various monitoring programs to check various illegal states that occur during HDL simulation. These illegal states can be expressed as various errors. For example, in a 3-state bus, both drivers should not be high at the same time. These monitoring programs are configurable—according to whether a specific logic is included in the configuration, some inspection items are added or canceled.

Co-simulation mechanism connects HDL and ISS126 together. It is used to check whether the state of the processor is the same in HDL and ISS126 at the end of the instruction. It is also configurable insofar as it knows which features to incorporate for each configuration and which states need to be compared. Thus, for example, the breakpoint feature of the data (results in) adding a special register. This mechanism needs to know how to compare against this new special purpose register.

The instruction semantics specified via the TIE can be translated into functionally equivalent C language functions for use in the ISS126 and for testing and verification by system designers. In the configuration database 106, the semantics of an instruction is converted into a C language function by various tools (the tool uses a standard syntax analysis tool to build a syntax tree), and then follows the syntax tree to check whether the syntax rules are met, And output the corresponding expression written in C language. This conversion requires a pre-pass to assign bit widths to all expressions and rewriting the syntax tree to simplify some conversions. These translators are relatively simple compared to other translators such as HDL to C or C to assembly language compilers, and can be written by professionals starting from TIE and C language specifications.

Using the compiler configured by the configuration file 100 and the assembler/disassembler 100, the benchmark application source code 118 is compiled and assembled, and, using the sample data set 124, it is simulated to obtain a software profile 130, which is also Sent to the user to configure the capture program for feedback to the user.

Having the ability to obtain hardware and software price/benefit characteristics for any choice of configuration parameters opens up opportunities for further optimization of the system by the designer for any configuration choice. In particular, this will allow the designer to choose the best configuration parameters that optimize the overall system according to some valuation function. One possible processing is based on a greedy strategy, ie by repeatedly selecting or not selecting a configuration parameter. At each step, those parameters are selected that have the best impact on overall system performance and price. This step is repeated until no single parameter that can improve the performance and price of the system can be found. Other extensions include looking at a set of configuration parameters simultaneously, or using more complex search algorithms.

In addition to obtaining the optimal choice of configuration parameters, this process can also be used to construct various extensions to the optimal processor. Due to the large number of possibilities in various extensions of the processor, it is important to limit the number of extension candidates. One technique is to analyze application software and focus only on those instruction extensions that improve system performance or price.

Having described the operation of an automatic processor configuration system according to this embodiment, an example of processor macroarchitecture configuration will now be given. The first example shows the advantages of applying the invention to image compression.

Motion estimation is an important part of many image compression algorithms, including MPEG video and 263 conferencing applications. Video image compression attempts to use the similarity from one frame to another to reduce the storage capacity required for each frame. In the simplest case, each block of the image to be compressed can be compared with the corresponding block (same X, Y position) of the reference image (only the immediately leading or subsequent image is compressed). Compression of image differences between frames is generally more bit efficient than compression of individual images. In video sequences, unique image features often move between frames, so the closest agreement between blocks in different frames is usually not exactly at the same X,Y position, but some Deviate. If some important part of the image moves between frames, it is necessary to identify and compensate for this motion before calculating these differences. This fact means that by encoding the differences between successive images (including the various unique features, as well as the X, Y deviations in the sub-images used for the calculated differences), the best contrast can be obtained. strong expression. The deviation in position used to calculate the image difference is called a motion vector.

In this type of image compression, the most computationally intensive task is to determine the most appropriate motion vector for each block. A common method of selecting a motion vector is to find the vector with the smallest average difference between pixels among each block of the compressed image and the set of candidate blocks of the previous frame image. Candidate blocks are the set of all neighboring blocks at positions surrounding the compressed block. The size of the image, the size of the block, and the size of each adjacent block, all affect the running time of the motion estimation algorithm.

Simple block-based motion estimation compares each sub-image of the image to be compressed with a reference image. In a video sequence, a reference image can precede or follow a subject image. In each case, the reference image should be considered valid by the decompression system before the subject image is decompressed. The comparison between the candidate blocks of an image to be compressed and the reference image is described as follows.

A search is performed for each block of the subject image around its corresponding location in the reference image. Typically, each color component (eg, YUV) of an image is analyzed separately. Sometimes, only one component, such as luminance, is analyzed. Compute the average pixel-to-pixel difference between the subject block and every possible block in the search area of the reference image. This difference is the absolute value of the difference in the size of the pixel values. The average value is proportional to the sum of N2 pixels in each pair of blocks (where N is the dimension of the block). The block of the reference image that yields the smallest average pixel difference defines the motion vector for that block of the subject image.

The following example shows a simple form of the motion estimation algorithm, which is then optimized for a small dedicated functional unit using TIE. This optimization yields a speedup of more than 10x, making processor-based compression suitable for many video applications. It illustrates the capabilities of a processor that combines ease of programming in a high-level language with the efficiency of dedicated hardware.

This example uses two matrices, OldB and NewB, representing the old image and the new image, respectively. The size of the image is determined as NX and NY. Block sizes are determined as BLOCKX and BLOCKY. Thus, the image consists of NX/BLOCKX by NY/BLOCKY blocks. The search area around a block is determined as SEARCHX and SEARCHY. Optimal motion vectors and values are stored in VectX, VectY, and VectB. The optimal motion vectors and values calculated by the base (reference) implementation are stored in BaseX, BaseY, and BaseB. These values are used to check the vectors computed by the implementation using instruction extensions. In the following C code segment, these basic definitions can be obtained:

#define NX 64 /*image width*/

#define NY 32 /*image height*/

#define BLOCKX 16 /*block width*/

#define BLOCKY 16 /*block height*/

#define SEARCHX 4 /*search region

width*/

#define SEARCHY 4 /*search region

height＊/

unsigned char OldB[NX][NY]; /*oldImage*/

unsigned char NewB[NX][NY]; /*newImage*/

unsignedshort VectX[NX/BLOCKX][NY/BLOCKY]; /* XmotionVector

*/

unsigned short VectY[NX/BLOCKX][NY/BLOCKY]; /* Y motion vector

*/

unsigned short VectB[NX/BLOCKX][NY/BLOCKY]; /*absolute

difference*/

unsigned short BaseX[NX/BLOCKX][NY/BLOCKY]; /*Base X motion

vector*/

unsigned short BaseY[NX/BLOCKX][NY/BLOCKY]; /*Base Y motion

vector*/

unsigned short BaseB[NX/BLOCKX][NY/BLOCKY]; /*Base absolute

difference*/

#define ABS(x) (((x)<0)?(-(x)):(x))

#define MIN(x,y) (((x)<(y))?(x):(y))

#define MAX(x,y) (((x)>(y))?(x):(y))

#define ABSD(x,y) (((x)>(y))?((x)one(y)):((y)-(x)))

The motion evaluation algorithm consists of 3 nested loops:

1. For each source block in the old image.

2. For each target block in the new image in the area surrounding the source block.

3. Calculate the absolute difference between each pair of pixels.

The complete code of the algorithm is listed below.

Reference software implementation

void

motion_estimate_base()

{

int bx, by, cx, cy, x, y;

int startx, starty, endx, endy;

unsigned diff, best, bestx, besty;

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(OldB[cx+x][cy+y],

NewB[bx＊BLOCKX+x][by＊BLOCKY+y]);

}

}

if(diff<best){

best = diff;

bestx=cx;

besty=cy;

}

}

}

BaseX[bx][by]=bestx;

BaseY[bx][by]=besty;

BaseB[bx][by]=best;

}

}

The basic implementation is simple, it cannot use much of the inherent parallelism in this block-to-block comparison. Configurable processor architectures provide two important tools that can significantly speed up the execution of such applications.

First, the ISA includes a powerful funneled shift primitive that allows fast fetching of misaligned fields in memory. This allows the inner loop of pixel comparisons to efficiently fetch groups of adjacent pixels from memory. The ring can be rewritten to run on 4 pixels (bytes) at the same time. In particular, for the purposes of this example, one wishes to define a new instruction to compute the absolute difference of 4 pixel pairs at the same time. However, before defining this new instruction, it is necessary to implement the algorithm again to take advantage of such an instruction.

The presence of this instruction allows such an improvement in the calculation of the inner loop difference that the opening of the loop becomes equally dramatic. The C code for the inner loop was rewritten to take advantage of the new sum-of-absolute-difference instruction and efficient shifting. Parts of the 4 overlapping blocks of the reference image can be compared in the same ring. SAD(x,y) is a new internal function corresponding to the added instruction. SRC(x, y) right-shifts the chain of x and y, and its displacement is stored in the SAR register.

Fast way of motion estimation using SAD instruction

/

void

motion_estimate_tie()

{

int bx, by, cx, cy, x;

int startx, starty, endx, endy;

unsigned diff0, diff1, diff2, diff3, best, bestx, besty;

unsigned *N, N1, N2, N3, N4, *O, A, B, C, D, E;

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(cy=starty; cy<endy; cy+=sizeof(long)){

for(cx=startx; cx<endx; cx++){

diff0=diff1=diff2=diff3=0;

for(x=0; x<BLOCKX; x++){

N=(unsigned*)&(NewB[bx*BLOCKX+x]

[by＊BLOCKY]);

N1=N[0];

N2=N[1];

N3=N[2];

N4=N[3];

O=(unsigned*)&(OldB[cx+x][cy]);

A=O[0];

B=O[1];

C=O[2];

D=O[3];

E=O[4];

diff0+=SAD(A, N1)+SAD(B, N2)+

SAD(C, N3)+SAD(D, N4);

SSAI(8);

diff1+=SAD(SRC(B,A),N1)+

SAD(SRC(C,B),N2)+SAD(SRC(D,C),

N3)+SAD(SRC(E,D),N4);

SSAI(16);

diff2+=SAD(SRC(B,A),N1)+

SAD(SRC(C,B),N2)+SAD(SRC(D,C),

N3)+SAD(SRC(E,D),N4);

SSAI(24);

diff3+=SAD(SRC(B,A),N1)+

SAD(SRC(C,B),N2)+SAD(SRC(D,C),

N3)+SAD(SRC(E,D),N4);

O+=NY/4;

N+=NY/4;

}

if(diff0<best) {

best = diff0;

bestx=cx;

besty=cy;

}

if(diff1<best) {

best = diff1;

bestx=cx;

besty=cy+1;

}

if(diff2<best) {

best = diff2;

bestx=cx;

besty=cy+2;

}

if(diff3<best) {

best = diff3;

bestx=cx;

besty=cy+3;

}

}

}

VectX[bx][by]=bestx;

VectY[bx][by]=besty;

VectB[bx][by]=best;

}

}

}

This implementation uses the following SAD function to evaluate the final new instruction:

4 bytes absolute difference summation

/

static inline unsigned

SAD (unsigned ars, unsigned art)

{

return ABSD(ars>>24, art>>24)+

ABSD((ars>>16) & 255, (art>>16) & 255)+

ABSD((ars>>8) & 255, (art>>8) & 255)+

ABSD(ars & 255, art &255);

}

To debug this new implementation, use the following test program to compare the two motion vectors and values calculated with the new implementation and with the base implementation:

main test program

/

int

main(int argc, char**argv)

{

int passwd;

#ifndef NOPRINTF

printf("Block=(%d,%d), Search=(%d,%d), size=(%d,%d)\n",

BLOCKX, BLOCKY, SEARCHX, SEARCHY, NX, NY);

#endif

init();

motion_estimate base();

motion_estimate_tie();

passwd = check();

#ifndef NOPRINTF

printf(passwd? "TIE version passed\n": "UTIE version

failed\n″);

#endif

return passwd;

}

This simple test program will be used throughout the development process. Here, a convention that should be followed is that the main program should return 0 when an error is detected, and 1 otherwise.

Using TIE allows for quick specification of new instructions. A configurable processor generator can fully implement these instructions, both in hardware implementations and software development tools. Hardware synthesis generates the optimal integration of new functions into the hardware datapath. The configurable processor's software environment fully supports new instructions in the C and C++ compilers, assemblers, symbolic debuggers, trace programs, and cycle-accurate instruction set emulators. The rapid regeneration of hardware and software makes dedicated instructions a fast and reliable tool for application acceleration.

This example uses TIE to implement a simple instruction to perform pixel difference, absolute value, and accumulation for 4 pixels in parallel. This single-byte instruction can perform 11 basic operations (multiple independent instructions may be required during normal processing), as an atomic operation. Here is the full description:

//define a new opcode for Sum of Absolute Difference(SAD)

//from which instruction decoding logic is derived

opcode SAD op2=4'b0000 CUSTO

//define a new instruction class

//from which compiler, assembler, disassembler

//routines are derived

iclass sad(SAD} {out arr, in ars, in art}

//semantic definition from which instruction-set

//simulation and RTL descriptions are derived

semantic sad_logic(SAD){

wire[8:0] diff01, diff11, diff21, diff31;

wire[7:0] diff0r, diff1r, diff2r, diff3r;

assign diff01 = art[7:0] - ars[7:0];

assign diff11 = art[15:8] - ars[15:8];

assign diff21 = art[23:16] - ars[23:16];

assign diff31 = art[31:24] - ars[31:24];

assign diff0r = ars[7:0] - art[7:0];

assign diff1r = ars[15:8] - art[15:8];

assign diff2r = ars[23:16] - art[23:16];

assign diff3r = ars[31:24] - art[31:24];

assign arr=

(diff01[8]?diff0r:diff01)+

(diff11[8]?diff1r:diff11)+

(diff21[8]?diff2r:diff21)+

(diff31[8]?diff3r:diff31);

}

This description represents the minimum steps required to define a new instruction. First, it is necessary to define a new set of opcodes for this new instruction. In this case, a new opcode SAD is defined as a sub-opcode of CUSTO. As noted above, CUSTO is predefined as:

opcode QRST op0=4'b0000

opcode CUSTO op1=4'b0100 QRST

It is easy to see that QRST is the top-level opcode. CUSTO is a sub-opcode of QRST, and SAD is a sub-opcode of CUSTO. This hierarchical organization of opcodes allows logical grouping and management of the opcode space. An important thing to remember is that CUSTO (and CUST1) are defined as reserved opcode space for users to add new instructions. Preferably, users stay in the allocated opcode space to ensure future reusability of TIE descriptions.

The second step in the TIE description is to define a new instruction class, which contains the new instruction SAD. This is where the operands of the SAD instruction are defined. In this case, SAD consists of 3 register operands, destination register arr, source registers ars and art. As noted earlier, arr is defined to be the register indexed by field r of the instruction, and ars and art are defined to be registers indexed by fields s and t of the instruction.

The last block in the description gives the formal semantic definition for the SAD instruction. This description uses a subset of the Verilog HDL language to describe combinational logic. It is this block that specifies exactly how the ISS will emulate the SAD instruction, and how an additional circuit will be synthesized and added to the configurable processor hardware to support the new instruction.

Second, debug and verify the TIE description using the various tools described above. After verifying the correctness of the TIE description, the next step is to evaluate the impact of the new instructions on hardware size and performance. As mentioned above, this can be done using, for example, Design Compiler ^(TM) . When the Design Compiler completes its work, the user can watch its output for a detailed area and velocity report.

After verifying that the TIE description is correct and valid, this is the time to configure and build a configurable processor that also supports the new SAD instructions. As mentioned above, this step is done using a graphical user interface GUI.

Again, the motion evaluation code is compiled to code for the configurable processor, which uses an instruction set emulator to verify the correctness of the program and more importantly measure its performance. This is done in 3 steps: run the test program using the emulator; run the base implementation to get instruction counts; and run the new implementation to get instruction counts.

The following is the simulation output of the second step:

Block=(16, 16), Search=(4, 4), size=(32, 32)

TIE version passed

Simulation Completed Successfully

Time for Simulation＝0.98 seconds

Events Number Number

per 100

instrs

Instructions 226005(100.00)

Unconditional taken branches 454(0.20)

Conditional branches 37149(16.44)

Taken 26947(11.92)

Not taken 10202(4.51)

Window Overflows 20(0.01)

Window Underflows 19 (0.01)

Here is the simulation output for the last step:

Block=(16, 16), Search=(4, 4), size=(32, 32)

TIE version passed

Simulation Completed Successfully

Time for Simulation＝0.36 seconds

Events Number Number

per 100

instrs

Instructions 51743(100.00)

Unconditional taken branches 706(1.36)

Conditional branches 3541(6.84)

Taken 2759(5.33)

Not taken 782(1.51)

Window Overflows 20 (0.04)

Window Underflows 19 (0.04)

From these two reports, it can be seen that about a 4x speedup has been achieved. It should be noted that the configurable processor instruction set emulator can also provide many other useful information.

After verifying the correctness and performance of the program, the next step is to run the test program using the Verilog emulator as described above. Professionals can find the details of this process from the makefile in Appendix C (the related files are also shown in Appendix C). The purpose of this simulation is to further verify the correctness of the new implementation and, more importantly, to make this test program part of the regression testing for this configured processor.

Finally, processor logic can be synthesized using eg Design Compiler ^(TM) , and placed and routed using eg Apollo ^(TM) .

For clarity and simplicity of illustration, this example provides a simplified look at video compression and motion evaluation. In fact, in standard compression algorithms, there are many additional nuances. For example, MPEG2 typically uses sub-pixel resolution for motion estimation and compensation. Two adjacent rows and columns of each pixel can be averaged to generate a set of pixels interpolated to an imaginary ideal position between two rows or two columns. Here, because only 3 or 4 lines of TIE codes can easily implement a group of parallel pixel averaging algorithms. So user-defined instructions for configurable processors are again useful. The pixels in a row are averaged again using efficient alignment operations of the processor's standard instruction set.

Thus, incorporating a simple sum-of-absolute-difference instruction adds only a few hundred gates, yet improves motion estimation performance by a factor of more than 10. This speedup represents a significant improvement in cost and power efficiency in the final system.

Furthermore, seamless expansion of software development tools (incorporating new motion evaluation instructions) allows rapid prototyping, performance analysis, and publication of complete software application solutions. The solution of the present invention enables simple, reliable and complete deployment of special purpose processors and provides dramatic improvements in cost, performance, functionality and power efficiency of the final system product.

As an example focused on adding a hardware functional unit, consider the basic configuration shown in Figure 6, which includes processor control functions, program counter (PC), branch select, instruction memory or cache, and instruction decoder, and the basic Integer data path, which includes the main register file, bypass multiplexers, pipeline registers, arithmetic logic unit ALU, address generator, and data memory for cache memory.

The HDL is written while the multiplier logic is conditionally present (when the "Multiplier" parameter is set), and as shown in Figure 7, the multiplier unit is added as a new pipeline stage (if required to support exact exceptions, then require conversion to exception handling). Of course, it would be nice to add the various instructions that use the multiplier along with the new unit.

As a second example, as shown in Figure 8, a full coprocessor can be added to the basic configuration as a digital signal processor such as a multiply/accumulate unit. This brings some changes to the control of the processor, such as adding various decoding control signals for multiply-accumulate operations, including decoding the contents of source and destination registers from extended instructions; adding appropriate pipeline delays for each control signal ; Extending the register destination logic; adding controls for a register bypass multiplexer to feed from the accumulation register, and incorporating a multiply-accumulate unit as possible sources for the execution result of an instruction. In addition, it requires the addition of a multiply-accumulate unit which brings additional accumulator registers, a multiply-accumulate array for main register sources and source selection multiplexers. Likewise, adding a coprocessor brings the extension of the register bypass multiplexer from the accumulation register, which takes a source from the accumulation register, and the expansion of the load/alignment multiplexer to allow Take out a source. Also, in order to use the new functional unit with actual hardware, the system preferably adds some instructions.

Another option that is particularly useful in combination with a digital signal processor is a floating point unit. Such a functional unit implementing the IEEE 754 single precision floating point arithmetic standard can be added along with instructions for accessing it. The floating point unit may be used in applications such as digital signal processing, such as audio compression and decompression, for example.

As yet another example of the flexibility of the present system, consider a 4KB memory interface as shown in FIG. 9 . Using the configurability of the present invention, the registers and datapaths of the coprocessor can be made wider or narrower than the main integer register file and datapath, and the width of the local memory can be changed so that the memory width is equal to the widest processor or the width of the coprocessor (memory addressing for reads and writes is adjusted accordingly). For example, Figure 10 shows a local memory system for a processor that supports 32-bit loads and stores to a processor/coprocessor combination. The above combinations address in the same array, but the coprocessor supports 128-bit loads and stores. This can be achieved with the TPP code

function memory(Select, A1, A2, DI1, DI2, W1, W2, DO1, DO2)

; SB1 = config_get_value("width_of_port_1"); SB2 =

config_get_value("width_of_port_2");

;$Bytes=config_get_value("size_of_memory");

;$Max=max($B1, $B2); $Min=min($B1, $B2);

;$Banks=$Max/SMin;

;$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] DO2=Wide2? RdData: RdData[(Lane+1)*B2*8-

1: Lane＊B2＊8];

Here, $Bytes is the total memory size, accessed with width B1 at byte address A1 of data bus D1 under the control of write signal W1, or using the corresponding parameters B2, A2, D2 and W2. In a given cycle, only a set of signals defined by Select are active. The TPP code implements memory as a collection of memory pools. The width of each pool is given by the minimum access width and the number of pools times the ratio of the maximum to minimum access width. A for loop is used to specify each memory pool and its associated write signals, ie, write enable and write data. The second for loop is used to collect the data read from all pools and send it to a single set of buses.

Figure 11 shows an example of incorporating user-defined instructions into the basic configuration. As shown, simple instructions can be added to the processor pipeline with timing and interfaces similar to those of the ALU. Instructions added in this way should produce no hangs or exceptions, contain no state, take as input only the two ordinary source register values and the instruction word, and produce a single output value. However, such constraints are unnecessary if the TIE language has provisions for specifying processor states.

Fig. 12 shows another example of implementing a user-defined unit in this system. The functional unit shown in the figure, an 8/16 parallel data unit extension of the ALU, is generated from the following ISA code:

Instruction {

Opcode ADD8_4 CUSTOM op2=0000

Opcode MIN16_2 CUSTOM op2=0001

Opcode SHIFT16_2 CUSTOM op2=0002

iclass MY 4ADD8, 2MIN16, SHIFT16_2

a<t, a<s, a>t_

}

Implementation {

input[31:0] art, ars;

input[23:0]inst;

input ADD8_4, MIN16_2, SHIFT16_2;

output[31:0] arr;

wire [31:0] add, min, shift;

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 min[15:0]=art[15:0]<ars[15:0]? Art [15:0]:

ars[15:0];

assign shift[31:16]=art[31:16]<<ars[31:16];

assign shift[15:0]=art[15:0]<<ars[15:0];

assign arr＝{32{ADD8_4}}& add|{32{MIN16_2}}& min|

{32{SHIFT16_2}}&shift;

}

In another aspect of the invention, which is of particular interest, the designer defines the instruction execution unit 96 in which the instructions defined by the TIE, including those which modify the state of the processor, are decoded and executed. In this aspect of the invention, building blocks have been added to the language, making it possible to specify additional processor states that can be read and written by new instructions. The "state" statement is used to specify additional processor state. The specification begins with the keyword state. The next part of the state statement specifies the size of the state and the number of bits, and how the bits of the state are indexed. The following part is the state name, which is used to identify the state in other description parts. The last part of the state statement is a list of properties associated with that state. For example,

state[63:0] DATA cpn=0 autopack

state[27:0] KEYC cpn=1 nopack

state[27:0] KEYD cpn=1

Define 3 new processor states, DATA, KEYC and KEYD. Status DATA is 64 bits wide with bits indexed from 63 to 0. Both KEYC and KEYD are 28-bit states. DATA has a coprocessor number attribute cpn, indicating which coprocessor the data DATA belongs to.

The attribute "autopack" indicates that the state DATA will be automatically mapped to certain registers in the user register file, so that the value of DATA can be read and written by various software tools.

The user_register section is defined to represent the mapping of state to registers in the user register file. The user_register section begins with a keyword user_register, followed by a number representing the register number, and ends with an expression representing the status bits to be mapped to the register. For example,

user_register 0 DATA[31:0]

user_register 1 DATA [63:32]

user_register 2 KEYC

user_register 3 KEYD

user_register 4{x, y, z}

The lower word of the specified DATA is mapped to the 1st user register file, and the upper word is mapped to the 2nd user register file. The next two user register file lines are used to hold the values of KEYC and KEYD. Obviously, the state information used in this section should be consistent with that used in the state section. Here, this consistency can be checked automatically by a computer program.

In another embodiment of the invention, a bin-packing algorithm is used to automatically assign status bits to rows of the user register file. In yet another embodiment, upward compatibility may be ensured using, for example, a combination of manual and automatic assignments.

The instruction field statement field is used to improve the readability of TIE code. Fields are subsets of concatenations of other fields that are grouped together and referenced by name. The complete set of bits in an instruction is the highest-level superset field inst, and this field can be divided into smaller fields. For example,

field xinst[11:8]

field yinst [15:12]

fieldxy[x,y]

Two 4-bit fields, x and y, are defined as subfields of a superlative field inst (bits 8-11 and 12-15, respectively), and an 8-bit field, xy, is defined as the concatenation of the x and y fields.

The statement opcode defines an opcode for an encoding-specific field. Instruction fields intended to specify operands, eg, registers or immediate constants intended to be used by opcodes thus defined, should first be defined with the field statement, followed by the operand statement.

For example,

opcode acs op2=4'b0000 CUSTO

opcode adse1 op2=4'b0001 CUSTO

Based on the previously defined opcode CUSTO (4'b0000 represents a 4-bit long binary constant 0000) to define two groups of new opcodes acs and adse1. The TIE description for the preferred core ISA has the following statement

field op0 inst[3:0]

field op1 inst[19:16]

field op2 inst[23P:20]

opcode QRST op0=4'b0000

opcode CUSTO op1=4'b0100 QRST

as part of its basic definition. Therefore, the definitions of acs and adse1 cause the TIE compiler to generate instruction decoding logic represented by the following statements, respectively:

inst[23:0]＝0000 0110 xxxx xxxx xxxx 0000

inst[23:0]＝0001 0110 xxxx xxxx xxxx 0000

The instruction operand statement operand identifies registers and immediate constants. However, before defining a field as an operand, it should have been previously defined as a field as described above. If the operand is an immediate constant, the value of the constant can be generated from the operand, or it can be taken out from a previously defined constant table whose definition will be described below. For example, to encode an immediate operand, the TIE code

field offset inst[23:6]

operand offs4 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 that holds a signed number and an operand offsets4 that is four times the number stored in the offset field. As those skilled in the art will understand, the last part of the operand statement actually describes the circuit used for computation in a subset of Verilog ^(TM) HDL used to describe combinational circuits.

Here, the wire statement defines a set of logical wires named t with a width of 32 bits. The first assign statement after the wire statement specifies that the logic signal driving the logic wiring is offsets4, and the second assign statement specifies that the lower 18 bits of t are put into the offset field. The first assign statement directly assigns the value of the operand offsets4 to a concatenation of 14 copies of offset and its sign bit (bit 17) followed by a left shift of two bits.

For a constant table operand, the TIE code

table prime16{

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;

Use the table statement to define a constant array prime (the number following the table name is the number of each element in the table), and use these operands as an index into the table prime to encode a value for the operand prime_s (note that in Use of Verilog ^TM statements when defining an index).

The instruction class statement iclass associates opcodes and operands in a common format. All instructions defined in an iclass statement have the same format and operand usage. Before defining an instruction class, its members must first be defined as fields, and then as opcodes and operands. For example, building on the previous example defining opcodes acs and adse1, the additional statement

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 the 3 register operands art, ars and arr (again note the use of Verilog ^TM statements in the definitions). Then, the iclass statement

iclass viterbi [adse1, acs] [out arr, in art in ars]

The specified operands adse1 and acs belong to a common class of the instruction viterbi, which takes two register operands art and ars as input, and writes the output to a register operand arr.

In the present invention, the instruction class statement iclass is modified to allow the description of the state access information of each instruction. It begins with the keyword "iclass", followed by the name of the instruction class, a list of opcodes belonging to the instruction class and a list of operand access information, and ends with a newly defined List of access information. For example,

iclass lddata {LDDATA} {out arr, in imm4} {in DATA}

iclass stdata {STDATA} {in ars, inart} {out DATA}

iclass stkey {STKEY} {in ars, in art} {out KEYC, out KEYD}

iclass des {DES} {out arr, in imm4} {inout KEYC, inout

DATA, inout KEYD}

Defines several instruction classes and how various new instructions access various states. The keywords "in", "out" and "inout" are used to indicate that the state is read, written or modified (read and write) by instructions in the iclass. In this example, the state "DATA" is read by the instruction "LDDATA", the states "KEYC" and "KEYD" are written by the instruction "STKEY", and "KEYC", "KEYD" and "DATA" are modified by the instruction "DES" .

Instruction Semantics A statement semantic describes the behavior of one or more instructions that use the same subset of Verilog ^TM used to encode their operands. By defining multiple instructions in a single semantic statement, certain common expressions can be shared and hardware implementations can be made more efficient. The variables allowed in a semantic statement are the operands for each opcode defined in the statement's opcode list, and a single-bit variable specified in the opcode list for each set of opcodes. This variable has the same name as the opcode, and it is evaluated to 1 when the opcode is checked out. It is used in the calculation part (Verilog ^TM subset part) to indicate the occurrence of the corresponding instruction.

//define a new opcode for BYTESWAP based on

// - a predefined instruction field op2

// - a predefined opcode CUST0

//refer to Xtensa ISA manual for descriptions of op2 and CUSTO

opcode BYTESWAP op2=4'b0000 CUST0

//declare state SWAP and COUNT

state COUNT 32

state SWAP1

//map COUNT and SWAp to user register file entries

user_register 0 COUNT

user_register 1 SWAP

//define a new instruction class that

// - reads data from ars(predefined to be AR[s])

// - uses and writes state COUNT

// - uses state SWAP

iclass bs { BYTESWAP } { outarr, inars } { inout COUNT, in

SWAp}

//semantic definition of byteswap

// COUNT the number of byte-swapped words

// Return the swapped or un-swapped data depending on SWAP

semantic bs {BYTESWAP} {

wire[31:0] ars_swapped=

{ars[7:0], ars[15:8], ars[23:16], ars[31:24]};

assign arr=SWAP? ars_swapped: ars;

assign COUNT=COUNT+SWAP;

}

Section 1 of the above code defines a set of opcodes for the new instruction, called BYTESWAP.

//define a new opcode for BYTESWAP based on

// - a predefined instruction field op2

// - a prede fined opcode CUSTO

//refer to Xtensa ISA manual for descriptions of op2 and CUSTO

opcode BYTESWAP op2=4'b0000 CUSTO

Here, a new opcode is defined as a set of sub-opcodes of CUSTO. From the "Xtensau ^TM Instruction Set Architecture Reference Manual" described in detail below, it can be seen that CUSTO is defined as

opcode QRST op0=4'b0000

opcode CUSTO op1=4'b0100 QRST

Here, both op0 and op1 are fields in the instruction. Opcodes are typically organized in a hierarchical fashion. Here, QRST is the top-level opcode, CUSTO is a sub-opcode of QRST, and BYTESWAP is again a sub-opcode of CUSTO. This hierarchical organization of opcodes allows logical clustering and management of the opcode space.

Paragraph 2 states the additional processor state required to represent the BYTESWAP instruction:

//declare state SWAP and COUNT

state COUNT 32

state SWAP 1

Here, COUNT is illustrated as a 32-bit state and SWAP is a 1-bit state. The TIE language specifies that the bits in COUNT are indexed from 31 to 0, with bit 0 being the lowest bit.

The Xtensa ^(TM) ISA provides two instructions, RSR and WSR, for storing (data) into and fetching from dedicated system registers. Similarly, it provides two other instructions, RUR and WUR (described in detail below), for storing and restoring the various states described in the TIE. In order to store and restore the various states described in TIE, the mapping relationship from each state to each row must be specified in the user register file that the RUR and WUR instructions can access. The following parts of the above code specify this mapping:

//map COUNT and SWAP to user register file entries

user_register 0 COUNT

user_register 1 SWAP

causes the following instructions to store the value of COUNT in a2 and the value of SWAP in a5:

RUR a2,0;

RUR a5,1;

This mechanism is actually used in the test program to verify various diesel locomotives in various states. In C language, the above two instructions have the following form:

x = RUR(0);

y = RUR(1);

The nested part of the TIE description is the definition of a new instruction class containing the new instruction BYTESWAP:

//define a new instruction class that

// - reads data from ars(predefined to be AR[s])

// - uses and writes state COUNT

// - uses state SWAP

iclass bs{BYTESWAP}{out arr, in ars}{inout COUNT, in

SWAP}

Here, iclass is the keyword and bs is the name of the iclass. The next clause lists the commands in the command class (BYTESWAP). Subsequent instructions specify the operands used by the instructions in this class (in this example, an input operand ars and an output operand arr). The last clause in the iclass definition specifies the various states within this class that are accessed by the instruction (in this example, the instruction will read state SWAP and read and write state COUNT).

The last block of the above code gives a formal semantic definition for the BYTESWAP instruction:

//semantic definition of byteswap

// COUNT the number of byte-swapped words

// Return the swapped or un-swapped data depending on SWAP

semantic bs {BYTESWAP}{

wire [31:0] ars_swapped

{ars[7:0], ars[15:8], ars[23:16], ars[31:24]};

assign arr=SWAP? ars_swapped: ars;

assign COUNT=COUNT+SWAP;

}

This description uses a subset of Verilog HDL to describe combinational logic. It is this block that specifies exactly how the instruction set emulator will emulate the BYTESWAP instruction, and how additional circuitry will be synthesized and added to the Xtensa ^™ processor hardware to support the new instruction.

In the present invention implementing various user-defined states, the stated states can be used like other variables to access information stored in the various states. A state identifier appearing on the right side of an expression indicates which state to read from. Writing to a state is accomplished by assigning a value or an expression to the state identifier. For example, the following semantic code snippet shows how an instruction reads or writes various states:

assign KEYC=sr==8'd2? art[27:0]: KEYC;

assign KEYD=sr==8'd3? art[27:0]: KEYD;

assign DATA = sr = = 8'd0 ? {DATA[63:32], art}: {art,

DATA[63:32]};

In order to illustrate the examples of various instructions that can be executed as core instructions in a configurable processor, and the purpose of each instruction that becomes available through the selection of various configuration options, "Xtensa ^TM Instruction Set Architecture" published by Tensilica Corporation (ISA) Reference Manual, Rev. 1.0, is incorporated herein by reference. Also, Instruction Extension Language (TIE) Reference Manual, Revision 1.3, also published by Tensilica Corporation, is incorporated by reference to illustrate various examples of TIE language instructions that can be used to implement such user-defined instructions This article.

From the TIE description, a program similar to that shown in Appendix D can be used, for example, to generate a hardware implementation that executes these instructions. Appendix E shows the code used to support the header files required for new instructions as intrinsics.

Using configuration instructions, the following items can be automatically generated:

- the instruction decoding logic of the processor 60;

- Illegal instruction detection logic for processor 60;

— the ISA-specific section of the assembler;

— ISA-specific support programs for compiling programs;

— the ISA-specific portion of the disassembler (used by the debugger); and

— The ISA-specific portion of the emulator.

Figure 16 is a diagram showing how the ISA-specific portions of these software tools are generated. The TIE parser 410 generates C language code from the user-generated TIE description file 400 for several segments of the program, each of which generates a file that can be accessed by one or more software development tools to obtain Information about user-defined instructions and status. For example, program tie2gcc 420 generates a C language header file 470 called xtensa_tie.h, which includes intrinsics for the new instructions. Program tie2isa 430 generates a dynamic link library (DLL) 480 containing information about the format of user-defined instructions (in the Wilson et al. patent application discussed below, this is effectively the combination of encoding and decoding DLLs discussed therein) . Program tie2iss 440 generates a performance simulator and produces a DLL 490 containing instruction semantics used by a host compiler to produce an emulator for use by the emulator, as discussed in the Wilson et al patent application DLL. Program tie2ver 450 generates the necessary description 500 for user-defined instructions in an appropriate hardware description language. Finally, program tie2xtos 460 generates save and restore code 510 for use by RUR and WUR instructions.

The fine-grained description of individual instructions and how they access various states makes it possible to generate efficient logic that can be plugged into existing high-performance microprocessor designs. The methods described in connection with this embodiment of the invention deal exclusively with new instructions that read from or write to one or more status registers. In particular, this embodiment shows how to derive the hardware logic for each status register in the sense of a microprocessor-like implementation that all uses pipelining as a technique to achieve high performance.

In a pipeline implementation such as that shown in Figure 17, a state register is typically replicated several times, with each specification representing the value of the state within a particular pipeline stage. In this embodiment, a state is converted to multiple copies of registers consistent with the preferred core processor implementation. At the same time, additional bypass and forward logic is created, again in a manner consistent with preferred core processor implementations. For example, in order to target a core processor implementation with 3 execution stages, this embodiment converts a state into 3 registers, and their connections are shown in FIG. 18 . In this embodiment, each register 610-630 represents the value of state in at one of the three pipeline stages. ctrl-1, ctrl-2, and ctrl-3 are all control signals for activating the data latch function in the corresponding flip-flops 610-630.

To make multiple copies of the status register consistent with the preferred processor implementation requires additional logic and control signals. "Consistent" means that the state should behave exactly the same as the rest of the state of the processor under conditions of interrupts, exceptions, pipeline stalls, etc. Typically, a given processor implementation defines certain signals indicative of various pipeline conditions. Such a signal is required for the pipeline status register to function correctly.

In a typical pipeline implementation, an execution unit includes multiple pipeline stages. Computation of an instruction occurs in multiple stages of the pipeline. The stream of instructions flows through the pipeline in a sequence directed by the control logic. At any given time, there may be as many as n instructions being executed in the pipeline. Here n is the number of stages. In a superscalar processor, the invention can also be implemented, and the number of instructions in the pipeline can be n×w, where w is the exit width of the processor.

The role of the control logic is to ensure that dependencies between instructions are honored and that any interference between instructions is resolved. If an instruction uses data calculated by a previous instruction, specialized hardware is required to send the data to a subsequent instruction without blocking the pipeline. If an interrupt occurs, all instructions in the pipeline need to be killed and then re-executed. An instruction should be suspended when it cannot execute because the input data or computing hardware it needs is not available. A cheap way to suspend an instruction is to kill it in its first execution phase and re-execute the instruction in the next cycle. The result of this technique is to generate an invalid stage (bubble) in the pipeline. This bubble, along with other instructions, flows through the pipeline. These bubbles are discarded at the end of the pipeline where instructions are corrupted.

Using the 3-stage pipeline example above, the additional logic and connections required for a typical implementation of such a processor state are shown in FIG.

Under normal circumstances, the value calculated in one stage will be sent to the next instruction immediately without waiting for the value to reach the end of the pipeline, so as to reduce the number of pipeline hangs introduced by data dependencies. This is accomplished by directly sending the output of the first flip-flop 610 to the semantic block so that it can be used immediately by the next instruction. To handle exceptions such as interrupts and exceptions, this embodiment requires the following three control signals: Kill_1, Kill_all, and Valid_3.

Signal Kill_1 indicates that the instruction currently at the first pipeline stage 110 should be killed because, for example, the data it needs is not available. The signal Kill_all indicates that all instructions in the pipeline should be killed because an instruction preceding them has generated an exception or an interrupt has occurred. The signal Valid_3 indicates whether the instruction currently in the last stage 630 is valid. This condition is usually the result of killing an instruction in the first pipeline stage 610 and a bubble (invalid instruction) in the pipeline. "Valid_3" simply indicates whether the instruction in the 3rd pipeline stage is valid or a bubble. Obviously, only valid instructions should be latched.

Figure 20 shows the additional logic and connections required to implement the status register. It also shows how to build the control logic to drive the signals "ctrl-1", "ctrl-2" and "ctrl-3" so that the implementation of the status register meets the above requirements. The following is sample HDL code automatically generated to implement the status register shown in Figure 19.

module tie_enflop(tie_out, tie_in, en, clk);

parameter size=32;

output[size-1:0] tie_out;

input[size-1:0] tie_in;

input en;

input clk;

reg[size-1:0]tmp;

assignie_out = tmp;

always@(posedge clk) begin

if (en)

tmp <= #1 tie_in;

end

endmodule

module tie_athens_state(ns, we, ke, kp, vw, clk, ps);

parameter size=32;

input[size-1:0] ns; //next state

input we; //write enable

input ke; //Kill E state

input kp; //Kill Pipeline

input vw; //Valid W state

input clk; //clock

output[size-1:0] ps; //present state

wire[size-1∶0]se; // state at E stage

wire[size-1∶0]sm; // state at M stage

wire[size-1∶0]sw; // state at W stage

wire[size-1∶0]sx; // state at X stage

wire ee; // write enable for EM register

wire ew; // write enable for WX register

assign se = kp? sx: ns;

assign ee = kp | we & ~ ke;

assign ew = vw &~kp;

assign ps = sm;

tie_enflop # (size) state_EM(.tie_out(sm), .tie_in(se), .en(ee),

\.clk(clk));

tie_enflop #(size) state_MW(.tie_out(sw), .tie_in(sm),

.en(1'b1),\.clk(clk));

tie_enflop # (size) state_WX(.tie_out(sx), .tie_in(sw), .en(ew),

\.clk(clk));

endmodule

If the semantic block specifies this state as its input, then use the above pipeline state register model to send the current state value of this state as an input variable to the semantic block. Generates a set of output signals if the semantic block has logic to generate a new value for a state. This output signal is used as the next state input to the pipeline status register.

This embodiment allows multiple semantic description blocks, each of which describes the behavior of multiple instructions. In this unconstrained description, it is possible that only a subset of semantic blocks produce the output of the next state for a given state. Furthermore, it is also possible for a given semantic block to conditionally depend on what instructions it executes at a given time to produce the output of the next state. Thus, additional hardware logic is required to combine the next state outputs from all semantic blocks to form the inputs to the pipeline state registers. In this embodiment of the invention, a set of signals is automatically derived for each semantic block to indicate whether the block has generated a new value for the state. In another embodiment, the specification of such a set of signals may be left to the designer.

Fig. 20 shows how to combine the next state output of a state from several semantic blocks sl-sn, and select one of them appropriately for input to the state register. In this figure, op1_1 and op1_2 are opcode signals for the 1st semantic block, op2_1 and op2_2 are opcode signals for the 2nd semantic block, and so on. The next state output of semantic block i is si (if there are multiple state registers, there are multiple next state outputs for this block). This signal indicates that the semantic block i has generated a new value for the state si_we. The signal s_we indicates whether any semantic block generates a new value for this state, and is used as a write enable signal input to the pipeline state register.

Even though the expressive power of a multi-semantic block is no greater than that of a single-semantic block, it still typically provides a more structured description by grouping related instructions into a single block. Multi-semantic blocks can also lead to a simpler analysis of the effects of instructions since the instructions are executed within a more restricted scope. On the other hand, for a single semantic block, it is often justified to describe the behavior of several instructions. Most commonly, this is due to the hardware implementation of these instructions sharing common logic. Describing multiple instructions in a single semantic block often leads to more efficient hardware design.

Due to interrupts and exceptions, it is necessary for software to load and restore (fetch) values of various states into and from data memory. It is possible to automatically generate such restore and load instructions based on the new state and the formal description of the new instructions. In one embodiment of the invention, the logic for recovery and loading is automatically generated as two semantic blocks, which can be recursively translated into actual hardware just like any other block. For example, from the description of the following states:

state[63:0] DATA cpn=0 autopack

state[27:0] KEYC cpn=1 nopack

state[27:0] KEYD cpn=1

user_register 0 = DATA[31:0];

user_register1 = DATA[63:32];

user_register2 = KEYC;

user_register 3 = KEYD;

The following semantic blocks can be generated to read the values of "DATA", "KEYC" and "KEYD" into the respective general purpose registers:

iclass rur{RUR}{out arr, in st}(in DATA, in KEYC, in KEYD}

semantic rur(RUR){

wire sel_0 = (st = = 8'd0);

wire sel_1 = (st = = 8'd1);

wire sel_2 = (st = = 8'd2);

wire sel_3 = (st = = 8'd3);

assign arr={32{sel_0}} & DATA[31:0]

{32{sel_1}} & DATA[64:32]

{32{sel_2}} & KEYC

{32{sel_3}} &KEYD;

}

Figure 21 shows a block diagram of the logic corresponding to this type of semantic logic. The input signal "st" is compared with various constants to form selection signals which are used to select bits from the status registers in a manner consistent with the user_register specification. Using the previous state description, bit 32 of DATA maps to bit 0 of the 2nd user register. Therefore, the 2nd input of the MUX in this figure should be connected to the 32nd bit of the DATA state.

The following semantic blocks can be generated to write values from the various general purpose registers to the states "DATA", "KEYC" and "KEYD"

iclass wur {WUR} {in art, in sr} {out DATA. out KEYC, out KEYD}

semantic wur (WUR) {

wire sel_0 = (st = = 8'd0);

wire sel_1 = (st = = 8'd1);

wire sel_2 = (st = = 8'd2);

wire sel_3 = (st = = 8'd3);

assign DATA={sel_1? art: DATA[63:32], sel_0? art:

DATA[31:0]};

assign KEYC = art;

assign KEYD = art;

assign DATA_we = WUR;

assign KEYC_we = WUR &sel_2;

assign KEYD_we = WUR &sel_3;

}

Figure 22 shows the logic of bit j of state S when mapped to bit k of the i user register. In a WUR instruction, if the user_register number "st" is "i", the kth bit of "ars" is loaded into the S[j] register; otherwise, the original value of S[j] is cycled again. Furthermore, signal S_we is activated if any bit of state S is reloaded.

The TIE user_register specification specifies the mapping from the additional processor state defined by the state specification to an identifier used by the RUR and WUR instructions to read and write to this state independently of the TIE instructions.

Appendix F presents the code used to generate the RUR and WUR instructions.

The main use of the RUR and WUR instructions is for task switching, in a multitasking environment where multitasking software shares the processor running according to some scheduling algorithm. When activated, the state of the task resides in processor registers. When the scheduling algorithm decides to switch to another task, the state held in the processor's registers is stored in memory, and the state of the other task is loaded from memory into the processor's registers . The Xtensa ^™ Instruction Set Architecture (ISA) includes RSR and WSR instructions to read and write states defined by the ISA. For example, the following code is part of the task "store to memory":

//save special registers

rsr a0, SAR

rsr a1, LCOUNT

s32i a0, a3, UEXCSAVE+0

s32i a1, a3, UEXCSAVE+4

rsr a0, LBEG

rsr a1, LEND

s32i a0, a3, UEXCSAVE+8

s32i a1, a3, UEXCSAVE+12

;if(config_get_value("IsaUseMAC16")){

rsr a0, acclo

rsr a1, ACCHI

s32i a0, a3, UEXCSAVE+16

s32i a1, a3, UEXCSAVE+20

rsr a0, MR_0

rsr a1, MR_1

s32i a0, a3, UEXCSAVE+24

s32i a1, a3, UEXCSAVE+28

rsr a0, MR_2

rsr a1, MR_3

s32i a0, a3, UEXCSAVE+32

s32i a1, a3, UEXCSAVE+36

;}

and the following code is part of the task "restore from memory":

//restore special registers

132i a2, a1, UEXCSAVE+0

132i a3, a1, UEXCSAVE+4

wsr a2, SAR

wsr a3, LCOUNT

132i a2, a1, UEXCSAVE+8

132i a3, a1, UEXCSAVE+12

wsr a2, LBEG

wsr a3, LEND

;if(config_get_value("IsaUseMAC16")){

132i a2, a1, UEXCSAVE+16

132i a3, a1, UEXCSAVE+20

wsr a2, acclo

wsr a3, ACCHI

132i a2, a1, UEXCSAVE+24

132i a3, a1, UEXCSAVE+28

wsr a2, MR_0

wsr a3, MR_1

132i a2, a1, UEXCSAVE+32

132i a3, a1, UEXCSAVE+36

wsr a2, MR_2

wsr a3, MR_3

;}

Here, SAR, LCOUNT, LBEG, LEND are all processor status registers part of core Xtensa ^TM ISA, and ACCLO, ACCHI, MR_0, MR_1, MR_2 and MR_3 are all part of MAC16Xtensa ^TM ISA options. (Registers are stored and restored in pairs to avoid pipeline interlocks.)

When the designer uses TIE to define a new state, it must also perform task switching like the above states. One possibility for the designer is to simply write the task switching code (part of which is given above) and add instructions RUR/S32I and L32I/WUR similar to the above code. However, a configurable processor will be most efficient when the software is automatically generated and architecturally correct. Accordingly, the present invention includes a means for automatically adding task switching code. The following tpp lines are added to the storage task above:

;my$off=0;

;my $i;

;for($i=0; $i<$#user_registers; $i+=2){

rur a2, `$user_registers[$i+0]`

rur a3, `$user_registers[$i+1]`

s32i a2, UEXCUREG + `$off+0`

s32i a3, UEXCUREG+ `$off+4`

; $off+=8;

;}

; if (@user_registers & 1) {

; # odd number of user registers

rur a2, `$user_registers[$#user_registers]`

s32i a2, UEXCUREG+`$off+0`

; $off+=4;

;}

and the following lines are added to the restore task above:

;my$off=0;

;my $i;

;for($i=0; $i<$#user_registers; $i+=2){

132i a2, UEXCUREG+ `$off+0`

132i a3, UEXCUREG+ `$off+4`

wur a2, `$user_registers[$i+0]`

wur a3, `$user_registers[$i+1]`

; $off+=8;

;}

; if (@user_registers & 1) {

; # odd number of user registers

132i a2, UEXCUREG+`$off+0`

wur a2, `$user_registers[$#user_registers]`

;$off+=4;

;}

Finally, the task state area in memory should have additional space allocated for user register storage, and the offset of this space from the base address of the task memory pointer is defined as the assembler constant UEXCUREG. This storage area is defined in advance with the following code #define UEXCREGSIZE(16*4)

#define UEXCPARMSIZE(4*4)

;if (&config_get_value("IsaUseMAC16")){

#define UEXCSAVESIZE(10*4)

;}else{

#define UEXCSAVESIZE(4*4)

;}

#define UEXCMISCSIZE(2*4)

#define UEXCpARM 0

#define UEXCREG(UEXCPARM+UEXCPARMSIZE)

#define UEXCSAVE(UEXCREG+UEXCREGSIZE)

#define UEXCMISC(UEXCSAVE+UEXCSAVESIZE)

#define UEXCWIN(UEXCMISC+0)

#define UEXCFRAME

(UEXCREGSIZE+UEXCPARMSIZE+UEXCSAVESIZE+UEXCMISCSIZE)

which is changed to

#define UEXCREGSIZE(16*4)

#define UEXCPARMSIZE(4*4)

;if(&config_get_value("IsaUseMAC16")){

#define UEXCSAVESIZE(10*4)

;}else{

#define UEXCSAVESIZE(4*4)

;}

#define UEXCMISCSIZE(2*4)

#define UEXCUREGSIZE `@user_registers*4`

#define UEXCPARM 0

#define UEXCREG(UEXCPARM+UEXCPARMSIZE)

#define UEXCSAVE(UEXCREG+UEXCREGSIZE)

#define UEXCMISC(UEXCSAVE+UEXCSAVESIZE)

#define UEXCUREG(UEXCMISC+UEXCMISCSIZE)

#define UEXCWIN(UEXCUREG+0)

#define UEXCFRAME\

(UEXCREGSIZE+UEXCPARMSIZE+UEXCSAVESIZE+UEXCMISCSIZE+UEXCUREGSIZE

)

This code relies on the existence of a tpp variable @user_register which holds a list of user register numbers, which is simply a list generated from the first argument of each user_register statement.

In some more complex microprocessor implementations, a state may be computed in different pipeline states, and handling this step requires several extensions (albeit simple ones) to the process described here. First, the description language needs to be extended so that it can associate a semantic block with a pipeline stage. This step can be accomplished in one of several ways. In one embodiment, each semantic block may explicitly specify the associated pipeline stage. In another embodiment, a range of pipeline stages may be specified for each semantic block. In yet another embodiment, pipeline stages can be automatically derived for a given semantic block according to the required computational latency.

The second task to support state generation in different pipeline stages is to handle various interrupts, various exceptions and various suspends. This usually involves adding appropriate bypass and forward logic under the control of pipeline control signals. In one embodiment, a generic diagram can be generated indicating the relationship between when the state is generated and when it is used. Based on application analysis, appropriate forward logic can be implemented to handle common cases, and interlock logic can be generated to suspend the pipeline for various cases not handled by the forward logic.

The method used to modify the instruction exit logic of a base processor depends on the algorithm used by the base processor. In general, however, for most instructions, whether single-exit or superscalar, and whether for single-cycle or multi-cycle instructions, the instruction exit logic depends only on the instruction being tested for producing:

1. signals for each processor state element indicating whether the instruction uses the state as a source;

2. signals for each processor state element indicating whether the instruction uses the state as a target;

3. For each functional unit, indicate whether the instruction uses various signals of each functional unit;

These signals are used to perform on-pipeline and cross-exit checks, and are used to update the state of the pipeline in pipeline-dependent exit logic. The TIE contains all the necessary information to add the various signals and their equations for each new instruction.

First, the TIE state specification results in a new set of signals being generated for the instruction exit logic. The in or inout operands or states listed in the 3rd or 4th argument of the iclass declaration are the instructions listed in the 2nd argument of the first set of equations for the specified processor state element Add instruction decode signal.

Second, the in or inout operands or states listed in the 3rd or 4th argument of the iclass declaration are those listed in the 2nd argument of the 1st set of equations for the specified processor state element Instructions add instruction decoding signals.

Third, the logic generated from each TIE semantic block represents a new functional unit, thus generating a new set of unit signals, and the decoded signals for the TIE instructions specified for that semantic block pass through the logic The "or" operations are combined to form the 3rd set of equations.

When an instruction is issued, the state of the pipeline should be updated for future issue decisions. Again, the method used to modify the instruction issue logic of the base processor depends on the algorithm used by the base processor. However, certain general observations are possible. The pipeline state shall provide the following states to the inverse of the issuing logic:

4. Various signals indicating the target for each command issued when the result is available for bypassing;

5. Various signals for each functional unit indicating that the functional unit is ready for another instruction.

The embodiment described here is a single-exit processor in which designer-defined instructions are limited to a single cycle of logical computation. In this case, the above problem is considerably simplified. No functional unit checks or cross-exit checks are required, and no single-cycle instruction can make a processor state element not pipeline-ready for the next instruction. Therefore, the export equation becomes exactly

issue＝(~srcluse|srclpipeready)&(~src2use|src2pipeready)

&(~srcNuse|srcNpipeready);

And wherein the src[i] pipeline ready signal is not affected by each additional instruction, and src[i]use is the first equation set explained and modified as described above. In this embodiment, the 4th and 5th group signals are not needed. For a multi-exit and multi-cycle alternative embodiment, the TIE description will be augmented for each instruction with a latent factor specification, giving the number of cycles required to build the computation pipeline.

By performing a logic "OR" operation on the instruction decoding signals of each instruction, they are gathered together to generate the fourth group of signals in each semantic block pipeline stage. According to the description, the execution of the instruction is completed in this stage.

By default the generated logic will be fully pipelined, and thus each functional unit generated by the TIE is usually single cycle after receiving an instruction. In this case, a Group 5 signal is usually established for each semantic block of the TIE. When the logic in each semantic block needs to be reused over multiple cycles, a further specification will specify how many cycles these instructions will use the functional unit. In this case, a fifth set of signals is generated in each semantic block pipeline stage by logically ORing the instruction decode signals of each instruction to generate a fifth set of signals in which each instruction is executed completes in the cycle count specified by the stage.

Alternatively, in a different embodiment, it can be used as an extension to TIE to let the designer specify the result ready signal and the functional unit ready signal.

Examples of codes processed according to this embodiment are found in the respective appendices. For the sake of brevity, this will not be described in detail; however, it will be understood by professionals after referring to the reference manual mentioned above. Appendix G is an example of implementing an instruction in the TIE language; Appendix H shows what a TIE compiler will produce for a compiler using such code. Similarly, Appendix I shows what a TIE compiler will produce for a simulation program; Appendix J shows what a TIE compiler will produce for a macro that expands a TIE instruction in a user program; and Appendix K shows what a TIE compiler will produce for simulation TIE instructions in native mode; Appendix L shows what the TIE compiler would produce as a Verilog HDL description of the attached hardware; and Appendix M shows what the TIE compiler would produce as a Design Compiler optimizing the Verilog HDL description above A manuscript to evaluate the impact of the TIE instruction on CPU size and performance in terms of area and speed.

As noted above, to begin the processor configuration process, the user begins by selecting a base processor via the GUI described above. As part of the process, as shown in Figure 1, a software development tool 30 is built and provided to the user. The software development tool 30 contains four important components related to another aspect of the present invention, see FIG. 6 for details: compiler 108 , assembler 110 , instruction set emulator 112 , and debugger 130 .

As is well known to those skilled in the art, a compiler converts a user application program written in a high-level programming language such as C or C++ into processor-specific assembly language. High-level programming languages, such as C or C++, are designed to allow application authors to describe their applications in a form that they can elaborately describe. These are not languages understood by various processors. The application author does not have to worry about all the special features of the processor to be used. Typically, the same C or C++ program can be used with little or no modification on many different types of processors.

An assembler converts a C or C++ program into assembly language. Assembly language is closer to machine language, and the processor directly supports machine language. Different types of processors have their own assembly languages. Each assembly instruction usually directly represents a machine instruction, but the two are not necessarily the same. Assembly instructions are designed as human-readable strings. Each instruction or operand is given a meaningful name or mnemonic, allowing a human to read the assembly instructions and easily understand what the machine will do. An assembler converts assembly language into machine language. Each string of assembly instructions is effectively encoded by the assembler into one or more machine instructions, which can be directly and efficiently executed by a processor.

Machine code can run directly on the processor, but various physical processors are not always immediately available. Building various physical processors is a time-consuming and costly process. When selecting possible processor configurations, the user cannot build a physical processor for each option. Instead, users are provided with a software program called an emulator. An emulator running on an ordinary computer can emulate the effects of a user application on a user-configured processor. An emulator mimics the semantics of the emulated processor and tells the user how fast the actual processor will run the user's application.

A debugger is a tool that lets users interactively find various problems with their software. Debuggers allow users to run their programs interactively. The user can stop the execution of the program at any time while viewing its C language source code, the resulting assembly code or machine code. The user can also view or modify her (any or all) variables or hardware register values at a breakpoint. The user can then continue execution—perhaps one statement at a time, perhaps one machine instruction at a time, perhaps branching to a new breakpoint of the user's choosing.

All 4 parts 108 , 110 , 112 and 130 need to know user-defined instructions 750 (see FIG. 3 ), and emulator 112 and debugger 130 must also know user-defined states 752 incidentally. The system allows the user to access user-defined instructions 750 via internal calls that are added to the user's C and C++ applications. Compiler 108 should convert internal calls to assembly language instructions 738 for user-defined instructions 750 . The assembler 110 should take the new assembly language instructions 738 , whether written directly by the user or converted by the compiler 108 , and encode them into machine instructions 740 corresponding to the user-defined instructions 750 . The emulator 112 should decode each user-defined machine instruction 740 . It should simulate the semantics of the instructions, and it should simulate the performance of the instructions on the configured processor. The simulator 112 should also simulate the values and performance implied by the user-defined states. Debugger 130 should allow a user to display assembly language instructions 738 , including user-defined instructions 750 . It should allow the user to view and modify the value of the user-defined state.

In this aspect of the invention, the user enables a tool, the TIE compiler 702, to process 736 currently possible user-defined enhancements. TIE compiler 702 is distinct from compiler 708 , which converts user applications into assembly language 738 . The TIE compiler 702 builds components that make the already built base software system 30 (compiler 708, assembler 710, simulator 712, and debugger 730) use new, user-defined enhancements 736. Each element of software system 30 uses a slightly different set of components.

Figure 24 is a diagram illustrating how the TIE-specific portions of these software tools are generated. TIE compiler 702 generates C language code for several programs from user-defined extension file 736, each segment of which generates a file that can be accessed by one or more software development tools to obtain information about user-defined instructions and states information. For example, program tie2gcc 800 produces a C language header file 842 called xtensa-tie.h (described in detail below) that contains the intrinsic function definitions for the new instructions. Program tie2isa 810 generates a dynamic link library (DLL) 844/848 that contains information about the format of user-defined instructions (the combination of encode DLL 844 and decode DLL 848 will be described in detail below). Program tie2iss 840 generates C language code 870 for performance simulation and instruction semantics, as discussed below, and is used by a host compiler 846 to generate the emulator DLL 849 used by the emulator, described in more detail below . Program tie2ver 850 generates the necessary description 850 for the user-defined instruction in the appropriate hardware description language. Finally, the program tie2xtos 860 saves and restores code 810, for scene switching? ? Save and restore user-defined states. Additional information on the implementation of user-defined states can be found in the application of Wang et al. above.

Compiler 708

In this embodiment, compiler 708 converts internal calls in the user application into assembly language instructions 738 for user-defined enhancements 736 . Compiler 708 implements this mechanism on top of macros, as well as the inline assembly mechanism found in compilers such as the GNU compiler. For more information on these mechanisms, see, eg, the GNU and C++ Compiler User's Guide, EGCS version 1.0.3.

Consider a user who wishes to generate a new instruction foo that operates on two registers and returns a result in the third register. The user places the instruction description into a specific directory of the user-defined instruction file 750 and activates the TIE compiler 702 . The TIE compiler 702 generates a file 742 with a standard name such as xtensa-tie.h. This file contains the following definition of foo.

#define foo(ars, art) \

({int arr; asm volatile("foo %0,%1,%2":"=a"(arr):\

"a"(ars), "a"(ar rt)); })

When the user enables compiler 708 in her application, she tells compiler 708 the name of the directory with user-defined improvements 736, either through a command line option or an environment variable. This directory also contains the xtensa-tie.h file 742. Compiler 708 automatically incorporates the file xtensa-tie.h into the C language or C++ language application program that the user is compiling, as if the user had written the definition of foo himself. The user includes the internal call into the instruction foo in his own application. Because of the included definitions, compiler 708 sees those internal calls as calls to included definitions. According to the standard macro mechanism provided by the compiler 708, when the compiler 708 processes the call of macro foo, it is as if the user directly writes the assembly language instruction 738 instead of a macro call. That is, according to the standard in-line assembly mechanism, the compiler 708 converts the call into a single assembly instruction foo. For example, a user might have a function that contains a call to internal foo.

int fred(int a, int b)

{

return foo(a,b);

}

The compiler uses the user-defined instruction foo to convert the function into the following assembly language subroutine.

fred:

.frame sp, 32

entry sp, 32

#APP

foo a2, a2, a3

#NO_APP

retw.n

When a user creates a new set of user-defined improvements 736, there is no need to write a new compiler. The TIE compiler 702 simply creates the file xtensa_tie.h 742, which is automatically incorporated into the user's application by the pre-built compiler.

Assembler 710

In this embodiment, assembler 710 encodes assembly instructions 750 using encoding library 744 . Enter this storehouse 744 and comprise following function:

— Convert the opcode mnemonic string to the internal opcode representation;

- providing for each set of opcodes a bitmap to be generated for the opcode field in a machine instruction 740; and

- Encode the operand values of the operands of each instruction and insert the encoded operand bitmap into the operand field of the machine instruction 740 .

For example, imagine our example above calling a user function inside foo. An assembler might take the instruction "foo a2, a2 a3" and convert it into a machine instruction represented by the hexadecimal number 0x62230, where the high-order 6 and low-order 0 together represent the opcode for foo, 2, 2, and 3 represent three registers a2, a2 and a3 respectively.

The internal implementation of these functions is based on a combination of tables and internal functions. Tables can be easily generated by TIE compiler 702, but their expressive power is limited. When greater flexibility is required, such as when expressing operand encoding functions, the TIE compiler 702 can generate random C code and include it in the library 744 .

Consider again the "foo a2, a2, a3" example. Each register field is simply encoded with the number of the register. The TIE compiler 702 creates the following function which checks for valid register values and returns the register number if the value is valid.

xtensa_encode_result encode_r(valP)

u_int32_t *valp;

{

u_int32_t val = * valp;

if((val>>4)!=0)

return xtensa_encode_result_too_high;

*valp=val;

return xtensa_encode_result_ok;

)

If all encodings were this simple, no encryption functions would be needed, and only one form would suffice. However, users can choose more complex encodings. The following encodings are written in the TIE language and encode each operand by dividing the value of the operand by 1024. Such encodings are useful for frequently encoded values that require multiples of 1024.

Operand t×10t{t<<10}{t×10>>10}

The TIE compiler converts the operand encoding description into the following C language functions.

xtensa_encode_result encode_tx10(valp)

u_int32_t * valp;

{

u_int32_t t, tx10;

tx10 = * valp;

t=(tx10>>10) &0×f;

tx10=decode_t×10(t);

if(t×10!=*valp){

return xtensa_encode_result_not_ok;

} else{

*valp=t;

}

return xtensa_encode_result_ok;

}

Since the range of possible values for operands is very large, it is not possible to use a table for such encoding. The table will have to be very large.

In one embodiment of encoding library 744, a table maps opcode mnemonic strings to internal opcode representations. The table may be sorted for efficiency, or it may be a hash table, or other data structure that allows efficient retrieval. Another table maps each set of opcodes to a template for a machine instruction, initializing the opcode field to the appropriate bitmap for that opcode. Opcodes with the same operand field and operand encoding are grouped together. For each operand in these groups, the library contains a function that encodes the operand value into a bitmap, and another function that inserts the bitmap into the appropriate field in the machine instruction. A separate internal table maps each instruction operand to these functions. Consider an example where the number of the result register is encoded as bits 12...15 of the instruction. The TIE compiler 702 will generate the following function to set bits 12...15 of the instruction to the value (number) of the result register:

void set_r_field(insn, val)

xtensa_insnbuf insn;

u_int32_t val;

{

insn[0] = (insn[0] & 0×ffff0fff)|({val<<12) &0×f000);

To enable changes to user-defined instructions without rewriting assembler 710, code library 744 is implemented as a dynamic link library (DLL). DLLs are the standard way for programs to dynamically extend their functionality. The details of handling DLLs are different in different host operating systems, but the basic concept is the same. As an extension of the program code, the DLL is dynamically loaded into the running program. The runtime linker resolves symbolic references between the DLL and the main program, and between the DLL and other loaded DLLs. In the case of a coded library or DLL 744 , a small portion of the code is statically linked into the assembler 710 . This code is responsible for loading the DLL, and combines the information in the DLL with the existing encoding information of the pre-established instruction set 746 (may have been loaded from an independent DLL), so that the information can be processed by each interface function as described above. access.

When a user creates a new improvement 736, she enables the TIE compiler 702 based on the description described by the improvement 736. The C language code generated by the TIE compiler 702 defines the internal tables and functions that implement the coded DLL. The TIE compiler 702 then enables the host system's native compiler 746 (which compiles code to run on the host, rather than the configured processor) to create the coded DLL 144 for the user-defined instructions 750 . Users enable the pre-written assembler 710 in their applications using flags or environment variables that point to directories containing user-defined enhancements 736 . A pre-written assembler 710 dynamically opens the DLL 744 in the directory. For each assembly instruction, the pre-written assembler 710 uses the encoding DLL 744 to look up the opcode mnemonic string, find the bitmap of the opcode field in the machine instruction, and encode each instruction operand.

For example, when the assembler 710 finds the TIE instruction "foo a2, a2, a3", the assembler 710 finds through a table that the "foo" opcode translates to the number 6 at bit positions 16 through 23. From the table, it finds the encoding function for each register. The function encodes a2 as the number 2, another a2 as the number 2, and a3 as the number 3. From the table, it finds the appropriate setup function. Set_r_field places the result value 2 in bit locations 12...15 of this instruction. A similar setup function also puts the additional 2 and 3 in place.

Emulator 712

Simulator 712 interacts with user-defined improvements 736 in several ways. For machine instructions 740, the emulator 712 must decode the instruction, that is, break the instruction into opcode and operand units. User defined enhancements 736 are decoded by a function of decode DLL 748 (encode DLL 744 and decode DLL 748 may actually be the same DLL). For example, suppose the user defines three opcodes: foo1, foo2, and foo3, encoded as 0x6, 0x16, and 0x26 in bits 16 to 23 of the instruction, and 0 in bits 0 to 3, respectively. The TIE compiler 702 generates the following decode function, which compares the opcode to all user-defined instructions 750:

int decode_insn(const xtensa_insnbuf insn)

{

if((insn[0] & 0×ff000f)==0×60000) return xtensa_fool_op;

if((insn[0] & 0×ff000f)==0×160000) return

xtensa_foo2_op;

if((insn[0] & 0×ff000f)==0×260000) return

xtensa_foo3_op;

return XTENSA_UNDEFINED;

}

When the number of user-defined instructions is large, it may be time-consuming to compare opcodes to all possible user-defined instructions 750, so the TIE compiler may use a separate hierarchy of switch statement groups instead.

switch(get_op0_field(insn)){

case 0×0:

switch(get_op1_field(insn)){

case 0×6:

switch(get_op2_field(insn)){

case 0×0: return xtensa_fool_op;

case 0×1: return xtensa_foo2_op;

case 0×2: return xtensa_foo3_op;

default: return XTENSA_UNDEFINED;

}

default: return XTENSA_UNDEFINED;

}

default: return XTENSA_UNDEFINED;

}

In addition to decoding instruction opcodes, decode DLL 748 includes functions for decoding instruction operands. This is done in exactly the same way as the operands are encoded in the encoding DLL744. First, the function that decodes the DLL748 picks the operand field from the machine instruction. Continuing with the above example, the TIE compiler 702 generates the following function to select a value from bits 12 through 15 of an instruction:

u_int32_t get_r_field (insn)

xtensa_insnbuf insn;

{

return((insn[0] &0×f000)>>12);

}

The TIE description of an operand includes the description of encoding and decoding, so whereas the encoding DLL 744 uses the operand encoding description, the decoding DLL 748 uses the operand decoding description. For example, the description of the TIE operand is:

Operand t×10t{t<<10}{t×10>>10}

Generates the following operand decoding functions:

u_int32_t decode_t×10(val)

u_int32_t val;

{

u_int32_t t, t×10;

t = val;

t×10=t<<10;

return t×10;

}

When the user starts the emulator 712, she tells the emulator 712 the directory containing the decoding DLL 748 for the user-defined enhancements 736. Emulator 712 opens the appropriate DLL. Whenever emulator 712 decodes an instruction, emulator 712 enables the decode function in DLL 748 if the instruction is not successfully decoded by the pre-programmed decode function of the instruction set.

Given a decoded instruction 750, the emulator 712 must interpret and simulate the semantics of the instruction 750. This is done in a functional way. Each instruction 750 has a corresponding function, allowing the simulation program 712 to simulate the semantics of the instruction 750 . The simulation program 712 internally keeps track of the overall state of the processor being simulated. The emulation program 712 has a fixed interface for updating or querying the state of the processor. As noted above, user-defined enhancements 736 are written in the TIE Hardware Description Language, which is a subset of Verilog. The TIE compiler 702 converts the hardware description language into C language functions, and the simulation program 712 uses the above C language functions to simulate the new improvement 736 . Hardware description language operators translate directly to corresponding C language operators. The operation of reading state or writing state is translated into the interface of emulator for updating or querying processor state.

As an example in this embodiment, assume that a user creates an instruction to add two registers. This example was chosen for simplicity only. Users can use the hardware description language to describe the added semantics as follows:

Semantic add{add}{assign arr=ars+art;}

The output register, denoted by the internal name arr, is given the sum of the two input registers, whose internal names are ars and art. TIE compiler 702 takes this description and generates semantic functions used by simulator 712:

void add_func(u32_OPND0_, u32_OPND1_, u32_OPND2_, u32

_OPND3_)

{

set_ar(_OPND0_, ar(_OPND1_)+ar(_OPND2_));

pc_incr(3);

}

The hardware operator "+" is directly converted to the corresponding C language operator "+". The reading of the hardware registers ars and art is translated into a call to the function "ar" of the emulator 712 . The writing of the hardware register arr is converted into a call to the function “set ar” of the emulation program 712 . Because each instruction implicitly increases the contents of the program counter pc by the size of that instruction, the TIE compiler 702 also generates a call to the emulator 712 function that increments the emulated pc by 3, the size of the add instruction.

When the TIE compiler 702 is enabled, a semantic function as described above is created for each user-defined instruction, along with a table that maps all opcode names to the associated semantic functions. The tables and functions are compiled into the emulator DLL 749 using a standard compiler 746 . When the user starts the emulator 712, she tells the emulator 712 the directory containing the user-defined enhancements 736. Emulator 712 opens the appropriate DLL. Whenever the emulation program 712 is activated, it decodes all the instructions in the program and creates a table containing the mapping relationship between each instruction and each related semantic function. When the mapping is established, the emulator 712 opens the DLL and retrieves the appropriate semantic functions. When emulating the semantics of the user-defined instructions 736, the emulator 712 directly invokes the functions in the DLL.

In order to tell the user how long it takes to run the application program on the simulated hardware, the simulation program 712 needs to simulate the execution effect of the instruction 750 . The simulation program 712 uses a pipeline model for this. Each instruction executes over several cycles. In each cycle, instructions use different resources of the machine. Emulator 712 initially attempts to execute all instructions in parallel. If multiple instructions use the same resource in the same cycle, the following instructions are suspended to wait for the resource to be freed. If a subsequent instruction reads the state written by a previous instruction in a subsequent cycle, the subsequent instruction is suspended, waiting for the value to be written. Simulator 712 uses a functional interface to simulate the effect of each instruction. Create a function for each type of instruction. These functions include calls to the emulator interface, which simulates the performance of the processor.

For example, suppose there is a simple 3-register instruction foo. The TIE compiler may create the following emulator functions:

void foo_sched(u32 op0, u32 op1, u32 op2, u32 op3)

pipe_use_i fetch(3);

pipe_use(REGF32_AR, op1, 1);

pipe_use(REGF32_AR, op2, 1);

pipe_def(REGF32_AR, op0, 2);

pipe_def_ifetch(-1);

}

The call to pipe_use_ifetch tells the emulator 712 that the instruction will need to fetch 3 bytes. The two calls to pipe_use tell the emulator 712 that the two input registers are to be read in cycle one. The call to pipe_def tells the emulator 712 that the output register is going to be written in cycle 2. The call to pipe_def_ifetch tells the emulator 712 that this instruction is not a branch, so the next instruction can be fetched on the next cycle.

The pointers to these functions are placed in the same table with the semantic functions. The functions themselves are compiled into DLL749 just like semantic functions. When the emulator 712 is enabled, it creates a mapping of instructions and execution functions. When the mapping is established, the emulator 712 opens the DLL 749 to retrieve the appropriate performance functions. When simulating the execution of user-defined instructions 736 , the emulator 712 directly invokes the functions in the DLL 749 .

debugger 730

The debugger interacts with user-defined enhancements 750 in two ways. First, the user can display assembly language instructions 738 for user-defined instructions 736 . To do this, debugger 730 must decode machine language instructions 740 into assembly language instructions 738 . This is the same principle used when the emulator 712 decodes instructions, and the DLL used by the debugger 730 is preferably exactly the same as the DLL used by the emulator 712 when decoding. In addition to decoding individual instructions, the debugger must convert the decoded instructions into strings. To this end, the decode DLL748 includes a function that maps each internal opcode representation to the corresponding mnemonic string. This can be accomplished with a simple form.

A user may enable a pre-written debugger using flags or environment variables pointing to a directory containing user-defined enhancements 750 . A pre-built debugger dynamically opens the appropriate DLL748.

Debugger 730 also interacts with user-defined states 752 . Debugger 730 must be able to read and modify state 752 . To this end, debugger 730 communicates with emulator 712 . It asks the emulator 712 how big the state is, and what the names of the state variables are. Whenever the debugger 730 is asked to display a value for a user state, it queries the emulator 712 for the value as if it were a predefined state. Similarly, to modify the user's state, the debugger 730 tells the emulator 712 to set the state to a given value.

Thus, it can be seen that support for user-defined instruction sets and states according to embodiments of the present invention can be accomplished using modules defining user functions embedded in the core software development tools. Therefore, when developing a system, specific user-defined enhancement embedded modules can be used as a group within the system for easy organization and operation.

In addition, core software development tools may be dedicated to a specific core instruction set and processor state, and user-defined enhancements to a single set of embedded modules may be combined with many core software development tools residing in the system evaluate.

Annex A

#Xtensa Configuration Database Description

#$Id: Definition, v1.65 1999/02/04 15:30:45adixit Exp $.

#Copyright 1998 Tensilica Corporation

#These coded instructions, statements, and computer programs are from Tensilica

# Confidential proprietary information that may not be disclosed to third parties or copied in whole or in part in any form without the prior written consent of Tensilica

#

#This is the configuration parameter definition file.

# - all supported configurations must be specified in this file

# - All tools that analyze configuration should check this file for correctness

# - Changes to this file should be kept minimal and handled with care

#

# naming convention

# Most parameter names start with a class name from the list:

# Addr address and conversion parameters

# Build?

# Cad target CAD environment

# DV Various design verification parameters

# Data One of the following:

# DataCache data cache parameter

# DataRAM data RAM parameters

# DataROM data ROM parameters

# Debug debugger options parameter

# Impl implements the goals of the scheme

# Inst One of the following:

# InstCache instruction cache parameters

# InstRAM instruction RAM parameters

# InstROM instruction ROM parameter

# Interrupt interrupt parameters

# Isa instruction set architecture parameters

# Iss instruction set emulator parameters

# PIF processor interface parameters

# Sys system parameters (eg memory map)

# TIE special instruction parameters

# Test production test parameters

# Timer cycle count/compare options

# Vector reset/exception/interrupt vector address

# Many parameters end with a suffix giving the units in which they are measured:

# Bits

# Bytes (ie 8 bits)

# Count is used as a general "number of" suffix

# Entries are similar to Count

# Filename absolute pathname of the file

# Interrupt interrupt flag (0...31)

# Level interrupt level (1...15)

# Max maximum value

# Paddr physical address

# An enumeration of possible values for Type

# Vaddr virtual address

Format of this document:

Column 1: Configuration parameter name

Column 2: Default value of the parameter

Column 3: Perl representation of the validity of the check value

# Xtensa Configuration Database Specification

# SId: Definition, v1.65 1999/02/04 15:30:45adixit Exp $

□

□

# Copyright 1998 Tensilica Inc.

# These coded instructions, statements, and computer programs are

# Confidential Proprietary Information of Tensilica Inc. and may not

be

# disclosed to third parties or copied in any form, in whole or in

part,

# without the prior written consent of Tensilica Inc.

#

# This is the configuration parameter definition file.

# -All supported configurations must be declared in thisfile

# -All tools parsing configurations must check against this file for

validity

# -Changes to this file must be kept minimum and dealt with care

#

# Naming Conventions

# Most parameter names begin with a category name from the following

# list:

# Addr Addressing and translation parameters

# Build?

# Cad Target CAD environment

# DV Design Verification parameters

# Data One of the following:

# DataCache Data Cache parameters

# DataRAM Data RAM parameters

# DataROM Data ROM parameters

# Debug Debug option parameters

# Impl Implementation goals

#Inst One of the following:

# InstCache Instruction Cache parameters

#InstRAM Instruction RAM parameters

#InstROM Instruction ROM parameters

# Interrupt Interrupt parameters

# Isa Instruction Set Architecture parameters

# Iss Instruction Set Simulator parameters  

# PIF Processor Interface parameters

# Sys System parameters (e.g. memory map)

#TIE Application-specific instruction parameters

# Test Manufacturing Test parameters

# Timer Cycle count/compare option parameters

# Vector Reset/Exception/Interrupt vector addresses

# Many parameters end in a suffix giving the units in which they

# are measured:

# Bits

# Bytes (i.e. 8 bits)

# Count used as a generic "number of" suffix

# Entries similar to Count

# Filename absolute pathname of file

# Interrupt interrupt id (0..31)

#################################################### #####################

#

ISA option

#

#################################################### #####################

######

IsaUseClamps 0 0|1

IsaUseMAC16 0 0|1

IsaUseMul16 0 0|1

IlsaUseException 1 1

IsaUseInterrupt 0 0|1

IsaUseHighLevelInterrupt 0 0|1

IsaUseDebug 0 0|1

IsaUseTimer 0 0|1

IsaUseWindowedRegisters 1 1

IsaMemoryOrder LittleEndian LittleEndian|BigEndian

IsaARRegisterCount 32 32|64

#################################################### #####################

######

# address and translation

#################################################### #####################

######

AddrPhysicalAddressBits 32 1[6-9]|2[0-9]|3[0-2]

AddrVirtualAddressBits 32 1[6-9]|2[0-9]|3[0-2]

#################################################### #####################

######

# Data Cache/RAM/ROM

#################################################### #####################

######

DataCacheBytes 1k 0k|1k|2k|4k|8k|16k

DataCacheLineBytes 16 16|32|64

Data RAM Bytes 0k 0k|1k|2k|4k|8k|16k

DataROM Bytes 0k 0k|1k|2k|4k|8k|16k

DataWriteBufferEntries 4 4|8|16|32

DataCacheAccessBits 32 32|64|128

#################################################### #####################

#

Instruction Cache/RAM/ROM

#

#################################################### #####################

######

InstCacheBytes 1k 0k|1k|2k|4k|8k|16k

InstCacheLineBytes 16 16|32|64

InstRAMBytes 0k 0k|1k|2k|4k|8k|16k

InstROM Bytes 0k 0k|1k|2k|4k|8k|16k

InstCacheAccessBits 32 32|64|128

#################################################### #####################

##

processor interface

#

#################################################### #####################

######

PIFReadDataBits 32 32|64|128

PIFWriteDataBits 32 32|64|128

PIFTracePort 0 0|1

#################################################### #####################

##

system

#

#################################################### #####################

######

SysAppStartVAddr 0×40001000 0×[0-9a-fA-F]+

SysDefaultCacheAttr 0×fff21122 0×[0-9a-fA-F]+

SysROM Bytes 128k [0-9]+(k|m)

SysROMPAddr 0×20000000 0×[0-9a-fA-F]+

SysRAMBytes 1m [0-9]+(k|m)

SysRAMPAddr 0×40000000 0×[0-9a-fA-F]+

SysStackBytes 16k [0-9]+(k|m)

SysXMONBytes 0×0000fd00 0×[0-9a-fA-F]+

SysXMONVAddr 0×20000300 0×[0-9a-fA-F]+

SysXTOSBytes 0x00000c00 0x[0-9a-fA-F]+

SysXTOSVAddr 0×40000400 0×[0-9a-fA-F]+

#################################################### #####################

#″″″″

vector address

#

#################################################### ####################

######

VectorResetVAddr 0×20000020 0×[0-9a-fA-F]+

VectorUserExceptionVAddr 0×40000214 0×[0-9a-fA-F]+

VectorKernelExceptionVAddr 0×40000204 0×[0-9a-fA-F]+

VectorWindowBaseVAddr 0×40000000 0×[0-9a-fA-F]+

VectorLevel2InterruptVAddr 0×40000224 0×[0-9a-fA-F]+

VectorLevel3InterruptVAddr 0×40000234 0×[0-9a-fA-F]+

#################################################### #####################

######

interrupt option

#

#################################################### #####################

######

InterruptCount 1 [1-9]|1[0-9]|2[0-9]|3[0-2]

InterruptLevelMax 1 [1-3]

Interrupt0Type External External|Internal|Software

InterruptlType External External|Internal|Software

Interrupt2Type External External|Internal|Software

Interrupt3Type External External|Internal|Software

Interrupt4Type Externa External|Internal|Software

Interrupt5Type External External|Internal|Software

Interrupt6Type External External|Internal|Software

Interrupt7Type External External|Internal|Software

Interrupt8Type External External|Internal|Software

Interrupt9Type External External|Internal|Software

Interrupt10Type External External|Internal|Software

Interrupt1lType External External|Internal|Software

Interrupt12Type External External|Internal|Software

Interrupt13Type External External|Internal|Software

Interrupt14Type External External|Internal|Software

Interrupt15Type External External|Internal|Software

Interrupt16Type External External|Internal|Software

Interrupt17Type External External|Internal|Software

Interrupt18Type External External|Internal|Software

Interrupt19Type External External|Internal|Software

Interrupt20Type External External|Internal|Software

Interrupt21Type External External|Internal|Software

Interrupt22Type External External|Internal|Software

Interrupt23Type External External|Internal|Software

Interrupt24Type External External|Internal|Software

Interrupt25Type External External|Internal|Software

Interrupt26Type External External|Internal|Software

Interrupt27Type External External|Internal|Software

Interrupt28Type External External|Internal|Software

Interrupt29Type External External|Internal|Software

Interrupt30Type External External|Internal|Software

Interrupt31Type External External|Internal|Software

Interrupt0Level 1 [1-3]

InterruptlLevel 1 [1-3]

Interrupt2Level 1 [1-3]

Interrupt3Level 1 [1-3]

Interrupt4Level 1 [1-3]

Interrupt5Level 1 [1-3]

Interrupt6Level 1 [1-3]

Interrupt7Level 1 [1-3]

Interrupt8Level 1 [1-3]

Interrupt9Level 1 [1-3]

Interrupt10Level 1 [1-3]

InterruptllLevel 1 [1-3]

Interrupt12Level 1 [1-3]

Interrupt13Level 1 [1-3]

Interrupt14Level 1 [1-3]

Interrupt15Level 1 [1-3]

Interrupt16Level 1 [1-3]

Interrupt17Level 1 [1-3]

Interrupt18Level 1 [1-3]

Interrupt19Level 1 [1-3]

Interrupt20Level 1 [1-3]

Interrupt21Level 1 [1-3]

Interrupt22Level 1 [1-3]

Interrupt23Level 1 [1-3]

Interrupt24Level 1 [1-3]

Interrupt25Level 1 [1-3]

Interrupt26Level 1 [1-3]

Interrupt27Level 1 [1-3]

Interrupt28Level 1 [1-3]

Interrupt29Level 1 [1-3]

Interrupt30Level 1 [1-3]

Interrupt31Level 1 [1-3]

#################################################### #####################

Other Processor Component Options Processor Timer Options

#

#

#################################################### #####################

######

TimerCount 0 [0-3]

Timer0Interrupt 0 [0-9]|1[0-9[12[0-9]|3[0-1]

Timer1 Interrupt 0 [0-9]|1[0-9]12[0-9]|3[0-1]

Timer2Interrupt 0 [0-9]|1[0-9]12[0-9]|3[0-1]

#################################################### #####################

######

Debugger options

#

#################################################### #####################

######

DebugDataVAddrTrapCount 0 [0-2]

DebugInstVAddrTrapCount 0 [0-2]

DebugInterruptLevel 2 [2-3]

DebugUseOnChipDebug 0 0|1

#################################################### #####################

######

Instruction Set Emulator

#

#################################################### ######################

######

ISSArgcPAddr 0×00012000 0×[0-9a-fA-F]+

ISSArgvPAddr 0×00012004 0×[0-9a-fA-F]+

#################################################### ####################

######

design verification

#

#################################################### #####################

######

DVMagicLocPAddr 0×00010000 0×[0-9a-fA-F]+

DVSerialRXADataPAddr 0×00011000 0×[0-9a-fA-F]+

DVSerialRXBDataPAddr 0×00011010 0×[0-9a-fA-F]+

DVSerialRXStatusPAddr 0×00011020 0×[0-9a-fA-F]+

DVSerialRXRequestPAddr 0×00011030 0×[0-9a-fA-F]+

DVCachedVAddr 0×60000000 0×[0-9a-fA-F]+

DVNonCachedVAddr 0×80000000 0×[0-9a-fA-F]+

#################################################### #####################

######

test options

#

#################################################### #####################

######

TestFullScan 0 0|1

TestLatchesTransparent 0 0|1

#################################################### #####################

##

Processor Implementation Configuration

#

#################################################### #####################

######

ImplTargetSpeed 250 [1-9][0-9]*

ImplTargetSize 20000 [1-9][0-9]*

ImplTargetPower 75 [1-9][0-9]*

ImplSpeedPriority High High|Medium|Low

ImplPowerPriority Medium High|Medium|Low

ImplSizePriority Low High|Medium|low

Impl Target Technology 25m

18m|25m|35m|cx3551|cx3301|acb25typ|acb25wst|t25typical|t25worst|

t35std|lss3g|ibm25typ|ibm25wc|vst_tsmc25tym

ImplOperatingCondition Typical Worst|Typical

#################################################### #####################

######

CAD option

#################################################### #####################

######

CadParUseApollo 1 0|1

CadParUseSiliconEnsembl 0 0|1

CadSimUseVCS 1 0|1

CadSimUseVerilogXL 1 0|1

CadSimUseVerilogNC 1 0|1

CadSimUseVantage 0 0|1

CadSimUseMTI 0 0|1

CadStvUseMotive 0 0|1

CadStvUsePrimeTime 1 0|1

CadSynUseBuildGates 0 0|1

CadSynUseDesignCompiler 1 0|1

#################################################### #####################

#

TIE instruction file. it must be an absolute pathname

#

#################################################### #####################

######

TIE file name \/.*|-

#################################################### #####################

######

#################################################### ###################

######

#

The following program segment is for internal use only. To upload any internal parameters, please confirm

#

# All product components support it.

#################################################### #####################

######

#################################################### #####################

######

#Constants for Athens implementation

IsaUseAthensCacheTest 1 0|1

IsaUseSpeculation 0 0

IsaUseCoprocessor 0 0

IsaUseFloatingPoint0 0

IsaUseDSP 0 0

IsaUseDensityInstruction 1 1

IsaUse32bitMulDiv 0 0

IsaUseAbsdif 0 0

IsaUseCRC 0 0

IsaUsePopCount 0 0

IsaUseLeadingZeros 0 0

IsaUseMinMax 0 0

IsaUseSignExtend 0 0

IsaUseSynchronization 0 0

DataCacheIndexLock 0 0

DataCacheIndexType physical physical

DataCacheMaxMissCount 1 1

DataCacheMissStart 32 32

DataCache ParityBits 0 0

DataCacheSectorSize 16 16

DataCacheTagParityBits 0 0

DataCacheTagType physical physical

DataCacheWayLock 0 0

InstCacheIndexLock 0 0

InstCacheIndexType physical physical

InstCacheMaxMissCount 1 1

InstCacheMissStart 32 32

InstCacheParityBits 0 0

InstCacheSectorSize 16 16

InstCacheTagParityBits 0 0

InstCacheTagType physical physical

InstCacheWayLock 0 0

#################################################### #####################

######

# Build mode...for Web customers.They can run a limited number of

# production builds, but as many eval builds as they like.

#UserCID is used for fingerprinting

#################################################### #####################

######

BuildMode Evaluation Evaluation|Production

BuildUserCID 999 [0-9]+

#################################################### ####################

######

#################################################### #####################

######

#Values used by the GUI-basically persistent state

#################################################### #####################

######

#################################################### #####################

######

SysAddressLayout Xtos Xtos|Manual

Annex B

#! /usr/xtensa/tools/bin/perl

# Tensilica PreProcessor

# SId: tpp, v 1.15 1998/12/17 19:36:03 earl Exp $

#Modified: Kaushik Sheth

# Copyright(C)1998 Tensilica. All rights reserved.

# The original code was taken from Iain McClatchie.

# perl preprocessor

# Copyright(C)1998 Iain McClatchie. All rights reserved. No

warranty implies.

#Author: Iain McClatchie

# You can redistribute and/or modify this software under the terms of the

# GNU General Public License as published by the FreeSoftware Foundation;

# either version 2, or (at your option) any later version.

use lib″@xtools@/lib″;

package tpp;

# Standard perl modules

use strict;

use Exporter();

use Getopt::Long;

# Module stuff

@tpp::ISA=qw(Exporter);

@tpp::EXPORT=qw(

include

error

);

@tpp::EXPORT_OK=qw(

include

the gene

error

);

%tpp::EXPORT_TAGS=();

use vars qw(

$debug

$lines

@incdir

$config

$output

@global_file_stack

);

#Main program

{

S::myname='tpp'; # for error messages

# parse command line

$debug=0; # -debug command line option

$lines=0; # -linescommand lineoption

@incdir=(); # -I command line options

$config="; # -c command line option

$output=undef; # -o command line option

my @eval = ();

if(!GetOptions(

"debug!"=>\$debug,

"lines!" => \Slines,

"I=s@"=>\@incdir,

"c=s"=>\$config,

"o=s"=>\$output,

"eval=s@"=>\@eval)

‖@ARGV<=0){

# command line error

print STDERR << "END";

tpp[args]file

Applies a perl preprocessor to the indicated file, and any files

included therein; the output of the preprocessor is written to

stdout.Perl is embedded in the source text by one of two means.

Whole lines of perl can be embedded by preceding them with a

semicolon (you would typically do this for looping statments or

subroutine calls). Alternatively, perl expressions can be embedded

into the middle of other text by escaping them with backticks.

-debug Print perl code to STDERR, so you can figure out why your

embedded

perl statements are looping forever.

-lines Embed\′#line 43\″foo.w\″\′directives in output, for

more

comprehensive error and warning messages from later

tools.

-I dir search for include files in directory dir

-o output_file Redirect the output to a file rather than astdout.

-c config_file Read the specified config file.

-e eval Eval eval before running program

NOTE:

the lines with only″;″and″; //″will go unaltered.

END

exit(1);

}

#Initialize

push(@INC, @incdir);

@global_file_stack = ();

#Read configuration file

tppcode::init($config);

# Open the output file

if ($output){

open(STDOUT, ">$output")

‖die("$::myname:$!,opening'$output'\n");

}

# Process evals

foreach(@eval){

tppcode::execute(S_);

}

# Process the input files

foreach (@ARGV){

include($_);

}

# Done

exit(0);

}

sub include{

my($file) = @_;

my($buf, $tempname, @chunks, $chunk, $state, $lasttype);

if ($file=~m|^/|){

if(!open(INP,"<$file")){

error($file, "$!, opening $file");

}

}else{

my $path;

foreach $path(″.”, @incdir) {

if(open(INP,"<$path/$file")){

$file = "$path/$file";

last;

}

}

error($file, "Couldn't find $file in @INC")

if tell(INP)==-1;

}

$lasttype="";

while(<INP>){

if(/^\s*;(.*)$/){

my $l = $1;

if ($lasttype ne″perl″){

$lasttype="perl";

}

if((/^\s*;\s*\/\//)‖(/^\s*;\s*$/)){

$buf.="print STDOUT\"$_\";\n";

}else{

$buf.=$1.″\n″;

}

}else{

if ($lines and $lasttype ne″text″){

$buf.＝"print STDOUT\"\#line $.\\\"$file\\\"\\n\";\n";

$lasttype="text";

}

chomp;

if(m/^$/){

$buf.="print STDOUT\"\\n\";\n";

next;

}

@chunks = split("\`");

$state=0;

$tempname="00";

foreach $chunk(@chunks){

if ($state==0){

$chunk = quotemeta($chunk);

$state=1;

} else{

if($chunk＝～m/^\W/){#Perl expression

$buf.="\$temp$tempname=$chunk;\n";

$chunk = "\$\{temp$tempname\}";

$tempname++;

$state=0;

} else{ # Backquoted something

$chunk = "\\\`".quotemeta($chunk);

$state=1;

}

}

}

# check if the line ends with a backquote

if(m/\`$/){

$state=1-$state;

}

error($file, "Unterminated embedded perl expression, line

$.")

if ($state==0);

$buf. = "print STDOUT\"". join("", @chunks).

"\\n\";\n";

}

}

close(INP);

print STDERR $buf if($debug);

push(@global_file_stack, $file);

tppcode::execute($buf);

pop(@global_file_stack);

if ($@){

chomp ($@);

error($file, $@);

}

}

sub gen {

print STDOUT(@_);

}

sub error {

my($file, $err) = @_;

print STDERR″$::myname: Error($err) while preprocessing file

\″$file\″\n″;

my $fn;

foreach $fn(@global_file_stack){

print STDERR″included from\″$fn\″\n″;

}

exit(1);

}

# This package is used to execute the tpp code

package tppcode;

no strict;

use Xtensa::Config;

sub ppp_require{

print STDERR(″tpp: Warning: ppp_require used instead of

tpp::include\n");

tpp::include(@_);

}

sub init(

my($cfile) = @_;

config_set($cfile);

}

sub execute{

my($code) = @_;

eval($code);

}

#

# Local Variables:

# mode: perl

# perl-indent-level: 4

# cperl-indent-level: 4

# End:

Annex C

# Change XTENSA to point to your local installation

XTENSA＝/usr/xtensa/awang/s8

#

# No need to change the rest

#

GCC=/usr/xtensa/stools/bin/gcc

XTCC=$(XTENSA)/bin/xt-gcc

XTRUN=$(XTENSA)/bin/xt-run

XTGO = $(XTENSA)/Hardware/scripts/xtgo

MFILE=$(XTENSA)/Hardware/diag/Makefile.common

all: run-base run-tie-cstub run-iss run-iss-old run-iss-new run-ver

#

# Rules to build various versions of me

#

me-base: me.c me_base.c me_tie.c src.c sad.c

$(GCC) -o me-base -g -O2 -DNX=64 -DNY=64 me.c

me-tie-cstub: me.c me_base.c me_tie.c src.c sad.c

$(GCC) -o me-tie-cstub -g -O2 -DTIE -DNX=64 -DNY=64me.c

me-xt: me.c me_base.c me_tie.c src.c sad.c

$(XTCC) -o me -xt -g -O2 -DXTENSA -DNX=32 -DNY=32me.c

me-xt-old: me.c me_base.c me_tie.c src.c sad.c

$(XTCC) -o me-xt-old -g -O3 -DOLD -DXTENSA -DNX＝32 -DNY＝32

me.c

me-xt-new: me.c me_base.c me_tie.c src.c sad.c

$(XTCC) -o me-xt-new -g -O3 -DNEW -DXTENSA -DNX=32 -DNY=32

me.c

me-xt.s: me.c me_base.c me_tie.c src.c sad.c

$(XTCC) -o me-xt.s -S-O3 -DNOPRINTF -DXTENSA -DNX=16 -DNY=16

me.c

#

# Rules for various runs of me

#

run-base: me-base

me-base; exit 0

run-tie-cstub: me-tie-cstub

me-tie-cstub; exit 0

run-iss:me-xt

$(XTRUN)me -xt

run-iss-old:me-xt-old

$(XTRUN) --verbose me-xt-old

run-iss-new:me-xt-new

$(XTRUN) --verbose me-xt-new

run-ver: me-xt.s testdir

cp me-xt.s testdir/me-xt

$(XTGO)-vcs -testdir `pwd`/testdir -test me-xt>run-ver.out

2>&1

grep Status run-ver.out

testdir:

mkdir -p testdir/me -xt

@echo'all:me-xt.dat me-xt.bfd'>testdir/me-xt/Makefile

@echo "include $(MFILE)" >>testdir/me-xt/Makefile

clean:

rm -rf me-＊＊.out testdir results

APPENDIX I: TEST PROGRAM

#include <stdio.h>

#include <stdlib.h>

#include <limits.h>

#ifndef NX

#define NX 32 /*image width*/

#endif

#ifndef NY

#define NY 32 /*image height*/

#endif

#define BLOCKX 16 /*block width*/

#define BLOCKY 16 /*block height*/

#define SEARCHX 4 /*search regionwidth*/

#define SEARCHY 4 /*search regionheight*/

unsigned char OldB[NX][NY]; /*old image*/

unsigned char NewB[NX][NY]; /*new image*/

unsigned short VectX[NX/BLOCKX][NY/BLOCKY]; /*X motion vector*/

unsigned short VectY[NX/BLOCKX][NY/BLOCKY]; /*Y motion vector*/

unsigned short VectB[NX/BLOCKX][NY/BLOCKY]; /*absolutedifference*/

unsigned short.BaseX[NX/BLOCKX][NY/BLOCKY]; /*Base X motionvector*/

unsigned short BaseY[NX/BLOCKX][NY/BLOCKY]; /*BaseY motionvector*/

unsigned short BaseB[NX/BLOCKX][NY/BLOCKY]; /*Base absolute

difference*/

#define ABS(x) (((x)<0)?(-(x)):(x))

#define MIN(x,y) (((x)<(y))?(x):(y))

#define MAX(x,y) (((x)>(y))?(x):(y))

#define ABSD(x,y) (((x)>(y))?((x)-(y)):((y)-(x)))

^L

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Initialize the 01dB and NewB arrays for testing purposes

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊/

void init()

{

int x, y, x1, y1;

for(x=0; x<NX; x++){

for(y=0; y<NY; y++)(

OldB[x][y]=x^y;

}

}

for(x=0; x<NX; x++){

for(y=0; y<NY; y++){

x1=(x+3)%NX;

y1=(y+4)%NY;

NewB[x][y]=OldB[x1][y1];

}

}

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Check results against full color data

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊/

unsigned check()

{

int bx, by;

for(by=0; by<NY/BLOCKY; by++){

for(bx=0; bx<NX/BLOCKX; bx++){

if (VectX[bx][by] != BaseX[bx][by]) return 0;

if (VectY[bx][by] != BaseY[bx][by]) return 0;

if (VectB[bx][by] != BaseB[bx][by]) return 0;

}

}

return1;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Various implementations of exercise assessment

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊/

#include "me_base.c"

#inClude "me_tie.c"

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

main test program

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊/

int

main(int argc, char ^** argv)

{

int passed;

#ifndef NOPRINTF

printf("Block=(%d,%d), Search=(%d,%d), size=(%d,%d)\n",

BLOCKX, BLOCKY, SEARCHX, SEARCHY, NX, NY);

#endif

init();

#ifdef OLD

motion_estimate base();

passed = 1;

#elif NEW

motion_estimate_tie();

passed = 1;

#else

motion_estimate_base();

motion_estimate_tie();

passed = check();

#endif

#ifndef NOPRINTF

printf(passed? "TIE version passed\n": "＊＊TIE version

failed\n″);

#endif

return passed;

}

APPENDIX II: ME_BASE.C

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊

Implementation of the reference software

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊/

void

motion_estimate_base()

{

int bx, by, cx, cy, x, y;

int startx, starty, endx, endy;

unsigned diff, best, bestx, besty;

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(OldB[cx+x][cy+y],

NewB[bx＊BLOCKX+x][by＊BLOCKY+y]);

}

}

if (diff<best) {

best = diff;

bestx=cx;

besty=cy;

}

}

}

BaseX[bx][by]=bestx;

BaseY[bx][by]=besty;

BaseB[bx][by]=best;

}

}

}

APPENDIX III: ME_TIE.C

#include "src.c"

#include "sad.c"

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Quick Style for Motion Evaluation Using SAD Instructions

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊/

void

motion_estimate_tie()

{

int bx, by, cx, cy, x;

int startx, starty, endx, endy;

unsigned diff0, diff1, diff2, diff3, best, bestx, besty;

unsigned*N, N1, N2, N3, N4, *O, A, B, C, D, E;

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(cy=starty; cy<endy; cy+=sizeof(long)){

for(cx=startx; cx<endx; cx++){

diff0=diff1=diff2=diff3=0;

for(x=0; x<BLOCKX; x++){

N=(unsigned*)

&(NewB[bx＊BLOCKX+x][by＊BLOCKY]);

N1=N[0];

N2=N[1];

N3=N[2];

N4=N[3];

O=(unsigned*)&(OldB[cx+x][cy]);

A=O[0];

B=O[1];

C=O[2];

D=O[3];

E=O[4];

diff0+=SAD(A, N1)+SAD(B, N2)+

SAD(C, N3)+SAD(D, N4);

#ifdef BIG_ENDIAN

SSAI(24);

diff1+=SAD(SRC(A,B),N1)+SAD(SRC(B,C),N2)

+

SAD(SRC(C,D),N3)+SAD(SRC(D,E),

N4);

SSAI(16);

diff2+=SAD(SRC(A,B),N1)+SAD(SRC(B,C),N2)

+

SAD(SRC(C,D),N3)+SAD(SRC(D,E),

N4);

SSAI(8);

diff3+=SAD(SRC(A,B),N1)+SAD(SRC(B,C),N2)

+

SAD(SRC(C,D),N3)+SAD(SRC(D,E),

N4);

#else

SSAI(8);

diff1+=SAD(SRC(B,A),N1)+SAD(SRC(C,B),N2)

+

SAD(SRC(D,C),N3)+SAD(SRC(E,D),

N4);

SSAI(16);

diff2+=SAD(SRC(B,A),N1)+SAD(SRC(C,B),N2)

+

SAD(SRC(D,C),N3)+SAD(SRC(E,D),

N4);

SSAI(24);

diff3+=SAD(SRC(B,A),N1)+SAD(SRC(C,B),N2)

+

SAD(SRC(D,C),N3)+SAD(SRC(E,D),

N4);

#endif

O+=NY/4;

N+=NY/4;

}

if(diff0<best){

best = diff0;

bestx=cx;

besty=cy;

}

if(diff1<best){

best = diff1;

bestx=cx;

besty=cy+1;

}

if(diff2<best){

best = diff2;

bestx=cx;

besty=cy+2;

}

if(diff3<best){

best = diff3;

bestx=cx;

besty=cy+3;

}

}

}

VectX[bx][by]=bestx;

VectY[bx][by]=besty;

VectB[bx][by]=best;

}

}

}

APPENDIX IV: SAD.C

#if defined(XTENSA)

#include <machine/Customer.h>

#elif defined(TIE)

#include "../dk/me_cstub.c"

#else

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

sum of absolute differences of 4 bytes

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊/

static inline unsigned

SAD (unsigned ars, unsigned art)

{

return ABSD(ars>>24, art>>24)+

ABSD((ars>>16)&255, (art>>16)&255)+

ABSD((ars>>8)&255, (art>>8)&255)+

ABSD(ars & 255, art &255);

}

#endif

APPENDIX V: SRC.C

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

If the object code is the original code, use a global variable to store the SSAI bits

displacement.

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Direct access to right-shift chained instructions. The offset should be loaded with SSAI() alone

register

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Direct access to the Shift Right Concatenate Instruction.

The shift amount register must be loaded separately with SSAI().

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊/

static inline unsigned

SRC (unsigned ars, unsigned art)

{

unsigned arr;

#ifndef XTENSA

arr=(ars<<(32-sar))|(art>>sar);

#else

asm volatile("src\t%0,%1,%2":"=a"(arr):"a"(ars), "a"

(art));

#endif

return arr;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

set displacement register

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊/

static inline void

SSAI(int count)

{

#ifndef XTENSA

sar=count;

#else

switch(count){

case 8:

asm volatile("ssai\t8");

break;

case 16:

asm volatile("ssai\t16");

break;

case 24:

asm volatile("ssai\t24");

break;

default:

exit(-1);

}

#endif

}

APPENDIX VI: SOURCE CODE

/*

Block Motion Estimation：

The purpose of motion estimation is to find the unaligned 8×8 blockof

an existing (old) image that most closely resembles an aligned 8×8

block.The search here is at any byte offset in+/- 16 bytes in×and

+/- 16 bytes in y. The search is a set of six nested loops.

OldB is pointer to a byte array of old block

NewB is pointer to a byte array of base block

*/

#define NY 480

#define NX 640

#define BLOCKX 16

#define BLOCKY 16

#define SEARCHX 16

#define SEARCHY 16

unsigned char OldB[NX][NY];

unsigned char NewB[NX][NY];

unsigned short VectX[NX/BLOCKX][NY/BLOCKY];

unsigned short VectY[NX/BLOCKX][NY/BLOCKY];

#define MIN(x,y) ((x<y)?x:y)

#define MAX(x, y) ((x > y)? x: y)

#define ABS(x) ((x<0)?(-x):(x))

/*initialization with reference image data for test purposes*/

void init()

{

intx,y;

for (x=0; x<NX; x++) for (y=0; y<NY; y++){

OldB[x][y]=x^y;

NewB[x][y]=x+2*y+2;

}

}

main()

{

int by, bx, cy, cx, yo, xo;

unsigned short best, bestx, besty, sumabsdiff0;

init();

for(by=0; by<NY/BLOCKY; by++){

for(bx=0; bx<NX/BLOCKX; bx++){/*for each 8×8 block in the

image＊/

best=0×ffff; /*look for the minimum difference*/

for(cy=MAX(0,(by*BLOCKY)-SEARCHY);

cy<MIN(NY-BLOCKY, (by＊BLOCKY)+SEARCHY);

cy++){/*for the old block at each line*/

for (cx=MAX(0, (bx*BLOCKX)-SEARCHX);

cx<MIN(NX-BLOCKX, (bx*BLOCKX)+SEARCHX);

cx++){

/*test the N×N block at (bx, by) against NxN blocks*/

/*at(cx, cy)*/

sumabsdiff0 = 0;

for(yo=0; yo<BLOCKY; yo++){/*for each of N rows in block

*/

for(xo=0; xo<BLOCKX; xo++){/*for each of N pixels in

row*/

sumabsdiff0+=

ABS(OldB[cx+xo][cy+yo]-

NewB[bx＊BLOCKX+xo][by＊BLOCKY+yo]);

}

}

if(sumabsdiff0<best){

best = sumabsdiff0; bestx = cx; besty = cy; }

}

}

VectX[bx][by]=bestx;

VectY[bx][by]=besty;

}

}

Appendix VII: Optimizing C Code with TIE

Pixel values are packed as 4/word

OldW is a pointer to a word array of the old block

NewW is a pointer to an array of words for the base block

#define NY 480

#define NX 640

#define BLOCKX 16

#define BLOCKY 16

#define SEARCHX 16

#define SEARCHY 16

#define MIN(x,y) ((x<y)?x:y)

#define MAX(x, y) ((x > y)? x: y)

unsigned long OldW[NY][NX/sizeof(long)];

unsigned long NewW[NY][NX/sizeof(long)];

unsigned short VectX[NY/BLOCKY][NX/BLOCKX];

unsigned short VectY[NY/BLOCKY][NX/BLOCKX];

void init()

{

int x, y;

for(x=0; x<NX/sizeof(long); x++) for(y=0; y<NY; y++){

OldW[y][x]=((x<<2)^y)<<24|(((x<<2)+1)^y)<<16|(((x<<2)+2 )^y)<<8

|((x<<2)+3)^y;

NewW[y][x]=((x<<2)+2*y+2)<<24|(((x<<2)+1)+2*y+2)<<16|

(((x<<2)+2)+2*y+2)<<8|((x<<2)+3)+2*y+2;

}

}

main()

{

register int by, bx, cy, cx, yo, xo;

register unsigned short

best, bestx, besty, sumabsdiff0, sumabsdiffl, sumabsdiff2, sumabsdiff3;

init();

for(by=0; by<NY/BLOCKY; by++){

for(bx=0; bx<NX/BLOCKX; bx++){/*for each N×N block in the

image＊/

best=0×ffff; /*look for the minimum difference*/

for(cy=MAX(0,(by*BLOCKY)-SEARCHY);

cy<MIN(NY-BLOCKY, (by＊BLOCKY)+SEARCHY);

cy++){/*for the old block at each line*/

for(cx=MAX(0,(bx*BLOCKX-SEARCHX)/sizeof(long));

cx<MIN((NX-BLOCKX-2)/sizeof(long), (bx*BLOCKX+SEARCHX)/

sizeof(long));

cx++){/*and each word(4byte)offset in line*/

/*test the NxN block at(bx，by) against four N×N blocks*/

/*at(cx, cy), (cx+1B, cy), (cx+2B, cy)(cx+3B, cy)*/

sumabsdiff0 = sumabsdiff1 = sumabsdiff2 = sumabsdiff3 = 0;

for(yo=0; yo<BLOCKY; yo++){/*for each of the N lines in

the block*/

for(xo=0; xo<BLOCKX/8; xo+=2){

register unsigned long*N, N1, N2*O, A, B, C, W, X;

N＝&NewW[by+yo][bx＊BLOCKX/sizeof(long)+xo];

N1=*N; N2=*(N+1); /*2words of subject image*/

O＝&OldW[cy+yo][cx+xo];

A=*O; B=*(O+1); C=*(O+2); /*3 words of

reference*/

sumabsdiff0+=sad(A,N1)+sad(B,N2);

SHIFT(24)/*shift A, B, C left by one byte into W, X*/

sumabsdiff1+=sad(W,N1)+sad(X,N2);

SHIFT(16)/*shift, B, C left by two bytes into W, X*/

sumabsdiff2+=sad(W,N1)+sad(X,N2);

SHIFT(8)/*shift A, B, C lft by three bytes into W, X

*/

sumabsdiff3+=sad(W,N1)+sad(X,N2);

}

}

if(sumabsdiff0<best){

best = sumabsdiff0; bestx = cx; besty = cy; }

if(sumabsdiff1<best){

best = sumabsdiffl; bestx = cx+1; besty = cy; }

if(sumabsdiff2<best){

best = sumabsdiff2; bestx = cx+2; besty = cy; }

if(sumabsdiff3<best){

best = sumabsdiff3; bestx = cx+3; besty = cy; }

}

}

VectX[bx][by]=bestx;

VectY[bx][by]=besty;

}

}

}

Annex D

/*

＊ TIE to Verilog translation routines

*/

/* SId: tie2ver_write.c, v 1.27 1999/05/11 00:10:18 awang Exp S */

/*

＊Copyright 1998-1999 Tensilica Inc.

* These coded instructions, statements, and computer programs are

＊Confidential Proprietary Information of Tensilica Inc. and may not

be

＊disclosed to third parties or copied in any form, in whole or in

part,

＊without the prior written consent of Tensilica Inc.

*/

#include <math.h>

#include "tie.h"

#include "st.h"

#define COMMENTS″//Do not modify this automatically generated file.”

static void tie2ver_write_expression(

FILE*fp, tie_t*exp, int lhs, st_table*is, st_table*os);

#define tie2ver_program_foreach_instruction(_prog, _inst) { \

tie_t*_iclass; \

tie_program_foreach_iclass(_prog, _iclass) { \

if(tie_get_predefined(_iclass))continue; \

tie_iclass_foreach_instruction(_iclass, _inst){

#define end_tie2ver_program_foreach_instruction \

} end_tie_iclass_foreach_instruction; \

} end_tie_program_foreach_iclass; \

}

#defineTIE_ENFLOP″\n\

module tie_enflop(tie_out, tie_in, en, clk);\n\

parameter size=32;\n\

output[size-1:0]tie_out;\n\

input[size-1:0]tie_in;\n\

input en;\n\

input clk;\n\

reg[size-1:0]tmp;\n\

assign tie_out=tmp;\n\

always@(posedge clk)begin\n\

if(en)\n\

tmp<=#1tie_in;\n\

end\n\

endmodule\n″

#define TIE_FLOP″\n\

module tie_flop(tie_out, tie_in, clk);\n\

parameter size=32;\n\

output [size-1:0] tie_out;\n\

input [size-1:0] tie_in;\n\

input clk;\n\

reg [size-1:0] tmp;\n\

assign tie_out = tmp;\n\

always @(posedge clk)begin\n\

tmp<=#1 tie_n;\n\

end\n\

endmodule\n″

#define TIE_ATHENS_STATE″\n\

module tie athens_state(ns, we, ke, kp, vw, clk, ps);\n\

parameter size=32;\n\

input[size-1:0]ns; //next state\n\

input we; //write enable\n\

input ke; //Kill E state\n\

input kp; //Kill Pipeline\n\

input vw; //Valid W state\n\

input clk; //clock\n\

output [size-1:0] ps; //present state\n\

\n\

wire[size-1∶0]se; //state at E stage\n\

wire[size-1∶0]sm; //state at M stage\n\

wire[size-1∶0]sw; //state at W stage\n\

wire[size-1∶0]sx; //state at X stage\n\

wire ee; //write enable for EM register\n\

wire ew; //write enable for WX register\n\

\n\

assign se=kp? sx:ns;\n\

assign ee＝kp|we &～ke;\n\

assign ew=vw &～kp;\n\

assign ps=sm;\n\

\n\

tie_enflop #(size) state_EM(.tie_out(sm), .tie_in(se), .en(ee),

.clk(clk));\n\

tie_flop #(size)state_MW(.tie_out(sw), .tie_in(sm), .clk(clk));\n\

tie_enflop #(size) state_WX(.tie_out(sx), .tie_in(sw), .en(ew),

.clk(clk));\n\

\n\

endmodule\n″

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Build and return global program → operations for operands of user-defined instructions

Make a table of numbers. The returned table does not contain the operations used by the pre-defined instructions

Count.

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static t_table*

tie2ver_program_get_operand_table(tie_t*prog)

{

static st_table * tie2ver_program_args = 0;

tie_t * inst;

char*key,*value;

st_table * operand_table;

st_generator * gen;

if (tie2ver_program_args==0){

tie2ver_program_args = st_init_table(strcmp, st_strhash);

tie2ver_program_foreach_instruction(prog, inst) {

operand_table = tie_instruction_get_operand_table(inst);

st_foreach_item(operand_table, gen, &key, &value){

st_insert(tie2ver_program_args, key, value);

}

} end_tie2ver_program_foreach_instruction;

}

return tie2ver_program_args;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

print a wiring statement

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_wire(FILE*fp, tie_t*wire)

{

int from, to, write_comma;

tie_t *first, *second, *var;

first = tie_get_first_child(wire);

ASSERT(tie_get_type(first)==TIE_INT);

from=tie_get_integer(first);

second = tie_get_next_sibling(first);

ASSERT(tie_get_type(second)==TIE_INT);

to = tie_get_integer(second);

fprintf(fp, "wire");

if(!(from==0 && to==0)){

fprintf(fp, "[%d:%d]", from, to);

}

write_comma=0;

var = tie_get_next_sibling(second);

while (var != 0) {

if(write_comma){

fprintf(fp, ", ");

}else{

write_comma=1;

}

fprintf(fp, "%s", tie_get_identifier(var));

var = tree_get_next_sibling(var);

}

fprintf(fp, ";\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

print a unary expression

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_unary(

FILE*fp, const char*op, tie_t*exp, intlhs, st_table*is, st_table

*os)

{

fprintf(fp, "%s(", op);

tie2ver_write_expression(fp, exp, lhs, is, os);

fprintf(fp, ")");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

print a binary expression

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_binary(

FILE*fp, const char*op, tie_t*exp1, tree_t*exp2,

int lhs, st_table*is, st_table*os)

{

fprintf(fp, "(");

tie2ver_write expression(fp, exp1, lhs, is, os);

fprintf(fp, ")%s(", op);

tie2ver_write_expression(fp, exp2, lhs, is, os);

fprintf(fp, ")");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

print an identifier

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_identifier(

FILE*fp, tie_t*id, int lhs, st_table*is, st_table*os)

{

tie_t *prog, *first, *second;

char *name, *dummy;

name = tie_get_identifier(id);

if((is != 0) && st_lookup(is, name, &dummy)){

fprintf(fp, "%s_%s", name, lhs? "ns": "ps");

} else if((os!=0) && st_lookup(os, name, &dummy)){

fprintf(fp, "%s_%s", name, lhs? "ns": "ps");

}else{

fprintf(fp, "%s", name);

}

first = tie_get_first_child(id);

if(first==0){

return;

}

/*detect whether this is a table access*/

prog = tie_get_program(id);

if(tie_program_get_table_by_name(prog, name) != 0){

switch(tie_get_type(first)){

caseTIE_ID:

fprintf(fp, "(%s)", tie_get_identifier(first));

break;

case TIE_INT:

fprintf(fp, "(%d)", tie_get_integer(first));

break;

default:

DIE("Error: expected type\n");

}

return;

}

second = tie_get_next_sibling(first);

if(second==0){

fprintf(fp, "[%d]", tie_get_integer(first));

return;

}

fprintf(fp, "[%d:%d]", tie_get_integer(first)

tie_get_integer(second));

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

print chain expression

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_concatenation(

FILE*fp, tie_t*exp, intlhs, st_table*is, st_table*os)

{

tie_t * comp;

int write_comma;

write_comma=0;

fprintf(fp, "{");

tie_foreach_child(exp, comp) {

if(write_comma){

fprintf(fp, ", ");

}else{

write_comma=1;

}

tie2ver_write_expression(fp, comp, lhs, is, os);

} end_tie_foreach_child;

fprintf(fp, "}");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

print conditional statement

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_conditional(

FILE*fp, tie_t*exp, int lhs, st_table*is, st_table*os)

{

tie_t *cond_exp, *then_exp, *else_exp;

cond_exp = tie_get_first_child(exp);

then_exp = tie_get_next_sibling(cond_exp);

else_exp = tie_get_next_sibling(then_exp);

ASSERT(tie_get_last_child(exp)==else_exp);

fprintf(fp, "(");

tie2ver_write_expression(fp, cond_exp, lhs, is, os);

fprintf(fp, ")? (");

tie2ver_write_expression(fp, then_exp, lhs, is, os);

fprintf(fp, "): (");

tie2ver_write_expression(fp, else_exp, lhs, is, os);

fprintf(fp, ")");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

print copy statement

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_replication(

FILE*fp, tie_t*exp, int lhs, st_table*is, st_table*os)

{

tie_t *num, *comp;

num = tie_get_first_child(exp);

comp = tie_get_next_sibling(num);

ASSERT(tie_get_last_child(exp)==comp);

ASSERT(tie_get_type(num)==TIE_INT);

fprintf(fp, "{%d{", tie_get_integer(num));

tie2ver_write_expression(fp, comp, lhs, is, os);

fprintf(fp, "}}");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

print an expression

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_expression(

FILE*fp, tie_t*exp, int lhs, st_table*is, st_table*os)

{

tie_type_ttype;

tie_t *first, *second;

first = tie_get_first_child(exp);

second=first==0?0: tie_get_next_sibling(first);

switch(type=tie_get_type(exp))(

case TIE_ID:

tie2ver_write_identifier(fp, exp, lhs, is, os);

break;

case TIE_INT:

fprintf(fp, "%d", tie_get_integer(exp)); break;

case TIE_CONST:

fprintf(fp, "%s", tie_get_constant(exp)); break;

case TIE_LOGICAL_NEGATION:

tie2ver_write_unary(fp, "!", first, lhs, is, os); break;

case TIE_LOGICAL_AND:

tie2ver_write_binary(fp, "&&", first, second, lhs, is, os);

break;

case TIE_LOGICAL_OR:

tie2ver_write_binary(fp, "||", first, second, lhs, is, os);

break;

case TIE_BITWISE_NEGATION:

tie2ver_write_unary(fp, "~", first, lhs, is, os); break;

case TIE_BITWISE_AND:

tie2ver_write_binary(fp, "&", first, second, lhs, is, os);

break;

case TIE_BITWISE_OR:

tie2ver_write_binary(fp, "|", first, second, lhs, is, os);

break;

case TIE_BITWISE_XOR:

tie2ver_write_binary(fp, "^", first, second, lhs, is, os);

break;

case TIE_BITWISE_XNOR:

tie2ver_write_binary(fp, "~^", first, second, lhs, is, os);

break;

case TIE_ADD:

tie2ver_write_binary(fp, "+", first, second, lhs, is, os);

break;

case TIE_SUB:

tie2ver_write_binary(fp, "-", first, second, lhs, is, os);

break;

case TIE_MULT:

tie2ver_write_binary(fp, "*", first, second, lhs, is, os);

break;

case TIE_GT:

tie2ver_write_binary(fp, ">", first, second, lhs, is, os);

break;

case TIE_GEQ:

tie2ver_write_binary(fp, ">=", first, second, lhs, is, os);

break;

case TIE_LT:

tie2ver_write_binary(fp, "<", first, second, lhs, is, os);

break;

case TIE_LEQ:

tie2ver_write_binary(fp, "<=", first, second, lhs, is, os);

break;

case TIE_EQ:

tie2ver_write_binary(fp, "==", first, second, lhs, is, os);

break;

case TIE_NEQ:

tie2ver_write_binary(fp, "!=", first, second, lhs, is, os);

break;

case TIE_REDUCTION_AND:

tie2ver_write_unary(fp, "&", first, lhs, is, os); break;

case TIE_REDUCTION_OR:

tie2ver_write_unary(fp, "|", first, lhs, is, os); break;

case TIE_REDUCTION_XOR:

tie2ver_write_unary(fp, "^", first, lhs, is, os); break;

case TIE_SHIFT_LEFT:

tie2ver_write_binary(fp, "<<", first, second, lhs, is, os);

break;

case TIE_SHIFT_RIGHT:

tie2ver_write_binary(fp, ">>", first, second, lhs, is, os);

break;

case TIE_REPLICATION:

tie2ver_write_replication(fp, exp, lhs, is, os);

break;

case TIE_CONCATENATION:

tie2ver_write_concatenation(fp, exp, lhs, is, os);

break;

case TIE_CONDITIONAL:

tie2ver_write_conditional(fp, exp, lhs, is, os);

break;

default:

fprintf(stderr, "Wrong type: %d\n", type);

DIE("Error: wrong expression type\n");

}

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

print an assignment statement

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_assignment(

FILE*fp, tie_t*assign, st_table*in_states, st_table*out_states)

{

tie_t *lval, *rval;

ASSERT(tie_get_type(assign)==TIE_ASSIGNMENT);

lval = tie_get_first_child(assign);

rval = tie_get_last_child(assign);

ASSERT(tie_get_next_sibling(lval)==rval);

ASSERT(tie_get_-prev_sibling(rval)==lval);

fprintf(fp, "assign");

tie2ver_write_expression(fp, lval, 1, in_states, out_states);

fprintf(fp, "=");

tie2ver_write_expression(fp, rval, 0, in_states, out_states);

fprintf(fp, ";\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

print a statement list

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_statement(

FIEE*fp, tie_t*statement, st_table*in_states, st_table*out_states)

{

tie_t*child;

ASSERT(tie_get_type(statement)==TIE_STATEMENT);

tie_foreach_child(statement, child){

switch(tie_get_type(child)){

case TIE_WIRE:

tie2ver_write_wire(fp, child);

break;

case TIE_ASSIGNMENT:

tie2ver_write_assignment(fp, child, in_states, out_states);

break;

default:

DIE("Error: illegal program statement\n");

}

} end_tie_foreach_child;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write a module definition for "iclass"

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_module_declaration(FILE*fp, tie_t*semantic)

{

st_table *operand_table, *state_table;

st_generator * gen;

tie_t *ilist, *inst;

char *c, *key, *value;

fprintf(fp, "\n");

fprintf(fp, "module %s(", tie_semantic_get_name(semantic));

c = "";

operand_table = tie_semantic_get_operand_table(semantic);

st_foreach_item(operand_table, gen, &key, &value){

fprintf(fp, "%s %s", c, key);

c = ",";

}

state_table = tie_semantic_get_in_state_table(semantic);

st_foreach_item(state_table, gen, &key, &value){

fprintf(fp, "%s%s_ps", c, key);

c = ",";

}

state_table = tie_semantic_get_out_state_table(semantic);

st_foreach_item(state_table, gen, &key, &value){

fprintf(fp, "%s%s_ns", c, key);

fprintf(fp, "%s%s_we", c, key);

c = ",";

}

ilist = tie_semantic_get_inst_list(semantic);

tie_inst_list_foreach_instruction(ilist, inst) {

fprintf(fp, ", %s", tie_instruction_get_name(inst));

} end_tie_inst_list_foreach_instruction;

fprintf(fp, ");\n");

st_foreach_item(operand_table, gen, &key, &value){

switch((tie_type_t)value){

case TIE_ARG_IN:

fprintf(fp, "input[31:0] %s;\n", key); break;

case TIE_ARG_OUT:

fprintf(fp, "output[31:0] %s;\n", key); break;

case TIE_ARG_INOUT:

fprintf(fp, "inout[31:0] %s;\n", key); break;

default:

DIE("Error: unexpected arg type\n");

}

}

state_table = tie_semantic_get_in_state_table(semantic);

st_foreach_item(state_table, gen, &key, &value){

fprintf(fp, "input[%d:0]%s_ps;\n", (int) value_1, key);

}

state_table = tie_semantic_get_out_state_table(semantic);

st_foreach_item(state_table, gen, &key, &value){

fprintf(fp, "output[%d:0]%s_ns;\n", (int) value-1, key);

fprintf(fp, "output% s_we;\n", key);

}

tie_inst_list_foreach_instruction(ilist, inst) {

fprintf(fp, "input %s;\n", tie_instruction_get_name(inst));

} end_tie_inst_list_foreach_instruction;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Print the "table" to a TIE file

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_table(FILE*fp, tie_t*table)

{

int i, width, size, bits, ivalue;

char *oname, *iname, *cvalue;

tie_t*value;

>

iname = "index";

width = tie_table_get_width(table);

size=tie_table_get_depth(table);

bits=(int)ceil(log(size)/log(2));

fprintf(fp, "\nfunction[%d:0] %s;\n", width-1, oname);

fprintf(fp, "input[%d:0]%s;\n", bits-1, iname);

fprintf(fp, "case(%s)\n", iname);

i=0;

tie table_foreach_value(table, value) {

fprintf(fp, "%d'd %d: %s=", bits, i, oname);

switch(tie_get_type(value)){

case TIE_CONST:

cvalue = tie_get_constant(value);

fprintf(fp, "%d'b%s;\n", width,

tie_constant_get_binary_string(cvalue));

break;

case TIE_INT:

ivalue = tie_get_integer(value);

fprintf(fp, "%d'd %d;\n", width, ivalue);

break;

default:

DIE("Internal Error: unexpected type\n");

}

i++;

} end_tie_table_foreach_value;

fprintf(fp, "default: %s = %d'd0;\n", oname, width);

fprintf(fp, "endcase\n");

fprintf(fp, "endfunction\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Write write-enable logic for each state modified by a "semantic" statement

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_semantic_write_we(FILE*fp, tie_t*semantic)

{

tie_t * inst;

st_table *semantic_state_table, *inst_state_table;

st_generator * gen;

char *key, *value, *c, *iname;

int found;

semantic_state_table = tie_semantic_get_out_state_table(semantic);

st_foreach_item(semantic_state_table, gen, &key, &value){

fprintf(fp, "assign%s_we=", key);

c = "";

tie_semantic_foreach_instruction(semantic, inst) {

iname = tie_instruction_get_name(inst);

inst_state_table = tie_instruction_get_state_table(inst);

found = st_lookup(inst_state_table, key, &value);

if (found && ((tie_type_t) value!=TIE_ARG_IN)){

fprintf(fp, "%s1'b1 & %s", c, iname);

}else{

fprintf(fp, "%s1'b0 & %s", c, iname);

}

c = "\n|";

} end_tie_semantic_foreach_instruction;

fprintf(fp, ";\n");

}

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

*

Write "semantic" statements to a TIE file

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_semantic(FILE*fp, tie_t*semantic)

{

tie_t *table, *statement;

ls_t *tables;

st_table *in_state_table, *out_state_table;

ASSERT(tie_get_type(semantic)==TIE_SEMANTIC);

tie2ver_write_module_declaration(fp, semantic);

statement = tie_semantic_get_statement(semantic);

in_state_table = tie_semantic_get_in_state_table(semantic);

out_state_table = tie_semantic_get_out_state_table(semantic);

tie2ver_write_statement(fp, statement, in_state_table,

out_state_table);

tables = tie_expression_get_tables(statement,

tie_get_program(semantic));

ls_foreach data(tie_t*, tables, table) {

tie2ver_write_table(fp, table);

} end_ls_foreach_data;

ls_free(tables);

tie2ver_semantic_write_we(fp, semantic);

fprintf(fp, "endmodule\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

print top-level module descriptions for composite semantics

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_top_module(FILE*fp, tie_t*prog)

{

st_generator * gen;

char*key,*value;

st_table * operand_table;

tie_t *inst, *iclass;

fprintf(fp, "\n");

fprintf(fp, "module UserInstModule(clk, out_E, ars_E, art_E,

inst_R″);

fprintf(fp, ", Kill_E, killPipe_W, valid_W");

tie_program_foreach_iclass(prog, iclass){

if(tie_get_predefined(iclass))continue;

tie_iclass_foreach_instruction(iclass, inst) {

fprintf(fp, ", %s_R", tie_instruction_get_name(inst));

} end_tie_iclass_foreach_instruction;

} end_tie_program_foreach_iclass;

fprintf(fp, ", en_R);\n");

fprintf(fp, "input clk;\n");

fprintf(fp, "output[31:0] out_E;\n");

fprintf(fp, "input[31:0]ars_E;\n");

fprintf(fp, "input[31:0]art_E;\n");

fprintf(fp, "input[23:0] inst_R;\n");

fprintf(fp, "input en_R;\n");

fprintf(fp, "input Kill_E, killPipe_W, valid_W;\n");

tie2ver_program_foreach_instruction(prog, inst) {

fprintf(fp, "input %s_R;\n", tie_instruction_get_name(inst));

} end_tie2ver_program_foreach_instruction;

tie2ver_program_foreach_instruction(prog, inst) {

fprintf(fp, "wire %s_E;\n", tie_instruction_get_name(inst));

} end_tie2ver_program_foreach_instruction;

operand_table = tie2ver_program_get_operand_table(prog);

st_foreach_item(operand_table, gen, &key, &value){

if((tie_type_t)value!=TIE_ARG_IN){

fprintf(fp, "wire[31:0]%s_E;\n", key);

}

}

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Write one for each semantic block and for each output of each selection signal

segment wiring program

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_wire_declaration(FILE*fp, tie_t*prog)

{

tie_t *semantic, *state;

st_table *operand_table, *global_operand_table;

st_table * state_table;

st_generator * gen;

char *key, *value, *shame;

int width;

global_operand_table = tie2ver_program_get_operand_table(prog);

st_forsach_item(global_operand_table, gen, &key, &value){

if((tie_type_t)value==TIE_ARG_IN){

if(strcmp(key, "art") != 0 && strcmp(key, "ars") != 0){

fprintf(fp, "wire[31:0] %s_R, %s_E;\n", key, key);

}

}

}

tie_program_foreach_state(prog, state) {

if(tie_get_predefined(state))continue;

sname = tie_state_get_name(state);

width = tie_state_get_width(state);

fprintf(fp, "wire[%d:0] %s_ps, %s_ns;\n", width-1, sname,

sname);

fprintf(fp, "wire % s_we;\n", sname);

} end_tie_program_foreach_state;

tie_program_foreach_semantic(prog, semantic){

if(tie_get_predefined(semantic))continue;

sname = tie_semantic_get_name(semantic);

operand_table = tie_semantic_get_operand_table(semantic);

st_foreach_item(operand_table, gen, &key, &value){

if((tie_type_t)value!=TIE_ARG_IN){

fprintf(fp, "wire{31:0] %s_%s;\n", sname, key);

}

}

state_table = tie_semantic_get_out_state_table(semantic);

st_foreach_item(state_table, gen, &key, &value){

fprintf(fp, "wire[%d:0] %s_%s_ns;\n", (int) value - 1,

sname,key);

fprintf(fp, "wire%s_%s_we;\n", sname, key);

}

fprintf(fp, "wire % s_select;\n", sname);

} end_tie_program_foreach_semantic;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write a floating-point arithmetic statement

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_flop_instance(FILE*fp, char*name, int num)

{

char*fmt;

fmt = "tie_flop#(%d)f%s(.tie_out(%s_E), .tie_in(%s_R),

.clk(clk));\n″;

fprintf(fp, fmt, num, name, name, name);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Latch all command signals for R class

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_flop(FILE*fp, tie_t*prog)

{

char*name;

tie_t * inst;

tie2ver_program_foreach_instruction(prog, inst) {

name = tie_instruction_get_name(inst);

tie2ver_write_flop_instance(fp, name, 1);

} end_tie2ver_program_foreach_instruction;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write an instance for each semantic block

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_semantic_instance(FILE*fp, tie_t*prog)

{

tie_t *semantic, *ilist, *inst;

const char *iname, *aname, *c;

st_table *operand_table, *state_table;

st_generator * gen;

char*key,*value;

tie_program_foreach_semantic(prog, semantic){

if(tie_get_predefined(semantic))continue;

iname = tie_semantic_get_name(semantic);

fprintf(fp, "%s i%s(", iname, iname);

c = "";

operand_table = tie_semantic_get_operand_table(semantic);

st_foreach_item(operand_table, gen, &key, &value){

if((tie_type_t)value==TIE_ARG_IN){

fprintf(fp, "%s\n.%s(%s_E)", c, key, key);

}else{

fprintf(fp, "%s\n.%s(%s_%s)", c, key, iname, key);

}

c = ",";

}

state_table = tie_semantic_get_in_state_table(semantic);

st_foreach_item(state_table, gen, &key, &value){

fprintf(fp, "%s\n.%s_ps(%s_ps)", c, key, key);

c = ",";

}

state_table = tie_semantic_get_out_state_table(semantic);

st_foreach_item(state_table, gen, &key, &value){

fprintf(fp, "%s\n.%s_ns(%s_%s_ns)", c, key, iname, key);

fprintf(fp, "%s\n.%s_-we(%s_%s_we)", c, key, iname, key);

c = ",";

}

ilist = tie_semantic_get_inst_list(semantic);

tie_inst_list_foreach_instruction(ilist, inst) {

aname = tie_instruction_get_name(inst);

fprintf(fp, ",\n.%s(%s_E)", aname, aname);

} end_tie_inst_list_foreach_instruction;

fprintf(fp, ");\n");

} end_tie_program_foreach_semantic;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write an instance for each state

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_state_instance(FILE*fp, tie_t*prog)

{

tie_t *state;

char*sname;

int width;

tie_program_foreach_state(prog, state) {

if(tie_get_predefined(state))continue;

sname = tie_state_get_name(state);

width = tie_state_get_width(state);

fprintf(fp, "tie_athens_state #(%d)i%s(\n", width, sname);

fprintf(fp, ".ns(%s_ns), \n", sname);

fprintf(fp, ".we(%s_we),\n", sname);

fprintf(fp, ".ke(Kill_E),\n");

fprintf(fp, ".kp(killPipe_W),\n");

fprintf(fp, ".vw(valid_W),\n");

fprintf(fp, ".clk(clk),\n");

fprintf(fp, ".ps(%s_ps));\n", sname);

} end_tie_program_foreach_state;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write operand selection logic for an output

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_operand_selection_logic_one(FILE*fp, tie_t*prog, char

*name)

{

tie_t * semantic;

char *c, *dummy;

st_table * operand_table;

fprintf(fp, "assign %s_E=", name);

c = "";

tie_program_foreach_semantic(prog, semantic){

if(tie_get_predefined(semantic))continue;

operand_table = tie_semantic_get_operand_table(semantic);

fprintf(fp, "%s", c);

if(st_lookup(operand_table, name, &dummy)){

fprintf(fp, "%s_", tie_semantic_get_name(semantic));

fprintf(fp, "%s &", name);

}else{

fprintf(fp, "{32{1'b0}}&");

}

fprintf(fp, "{32{%s_select}}", tie_semantic_get_name(semantic));

c = "\n|";

} end_tie_program_foreach_semantic;

fprintf(fp, ";\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Write state selection logic for a state

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_state_selection_logic_one(

FILE*fp, tie_t*prog, char*name, int width)

{

tie_t * semantic;

char *c, *value, *sname;

st_table * state_table;

fprintf(fp, "assign %s_ns=", name);

c = "";

tie_program_foreach_semantic(prog, semantic){

if(tie_get_predefined(semantic))continue;

sname = tie_semantic_get_name(semantic);

state_table = tie_semantic_get_out_state_table(semantic);

fprintf(fp, "%s", c);

if(st_lookup(state_table, name, &value)){

fprintf(fp, "%s_%s_ns &", sname, name);

}else{

fprintf(fp, "{%d{1'b0}}&", width);

}

fprintf(fp, "{%d{%s_select}}", width, sname);

c = "\n|";

} end_tie_program_foreach_semantic;

fprintf(fp, ";\n");

fprintf(fp, "assign %s_we = ", name);

c = "";

tie_program_foreach_semantic(prog, semantic){

if(tie_get_predefined(semantic))continue;

sname = tie_semantic_get_name(semantic);

state_table = tie_semantic_get_out_state_table(semantic);

fprintf(fp, "%s", c);

if(st_lookup(state_table, name, &value)){

fprintf(fp, "%s_%s_we &", sname, name);

}else{

fprintf(fp, "1'b0 &");

}

fprintf(fp, "%s_select", sname);

c = "\n|";

} end_tie_program_foreach_semantic;

fprintf(fp, ";\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write selection logic for top-level modules

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_selection_logic(FILE*fp, tie_t*prog)

{

tie_t *semantic, *ilist, *inst, *state;

char *key, *value, *c, *sname;

st_table * global_operand_table;

st_generator * gen;

int width;

tie_program_foreach_semantic(prog, semantic){

if(tie_get_predefined(semantic))continue;

ilist = tie_semantic_get_inst_list(semantic);

fprintf(fp, "assign %s_select=",

tie_semantic_get_name(semantic));

c = "";

tie_inst_list_foreach_instruction(ilist, inst) {

fprintf(fp, "%s%s_E", c, tie_instruction_get_name(inst));

c = "\n|";

} end_tie_inst_list_foreach_instruction;

fprintf(fp, ";\n");

} end_tie_program_foreach_semantic;

global_operand_table = tie2ver_program_get_operand_table(prog);

st_foreach_item(global_operand_table, gen, &key, &value){

if((tie_type_t)value!=TIE_ARG_IN){

tie2ver_write_operand_selection_logic_one(fp, prog, key);

fprintf(fp, "assign out_E = %s_E;\n", key);

}

}

tie_program_foreach_state(prog, state) {

if(tie_get_predefined(state))continue;

sname = tie_state_get_name(state);

width = tie_state_get_width(state);

tie2ver_write_state_selection_logic_one(fp, prog, sname, width);

} end_tie_program_foreach_state;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write a series of assignment statements to extract the "fields" from the directive

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_field_recur(FILE*fp, tie_t*prog, tie_t*field, char

*suffix)

{

tie_t *subfield, *newfield;

char *c, *name;

c = "";

fprintf(fp, "{");

tie_field_foreach_subfield(field, subfield){

fprintf(fp, "%s", c);

switch(tie_get_type(subfield)){

case TIE_ID:

name = tie_get_identifier(subfield);

newfield = tie_program_get_field_by_name(prog, name);

if(newfield==0){

fprintf(fp, "inst R");

}else{

tie2ver_write_field_recur(fp, prog, newfield, suffix);

}

break;

case TIE_SUBFIELD:

name = tie_subfield_get_name(subfield);

newfield = tie_program_get_field_by_name(prog, name);

if(newfield==0){

fprintf(fp, "inst_R");

}else{

DIE("Error: unexpected subfield name(expect'inst')\n");

}

fprintf(fp, "[%d:", tie_subfield_get_from_index(subfield));

fprintf(fp, "%d]", tie_subfield_get_to_index(subfield));

break;

default:

DIE("Error: unexpected subfield type\n");

}

c = ",";

} end_tie_field_foreach_subfield;

fprintf(fp, "}");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write a series of assignment statements to extract the "fields" from the directive

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_field(FILE*fp, tie_t*prog, tie_t*field, char*suffix)

{

fprintf(fp, "assign %s %s=", tie_field_get_name(field), suffix);

tie2ver_write_field_recur(fp, prog, field, suffix);

fprintf(fp, ";\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write a module for "operand"

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_one_immediate(FILE*fp, tie_t*prog, tie_t*operand)

{

tie_t *decoding, *field, *table;

char *oname, *fname;

ls_t *tables;

int width;

ASSERT(tie_get_type(operand)==TIE_OPERAND);

>

fname = tie_operand_get_field_name(operand);

field = tie_program_get_field_by_name(prog, fname);

width = tie_field_get_width(field);

fprintf(fp, "\n");

fprintf(fp, "module %s(inst_R, %s);\n", oname, oname);

fprintf(fp, "input[23:0] inst_R;\n");

fprintf(fp, "output[31:0] %s;\n", oname);

fprintf(fp, "wire[%d:0]%s;\n", tie_field_get_width(field)-1,

fname);

tie2ver_write_field(fp, prog, fieid, "");

decoding = tie_operand_get_decoding_expression(operand);

fprintf(fp, "assign %s=", oname);

tie2ver_write_expression(fp, decoding, 0, 0, 0);

fprintf(fp, ";\n");

tables = tie_expression_get_tables(decoding, prog);

ls_foreach_data(tie_t*, tables, table) {

tie2ver_write_table(fp, table);

} end_ls_foreach_data;

ls_free(tables);

fprintf(fp, "endmodule\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write a module for each immediate operand decoding logic

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_immediate(FILE*fp, tie_t*prog)

{

st_table * operand_table;

char*key,*value;

st_generator * gen;

tie_t *operand;

tie_t*field;

operand_table = tie2ver_program_get_operand_table(prog);

st_foreach_item(operand_table, gen, &key, &value){

if((tie_type_t)value==TIE_ARG_IN){

if(strcmp(key, "art") != 0 && strcmp(key, "ars") != 0){

operand = tie_program_get_operand_by_name(prog, key);

if(operand!=0){

if(!tie_get_predefined(operand)){

tie2ver_write_one_immediate(fp, prog, operand);

}

}else{

field = tie_program_get_fieid_by_name(prog, key);

if(field==0){

fprintf(stderr, "Error: invalidoperand %s\n", key);

}

}

}

}

}

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write a module for the operand "

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_one_operand_instance(FILE*fp, tie_t*prog, tie_t

＊operand)

{

char * oname;

ASSERT(tie_get_type(operand)==TIE_OPERAND);

>

fprintf(fp, "%s i%s(.inst(inst_R), .%s(%s_R));\n", oname, oname,

oname,oname);

tie2ver_write_flop_instance(fp, oname, 32);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Write a statement to extract the "field name" from inst_R

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_one_field_instance(FILE*fp, tie_t*prog, tie_t*field)

{

char*name;

tie2ver_write_field(fp, prog, field, "_R");

name = tie_field_get_name(field);

tie2ver_write_flop_instance(fp, name, 32);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Write an instance for each immediate operand decoding logic

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2ver_write_immediate_instance(FILE*fp, tie_t*prog)

{

char*key,*value;

st_table * operand_table;

st_generator * gen;

tie_t *operand, *field;

operand_table = tie2ver_program_get_operand_table(prog);

st_foreach_item(operand_table, gen, &key, &value){

if((tie_type_t)value==TIE_ARG_IN){

operand = tie_program_get_operand_by_name(prog, key);

if(operand!=0 && tie_operand_is_immediate(operand)){

tie2ver_write_one_operand_instance(fp, prog, operand);

}else if(operand==0){

field = tie_program_get_field_by_name(prog, key);

if (field != 0) {

tie2ver_write_one_field_instance(fp, prog, field);

}

}

}

}

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Print "prog" to a TIE file

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

void

tie2ver_write_verilog(FILE*fp, tie_t*prog)

{

tie_t *semantic;

/*write tie primitives*/

fprintf(fp, COMMENTS);

fprintf(fp, TIE_ENFLOP);

fprintf(fp, TIE_FLOP);

fprintf(fp, TIE_ATHENS_STATE);

/*write each semantic block as a verilog module*/

ASSERT(tie_get_type(prog)==TIE_PROGRAM);

tie_program_foreach_semantic(prog, semantic){

if(tie_get_predefined(semantic))continue;

tie2ver_write_semantic(fp, semantic);

} end_tie_program_foreach_semantic;

/*write each immediate operand as a verilog module*/

tie2ver_write_immediate(fp, prog);

/*write the top_level Verilog module*/

tie2ver_write_top_module(fp, prog);

tie2ver_write_wire_declaration(fp, prog);

tie2ver_write_flop(fp, prog);

tie2ver_write_immediate_instance(fp, prog);

tie2ver_write_semantic_instance(fp, prog);

tie2ver_write_state_instance(fp, prog);

tie2ver_write_selection_logic(fp, prog);

fprintf(fp, "endmodule\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Print "prog" to a TIE file

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

void

tie2ver_write_instruction(FILE*fp, tie_t*prog)

{

tie_t*inst;

int first = 1;

tie2ver_program_foreach_instruction(prog, inst) {

if(first){

fprintf(fp, "%s", tie_instruction_get_name(inst));

first=0;

}else{

fprintf(fp, "%s", tie_instruction_get_name(inst));

}

} end_tie2ver_program_foreach_instruction;

}

/*

＊Local Variables:

*mode:c

*c-basic-offset: 4

*End:

*/

Annex E

#include "tie.h"

#define COMMENTS″/*Do not modify. This is automatically

generated.*/″

#define tie2gcc_program_foreach_instruction(_prog, _inst) { \

tie_t*_iclass; \

tie_program_foreach_iclass(_prog, _iclass) { \

if(tie_get_predefined(_-iclass))continue; \

tie_iclass_foreach_instruction(_iclass, _inst){

#define end_tie2gcc_program_foreach_instruction \

}end_tie_iclass_foreach_instruction;\

}end_tie_program_foreach_iclass;\

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Build and return Global Program→Argument table for each user-defined instruction.

The returned table does not contain the respective variables used in the pre-defined commands.

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static st_table*

tie2gcc_program_get_operand_table(tie_t*prog)

{

static st_table *tie2gcc_program_args = 0;

tie_t * inst;

char*key,*value;

st_table * arg_table;

st_generator * gen;

if(tie2gcc_program_args==0){

tie2gcc_program_args = st_init_table(strcmp, st_strhash);

tie2gcc_program_foreach_instruction(prog, inst) {

arg_table = tie_instruction_get_operand_table(inst);

st_foreach_item(arg_table, gen, &key, &value){

st_insert(tie2gcc_program_args, key, value);

}

st_free_table(arg_table);

} end_tie2gcc_program_foreach_instruction;

}

return tie2gcc_program_args;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Generate Function and Argument Specifications

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2gcc_write_function(FILE*fp, tie_t*inst, tie_t*args)

{

tie_t * arg;

char*c;

c = "";

fprintf(fp, "\n#define %s(", tie_instruction_get_name(inst));

tie_args_foreach_arg(args, arg){

if(tie_get_type(arg) != TIE_ARG_OUT){

fprintf(fp, "%s %s", c, tie_arg_get_name(arg));

c = ",";

}

} end_tie_args_foreach_arg;

fprintf(fp, ")\\\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Return a list of the respective variables in "args", outputting args first. returned columns, table

Should be freed by the caller.

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

ls_t*

tie2gcc_args_get_ordered(tie_t*args)

{

tie_t * arg;

ls_t *arglist;

arglist = ls_alloc();

tie_args_foreach_arg(args, arg){

if(tie_get_type(arg) != TIE_ARG_IN){

ls_append(arglist, arg);

}

} end_tie_args_foreach_arg;

tie_args_foreach_arg(args, arg){

if(tie_get_type(arg) != TIE_ARG_OUT){

ls_append(arglist, arg);

}

} end_tie_args_foreach_arg;

return arglist;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Write an ASM statement

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2gcc_write_one_asm(

FILE*fp, tie_t*prog, tie_t*inst, tie_t*args, int value)

{

tie_t *arg, *operand, *state;

tie_type_t type, ptype;

ls_t *arglist;

char *t, s, c, *name, *n;

int i;

/*write the asm statement*/

fprintf(fp, "asm volatile(\"%s\t",

tie_instruction_get_name(inst));

i=0;

tie_args_foreach_arg(args, arg){

fprintf(fp, "%s%%%d", i==0? "":", ", i);

i++;

} end_tie_args_foreach_arg;

fprintf(fp, "\"");

ptype = TIE_UNKNOWN;

arglist = tie2gcc_args_get_ordered(args);

ls_foreach_data(tie_t*, arglist, arg) {

name = tie_arg_get_name(arg);

operand = tie_program_get_operand_by_name(prog, name);

if(operand!=0){

state = tie_operand_get_state(operand);

if (state != 0) {

n = tie_state_get_name(state);

if(strcmp(n, "AR")==0}{

c = 'a';

}else if(strcmp(n, "FR")==0){

c = 'f';

}else if(strcmp(n, "DR")==0){

c = 'd';

}else if(strcmp(n, "BR")==0){

c = 'b';

}else{

DIE("Internal Error: invalid state\n");

}

}else{

c = 'i';

}

}else{

c = 'i';

}

type = tie_get_type(arg);

if(ptype==TIE_UNKNOWN && type==TIE_ARG_IN){

fprintf(fp, ":");

}

s=type==ptype? ',':':';

t=type==TIE_ARG_IN? "":, "=";

fprintf(fp, "%c\"%s%c\"(%s)", s, t, c, name);

ptype = type;

} end_ls_foreach_data;

ls_free(arglist);

fprintf(fp, "); ");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

generate inline functions for 'inst'

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2gcc_write_asm(FILE*fp, tie_t*prog, tie_t*inst, tie_t*args)

{

tie_t *arg, *out_arg;

/*declear output variable and find the immediate operand*/

fprintf(fp, "({");

out_arg = 0;

tie_args_foreach arg(args, arg) {

if(tie_get_type(arg)==TIE_ARG_OUT){

fprintf(fp, "iht %s;", tie_arg_get_name(arg));

out_arg = arg;

}

} end_tie_args_foreach_arg;

tie2gcc_write_one_asm(fp, prog, inst, args, _1);

/*return the results*/

if(out_arg != 0){

fprintf(fp, "%s;", tie_arg_get_name(out_arg));

}

fprintf(fp, "})\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

generate a macro for "inst"

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2gcc_write_inst(FILE*fp, tie_t*prog, tie_t*inst, tie_t*args)

{

tie2gcc_write_function(fp, inst, args);

tie2gcc_write_asm(fp, prog, inst, args);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Generates gcc header files, which will be incorporated into application code to use user-defined

of the instructions.

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

void

tie2gcc_write_gcc(FILE*fp, tie_t*prog)

{

tie_t *iclass, *ilist, *inst, *args;

ASSERT(tie_get_type(prog)==TIE_PROGRAM);

fprintf(fp, "%s\n", COMMENTS);

tie_program_foreach_iclass(prog, iclass){

if(tie_get_predefined(iclass))continue;

ilist = tie_iclass_get_inst_list(iclass);

args = tie_iclass_get_-io_args(iclass);

tie_inst_list_foreach_instruction(ilist, inst) {

tie2gcc_write_inst(fp, prog, inst, args);

} end_tie_inst_list_foreach_instruction;

} end_tie_program_foreach_iclass;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Write functions to test for the correct value of each immediate value

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie2gcc_write_operand_check_one(FILE*fp, char*name)

{

fprintf(fp, "\nint\n");

fprintf(fp, "tensilica_%s(int v)\n", name);

fprintf(fp, "{\n");

fprintf(fp, "tensilica_insnbuf_type insn;\n");

fprintf(fp, "int new_v;\n");

fprintf(fp, "if(!set_%s_field(insn, v)) return O;\n", name);

fprintf(fp, "new_v=get_%s_field(insn);\n", name);

fprintf(fp, "return new_v==v;\n");

fprintf(fp, "}\n");

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊

Write functions to test for the correct value of each immediate value

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

void

tie2gcc_write_operand_check(FILE*fp, tie_t*prog)

{

st_table * arg_table;

st_generator * gen;

char*key,*value;

arg_table = tie2gcc_program_get_operand_table(prog);

st_foreach_item(arg_table, gen, &key, &value){

if((tie_type_t)value==TIE_ARG_IN){

if(strcmp(key, "art") != 0 && strcmp(key, "ars") != 0){

tie2gcc_write_operand_check_one(fp, key);

}

}

}

}

Annex F

/*

*TIE user_register routines

*/

/*$Id*/

/*

＊Copyright 1998-1999 Tensilica Inc.

＊These coded instructions, statements, and computer programs are

＊Confidential Proprietary Information of Tensilica Inc. and may not

be

＊disclosed to third parties or copied in any form, in whole or in

part,

*Without the prior written consent of Tensilica Inc.

*/

#include <math.h>

#include "tie.h"

#include "tie_int.h"

typede fstruct ureg_struct{

int statef;

int state;

int uregf;

int uregt;

int ureg;

char*name;

}ureg_t;

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Returns the index of "ureg"

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

int

tie_ureg_get_index(tie_t*ureg)

{

ASSERT(tie_get_type(ureg)==TIE_UREG);

return tie_get_integer(tie_get_first_child(ureg));

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

An expression that returns "ureg"

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

tie_t*

tie_ureg_get_expression(tie_ureg*ureg)

{

tie_t * index;

ASSERT(tie_get_type(ureg)==TIE_UREG);

index = tie_get_first_child(ureg);

return tie_get_next_sibling(index);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

yields a string representing the constant index of "ureg"

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static char ureg_index[10];

char*tie_ureg_get_index_constant(tie_t*ureg)

{

sprintf(ureg_index, "8'd %d", tie_ureg_get_index(ureg));

return ureg_index;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊

Generate st field for RUR instruction

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_program_generate_st_field(tie_t*program)

{

tie_t*field;

field = tie_alloc(TIE_FIELD);

tie_append_child(field, tie_create_identifier("st"));

tie_append_child(field, tie_create_identifier(″s″));

tie_append_child(field, tie_create_identifier(″t″));

tie_program_add(program, field);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Generate RUR opcode

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_program_generate_rur_opcode(tie_t*program)

{

tie_t *opcode, *encode;

opcode = tie_alloc(TIE_OPCODE);

tie_append_child(opcode, tie_create_identifier("RUR"));

encode = tie_alloc(TIE_ENCODING);

tie_append_child(opcode, encode);

tie_append_child(encode, tie_create_identifier("op2"));

tie_append_child(encode, tie_create_constant("4'b1110"));

encode = tie_alloc(TIE_ENCODING);

tie_append_child(opcode, encode);

tie_append_child(encode, tie_create_identifier("RST3"));

tie_program_add(program, opcode);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Generate WUR opcode

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_program_generate_wur_opcode(tie_t*program)

{

tie_t *opcode, *encode;

opcode = tie_alloc(TIE_OPCODE);

tie_append_child(opcode, tie_create_identifier("WUR"));

encode = tie_alloc(TIE_ENCODING);

tie_append_child(opcode, encode);

tie_append_child(encode, tie_create_identifier("op2"));

tie_append_child(encode, tie_create_constant("4'b1111"));

encode = tie_alloc(TIE_ENCODING);

tie_append_child(opcode, encode);

tie_append_child(encode, tie_create_identifier("RST3"));

tie_program_add(program, opcode);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Generate RUR iclass

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_program_generate_rur_iclass(tie_t*program)

{

tie_t *iclass, *ilist, *args, *arg, *state;

char*name;

iclass = tie_alloc(TIE_ICLASS);

tie_append_child(iclass, tie_create_identifier("rur"));

ilist = tie_alloc(TIE_INST_LIST);

tie_append_child(iclass, ilist);

tie_append_child(ilist, tie_create_identifier("RUR"));

args = tie_alloc(TIE_ARG_LIST);

tie_append_child(iclass, args);

arg = tie_alloc(TIE_ARG_OUT);

tie_append_child(args, arg);

tie_append_child(arg, tie_create_identifier("arr"));

arg = tie_alloc(TIE_ARG_IN);

tie_append_child(args, arg);

tie_append_child(arg, tie_create_identifier("st"));

args = tie_alloc(TIE_ARG_LIST);

tie_append_child(iclass, args);

tie_program_foreach_state(program, state){

if(tie_get_predefined(state))continue;

arg = tie_alloc(TIE_ARG_IN);

tie_append_child(args, arg);

name = tie_state_get_name(state);

tie_append_child(arg, tie_create_identifier(name));

} end_tie_program_foreach_state;

tie_program_add(program, iclass);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Generate WUR opcode

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_program_generate_wur_iciass(tie_t*program)

{

tie_t *iclass, *ilist, *args, *arg, *state;

char*name;

iclass = tie_alloc(TIE_ICLASS);

tie_append_child(iclass, tie_create_identifier("wur"));

ilist = tie_alloc(TIE_INST_LIST);

tie_append_child(iclass, ilist);

tie_append_child(ilist, tie_create_identifier("WUR"));

args = tie_alloc(TIE_ARG_LIST);

tie_append_child(iclass, args);

arg = tie_alloc(TIE_ARG_IN);

tie_append_child(args, arg);

tie_append_child(arg, tie_create_identifier("art"));

arg = tie_alloc(TIE_ARG_IN);

tie_append_child(args, arg);

tie_append_child(arg, tie_create_identifier("sr"));

args = tie_alloc(TIE_ARG_LIST);

tie_append_child(iclass, args);

tie_program_foreach_state(program, state){

if(tie_get_predefined(state))continue;

arg = tie_alloc(TIE_ARG_INOUT);

tie_append_child(args, arg);

name = tie_state_get_name(state);

tie_append_child(arg, tie_create_identifier(name));

} end_tie_program_foreach_state;

tie_program_add(program, iclass);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Generate a set of select signals for each ureg

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_program_generate_selection_signals(tie_t*prog, tie_t*stmt, char

*fname)

{

tie_t *ureg, *wire, *assign, *equal, *id;

int index, max_index, width;

char wname[80];

max_index = 0;

tie_program_foreach_ureg(prog, ureg){

index = tie_ureg_get_index(ureg);

max_index = MAX(max_index, index);

} end_tie_program_foreach_ureg;

width=(int)ceil(log(max_index+1)/log(2));

tie_program_foreach_ureg(prog, ureg){

index = tie_ureg_get_index(ureg);

wire = tie_alloc(TIE_WIRE);

sprintf(wname, "ureg_sel_%d", index);

tie_append_child(wire, tie_create_integer(0));

tie_append_child(wire, tie_create_integer(0));

tie_append_child(wire, tie_create_identifier(wname));

tie_append_child(stmt, wire);

assign = tie_alloc(TIE_ASSIGNMENT);

tie_append_child(assign, tie_create_identifier(wname));

tie_append_child(stmt, assign);

equal = tie_alloc(TIE_EQ);

sprintf(wname, "%d'd %d", width, index);

id = tie_create_identifier(fname);

tie_append_child(id, tie_create_integer(width_1));

tie_-append_child(id, tie_create_integer(0));

tie_append_child(equal, id);

tie_append_child(equal, tie_create_constant(wname));

tie_append_child(assign, equal);

} end_tie_program_foreach_ureg;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Returns the RUR selection logic for "ureg" and all uregs preceding it

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static tie_t*

tie_program_rur_semantic_recur(ls_handle_t*ureg_handle)

{

tie_t *and, *node, *or, *rep;

node = tie_program_rur_semantic_recur(handle);

tie_append_child(assign, node);

ls_free(ureg_list);

tie_program_add(program, semantic);

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

Send all members of "ureg" to "list"

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_ureg_exp_get_components(tie_t*exp, ls_t*list)

{

tie_t*child;

if(tie_get_type(exp)==TIE_ID){

ls_prepend(list, exp);

}

tie_foreach_child(exp, child) {

tie_ureg_exp_get_components(child, list);

} end_tie_foreach_child;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Take a status list and send it to ur mapping

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_state_list_insert(ls_t*list, ureg_t*ur)

{

ureg_t *item;

ls_handle_t *handle;

handle = 0;

ls_foreach_handle(list, handle) {

item = (ureg_t*) ls_handle_get_data(handle);

if(item->statef<ur->statet){

break;

}

} end_ls_forea_handle;

if(handle==0){

ls_append(list, ur);

}else{

ls_insert_before(handle, ur);

}

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Take a status list and send it to ur mapping

tie_t*ureg=(tie_t*)ls_handle_get_data(ureg_handle);

ls_handle_t * ureg_next;

char sname[80];

and = tie_alloc(TIE_BITWISE_AND);

rep = tie_alloc(TIE_REPLICATION);

tie_append_child(and, rep);

tie_append_child(rep, tie_create_integer(32));

sprintf(sname, "ureg_sel_%d", tie_ureg_get_index(ureg));

tie_append_child(rep, tie_create_identifier(sname));

tie_append_child(and, tie_dup(tie_ureg_get_expression(ureg)));

ureg_next = ls_handle_get_next_handle(ureg_handle);

if(ureg_next==0){

return and;

}else{

node = tie_program_rur_semantic_recur(ureg_next);

or = tie_alloc(TIE_BITWISE_OR);

tie_append_child(or, and);

tie_append_child(or, node);

return or;

}

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Generate RUR semantic block

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_program_generate_rur_semantic(tie_t*program)

{

tie_t *ureg, *semantic, *ilist, *statement, *assign, *node;

ls_t * ureg_list;

ls_handle_t *handle;

semantic = tie_alloc(TIE_SEMANTIC);

tie_append_child(semantic, tie_create_identifier("rur"));

ilist = tie_alloc(TIE_INST_LIST);

tie_append_child(ilist, tie_create_identifier("RUR"));

tie_append_child(semantic, ilist);

statement = tie_alloc(TIE_STATEMENT);

tie_append_child(semantic, statement);

tie_program_generate_selection_signals(program, statement, "st");

assign = tie alloc(TIE_ASSIGNMENT);

tie_append_child(statement, assign);

tie_append_child(assign, tie_create_identifier("arr"));

ureg_list = ls_alloc();

tie_program_foreach_ureg(program, ureg){

ls_append(ureg_list, ureg);

} end_tie_program_foreach_ureg;

handle = ls_get_first_handle(ureg_list);

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_state_get_ur_mapping(tie_t*prog, tie_t*state, tie_t*ureg, ls_t

*list)

{

tie_t *exp, *child, *s, *id;

int num, uregf, uregt, statef, statet;

ls_t * id_list;

char *sname, *iname;

ureg_t*ur;

exp = tie_ureg_get_expression(ureg);

num = tie_ureg_get_index(ureg);

sname = tie_state_get_name(state);

id_list = ls_alloc();

tie_ureg_exp_get_components(exp, id_list);

uregt = uregf = -1;

ls_foreach_data(tie_t*, id_list, id) {

iname = tie_get_identifier(id);

child = tie_get_first_child(id);

/*compute the next uregf and uregt*/

if(child==0){

s = tie_program_get_state_by_name(prog, iname);

ASSERT(s != 0);

state=0;

statef = tie_state_get_width(s) - 1;

}else{

statef = tie_get_integer(child);

child = tie_get_next_sibling(child);

if(child==0){

statet = statef;

}else{

statet = tie_get_integer(child);

}

}

uregt=uregf+1;

uregf = uregt + (statef - statet);

if(strcmp(iname, sname)==0){

ur = ALLOC(ureg - t, 1);

ur->statef=statef;

ur->statet=statet;

ur->uregf = uregf;

ur->uregt=uregt;

ur->ureg=num;

ur->name="art";

tie_state_list_insert(list, ur);

}

} end_ls_foreach data;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Fill gaps in the state-to-ur mapping table

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_state_fill_gap(tie_t*state, ls_t*list)

{

int width, statet, statef;

ls_handle_t *handle;

ureg_t *ur, *gap;

char*name;

width = tie_state_get_width(state);

name = tie_state_get_name(state);

statet = statef = width;

ls_foreach_handle(list, handle) {

ur=(ureg_t*)ls_handle_get_data(handle);

if(ur->statef<(state-1)){

gap = ALLOC(ureg_t, 1);

gap->statef = statet-1;

gap->statet=ur->statef+1;

gap->uregf=gap->uregt=gap->ureg=-1;

gap->name=0;

ls_insert_before(handle, gap);

}

statet=ur->statet;

statef=ur->statef;

} end_ls_foreach_handle;

handle = ls_get_last_handle(list);

ur=(ureg_t*)ls_handle_get_data(handle);

if(ur->statet>0){

gap = ALLOC(ureg_t, 1);

gap->statef=ur->statet-1;

gap->state=0;

gap->uregf=gap->uregt=gap->ureg=-1;

gap->name=0;

ls_insert_after(handle, gap);

}

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Generate WUR semantic block

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

static void

tie_program_generate_wur_semantic(tie_t*program)

{

tie_t *ureg, *semantic, *ilist, *statement, *assign, *cond;

tie_t *state, *concat, *id;

ureg_t*ur;

char *sname, selname[80];

ls_t*list;

semantic = tie_alloc(TIE_SEMANTIC);

tie_append_child(program, semantic);

tie_append_child(semantic, tie_create_identifier("wur"));

ilist = tie_alloc(TIE_INST_LIST);

tie_append_child(ilist, tie_create_identifier("WUR"));

tie_append_child(semantic, ilist);

statement = tie_alloc(TIE_STATEMENT);

tie_append_child(semantic, statement);

tie_program_generate_selection_signals(program, statement, "sr");

tie_program_foreach_state(program, state){

if(tie_get_predefined(state))continue;

sname = tie_state_get_name(state);

list = ls_alloc();

tie_program_foreach_ureg(program, ureg){

tie_state_get_ur_mapping(program, state, ureg, list);

} end_tie_program_foreach_ureg;

tie_state_fill_gap(state, list);

assign = tie_alloc(TIE_ASSIGNMENT);

tie_append_child(statement, assign);

tie_append_child(assign, tie_create_identifier(sname));

concat = tie_alloc(TIE_CONCATENATION);

tie_append_child(assign, concat);

ls_foreach_data(ureg_t*, list, ur) {

if(ur_>name!=0){

cond = tie_alloc(TIE_CONDITIONAL);

tie_append_child(concat, cond);

sprintf(selname, "ureg_sel_%d", ur_>ureg);

id = tie_create_identifier(selname);

tie_append_child(cond, id);

id = tie_create_identifier(ur_>name);

tie_append_child(id, tie_create_integer(ur->uregf));

tie_append_child(id, tie_create_integer(ur->uregt));

tie_appemd_child(cond, id);

id = tie_create_identifier(sname);

tie_append_child(id, tie_create_integer(ur->statef));

tie_append_child(id, tie_create_integer(ur->statet));

tie_append_child(cond, id);

}else{

id = tie_create_identifier(sname);

tie_append_child(id, tie_create_integer(ur->statef));

tie_append_child(id, tie_create_integer(ur->statet));

tie_append_child(concat, id);

}

} end_ls_foreach_data;

ls_free(list);

} end_tie_program_foreach_state;

}

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊＊

Generate WUR semantic block

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊＊＊＊＊/

void

tie_program_generate_rurwur(tie_t*program)

{

tie_t*ureg;

int_num=0;

tie_program_foreach_ureg(program, ureg){

num++;

} end_tie_program_foreach_ureg;

if(num==0){

return;

}

tie_program_generate_st_field(program);

tie_program_generate_rur_opcode(program);

tie_program_generate_wur_opcode(program);

tie_program_generate_rur_iclass(program);

tie_program_generate_wur_iclass(program);

tie_program_generate_rur_semantic(program);

tie_program_generate_wur_semantic(program);

}

Annex G

150

//define a new opcode for BYTESWAP based on

// -a predefined instruction field op2

// -a predefined opcode CUSTO

//refer to Xtensa ISA manual for descriptions of op2 and CUSTO

opcode BYTESWAP op2=4'b0000 CUSTO

//declare a state ACC used to accumulate byte-swapped data

state ACC 32

//declare a mode bit SWAP to control the swap

state SWAP 1

//use″RUR ar，0″and″WUR ar，0″to move data between AR and ACC

user_register 0 ACC

//use″RUR ar，1″and″WUR ar，1″to move data between AR and SWAP

user_register 1 SWAP

//define a new instruction class that

// -reads data from ars(predefined to be AR[s])

// -uses and writes state ACC

// -uses state SWAP

iclass bs{BYTESWAP}{in ars}{inout ACC, in SWAP}

//semantic definition of byteswap

// Accumulates to ACC the byte-swapped ars(AR[s]) or

//ars depending on the SWAP bit

semantic bs{BYTESWAP}{

wire[31:0] ars_swap={ars[7:0], ars[15:8], ars[23:16], ars[31:24]};

assign ACC=ACC+(SWAP?ars_swap:ars);

}

Annex H

#define PARAMS(_arg)_arg

typedef signed int int32_t;

typedef unsigned int u_int32_t;

typedef void *xtensa_isa;

typedef void * xtensa_operand;

typedef int xtensa_opcode;

#define XTENSA_UNDEFINED-1

typedef u_int32_t xtensa_insnbuf_word;

typedef xtensa insnbuf_word *xtensa insnbuf;

typedef enum{

xtensa_encode_result_ok,

xtensa_encode_result_align,

xtensa_encode_result_not_in_table,

xtensa_encode_result_too_low,

xtensa_encode_result_too_high,

xtensa_encode_result_not_ok

} xtensa_encode_result;

typedef u_int32_t(*xtensa_immed_decode_fn) params((u_int32_t val));

typedef xtensa_encode_result(*xtensa_immed_encode_fn)

params((u_int32_t*valp));

typedef u_int32_t(*xtensa_get_field_fn) PARAMS((const xtensa_insnbuf

insn));

typedef void(*xtensa_set_field_fn) PARAMS((xtensa_insnbuf insn,

u_int32_t val));

typedef int(*xtensa_insn_decode_fn) PARAMS((const xtensa_insnbuf

insn));

typedef struct xtensa_operand_internal_struct{

char operand_kind;

char inout;

xtensa_get_field_fn get_field;

xtensa_set_field_fn set_field;

xtensa_immed_encode_fn encode;

xtensa_immed_decode_fn decode;

} xtensa_operand_internal;

typede fstruct xtensa_iclass_internal_struct{

int num_operands;

xtensa_operand_internal**operands;

} xtensa_iclass_internal;

typedef struct xtensa_opcode_internal_struct{

const char *name;

int length;

xtensa_insnbuf encoding_template;

xtensa_iclass_internal*iclass;

} xtensa_opcode_internal;

typedef struct topname_lookup_entry_struct{

const char*key;

xtensa_opcode opcode;

}opname_lookup_entry;

typedef struct xtensa_isa_internal_struct{

int insn_size;

int insnbuf_size;

int num_opcodes;

xtensa_opcode_internal**opcode_table;

int num_modules;

int *module_opcode base;

xtensa_insn_decode_fn *module_decode_fn;

opname_lookup_entry *opname_lookup_table;

} xtensa_isa_internal;

externu_int32_tget_r_field(const xtensa_insnbuf insn);

extern void set_r_field(xtensa_insnbuf insn, u_int32_t val);

extern u_int32_t get_s_field(const xtensa_insnbuf insn);

extern void set_s_field(xtensa_insnbuf insn, u_int32_t val);

extern u_int32_t get_sr_field(const xtensa_insnbuf insn);

extern void set_sr_field(xtensa_insnbuf insn, u_int32_t val);

extern u_int32_t get_t_field(const xtensa_insnbuf insn);

extern void set_t_field(xtensa_insnbuf insn, u_int32_t val);

extern xtensa_encode_result encode_r(u_int32_t*valp);

extern u_int32_t decode_r(u_int32_t val);

extern xtensa_encode_result encode_s(u_int32_t*valp);

extern u_int32_t decode_s(u_int32_t val);

extern xtensa_encode_result encode_sr(u_int32_t*valp);

extern u_int32_t decode_sr(u_int32_t val);

extern xtensa_encode_result encode_t(u_int32_t*valp);

extern u_int32_t decode_t(u_int32_tval);

static u_int32t get_st_field(insn)

const xtensa_insnbuf insn;

{

u_int32_t temp;

temp=0;

temp|=((insn[0] &0×f00)>>8)<<4;

temp|=((insn[0] &0×f0)>>4)<<0;

return temp;

}

static void set_st_field(insn, val)

xtensa_insnbuf insn; u_int32_tval;

{

insn[0]=(insn[0] & 0×fffff0ff)|((val &0×f0)<<8);

insn[0]=(insn[0] & 0×ffffff0f)|((val &0×f)<<4);

}

static u_int32t decode_st(u_int32_t val)

{

return val;

}

static xtensa_encode_result encode_st(u_int32_t*valp)

{

if((*valp>>8)!=0){

return xtensa_encode_result_too_high;

}else{

return xtensa_encode_result_ok;

}

}

static xtensa_operand_internal aor_operand={

'a',

'>',

get_r_field,

set_r_field,

encode_r,

decode_r

};

static xtensa_operand_internal ais_operand = {

'a',

'<',

get_s_field,

set_s_field,

encode_s,

decode_s

};

static xtensa_operand_internal ait_operand = {

'a',

'<',

get_t_field,

set_t_field,

encode_t,

decode_t

};

static xtensa_operand_internal iisr_operand = {

'i',

'<',

get_sr_field,

set_sr_field,

encode_sr,

decode_sr

};

static xtensa_operand_internal iist_operand = {

'i',

'<',

get_st_field,

set_st_field,

encode_st,

decode_st

};

static xtensa_operand_internal*bs_operand_list[]={

&ais_operand

};

static xtensa_iclass_internal bs_iclass={

1,

&bs_operand_list[0]

};

static xtensa_operand_internal*rur_operand_list[]=(

&aor_operand,

&iist_operand

};

static xtensa_iclass_internal rur_iclass = {

2,

&rur_operand_list[0]

};

static xtensa_operand_internal*wur_operand_list[]={

&ait_operand,

&iisr_operand

};

static xtensa_iclass_internal wur_iclass={

2,

&wur_operand_list[0]

};

static xtensa_insnbuf_word BYTESWAP_template[] = {0x60000};

static xtensa_opcode_internal BYTESWAP_opcode = {

"byteswap",

3,

&BYTESWAP_template[0],

&bs_iclass

};

static xtensa_insnbuf_word RUR_template[] = {0xe30000};

static xtensa_opcode_internal RUR_opcode = {

"rur",

3,

&RUR_template[0],

&rur_iclass

};

static xtensa_insnbuf_word WUR_template[] = {0xf30000};

static xtensa_opcode_internal WUR_opcode = {

"wur",

3,

&WUR_template[0],

&wur_iclass

};

static xtensa_opcode_internal*opcodes[]={

&BYTESWAP_opcode,

&RUR_opcode,

&WUR_opcode

};

xtensa_opcode_internal*** get_opcodes() { return &opcodes[0]; }

const int get_num_opcodes() { return3; }

#define xtensa_BYTESWAP_op 0

#define xtensa_RUR_op1

#define xtensa_WUR_op2

int decode_insn(const xtensa_insnbuf insn)

{

if((insn[0] & 0×ff000f)==0×60000) return xtensa_BYTESWAP_op;

if((insn[0] & 0×ff000f)==0×e30000) return xtensa_RUR_op;

if((insn[0] & 0×ff000f)==0×f30000) return xtensa_WUR_-op;

return XTENSA_UNDEFINED;

}

Annex I

typedef unsigned u32;

typedef struct u64str { unsigned int lo; unsigned int hi; } u64;

extern u32 state32(inti);

extern u64 state64(inti);

extern void set_state32(int i, u32v);

extern void set_state64(int i, u64v);

extern void set_ar(int i, u32v);

extern u32 ar(int i);

extern void pc_incr(int i);

extern int au×32_fetchfirst(void);

extern void pipe_use_ifetch(intn);

extern void pipe_use_dcache(void);

extern void pipe_def_ifetch(int n);

extern int arcode(void);

extern void pipe_use(int n, int v, int i);

extern void pipe_def(int n, int v, int i);

struct state_tbl_entry{

const char *name;

int numbits;

};

#define STATE_ACC 0

#define STATE_SWAP 1

#define NUM_STATES 2

struct state_tbl_entrylocal_state_tbl[NUM_STATES+1]={

{"ACC",32},

{"SWAP", 1},

{″″,0}

};

extern "C" struct state_tbl_entry * get_state_tbl(void);

structstate_tbl_entry*get_state_tbl(void)

{

return &local_state_tbl[0];

}

/*constant table ai4const */

static const unsigned CONST_TBL_AI4CONST[]={

0×ffffffff,

0×1,

0×2,

0×3,

0×4,

0×5,

0×6,

0×7,

0×8,

0×9,

0×a,

0×b,

0×c,

0×d,

0×e,

0×f

};

/*constant table b4const*/

static const unsigned CONST_TBL_B4CONST[]={

0×ffffffff,

0×l,

0×2,

0×3,

0×4,

0×5,

0×6,

0×7,

0×8,

0×a,

0×c,

0×10,

0×20,

0×40,

0×80,

0×100

};

/*constant table b4constu*/

static const unsigned CONST_TBL_B4CONSTU[]={

0×8000,

0×10000,

0×2,

0×3,

0×4,

0×5,

0×6,

0×7,

0×8,

0×a,

0×c,

0×10,

0×20,

0×40,

0×80,

0×100

};

/*constant table d01tab*/

static const unsigned CONST_TBL_D01TAB[]={

0,

0×1

};

/*constant table d23tab*/

static const unsigned CONST_TBL_D23TAB[]={

0×2,

0×3

};

/*constant table i4plconst*/

static const unsigned CONST_TBL_I4P1CONST[]={

0×1,

0×2,

0×3,

0×4,

0×5,

0×6,

0×7,

0×8,

0×9,

0×a,

0×b,

0×c,

0×d,

0×e,

0×f,

0×10

};

/*constant table mip32const*/

static const unsigned CONST_TBL_MI P32CONST[]={

0×20,

0×1f,

0×1e,

0×1d,

0×1c,

0×1b,

0×1a,

0×19,

0×18,

0×17,

0×16,

0×15,

0×14,

0×13,

0×12,

0×11,

0×10,

0×f,

0×e,

0×d,

0×c,

0×b,

0×a,

0×9,

0×8,

0×7,

0×6,

0×5,

0×4,

0×3,

0×2,

0×1

};

void

BYTESWAP_func(u32_OPND0_, u32_OPND1_, u32_OPND_2_, u32_OPND3)

{

unsigned ars = ar(_OPND0_);

u32 ACC = state32(STATE_ACC);

u32S WAP = state32(STATE_SWAP);

unsigned_tmp0;

unsigned SWAP_ps;

unsigned ACC_ps;

unsigned ACC_ns;

unsigned ars_swap;

SWAP_ps = SWAP;

ACC_ps = ACC;

ars_swap＝(((ars & 0×ff))<<24)|((((ars>>8) & 0×ff))<<

16)|((((ars>>16) & 0×ff))<<8)|(((ars>>24) &0×ff));

if(SWAP_ps){

_tmp0 = ars_swap;

)else{

_tmp0 = ars;

}

ACC_ns=ACC_ps+_tmp0;

ACC = ACC_ns;

set_state32(STATE_ACC, ACC);

pc_incr(3);

}

void

RUR_func(u32_OPND0_, u32_OPND1_, u32_OPND2_, u32_OPND3_)

{

unsigned arr;

unsigned st = _OPND1_;

u32 ACC = state32(STATE_ACC);

u32 SWAP = state32(STATE_SWAP);

unsigned_tmp1;

unsigned_tmp0;

unsigned SWAP_ps;

unsigned ACC_ps;

SWAP_ps = SWAP;

ACC_ps = ACC;

if(st==1){

_tmp0 = SWAP_ps;

}else{

_tmp0=0;

}

if(st==0){

_tmp1 = ACC_ps;

}else{

_tmp1 = _tmp0;

}

arr = _tmp1;

set_ar(_OPND0_, arr);

pc_incr(3);

}

void

WUR_func(u32_OPND0_, u32_OPND1_, u32_OPND2_, u32_OPND3_)

{

unsigned art = ar(_OPND0_);

unsigned sr = _OPND1_;

u32 ACC = state32(STATE_ACC);

u32 SWAP = state32(STATE_SWAP);

unsigned_tmp1;

unsigned_tmp0;

unsigned SWAP_ps;

unsigned ACC_ps;

unsigned SWAP_ns;

unsigned ACC_ns;

unsigned ureg_sel_0;

unsigned ureg_sel_1;

SWAP_ps = SWAP;

ACC_ps = ACC;

ureg_sel_0 = sr = = 0;

ureg_sel_1 = sr = = 1;

if(ureg_sel_0){

_tmp0 = art;

}else{

_tmp0 = ACC_ps;

}

ACC_ns = _tmp0;

if(ureg_sel_1){

_tmp1=(art &0×1);

}else{

_tmp1=(SWAP_ps &0×1);

}

SWAP_ns = _tmp1;

ACC = ACC_ns;

SWAP = SWAP_ns;

set_state32(STATE_ACC, ACC);

set_state32(STATE_SWAP, SWAP);

pc_incr(3);

}

void BYTESWAP_sched(u32 op0, u32 op1, u32 op2, u32 op3)

{

int ff;

int cond;

ff=au×32_fetchfirst();

if(ff){

pipe_use_ifetch(3);

}

pipe_use(arcode(), op0, 1);

if (!ff) {

pipe_use_ifetch(3);

}

pipe_use_dcache();

pipe_def_ifetch(-1);

}

void RUR_sched(u32 op0, u32 op1, u32 op2, u32 op3)

{

int ff;

int cond;

ff=au×32 fetchfirst();

if(ff){

pipe_use_ifetch(3);

}

if (!ff) {

pipe_use_ifetch(3);

}

pipe_use_dcache();

pipe_def(arcode(), op0, 2);

pipe_def_ifetch(-1);

}

void WUR_sched(u32 op0, u32 op1, u32 op2, u32 op3)

{

int ff;

int cond;

ff=au×32_fetchfirst();

if (ff){

pipe_use_i fetch(3);

}

pipe_use(arcode(), op0, 1);

if (!ff) {

pipe_use_ifetch(3);

}

pipe_use_dcache();

pipe_def_ifetch(-1);

}

typedef void(SEMFUNC)(u32_OPND0_, u32_OPND1_, u32_OPND2_, u32

_OPND3_);

struct isafunc_tbl_entry{

const char *opname;

semfunc * semfn;

SEMFUNC * schedfn;

};

static struct isafunc_tbl_entrylocal_fptr_tbl[]={

{"byteswap", BYTESWAP_func, BYTESWAP_sched},

{"rur", RUR_func, RUR_sched},

{"wur", WUR_func, WUR_sched},

{″″,0,0}

};

extern "C" struct isafunc_tbl_entry*get_isafunc_tbl(void);

struct isafunc_tbl_entry *get_isafunc_tbl(void)

{

return &local_fptr_tbl[0];

}

Annex J

/* Do not modify. This is generated automatically. */

#define BYTESWA

P(ars)\

({asm volatile("BYTESWAP %0"::"a"(ars)); })

#define RUR(st)\

({ int arr; asm volatile("RUR %0,%1":"=a"(arr):"i"(st));

arr; })

#define WUR(art,sr)\

({asm volatile("WUR %0,%1"::"a"(art), "i"(sr))

Annex K

#ifdef TIE_DEBUG

#define BYTESWAP TIE_BYTESWAP

#define RUR TIE_RUR

#define WUR TIE_WUR

#endif

typedef unsigned u32;

#define STATE32_ACC 0

#define STATE_ACC STATE32_ACC

#define STATE32_SWAP 1

#define STATE_SWAP STATE32_SWAP

#define NUM_STATE32 2

static u32 state32table[NUM_STATE32];

static char*state32_name_table[NUM_STATE32]={

"ACC",

"SWAP"

};

static u32 state32(int rn) { return state32_table[rn]; }

static void set_state32(int rn, u32s) { state32_table[rn] = s; }

static int num_state32(void) { return NUM_STATE32; }

static char * state32_name(int rn) { return state32_name_table[rn]; }

void

BYTESWAP(unsigned ars)

{

u32 ACC = state32(STATE_ACC);

u32 SWAP = state32(STATE_SWAP);

unsigned_tmp0;

unsigned SWAP_ps;

unsigned ACC_ps;

unsigned ACC_ns;

unsigned ars_swap;

SWAP_ps = SWAP;

ACC_ps = ACC;

ars_swap＝(((ars & 0×ff))<<24)|((((ars>>8)& 0×ff))<<

16)|((((ars>>16)& 0×ff))<<8)|(((ars>>24)&0×ff));

if(SWAP_ps){

_tmp0 = ars_swap;

}else{

_tmp0 = ars;

}

ACC_ns=ACC_ps+_tmp0;

ACC = ACC_ns;

set_state32(STATE_ACC, ACC);

}

unsigned

RUR (unsigned st)

{

unsigned arr;

u32 ACC = state32(STATE_ACC);

u32 SWAP = state32(STATE_SWAP);

unsigned_tmp1;

unsigned_tmp0;

unsigned SWAP_ps;

unsigned ACC_ps;

SWAP_ps = SWAP;

ACC_ps = ACC;

if(st==1){

tmp0 = SWAP_ps;

}else{

tmp0=0;

}

if(st==0){

_tmp1 = ACC_ps;

}else{

_tmp1 = tmp0;

}

arr = _tmp1;

return arr;

}

void

WUR (unsigned art, unsigned sr)

{

u32 ACC = state32(STATE_ACC);

u32 SWAP = state32(STATE_SWAP);

unsigned_tmp1;

unsigned_tmp0;

unsigned SWAP_ps;

unsigned ACC_ps;

unsigned SWAP_ns;

unsigned ACC_ns;

unsigned ureg_sel_0;

unsigned ureg_sel_1;

SWAP_ps = SWAP;

ACC_ps = ACC;

ureg_sel_0 = sr = = 0;

ureg_sel_1 = sr = = 1;

if(ureg_sel_0){

tmp0 = art;

}else{

_tmp0 = ACC_ps;

}

ACC_ns = _tmp0;

if(ureg_sel_1){

tmp1 = (art&0×1);

}else{

_tmp1=(SWAP_ps &0×1);

}

SWAP_ns = _tmp1;

ACC = ACC_ns;

SWAP = SWAP_ns;

set_state32(STATE_ACC, ACC);

set_state32(STATE_SWAP, SWAP);

}

#ifdef TIE_DEBUG

#unde fBYTESWAP

#undef RUR

#undef WUR

#endif

Annex L

//Do not modify this automatically generated file.

module tie_enflop(tie_out, tie_in, en, clk);

parameter size=32;

output[size-1:0] tie_out;

input[size-1:0] tie_in;

input en;

input clk;

reg[size-1:0]tmp;

assign tie_out = tmp;

always @(p@osedge clk) begin

if (en)

tmp <= #1 tie_in;

end

endmodule

module tie_flop(tie_out, tie_in, clk);

parameter size=32;

output[size-1:0] tie_out;

input[size-1:0] tie_in;

input clk;

reg[size-1:0]tmp;

assign tie_out = tmp;

always @(posedge clk) begin

tmp <= #1 tie_in;

end

endmodule

module tie_athens_state(ns, we, ke, kp, vw, clk, ps);

parameter size=32;

input[size-1:0]ns; //next state

input we; //write enable

input ke; //Kill E state

input kp; //Kill Pipeline

input vw; //Valid W state

input clk; //clock

output[size-1:0] ps; //presentstate

wire [size-1∶0] se; //state at E stage

wire[size-1∶0]sm; //state at M stage

wire[size-1∶0]sw; //state at W stage

wire[size-1∶0]sx; //state at X stage

wire ee; // write enable for EM register

wire ew; // write enable for WX register

assign se=kp ? sx: ns;

assign ee = kp l we & ~ ke;

assign ew = vw & ~ kp;

assign ps = sm;

tie_enflop #(size) state_EM(.tie_out(sm), .tie_in(se), .en(ee),

.clk(clk));

tie_flop #(size) state_MW(.tie_out(sw), .tie_in(sm), .clk(clk));

tie_enflop #(size) state_WX(.tie_out(sx), .tie_in(sw), .en(ew),

.clk(clk));

endmodule

module bs(ars, ACC_ps, SWAP_ps, ACC_ns, ACC_we, BYTESWAP);

input[31:0] ars;

input[31:0] acc_ps;

input[0:0] SWAP_ps;

output[31:0] ACC_ns;

output ACC_we;

input BYTESWAP;

wire[31:0] ars_swap;

assign ars_swap = {ars[7:0], ars[15:8], ars[23:16], ars[31:24]};

assign ACC_ns=(ACC_ps)+((SWAP_ps)?(ars_swap):(ars));

assign ACC_we=1′b1 &BYTESWAP;

endmodule

module rur(arr, st, ACC_ps, SWAP_ps, RUR);

output[31:0] arr;

input[31:0]st;

input[31:0] acc_ps;

input[0:0] SWAP_ps;

input RUR;

assign arr=((st)==(8'd0))? (ACC_ps): (((st)==(8'd1))?

(SWAP_ps):(32'b0));

endmodule

module wur(art, sr, ACC_ps, SWAP_ps, ACC_ns, ACC_we, SWAP_ns, SWAP_we, WUR);

input [31:0] art;

input[31:0] sr;

input[31:0] acc_ps;

input[0:0] SWAP_ps;

output[31:0] ACC_ns;

output ACC_we;

output[0:0] SWAP_ns;

output SWAP_we;

input WUR;

wire ureg_sel_0;

assign ureg_sel_O=(sr)==(8'h0);

wire ureg_sel_1;

assign ureg_sel_1=(sr)==(8'h1);

assign ACC_ns = {(ureg_sel_0)? (art[31:0]):(ACC_ps[31:0])};

assign SWAP_ns = {(ureg_sel_1)? (art[0:0]):(SWAP_ps[0:0])};

assign ACC_we=1′b1 &WUR;

assign SWAP_we=1′b1 &WUR;

endmodule

module UserInstModule(clk, out_E, ars_E, art_E, inst_R, Kill_E,

killPipe_W, valid_W, BYTESWAP_R, RUR_R, WUR_R, en_R);

input clk;

output[31:0] out_E;

input[31:0] ars_E;

input[31:0] art_E;

input[23:0] inst_R;

input en_R;

input Kill_E, killPipe_W, valid_W;

input BYTESWAP_R;

input RUR_R;

input WUR_R;

wire BYTESWAP_E;

wire RUR_E;

wire WUR_E;

wire[31:0] arr_E;

wire [31:0] sr_R, sr_E;

wire [31:0] st_R, st_E;

wire[31:0] ACC_ps, ACC_ns;

wire ACC_we;

wire [0:0] SWAP_ps, SWAP_ns;

wire SWAP_we;

wire[31:0] bs_acc_ns;

wire bs_ACC_we;

wire bs_select;

wire[31:0] rur_arr;

wire rur_select;

wire[31:0] wur_acc_ns;

wire wur_ACC_we;

wire[0:0] wur_SWAP_ns;

wire wur_SWAP_we;

wire wur_select;

tie_enflop#(1) fBYTESWAP(.tie_out(BYTESWAP_E), .tie_in(BYTESWAP_R),

.en(en_R), .clk(clk));

tie_enflop#(1)fRUR(.tie_out(RUR_E), .tie_in(RUR_R), .en(en_R),

.clk(clk));

tie_enflop#(1)fWUR(.tie_out(WUR_E), .tie_in(WUR_R), .en(en_R),

.clk(clk));

assign sr_R = {{inst_R[11:8]}, {inst_R[15:12]}};

tie_enflop #(32) fsr(.tie_out(sr_E), .tie_in(sr_R), .en(en_R),

.clk(clk));

assign st_R = {{inst_R[11:8]}, {inst_R[7:4]}};

tie_enflop#(32) fst(.tie_out(st_E), .tie_in(st_R), .en(en_R),

.clk(clk));

bs ibs(

.ars(ars_E),

.ACC_ps(ACC_ps),

.SWAP_ps(SWAP_ps),

.ACC_ns(bs_ACC_ns),

.ACC_we(bs_ACC_we),

.BYTESWAP(BYTESWAP_E));

rur irur(

.arr(rur_arr),

.st(st_E),

.ACC_ps(ACC_ps),

.SWAP_ps(SWAP_ps),

.RUR(RUR_E));

wur iwur(

.art(art_E),

.sr(sr_E),

.ACC_ps(ACC_ps),

.SWAP_ps(SWAP_ps),

.ACC_ns(wur_ACC_ns),

.ACC_we(wur_ACC_we),

.SWAP_ns(wur_SWAP_ns),

.SWAP_we(wur_SWAP_we),

.WUR(WUR_E));

tie_athens_state#(32)iACC(

.ns(ACC_ns),

.we(ACC_we),

.ke(Kill_E),

.kp(killPipe_W),

.vw(valid_W),

.clk(clk),

.ps(ACC_ps));

tie_athens_state#(1)iSWAP(

.ns(SWAP_ns),

.we(SWAP_we),

.ke(Kill_E),

.kp(killPipe_W),

.vw(valid_W),

.clk(clk),

.ps(SWAP_ps));

assign bs_select = BYTESWAP_E;

assign rur_select = rur_e;

assign wur_select = wur_e;

assign arr_E={32{1′b0}} & {32{bs_select}}

| rur_arr & {32{rur_select}}

| {32{1′b0}} &{32{wur_select}};

assign out_E = arr_E;

assign ACC_ns=bs_ACC_ns&{32{bs_select}}

| {32{1′b0}} & {32{rur_select}}

| wur_ACC_ns &{32{wur_select}};

assign ACC_we = bs_ACC_we & bs_select

|1′b0 & rur_select

|wur_ACC_we &wur_select;

assign SWAP_ns={1{1′b0}} & {1{bs_select}}

| {1{1′b0}} & {1{rur_select}}

| wur_SWAP_ns &{1{wur_select}};

assign SWAP_we=1′b0 & bs_select

|1′b0 & rur_select

|wur_SWAP_we &wur_select;

endmodule

Annex M

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

You need to fill in the necessary information for this section

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

*/

/* Set the search path to include the library directories*/

SYNOPSYS = get_unix_variable("SYNOPSYS")

search_path=SYNOPSYS+/libraries/syn

/*Set the path and name of target library*/

search_path=<...>+search_path

target_library=<nameofthelibrary>

/*Constraint information*/

OPERATING_CONDITION=<name of the operating condition>

WIRE_LOAD=<name of the wire-load model>

BOUNDARY_LOAD=<library name>/<smallest inverter name>/<input pin

name>

DRIVE_CELL=<largeFF name>

DRIVE_PIN=<Q pin name of the FF>

DRIVE_PIN_FROM=<clock pin name of the FF>

/*target processor clock period*/

CLOCK_PERIOD=<target clock period>

/＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

＊＊

You don't need to make any changes below

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊ ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

*/

link_library={″*″}+target_library

symbol_library=generic.sdb

/*prepare workdir for hdl compiler*/

hdlin_auto_save_templates="TRUE"

define_design_lib WORK-path workdir

sh mkdir -p workdir

read -f verilog./prim.v

read -f erilog./ROOT.v

current_design UserInstModule

link

set_operating_conditions OPERATING_CONDITION

set_wire_load WIRE_LOAD

create_clock clk-period CLOCK_PERIOD

set_dont_touch_network clk

set_load{2*load_of(BOUNDARY_LOAD)}all_outputs()

set_load{2*load_of(BOUNDARY_LOAD)}all_inputs()

set_driving_cell-cellDRIVE_CELL-pin DRIVE_PIN-from_pin

DRIVE_PIN_FROM all_inputs()

set_max_delay 0.5 * CLOCK_PERIOD - from all_inputs() - to find(clock,

clk)

set_max_delay 0.5 * CLOCK_PERIOD - from find (clock, clk) - to

all_outputs()

set_max_delay 0.5 * CLOCK_PERIOD - from all_inputs() - to all_outputs()

set_drive-rise O clk

set_drive-fall O clk

compile-ungroup_all

report_timing

report_constraint-all_viol

report_area

Claims (134)

1. A system for designing a configurable processor, the system comprising: means for generating a description of a hardware implementation of a processor based on a configuration specification, wherein the configuration specification includes: a binary selection portion for determining whether certain features are included in the processor; the parameter selection part of the parameters of some predetermined features; and means for generating software development tools specific to the hardware implementation based on the configuration specification, Wherein, the configuration description includes at least one extended description of the processor's extensible features, and the extended description specifies the inclusion of a user-defined instruction and an implementation scheme for the instruction. 2. The system of claim 1, wherein the software development tool is used to generate code to run on the processor. 3. The system of claim 1, wherein the software development tool includes a compiler, adapted to the configuration specification, for compiling the application into code executable by the processor. 4. The system of claim 1, wherein the software development tool includes an assembler program adapted to the configuration specification for assembling the application into code executable by the processor. 5. The system of claim 1, wherein the software development tool includes a linker, adapted to the configuration specification, for linking code executable by the processor. 6. The system of claim 1, wherein the software development tool includes a decompiler adapted to the configuration specification for disassembling code executable by the processor. 7. The system of claim 1, wherein the software development tool includes a debugger adapted to the configuration specification for debugging code executable by the processor. 8. The system of claim 7, wherein the debugger has a common interface and configuration for the instruction set simulator and the hardware implementation. 9. The system of claim 1, wherein the software development tool includes an instruction set simulator adapted to the configuration specification for simulating code executable by the processor. 10. The system of claim 9, wherein the instruction set simulator is capable of simulating the execution of the simulated code to measure one or more performance specifications including execution cycles. 11. The system of claim 10, wherein the performance specification is based on specific configurable microarchitectural features. 12. The system of claim 10, wherein the instruction set simulator is capable of configuring the execution of the simulated program to record standard configuration statistics including the number of cycles executed in each simulated function. 13. The system of claim 1, wherein the hardware implementation description includes at least one of the following: a detailed HDL hardware implementation description; a synthetic script; a layout and wiring script; a programmable logic device script scripts; test benches; diagnostic tests for verification; scripts for running diagnostic tests on a simulated program; and test tools. 14. The system according to claim 1, wherein the means for generating a hardware implementation description comprises: means for generating a hardware description language description of a hardware implementation description from a configuration specification; means for synthesizing logic for a hardware implementation based on a hardware description language description; and A device for placing and wiring elements on a chip to form circuits based on synthesized logic. 15. The system according to claim 14, the means for generating a hardware implementation description further comprising: means for verifying the timing of the circuit; and A device used to determine the area, cycle time, and power consumption of a circuit. 16. The system of claim 1, further comprising means for generating configuration instructions. 17. The system of claim 16, wherein the means for generating configuration instructions is responsive to selection of configuration parameters by a user. 18. The system of claim 16, wherein the means for generating a configuration specification is for generating a specification based on a processor design target. 19. The system of claim 1, wherein the configuration specification includes at least one parametric specification of a modifiable characteristic of the processor. 20. The system of claim 19, wherein at least one parameter specification specifies inclusion of a functional unit, and at least one processor instruction to execute the functional unit. 21. The system of claim 19, wherein at least one parameter specification specifies one of inclusion, exclusion, and characteristics of a structure that affects processor state. 22. The system of claim 21, wherein the structure is a register file and the parameter specification specifies the number of registers in the register file. 23. The system of claim 21, wherein the structure is an instruction cache. 24. The system of claim 21, wherein the structure is a data cache. 25. The system of claim 21, wherein the structure is a write cache. 26. The system of claim 21, wherein the structure is one of on-chip ROM and on-chip RAM. 27. The system of claim 19, wherein at least one parameter specification specifies a semantic property that controls interpretation of at least one of data and instructions in the processor. 28. The system of claim 19, wherein at least one parameter specification specifies an execution characteristic that controls execution of instructions in the processor. 29. The system of claim 19, wherein at least one parameter specifies a debug characteristic of a given processor. 30. The system of claim 19, wherein the configuration specification includes a parameter specification specifying at least one selected from among predetermined features, size or number of processor elements, and assignment of values. 31. The system of claim 1, further comprising means for evaluating the applicability of the configuration specification. 32. The system of claim 31, wherein the means for evaluating comprises an interactive evaluation tool. 33. The system of claim 31, wherein the means for evaluating is to evaluate hardware characteristics of the processor described by the configuration specification. 34. The system of claim 31, wherein the means for evaluating is to evaluate applicability of the configuration specification based on the evaluated performance characteristics of the processor. 35. A system according to claim 34, further comprising means for providing information which modifies the configuration specification based on the evaluated performance characteristics. 36. The system of claim 34, wherein the performance characteristics include at least one of an area required to implement the processor on a chip, power consumed by the processor, and a clock speed of the processor. 37. The system of claim 31, wherein the means for evaluating is to evaluate the applicability of the configuration specification based on the evaluated software characteristics of the processor. 38. The system of claim 37, wherein the means for evaluating determines at least one of required code size and number of cycles by executing a suite of benchmark programs on the processor described by the configuration specification An assessment is made to interactively provide a suitability assessment to the user. 39. The system according to claim 31, wherein the means for evaluating evaluates each hardware characteristic and each software characteristic of the processor described by the configuration specification. 40. The system of claim 1, wherein the means for generating a description of a hardware implementation of a processor also simultaneously provides performance and cost characteristics of the hardware, and the means for generating software development tools together with the means for generating a processing The device hardware implementation described means for generating software application performance information for modification of configuration specifications. 41. The system of claim 1, wherein the means for generating a description of a hardware implementation of a processor also simultaneously provides performance and cost characteristics of the hardware, and the means for generating software development tools together with the means for generating The processor hardware implementation describes means for generating software application performance information to extend configuration specifications. 42. The system of claim 1 , wherein the means for generating a hardware description of a processor also simultaneously provides performance and cost characteristics of the hardware, and the means for generating a software development tool together with the means for generating a processor hardware Embodiments describe means for generating software application performance information to facilitate the description of configuration specifications; and means for generating a hardware description of a processor providing performance and cost characteristics of the hardware, and means for generating software development tools in conjunction with Means for generating a processor hardware implementation description for generating software application performance information for describing extensions to configuration descriptions. 43. The system of claim 1, further comprising means for generating a configuration of processors by extending a basic configuration of processors. 44. The system of claim 1, wherein the extended specification specifies additional instructions. 45. The system of claim 1, wherein the means for generating a software development tool comprises means for suggesting to a user possible user-defined instructions suitable for at least one application. 46. The system of claim 1, wherein the software development tool includes a compiler to generate user-defined instructions. 47. The system of claim 46, wherein the compiler is capable of optimizing code containing user-defined instructions. 48. The system of claim 1 , wherein the software development tools include at least one of: an assembler capable of generating user-defined instructions; a simulator capable of simulating execution of user code using user-defined instructions; and A tool capable of validating user implementations of user-defined directives. 49. The system of claim 46, wherein the compiler is capable of automatically generating additional instructions. 50. The system of claim 1, wherein: An extension specification specifies a new feature with functionality designed in abstract form by the user; and The means for generating the hardware implementation description also redefines new features and integrates them into the detailed hardware implementation description. 51. The system of claim 50, wherein an extension specification is a statement in an instruction set architecture language that is used to specify an opcode assignment and an instruction semantics. 52. The system of claim 51, wherein the means for generating a hardware implementation description comprises means for generating instruction decode logic from an instruction set architecture language definition. 53. The system of claim 52, wherein the means for generating a hardware implementation description further comprises an instruction set architecture language definition for generating signals specifying register operand usage for instruction interlock and suspend logic installation. 54. The system of claim 50, wherein the means for generating a software development tool includes means for generating an instruction decoding method for use in an instruction set simulation program adapted to a configuration specification. 55. The system of claim 50, wherein the means for generating a software development tool includes means for generating a coding table for a segment of assembly for generating a processor's object code adapted to a configuration specification in the program. 56. The system of claim 50, wherein the means for generating a hardware implementation description is further configured to generate a hardware description of a data path for a new feature, the hardware of the data path being related to the particular pipeline architecture of the processor The structure is consistent. 57. The system of claim 44, wherein additional instructions add no new state to the processor. 58. The system of claim 44, wherein additional instructions add state to the processor. 59. The system of claim 1, wherein the configuration description includes at least a portion specified by an instruction set architecture description language description. 60. The system of claim 59, wherein the means for generating a hardware implementation description comprises means for automatically generating instruction decode logic from an instruction set architecture language description. 61. The system of claim 59, wherein the means for generating a software development tool includes means for automatically generating an assembler kernel from an instruction set architecture language description. 62. The system of claim 59, wherein the means for generating a software development tool includes means for automatically generating a compiled program from an instruction set architecture language description. 63. The system of claim 59, wherein the means for generating a software development tool includes means for automatically generating a disassembler from an instruction set architecture language description. 64. The system of claim 59, wherein the means for generating a software development tool includes means for automatically generating an instruction set simulation program from an instruction set architecture language description. 65. The system of claim 1, wherein the means for generating a hardware implementation description includes preprocessing a portion of at least one of the hardware implementation description and the means for software development tools, so that according to the configuration specification, respectively Means for making modifications to hardware implementation descriptions and software tools. 66. The system of claim 65, wherein the means for preprocessing evaluates an expression in one of the hardware implementation description and the software development tool from the configuration specification and replaces the expression with a numerical value Mode. 67. The system of claim 66, wherein the expression includes at least one of an iteration structure, a conditional structure, and a database query. 68. The system of claim 1, wherein the configuration specification includes at least one parameter specification specifying modifiable characteristics of the processor. 69. The system of claim 68, wherein the modifiable feature is one of a modification to the core specification and an optional feature not specified in the core specification. 70. The system of claim 1, wherein the configuration specification includes at least one parameter specification specifying a binary selectable characteristic of the processor, at least one processor characteristic that can be specified with parameters. 71. A method for designing a configurable processor, the method comprising: A description of a hardware implementation of a processor is generated from a configuration specification, wherein the configuration specification includes a binary selection portion for determining whether certain features are included in the processor and parameters for specifying certain predetermined features of the processor The parameter selection part of the ; and Generate software development tools specific to the hardware implementation according to the configuration instructions, Wherein, the configuration description includes at least one extended description of the processor's extensible features, and the extended description specifies the inclusion of a user-defined instruction and an implementation scheme for the instruction. 72. A system for designing a configurable processor, the system comprising: Means for generating configuration instructions with user-definable parts comprising: Notes on user-defined processor states, and at least one user-defined instruction and an associated user-defined function that includes at least one of reading from and writing to a user-defined processor state; and Means for generating a hardware implementation description of a processor based on a configuration specification, wherein the hardware implementation of the processor includes a user-defined instruction execution unit for executing user-defined instructions. 73. The system of claim 72, wherein the hardware implementation description of the processor includes a description of the control logic required to execute at least one user-defined instruction and to implement the user-defined processor state. 74. The system of claim 73, wherein: The hardware implementation of the processor describes a pipeline of instruction execution; and Control logic includes portions associated with each stage of the pipeline for instruction execution. 75. The system of claim 74, wherein: The hardware implementation description includes a description of the circuitry used to halt execution of instructions; and The control logic includes circuitry for preventing modification of the user-defined state by the aborted instruction. 76. The system of claim 75, wherein the control logic includes circuitry for performing at least one of instruction issue, operand bypass, and operand write enable for at least one user-defined instruction. 77. The system of claim 74, wherein the hardware implementation description includes registers for implementing user-defined states in a number of stages of a pipeline of instruction execution. 78. The system of claim 74, wherein: The hardware implementation description includes status registers that are written in a pipeline stage different from the pipeline stage in which each output operand is generated; The hardware implementation description specifies bypassing such writes into subsequent instructions that reference user-defined processor state before acknowledging the write to the state register. 79. The system of claim 72, wherein: the configuration description includes a predetermined section other than the user-defined section; and The predetermined portion of the description includes an instruction that facilitates storing a user-defined state into memory, and an instruction that facilitates retrieving the user-defined state from memory. 80. The system of claim 79, further comprising means for generating software for context switching a user-defined state using said instructions that facilitate storing the user-defined state in memory. 81. The system of claim 72, further comprising means for generating at least one of: an assembler program for assembling user-defined processor states and at least one user-defined instruction; a compiler for compiling user-defined processor states and at least one user-defined instruction; a simulation program that simulates a user-defined processor state and at least one user-defined instruction; and A debugger for debugging user-defined processor states and at least one user-defined instruction. 82. The system of claim 72, further comprising generating an assembler for assembling user-defined processor states and at least one user-defined instruction; a compiler for user-defined processor states and compiles for at least one user-defined instruction; a simulator for simulating user-defined processor states and at least one user-defined instruction; and a debugger for user-defined processor states and at least one user-defined instruction Device for debugging. 83. The system of claim 72, wherein the user-defined portion of the specification includes at least one statement specifying a size and an index of the user-defined state. 84. The system of claim 83, wherein the user-defined portion of the specification includes at least one attribute related to a user-defined state in a processor register and a package specifying the user-defined state. 85. The system of claim 72, wherein the user-defined portion of the specification includes at least one statement specifying a mapping of user-defined states to processor registers. 86. The system of claim 72, wherein the means for generating a hardware implementation description comprises means for automatically mapping user-defined states to registers of the processor. 87. The system of claim 72, wherein the user-defined portion of the description includes at least one statement to describe a type of user-defined instruction and its effect on a user-defined state. 88. The system of claim 72, wherein the user-defined portion of the description includes at least one assignment statement to assign a value to the user-defined state. 89. A system for designing a configurable processor, the system comprising: core software tools for generating software development tools specific to an instruction set architecture specification from that specification; and A user-defined instruction module for generating at least one module from a user-defined instruction specification for use by core software tools in implementing the user-defined instruction, wherein the hardware implementation of the configurable processor includes a The user-defined instruction execution unit for the defined instruction. 90. The system of claim 89, wherein the core software tools include software tools capable of generating code to run on the processor. 91. The system of claim 89, wherein at least one module is implemented as a dynamic link library. 92. The system of claim 89, wherein at least one module is implemented as a table. 93. The system of claim 89, wherein the core software tools include a compiler that uses user-defined instruction modules for compiling the application into code that uses the user-defined instructions and is executable by the processor . 94. The system of claim 93, wherein at least one module includes a module used by a compiler to compile user-defined instructions. 95. The system of claim 89, wherein the core software tools include an assembler that uses user-defined modules for assembling the application into code that uses user-defined instructions and that is executable by the processor. 96. The system of claim 95, wherein at least one module includes a module used by an assembler to map assembly language instructions into user-defined instructions. 97. The system of claim 96, wherein: The system also includes core instruction set descriptions for non-user-defined instructions; and Description of the core instruction set, used by the assembler to assemble the application into code that can be executed by the processor. 98. The system of claim 89, wherein the core software tool includes an instruction set simulator for simulating code executable by the processor. 99. The system of claim 98, wherein at least one module includes a simulator module used by the simulator to simulate execution of user-defined instructions. 100. The system of claim 99, wherein the modules used by the simulation program include data for decoding user-defined instructions. 101. The system of claim 100, wherein the emulator uses a module to decode instructions using the emulator module when the instruction cannot be decoded as a predefined instruction. 102. The system of claim 89, wherein the core software tools include a debugger that uses user-defined modules to debug code that uses user-defined instructions and is executable by the processor. 103. The system of claim 102, wherein at least one module includes a module used by the debugger to decode machine instructions into assembly instructions. 104. The system of claim 102, wherein at least one module includes a module used by the debugger to convert assembly instructions to strings. 105. The system of claim 102, wherein: The core software tool includes an instruction set emulation program that simulates the code that can be executed by the processor; and The debugger is used to communicate with the simulator to obtain information about user-defined states for debugging. 106. The system of claim 89, wherein a single user-defined instruction can be used without modification by multiple core software tools according to different core instruction set specifications. 107. A system for designing a configurable processor, the system comprising: Core software tools for producing software development tools specific to a specification based on an instruction set architecture; A user-defined instruction module for generating a set of at least one module based on a user-defined instruction specification, which is used by the core software tools to implement each user-defined instruction, wherein the hardware implementation of the processor includes a The user-defined instruction execution unit of the instruction; and Storage means for simultaneously storing groups generated by the user-defined instruction modules, each group corresponding to a different set of user-defined instructions. 108. The system of claim 107, wherein at least one module is implemented as a dynamic link library. 109. The system of claim 107, wherein at least one module is implemented as a table. 110. The system of claim 107, wherein the core software tools include a compiler that uses user-defined instruction modules for compiling an application into a processor-executable code. 111. The system of claim 110, wherein at least one module comprises a module used by a compiler to compile user-defined instructions. 112. The system of claim 107, wherein the core software tools include an assembler that uses user-defined instruction modules for assembling the application into code that uses the user-defined instructions and that is executable by the processor . 113. The system of claim 112, wherein at least one module comprises a module used by an assembler to map assembly language instructions to user-defined instructions. 114. The system of claim 107, wherein the core software tool includes an instruction set simulator for simulating code executable by the processor. 115. The system of claim 114, wherein at least one module includes a module used by the simulation program to simulate execution of user-defined instructions. 116. The system of claim 115, wherein the modules used by the simulation program include data for decoding user-defined instructions. 117. The system of claim 116, wherein the emulator uses a module to decode instructions using the emulator module when the instruction cannot be decoded as a predefined instruction. 118. The system of claim 107, wherein the core software tools include a debugger that uses user-defined modules to debug code that uses user-defined instructions and is executable by the processor. 119. The system of claim 118, wherein at least one module includes a module used by the debugger to decode machine instructions into assembly instructions. 120. The system of claim 118, wherein at least one module includes a module used by the debugger to convert assembly instructions to strings. 121. A system for designing a configurable processor, the system comprising: A set of core software tools for producing software development tools specific to the specification based on the instruction set architecture; A user-defined instruction module for generating at least one module, based on a user-defined instruction set specification, which is used by a core set of software tools to implement the user-defined instructions, wherein the hardware implementation of the processor includes instructions for executing the user-defined A user-defined instruction execution unit for instructions. 122. The system of claim 121, wherein at least one module is implemented as a dynamic link library. 123. The system of claim 121, wherein at least one module is implemented as a table. 124. The system of claim 121 , wherein at least one set of core software tools includes a compiler that uses user-defined instruction modules for compiling applications to use user-defined instructions and that can be processed by a processor The executed code. 125. The system of claim 124, wherein at least one module comprises a module used by a compiler to compile user-defined instructions. 126. The system of claim 121 , wherein at least one set of core software tools includes an assembler that uses user-defined instruction modules for assembling an application into a The executed code. 127. The system of claim 126, wherein at least one module includes a module used by an assembler to map assembly language instructions to user-defined instructions. 128. The system of claim 121, wherein at least one set of core software tools includes an instruction set simulator for simulating code executable by the processor. 129. The system of claim 128, wherein at least one module includes a module used by the simulation program to simulate execution of user-defined instructions. 130. The system of claim 129, wherein the modules used by the simulation program include data for decoding user-defined instructions. 131. The system of claim 130, wherein the emulator uses a module to decode instructions using the emulator module when the instruction cannot be decoded as a predefined instruction. 132. The system of claim 121, wherein at least one set of core software tools includes a debugger that uses user-defined modules to debug code executable by the processor using user-defined instructions. 133. The system of claim 132, wherein at least one module comprises A module used by the program being debugged to decode machine instructions into assembly instructions. 134. The system of claim 132, wherein at least one module includes a module used by the debugger to convert assembly instructions to character strings.

Images