JP4801210B2 - System for designing expansion processors - Google Patents

Description

  The present invention is directed to a microprocessor system, and more particularly, the present invention is configured and enhanced at the processor design time to improve the processor's suitability for a particular application. Directed to the design of application solutions that include one or more processors. The present invention is such as new instructions up to an existing instruction set architecture, including new instructions that allow application developers to manipulate user-defined processor states and immediately assess the impact of expansion to application execution time and processor cycle time. It is aimed at systems that can quickly develop instruction extensions.

  Processors have traditionally been difficult to design and change. For this reason, most systems that include a processor use a processor that has been designed and verified once for general use and then used by multiple applications over time. As such, the suitability of a processor for a particular application is not always ideal. It is often appropriate to change the processor (eg, run faster, consume less power, require less cost) to beneficially execute code for a particular application. However, it is difficult to change existing processor designs, and thus even time, cost and risk are high and this is not typically done.

  To better understand the difficulties in making a conventional processor configurable, consider the development of this processor. First of all, an instruction set architecture (ISA) is developed. This is a measure that was originally performed once and was used for 10 years by many systems. For example, the Intel Pentium processor can extend the legacy of set processor instructions to the 8008 and 8080 microprocessors introduced in the mid-1970s. In this transition, based on a predetermined ISA design standard, ISA instructions, syntax, and the like are developed, and software development tools for the ISA such as an assembler, a debugger, and a compiler are developed. Next, a simulator for this particular ISA is developed, and various benchmarks are run to evaluate the efficiency of the ISA, and the ISA is revised according to the results of the evaluation. In some respects, the ISA is well considered and the ISA processing ends with fully developed ISA usage, including assemblers, debuggers, compilers, etc., ISA simulators, ISA verification suites and development suites.

  Next, processor design begins. Processors can have many years of useful life, and this transition occurs occasionally, and is typically designed once and used by several systems for several years. Given the ISA, ISA validation suite and simulator, and various processor development goals, the processor microarchitecture is designed, simulated, and revised. Once the microarchitecture is completed, the microarchitecture is executed in a hardware description language (HDL) and a microarchitecture verification suite is developed and used to verify the HDL implementation (and more later) . Next, unlike the manual processing described up to this point, the automated design tool may integrate circuits based on the HDL description, place circuit components, and route. Thus, this layout is revised to optimize chip area usage and timing. Alternatively, additional manual processing may form a floor plan based on the HDL description, convert the HDL into a circuit, and then verify and layout the circuit both manually and automatically. Finally, the layout is verified using an automated tool to ensure that it matches the circuit, and the circuit is verified according to the layout parameters.

  After processor development is complete, the entire system is designed. Unlike ISA and processor designs, system designs (which may include the design of the chip that currently contains the processor) are quite common, and the systems are typically designed sequentially. Each system is used for a relatively short time (one year or two years) depending on the particular application. Based on predetermined system objectives such as cost, performance, power and functionality, pre-existing processor specifications, and chip foundry (usually tightly coupled with processor vendors) specifications, the overall system architecture is Designed, the processor is selected to meet the design objectives, and the chip foundry is selected (this is closely coupled to the processor selection).

  Next, given the selection processor, ISA and foundry and simulation, verification and pre-developed development tools (and standard cell library for the selected foundry), the HDL implementation of the system is designed, A verification suite is developed for a system HDL implementation and this implementation is verified. The system development is then integrated, placed on the circuit board, routed, and layout and timing are reoptimized. Finally, the circuit board is designed and laid out, the chip is manufactured, and the circuit board is assembled.

  Because only any given application requires a specific set of functions, a processor with functions that are not required by the application is very expensive, consumes more power, and is more difficult to manufacture In addition, other difficulties associated with conventional processor design stem from the fact that it is not appropriate to simply design a conventional processor with more functions to cover the entire application. Furthermore, when the processor is first designed, not all of the application goals are known. If the processor change process can be automated and made reliable, the ability of the system designer to form an application solution is 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, the processing is completely hard-wired, for example, cannot be reasonably done in combination, logic, instead a programmable processor is introduced into the system for protocol processing. Programmability also allows bug fixing and upgrades to a protocol that is done later by loading instruction memory with new software. However, conventional processors were probably not designed for this particular application (the application may not even be present if the processor was designed) and need to be executed, one for additional processor logic. There can be operations that require a large number of instructions to execute, which can be done with one or a few instructions.

  Because processors cannot be easily enhanced, many system designers do not attempt to do so and instead instead run a useless pure software solution with available general-purpose processors. To do. Inefficiency results in a solution that may be slower, may require more power, or may be more expensive (eg, because this solution runs a program at a sufficient speed) May require a larger and more powerful processor). Other designers choose to provide some of the processing requirements of dedicated hardware designed for applications such as coprocessors, and then programmer code-up access to dedicated hardware at various points in the program Have However, because only a fairly large unit of work can speed up sufficiently, the time saved by using dedicated hardware is greater than the additional time required to transfer data to and from the dedicated hardware. Therefore, the time to transfer data between the processor and such dedicated hardware limits this type of utility to the system.

In communication channel application examples, the protocol may require encryption, error correction, or compression / decompression. This process often operates on individual bits rather than larger words of the processor. The circuitry for the computation may be rather normal, but the request to the processor to extract each bit processes each bit sequentially and then repacks the significant overhead of bit addition. As a very specific example, consider Huffman decoding using the rules shown in Table 1 (similar encoding is used in the MPEG compression standard). Since both value and length must be calculated, the length bits can be shifted off to find the beginning of the next element to be decoded in the stream.

  There are many ways to encode this for a traditional instruction set, but all of this method requires a large number of instructions due to the large number of tests performed, and a single for combinatorial logic. Unlike gate delay, each software implementation requires multiple processor cycles. For example, a valid conventional implementation using the MIPS instruction set may require six logical operations, six conditional branches, arithmetic operations, and associated register loads. Using an advantageously designed instruction set, encoding is better, but expensive in terms of time, ie one logical operation, six conditional branches, arithmetic operations and associated register loads.

  With respect to processor resources, this is so expensive that a 256 entry lookup table is generally used instead of encoding the process as a series of bit-by-bit comparisons. However, the 256 entry look-up table takes a significant pace and can also be several cycles to access. For longer Huffman coding, the table size becomes prohibitive, resulting in more complex and slower code.

  A possible solution to the problem of accepting processor specific application requirements is to use a configurable processor with an architecture that can be easily modified and expanded to enhance instruction set and processor functionality and customize this functionality There is to do. The simplest type of configurability is binary selection. That is, it has either a function or not. For example, the processor may be provided either with or without floating point hardware.

  Versatility may be improved by configuration selection with finer grading. For example, this processor allows the system designer to specify the number of registers in the register file, memory width, cache size, cache relevance, and so on. However, these options still do not reach the level of customizability by the system designer. For example, in the above Huffman coding example, although not known in the prior art, the system designer may prefer to perform decoding of, for example, huff8t1, t0, including specific instructions. Here, the most significant 8 bits of this result are the decoded value, and the least significant 8 bits are the length. Significantly different from the software implementation described above, the direct hardware implementation of Huffman decoding is quite simple, and the logic to decode the instructions is for combinatorial logic functions, etc. Shows about 30 gates, or less than 0.1% of a typical processor gate count, and can be calculated in a single cycle with dedicated processor instructions, showing 4-20 improvement over using only general purpose instructions .

  Conventional attempts to generate configurable processors generally fall into two categories. That is, automatic retargeting of compilers and assemblers from logic integration and abstract machine descriptions combined with parameterized hardware descriptions. The first category includes integrable processor hardware designs such as Synopsys DW8051 processor, ARM / Synopsys ARM7-S, LexraLX-4080, ARC configurable RISC core and to some extent Synposys integrable / configurable PCI bus interface .

Among the above, Synopsys DW8051 is a binary compatible implementation of an existing processor architecture, a few integration parameters, eg 128 or 256 bytes internal RAM, parameters rom addr Includes an interrupt device that supports a ROM address range determined by size, an optional internal timer, a variable number (0-2) of serial ports, and either 6 or 13 sources. Although the DW8051 architecture can be changed somewhat, the DW8051 instruction set architecture cannot be changed at all.

  The ARM / Synopsys ARM7-S processor includes binary compatible implementations of existing architectures and microarchitectures. The processor has the inclusion of two configurable parameters: a high performance or low performance multiplier and debug and in-circuit emulation logic. Although a change in the ARM7-S instruction set architecture is possible, since this change is a subset of the existing non-configurable processor implementation, no new software is required.

  The Lexra LX-4080 processor has a configurable variant of the standard MIPS architecture and has no software support for instruction set extensions. This processor option includes a custom engine interface that allows the extension of MIPS ALU opcodes for application specific operations, and internal hardware that includes register sources and registers or 16-bit wide immediate sources and destination signals and stall signals Interface, simple memory management device option, 3 MIPS coprocessor interface, flexible local memory interface to cache, scratchpad RAM or ROM, and bus controller to connect peripheral functions and memory to the processor dedicated local bus Including write buffers of possible depth.

  ARC configurable RISC core has user interface and block to memory for on-the-fly gate count estimation, instruction cache configuration, instruction set expansion, timer option, scratch pad memory option, and memory controller option based on target technology and clock speed Local scratchpad RAM with move, dedicated register, up to 16 extra conditional code selections, 32x32 bit scoreboard multiplication block, single cycle 32 bit barrel shifter / rotate block, normalization (find the first bit) Instructions, write results directly to command buffer (not register file), 16-bit MUL / MAC block and 36-bit accumulator, and local SRAM using linear arithmetic Having an instruction set options selectable as sliding pointer access, and a user command which is defined by the manual editing of the VHDL source code. The ARC design has no functionality to execute an instruction set description language and does not generate software tools specific to the configuration processor.

  The Synopsys configurable PCI interface includes a GUI or command line interface for installation, configuration, and integration activities, checks that pre-required user activities are performed at each step, and a selection design file based on the configuration (Verilog vs. VHDL) installation and user parameter settings and prompts for configuration values for combination validity checking and selection configuration such as user update of HDL source code and HDL generation for no editing of HDL source files; Analyze the technology library to select I / O pads, technology-independent constraints and integration scripts, pad inserts, and prompt for conversion to technology-dependent scripts and technology-independent formula-dependent scripts User interface And a kind of integration features. A configurable PCI bus interface is important for performing parameter consistency checking, configuration based installation, and automatic modification of HDL files.

  Furthermore, conventional integration techniques can select different mappings based on user objective specifications, and the mapping can be optimized for speed, power, area, and target components. In this regard, the prior art cannot obtain feedback of the effect of reconfiguring the processor in these ways without performing this design by the entire mapping process. Such feedback can be used to further reconfigure the processor until system design objectives are achieved.

  The second category of prior art research in the field of configurable processor generation, the automatic goal of compilers and assemblers, encompasses the well-developed areas of university research. For example, Hanono et al., "AVIV retargetable code generator instruction selection, resource allocation and scheduling" (indicating machine instructions used for automatic generation of code generators); Fauth et al., "Using nML Ramsety et al. “Machine description forming tools for embedded systems”; Aho et al. “Code generation using tree matching and dynamic programming” (translation associated with each machine instruction). A series of program operations, such as combining algorithms, eg, add, load, store, branch, etc., is represented by an intermediate format that is not machine dependent using methods such as pattern matching; and Cattel's “Code Generator Format And automatic derivation ”(Compiler Lab See, the abstract description) of the machine architecture that is used for.

  Once the processor is designed, the operation of the processor must be verified. That is, the processor typically executes instructions from the stored program using a pipeline having stages suitable for one phase of instruction execution. Thus, changing or adding instructions or changing the configuration may require extensive changes in the processor logic so that multiple pipeline stages can perform the proper operation of each such instruction. The configuration of the processor requires that the processor should be revalidated and that this verification be adapted to changes and additions. This is not an easy task. Processors are complex logic devices with a wide range of internal and control states, and control and data and program linkage analysis make verification a demanding technology. Adding to the difficulty of processor verification is a challenge in developing an appropriate verification tool. Since verification is not automated by the prior art, the versatility, speed and reliability of verification are not very optimal.

  Furthermore, once the processor is designed and verified, the processor is not particularly useful if the processor cannot be easily programmed. The processor is typically programmed using a wide range of software tools including compilers, assemblers, linkers, debuggers, simulators and profilers. If the processor changes, the software tool must also change. If this instruction cannot be compiled, assembled, simulated or debugged, adding the instruction is useless. The cost of software changes associated with processor modifications and enhancements has been a major obstacle to prior art general purpose processor designs.

  Thus, it can be seen that conventional processor designs are at a level of difficulty that the processor is typically not designed or modified in general for a particular application. Furthermore, it can be seen that significant improvements in system efficiency are possible if the processor can be configured or expanded for specific applications. Furthermore, the efficiency and effectiveness of the design process can be increased if feedback of implementation characteristics such as power consumption, speed, etc. can be used in improving the processor design. Furthermore, in the prior art, once a processor is changed, much effort is needed to verify the correct operation of the processor after the change. Finally, although the prior art provides for limited processor configurability, this technique cannot be provided for the generation of software development tools tailored for use with the configuration processor.

  A system that meets the above criteria is certainly an improvement over the prior art, but improvements can be made, for example, accessing processor states that significantly limit the range of information stored in special registers, i.e. the instructions that can be obtained. Alternatively, there is a need for a processor system with instructions that limit changes and thus the amount of performance improvement that can be achieved.

  In addition, inventing new application specific instructions requires a complex trade-off between cycle count reduction, additional hardware resources and CPU cycle time impact. Another challenge is to obtain an effective hardware implementation for new instructions without engaging application developers in the often cumbersome details of high performance microprocessor implementations.

  The above system gives the user the flexibility to design the best processor for the user's application. To better understand this problem, consider the typical scheme used by many software designers to match the performance of many software designers' software applications. Many software designers generally consider a possible improvement, modify the designer's software to use this potential improvement, and recompile the designer's software source And generate an executable application that includes this potential improvement, and then evaluate this potential improvement. Depending on the results of this evaluation, many software designers may retain or discard this potential improvement. In general, the entire process can be completed in just a few minutes. This allows the user to experiment freely, quickly try out ideas, and retain or discard them. In some cases, rigorous evaluation of possible ideas is complex. Users may want to experiment with ideas in a wide variety of situations. In such cases, the user owns multiple versions of the compiled application, one original version and the other version containing possible improvements. In some cases, possible improvements may affect each other, and the user may own more than one copy of the application, each copy using a different subset of possible improvements . By maintaining multiple versions, users can easily test different versions repeatedly under different environments.

  Configurable processors want software developers to collaborate and develop hardware and software in a manner similar to how traditional processor software is resolved. Consider the case of a user adding custom instructions to a configurable processor. The user wants to interact and add the possible instructions to his processor and test and evaluate these instructions in his specific application. For conventional systems, this is difficult for three reasons.

  First of all, after proposing a potential instruction, the user must wait for an hour or more before getting a compiler and simulator that can use the instruction.

  Second, if the user wants to experiment with a large number of possible instructions, the user must create and maintain a software development system for each instruction. The software development system can be very large. Keeping multiple versions can become unmanageable.

  Finally, the software development system is configured for all processors. This makes it difficult to separate development processes among different engineers. Consider an example where two developers work on a specific application. One developer should be responsible for determining the cache characteristics of the processor, and the other developer may be responsible for adding customized instructions. Although the work of the two developers is related, each work is sufficiently separable, so each developer can work in isolation and work on his or her work. A cache developer may propose a specific configuration first. The other developer starts with this configuration and tries out several instructions to form a software development system for each possible instruction. The cache developer then changes the proposed cache configuration. Since each developer configuration takes the initial cache configuration, the other developer must recreate every configuration in the developer configuration. For many developers working on a project, organizing different configurations can quickly become unmanageable.

  The present invention solves these problems of the prior art and automatically configures the processor by generating both a description of the hardware implementation of the processor and a set of software development tools that program the processor from the same configuration specifications. To provide a system that can.

  It is another object of the present invention to provide such a system that can optimize hardware implementations and software tools for various performance criteria.

  Another object of the present invention is to provide such a system that allows various types of configurability for the processor, including extensibility, binary selection and parameter changes.

  Another object of the present invention is to provide such a system that can indicate the instruction set architecture of a processor in a language that can be easily implemented in hardware.

  It is another object of the present invention to provide a system and method for developing and executing instruction set extensions that change processor state.

  It is another object of the present invention to provide a system and method for developing and executing instruction set extensions that change processor registers.

  Another object of the present invention is that the processor configuration can be customized by adding new instructions within a few minutes that the user can evaluate this property.

  The above objective is to use customized processor instruction set options and descriptions of standardized language extensions to define the configuration of the target instruction set, the hardware description language description of the circuitry required to execute the instruction set, and the processor This is accomplished by providing an automatic processor generation system that develops development tools such as compilers, assemblers, debuggers and simulators that can be used to generate software and verify the processor. The implementation of the processor circuit can be optimized for various criteria such as area, power consumption and speed. Once the processor configuration is developed, the processor configuration can be tested and entered into a system that is modified to repeatedly optimize the processor implementation.

  To develop an automatic processor generation system according to the present invention, an instruction set architecture description language is defined and configurable processor / system configuration tools and development tools such as assemblers, linkers, compilers and debuggers are developed. This is part of the development process because most tools are standard, but must be automatically constructed from ISA descriptions. Part of this design process is generally performed by the designer or manufacturer of the automatic processor design tool itself.

  The automatic processor generation system according to the present invention operates as follows. A user, for example a system designer, develops a configuration instruction set architecture. That is, using ISA definitions and pre-developed tools, a configurable instruction set architecture is developed that conforms to predetermined ISA design objectives. Development tools and simulators are then configured for this instruction set architecture. Using the configured simulator, the benchmark is run to evaluate the efficiency of the configurable instruction set architecture, and this center is revised based on the evaluation results. Once the configurable instruction set architecture is satisfactory, a verification suite is developed for it.

  Along with these software aspects of this process, the system accompanies the hardware aspects by developing configurable processors. Thus, using information on system objectives such as cost, performance, power and functionality and available processor fabrication, this system has an overall system architecture that allows for configurable ISA options, extensions and processor function selection. design. Using the entire system architecture, development software, simulator, configurable instruction set architecture and processor HDL implementation, the processor ISA, HDL implementation, software and simulator are configured by the system, and the system HDL is system-on-a-chip. Designed for design. Further, based on the system architecture and chip foundry specifications, the chip foundry is selected based on an evaluation of the foundry function for the system HDL (not related to processor selection as in the prior art). Finally, using the foundry standard battery library, the configuration system provides the ability to integrate the circuit, place and route this circuit, and reoptimize layout and timing. Thus, if this design is not of a single chip type, the circuit board layout is designed, the chip is manufactured, and the circuit board is assembled.

  As can be seen above, several techniques are used to facilitate extensive automation of the processor design process. The first technique used to address these issues is to design and implement a specific mechanism that is not as flexible as any changes or extensions, yet allows significant functional improvements. . By suppressing the voluntary nature of the change, the problems associated with it are suppressed.

  The second technique consists in making a single description of the changes and automatically generating changes and extensions of all affected components. Doing something manually once describes a tool, does this tool automatically, and is often cheaper than using this tool once, so a processor designed in the prior art is Did not do. Use automation advantages when a task is repeated several times.

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

  Finally, the fourth technique is to provide hardware and software in a form that is useful for configuration. In an embodiment of the present invention, some of the hardware and software are not directly described in standard hardware and software languages, but standard hardware and software languages with configuration database queries and replacements, conditionals, duplications and other modifications It is written in a language enhanced by the addition of a preprocessor that allows code generation. The core processor design is therefore done with hooks to which enhancements can be linked in.

  To illustrate these techniques, consider the addition of application specific instructions. By constraining this method to instructions that have registers and constant operands and produce register results, the operation of the instructions can be specified only in combinatorial (stateless, free feedback) logic. This input specifies operational code assignment, instruction name, assembly brush syntax, and combinational logic for the instruction. From this instruction, the tool will: • Instruction decoding logic in which the processor recognizes the new operation code; • Addition of a functional unit that performs a combinational logic function on the register operand; Instruction scheduling logic input;-Assembler changes that accept new opcodes and their operands and generate correct machine code;-Compiler changes that add new unique functions to access new instructions;-Machine code as new instructions Change the simulator to perform the specified logic function; and Generate a diagnostic generator that includes both the result of the additional instruction and generates both a direct code sequence and a random code sequence that examines the result.

  All of the above techniques are used to add application specific instructions. Input is constrained by input and output operands and logic that evaluates these operands. This change is described in one place, and all hardware and software changes are derived from this description. This feature shows how a single input can be used to enhance multiple components.

  The trade-off between the processor and the rest of the system logic can be done very late in the design process, so the result of this process is much more than conventional technology by meeting system application requirements. It is an excellent system. This system is superior to many of the conventional methods described above in that the system configuration may be applied to many more display formats. A single source may be used for full ISA encoding, software tools and high-level simulations may be included in the configurable package, and the flow for iteration to find the optimal combination of configuration values May be designed. Furthermore, while the foregoing method has focused solely on hardware or software configuration without a single user interface for control or a measurement system for redefinition for the user, the present invention is not limited to processor hardware. Includes feedback from hardware design results and software performance that contribute to completing the flow for hardware and software configuration and help select the optimal configuration.

  These objectives are to use a customized processor instruction set extension description in a standardized language for a configurable definition of the target instruction set, a hardware description language for the circuitry required to execute the instruction set, and a processor. It is achieved in accordance with aspects of the present invention by providing an automated processor design that develops development tools such as compilers, assemblers, debuggers and simulators that can be used to develop and validate applications. Standardized languages can handle instruction set extensions that use processor states that change processor state or are configurable. By providing a zone of expansion and optimization, the process can be automated to a high degree, thereby facilitating fast and reliable development.

  The above objectives also allow the user to maintain multiple sets of possible instructions or states (hereinafter, possible combinations of configurable instructions or states are collectively referred to as “processor enhancements”), If the application of processor enhancement can be evaluated, it is achieved by another aspect of the invention that provides a system that can be easily switched between processor enhancements.

  The user selects and forms a base processor configuration using the method shown here. The user creates a new set of user-defined processor enhancements and places this processor enhancement in the file directory. The user then invokes a tool that processes the user enhancement and converts it into a form usable by the base software development tool. This conversion is very fast because it includes only user-defined enhancements and does not form an entire software system. The user then invokes the base software development tool and informs the tool to dynamically use the processor enhancement formed in the new directory. Preferably, the directory location is provided to the tool either by command line option or environment. To further simplify the process, the user can use a standard software makefile. These allow the user to use the base software development system to change the processor instructions, then process the enhancements with a single make command, reshape and evaluate the application with respect to the new processor enhancements.

  The present invention overcomes three limitations of the conventional scheme. Given a new set of possible enhancements, the user can evaluate the new enhancement with a momentary problem. Users can maintain multiple versions of potential enhancements by creating a new directory for each set. Since the directory only contains a description of the new enhancement and not the entire software system, the storage space required is minimal. Finally, the new enhancement is cut off from the rest of the configuration. Once the user has created a directory with a possible set of new enhancements, the user can use this directory with any base configuration.

FIG. 2 is a block diagram of a processor that executes an instruction set according to a preferred embodiment of the present invention. It is a block diagram of the pipeline used with the processor by a present Example. 2 shows a configuration manager of a GUI according to the present embodiment. 3 shows a GUI configuration editor according to the present embodiment. The different types of configuration possibilities according to this embodiment are shown. It is a block diagram which shows the flow of the processor structure of a present Example. It is a block diagram of the instruction set simulator by a present Example. It is a block diagram of the emulation board for using together with the processor comprised by the present Example. FIG. 2 is a block diagram illustrating a logical architecture of a configurable processor according to an embodiment. FIG. 10 is a block diagram illustrating the addition of multipliers to the architecture of FIG. FIG. 10 is a block diagram illustrating the addition of a multiply-accumulate device to the architecture of FIG. It is a figure which shows the structure of the memory of a present Example. It is a figure which shows the structure of the memory of a present Example. FIG. 9 illustrates the addition of a user-defined functional device of the architecture of FIG. FIG. 9 illustrates the addition of a user-defined functional device of the architecture of FIG. FIG. 6 is a block diagram illustrating the flow of information between system components of another preferred embodiment. FIG. 3 is a block diagram illustrating how custom code is generated for the software development tool of the present embodiment. FIG. 6 is a block diagram illustrating the generation of various software modules used in another preferred embodiment of the present invention. It is a block diagram of the pipeline structure of the configurable processor by a present Example. It is a gate register implementation according to the present embodiment. FIG. 6 is a diagram of additional logic required to perform a state register implementation in this example. FIG. 7 is a diagram illustrating the coupling of the next state output of the state from the various semantic blocks and selection blocks to the input of the state register according to this embodiment. The logic corresponding to the semantic logic by a present Example is shown. If the status bits are mapped to the bits of the user register of this embodiment, the logic for the status bits is shown.

  In general, the automatic processor generation process begins with a configurable processor definition and its user-specified change, and a user-specified application in which the processor is to be configured. This information is used to generate a configured processor that takes into account user changes and to generate software development tools, eg, compilers, simulators, assemblers, disassemblers, etc. for this tool. In addition, the application is recompiled using new software development tools. The recompiled application is simulated using a simulator to generate a software profile that describes the performance of the configured processor executing the application, and the configured processor is hardware that features a processor circuit implementation. Evaluated for silicon chip area usage, power consumption, speed, etc. to generate a profile. Software and hardware profiles are fed back and supplied to the user to allow other iterative configurations so that the processor can be optimized for this particular application.

  The automatic processor generation system 10 according to the preferred embodiment of the present invention has four main components as shown in FIG. That is, the four main components are for a user configuration interface 20 where a user desiring to design a processor enters user configurability and extensibility options and other design constraints, and for criteria selected by the user. A set of software development tools 30 that can be customized for the designed processor, a parameterized decompression description of the hardware implementation of the processor 40, and input data from the user interface, and the requested processor's A forming system 50 that generates customized and integratable hardware descriptions, changes software development tools, and accepts selected designs. Preferably, the forming system 50 further generates diagnostic tools, validates hardware and software designs and estimators, and estimates hardware and software characteristics.

  A “hardware implementation description” as used herein and as used in the appended claims describes a physical implementation aspect of a processor design and describes one or more other , Or together with this description, means one or more descriptions that facilitate the manufacture of the chip according to this design. Thus, the components of the hardware implementation description may be at a level of abstraction that varies from a relatively high level, such as a hardware description language with a netlist and microcoating masking the description. However, in this embodiment, the main components of the hardware implementation description are described in HDL, netlist, and script.

  Further, HDL as used herein and as used in the appended claims is intended to indicate a general class of hardware description language used to describe microarchitectures, etc. Is intended to show that any particular example of such a language is given.

  In this embodiment, the basis for the processor configuration is the architecture 60 shown in FIG. Many architectural elements are basic functions that cannot be changed directly by the user. These include a processor control unit 62, an alignment / decoding unit 64 (part of which is based on a user-specified configuration), an ALU / address generation unit 66, a branch logic / instruction fetch 68, Processor interface 70. Other devices are part of the basic processor but are user configurable. These include an interrupt control unit 72, data and instruction address monitoring units 74 and 76, a window register file 78, a data and instruction cache and tag unit 80, a write buffer 82, and a timer 84. The remaining portion shown in FIG. 2 is optionally included by the user.

  The central component of the processor configuration system 10 is a user configuration interface 20. This is preferably a graphical user interface (GUI) that allows the selection of processor functionality including compiler reconfiguration and assembler, disassembler and instruction set simulator (ISS) playback, and creation of inputs that start full processor integration, placement and routing. ) To the user. Thereby, users can also take advantage of a quick estimate of code size for processor area, power consumption, cycle time, application performance and other iterations and enhancements of the processor configuration. Preferably, the GUI also accesses the configuration database, obtains default values, and performs user input error checking.

  In order to use the automatic processor generation system 10 according to the present embodiment to design the processor 60, the user inputs design parameters into the user configuration interface 20. The automatic processor generation system 10 may be a stand-alone system that runs on a computer system under the control of a user. That is, however, the system 10 preferably runs primarily in the system under the control of manufacturing the automatic processor generation system 10. User access may then be provided via a communication network. For example, the GUI may be provided using a web browser having a data entry screen written in HTML and Java. This has several advantages such as maintaining the confidentiality of the backend software that can claim arbitrary ownership, simplifying maintenance, updating the backend software and the like. In this case, in order to access the GUI, the user may first log on to the system 10 to prove his identity.

  Once the user has access, the system displays a configuration manager screen 86 as shown in FIG. The configuration manager 86 is a directory that lists all of the configurations accessible by the user. The configuration manager 86 of FIG. 3 has a user having two configurations, “just intr” and “high prior”, the first one already formed, ie finished for manufacturing and the second one Indicates that it should still be formed. From this screen 86, the user may create, delete, and edit the selected configuration and generate a report that specifies which configurations and extensions are selected for this configuration or form a new configuration. . For those configurations formed like “just intr”, a set of software development tools 30 customized for it can be downloaded.

  Creating a new configuration or editing an existing configuration brings up the configuration editor 88 shown in FIG. The configuration editor 88 has an “Options” section menu on the left that shows various general aspects of the processor 60 that can be configured and expanded. When an options section is selected, a screen with a configuration section for this section is displayed on the right, and these options are available as pull-down menus, note menus, note boxes, check boxes, as known in the art. Can be set with a radio button. Although the user can select options and enter data randomly, preferably there is a logical dependency between sections so that data is entered sequentially into each. For example, the number of interrupts must be selected in the “ISA Options” section in order to properly display the options in the “Interrupts” section.

In this embodiment, the following configuration options are available for each section.
the purpose
Technique for estimation
Target ASIC technology: 18,. 25. . 35 microns
Target operating condition: typical, worst case
Implementation goals
Target speed: Arbitrary Total number of gates: Arbitrary
Target power: Any
Objective prioritization: speed, area power, speed, power, area ISA options
Numeric option
MAC16 with 40-bit accumulator: yes, no
16-bit multiplier: yes, no
Exception options
Number of interrupts: 0 to 32
High priority interrupt level: 0-14
Enable debugging: yes, no
Number of timers: 0-3
Other
Byte array: little endian, big endian
Number of registers available for calling Windows®: 32, 64
Processor cache & memory
Processor interface read width (bit): 32, 64, 128
Write buffer entry (address / value pair): 4, 8, 16, 32
Processor cache
Instruction / data cache size (kB): 1, 2, 4, 8, 16
Instruction / data cache line size (kB): 16, 32, 64
Peripheral components
Timer
Timer interrupt count
Timer interrupt level debugging support
Number of instruction address breakpoint registers: 0 to 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 interrupt
Source: External, Software
Priority level system memory address
Vector and address calculation methods: XTOS, manual
Configuration parameters
RAM size, start address: Any
ROM size, start address: Any
XTOS: optional
Configuration specific address
User exception vector: Any
Kernel exception vector: any
Register window overflow / underflow vector base: Any
Reset vector: Any
XTOS start address: Any
Application start address: Arbitrary TIE instruction
(Defines ISA extensions) Target CAD environment
Simulation Verilog (R): yes, no
Integration
Design Compiler (R): yes, no
Location & Route
Apollo®: yes, no In addition, system 10 includes 32-bit integer multiplier / divider or floating point arithmetic unit, memory management unit, on-chip RAM and ROM option, cache associativity, enhanced DSP and coprocessor instructions Provides options for adding other additional devices such as sets, write-back cache, multiprocessor synchronization, compiler-oriented guessing, and support for additional CAD packages. Whatever configuration option is available for a given configuration processor, this configuration option is preferably used by the system 10 for syntax checks, etc. once the user has selected the appropriate option. Listed in a definition file (for example, the definition file shown in Appendix A).

  From the foregoing, the automatic processor configuration system 10 has two general types of configurability 300 as shown in FIG. 5 for the user: extensibility 302 that allows the user to define any function and structure from scratch, and user A changeability 304 is provided that can be selected from a predetermined set of constrained options. Within the possibility of change, the system may determine whether a given function, eg MAC 16 or DSP, should be added to the processor 60 and other processor functions, eg binary number of parameter specifications 308 for interrupt count and cache size. Allows selection 306.

  Many of the above configuration options are well known to those skilled in the art. However, others deserve special attention. For example, RAM and ROM options allow the designer to include a scratchpad or firmware in the processor 10 itself. The processor 10 fetches instructions and reads and writes data from these memories. The size and placement of the memory is configurable. In this embodiment, each of these memories is accessed as an additional set of set associative caches. Memory hits can be detected by comparing to a single tag memory.

  System 10 provides separate configuration options for interrupts (performing level 1 interrupts) and high priority interrupt options (performing level 2-15 interrupts and non-maskable interrupts). Because each high priority interrupt level requires three special registers, these registers are more expensive.

  MAC16 with 40-bit accumulator option (shown at 90 in FIG. 2) is a 16-bit multiplier / add function with 40-bit accumulator, 8 16-bit operand registers and multiplication, accumulation, operand load and address update Add a set of compound instructions that combine the instructions. Operand registers can be loaded with pairs of 16-bit values from memory in parallel with multiply / accumulate operations. This device can sustain an algorithm with two loads per cycle and multiplication / accumulation.

  An on-chip debug module (shown at 92 in FIG. 2) is used to access the internal software visible state of the processor 60 via the JTAG port 94. Module 92 provides support for exception generation that places processor 60 in debug mode, access to all processor visible registers or memory locations, execution of any instructions configured for execution by processor 60, and desired location of code. Change the PC to jump to and a utility that can return to the normal operating mode that is activated from outside the processor 60 via the JTAG port 94.

  Once processor 10 enters debug mode, processor 10 waits for an indication from the external area that a valid instruction has been scanned in via JTAG port 94. The processor then executes this instruction and waits for the next valid instruction. Once the hardware implementation of the processor 10 has been manufactured, this module 92 can be used to debug the system. The execution of the processor 10 can be controlled via a debugger running on the remote host. This debugger interfaces with the processor via the JTAG port 94 and uses the functions of the on-chip debug module 92 to determine and control the state of the processor 10 as well as control the execution of instructions.

  A counter / timer 84 of up to 32 bits may be configured. This increments each clock cycle in the same way as the comparator that compares the compare register and compare register contents with the current clock register count (for each configuration timer) 32 for use with interrupt functions and similar functions. Requires the use of bit registers. This counter / timer can be configured to be edge triggered and can generate normal or high priority internal interrupts.

  The speculation option provides greater compiler scheduling flexibility by allowing the load to speculatively move to control the flow if the load is not necessarily performed. This load movement can be introduced into a valid program that did not initially raise an exception, since the load may cause an exception. If the load is not performed, speculative loading prevents these exceptions from occurring, but gives an exception if this data is needed. Instead of raising an exception for load errors, speculative loads reset the destination register valid bit (the new processor state associated with this option).

  If multiple processors are used in the system, the core processor 60 preferably has some basic pipeline synchronization capability, but some communication and synchronization between the processors is required. In some cases, self-synchronous communication techniques such as input / output queues are used. In other cases, a shared memory model is used for communication, and the shared memory needs to provide instruction set support for synchronization to provide the required semantics. For example, an additional load instruction and a store instruction for obtaining and releasing semantics can be added. These are useful for controlling the arrangement of memory references in a microprocessor system where memory locations may be used for synchronization and data so that the exact arrangement between synchronization criteria must be maintained.

  In some cases, a shared memory model is used for communication, and it is necessary to provide instruction set support for synchronization because the shared memory does not provide the required semantics. This is done with the microprocessor synchronization option.

  Perhaps the most prominent configuration option is the TIE instruction definition in which the designer-defined instruction execution unit 96 is formed. The TIE® (Tensilica Instruction Set Extensions) language, developed by Tensilica Corporation of Santa Clara, California, allows users to write custom functionality for applications in the form of extensions and new instructions, and to create a base ISA Can be expanded. Further, due to the generality of TIE, TIE may be used to describe the portion of the ISA that cannot be changed by the user. In this way, the entire ISA can be used to uniformly generate the software development tool 30 and the hardware implementation description 40. The TIE technique uses a number of building blocks and describes the attributes of a new instruction as follows:

Instruction field Instruction class
Instruction operation code Instruction semantics
Instruction operand ... Constant table
The instruction field statement field is used to improve the readability of the TIE code. A field is a concatenated subset of other fields that are grouped together and referenced by name. The entire set of instruction bits is the highest level superset field inst, which can be divided into smaller fields. For example,

Defines two 4-bit fields, x and y are subfields of the highest level field inst (bits 8-11 and 12-15, respectively), and 8-bit field xy is a concatenation of x and y fields Stipulate.

A statement operation code defines an operation code that encodes a particular field. An instruction field intended to specify an operand, such as a register or an immediate constant, to be used by an operation code defined in this way must first be specified in the field statement and then in the operand statement.
For example,

Defines two new operation codes, acs and adsel, based on the predefined operation code CUSTO (4, b | 0000 indicates a binary constant 0000 with a length of 4 bits). The preferred core ISA TIE specification has the following statements as part of its base definition:

Thus, with the definitions of acs and adsel, the TIE compiler generates instruction decoding logic respectively indicated by:

Instruction Operand Statement operand identifies a register and an immediate constant. However, before defining a field as an operand, this operand had to be defined in advance 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 the value of the constant can be taken from a predefined constant table defined as described below. For example, to encode an immediate operand, the following TIE code:

  Defines an 18-bit field name offset that holds an operand offset4 that is four times the number stored in the signed number and offset field. The last part of the operand statement actually describes the circuit used to perform the computation of the Verilog® HDL subset describing the combinational circuit, as will be apparent to those skilled in the art.

  Here, the wire statement defines a set of 32 bit wide logical wires named t. The first assign statement after the wire statement specifies that the logic signal driving the logic wire is an offset4 constant shifted to the right, and the second assign statement contains the lower 18 bits of t in the offset field. Specify that The very first assign statement directly specifies the value of the offset4 operand as a 14th copy of its sign bit (bit 17) followed by a concatenation of offset and a 2 bit left shift.

TIE code for constant table operands

Uses a table statement, specifies a constant array prime (the number following the table name is the number of elements in the table), uses operands as indexes, table primes, and operands prime Encode the value for s (note the use of Verilog® statements in defining the indexing).

The instruction class statement icclass associates an operation code with a common format operand. All instructions specified in the iclass statement have the same format and operand usage. Before defining an instruction class, its components must first be defined as fields, then as operational codes and operands. For example, when formed with the code used in the previous example defining the operands acs and adsel, the following additional statement:

Uses operand statements to define the three register operands art, ars, and arr (again, note the use of the definition Verilog® statement). Therefore, the iclass statement

Specifies that operands adsel and acs belong to the ordinary class of instructions viterbi that takes two register operands art and ars as inputs, and writes the output to register operand arr.

  The instruction semantic statement semantic describes the work of one or more instructions using the same subset of Verilog® used to encode the operands. By defining multiple instructions in a single semantic statement, several common expressions can be shared and the hardware implementation can be made more efficient. The variables allowed in the semantic statement are single bit variables for each operation code specified in the operand and operation code list specified in the operation code list of the statement. This variable has the same name as the operation code, and if an operation code is detected, a numerical value for 1 is obtained. This variable is used in the calculator (Verilog® subset section) to indicate the presence of the corresponding instruction.

For example, a new instruction ADD8 that performs the addition of four 8-bit operands of a 32-bit word with each 8-bit operand of another 32-bit word A new instruction MIN16 that performs a minimum value selection between two 16-bit operands of 4 and 32-bit words and each 16-bit operand of the other 32-bit word The TIE code that defines 2 may read:

Here, op2, CUSTO, arr, art, and ars are predefined operands as described above and opcode and iclas statement functions as described above.

Semantic statements specify calculations performed by new instructions. As will be readily apparent to those skilled in the art, the second line in the semantic statement is the new ADD8 Specifies the computation performed by the four instructions, among which the third and fourth lines are the new MIN16 Specifies the computation performed by the two instructions, and the last line in this section specifies the result written to the arr register.

  Returning to the discussion of the user input interface 20, once the user has entered all of the desired configuration and expansion options, the forming system 50 takes over. As shown in FIG. 5, the forming system 50 receives configuration specifications configured by parameters set by the user and decompression functions designed by the user, and adds these to additional parameters that define the core processor architecture, eg, user Combined with the functions that can be changed by, form a single configuration specification 100 that describes all processors. For example, in addition to the configuration settings selected by the user, the forming system 50 may include a parameter specifying the number of physical address bits for the processor's physical address space, the first instruction executed by the processor 60 after reset. You may add a position etc.

  Tensilica Xtensa® Instruction Set Architecture (ISA) Standard Manual Revision 1.0 is intended to show examples of instructions that can be used as core instructions in a configurable processor and instructions that can be used by selecting configuration options Incorporated for reference here.

The config spec 100 was supplied by the user, with an ISA package containing a TIE language statement specifying the base ISA, any additional package selected by the user, such as a coprocessor package 96 (see FIG. 2) or a DSP package. Includes optional TIE extensions. In addition, the config spec 100 may have a number of statements that set a flag that indicates whether a given structural function should be included in the processor 60. For example,

Indicates that the processor includes an on-chip debugging module 92, an interrupt function 72, and exception handling, but does not include a high priority interrupt function.

Using the configuration specification 100, the following can be automatically generated as shown below. -Instruction decoding logic for processor 60-Invalid instruction detection logic for processor 60-Part for specific ISA of assembler 110-Support routine for specific ISA for compiler 108-Specification of disassembler 100 (used by debugger) Part for ISA ・ Part for specific ISA of simulator 112
It is useful to generate these automatically because an important configuration function is to specify package inclusion of instructions. For some things, if an instruction is configured, it can be executed with conditional code in each of the tools to process the instruction, but this is cumbersome. More importantly, the instructions allow the system designer to easily add instructions for the designer's system.

  In addition to treating the configuration specification 100 as input from the designer, it can also accept goals, have a forming system 50, and automatically determine the configuration. The designer can specify goals for the processor 60. For example, clock speed, area, cost, typical power consumption, and maximum power consumption may be goals. Since some of the goals are competing (eg, often performance can only be increased by increasing area or power consumption or both), the forming system 50 also performs prioritization for the goals. The forming system 50 then examines the search engine 106 to determine the set of available configuration options and how to set each option from an algorithm that attempts to execute the input goals simultaneously.

  The search engine 106 includes a database having entries that describe the effect on various distances. Entry has the effect that certain configuration settings are additive, multiplicative or limited to distance. The entry can also be indicated as requiring other configuration options as a prerequisite or as incompatible with other options. For example, a simple branch prediction option can specify multiplicative or additive effects in the cycle per instruction (CPI ... performance determinant), limit on clock speed, additive effect on area, and additive effect on power. . This option can be shown as not matching the more elaborate branch predictor and depends on setting the instruction fetch queue size to at least two entries. These effect values may be a function of a parameter such as a branch prediction table size. In general, a data entry can be shown as a function whose value is determined.

  Various algorithms are possible to find the configuration setting that is closest to achieving the input goal. For example, a simple knapsack packing algorithm considers each option in a value array divided by cost and accepts any option specification that increases the value while keeping the cost within certain limits. So, for example, to minimize performance while keeping power below a specified value, this option is categorized by performance divided by power, increasing the performance that can be configured without exceeding the power limit. Each option is accepted. The more complicated knapsack algorithm provides some amount of backtracking.

A very different kind of algorithm to determine the configuration from the goal and design database is based on simulated annealing. A random initial set of parameters is used as a starting point, and then individual parameter changes are accepted or rejected by determining the value of the global utility function. Utility function improvements are always accepted while negative changes are accepted on a probabilistic basis based on a threshold that drops as optimization proceeds. In this system, the utility function consists of input targets. For example, given a target performance> 200, power <100, area <4, with respect to power, area and performance priorities, the power consumption will be rewarded for reduction in power consumption until the power consumption is less than 100 and then neutral. The following utility functions can be used that reward an area reduction until the next neutral is less than 4, and a performance increase until the next neutral is 200 or more.

There are also components that reduce power usage when the power or area is out of specification, where power reduces off-specific area usage.

  These and other algorithms can be used to look for configurations that meet specified goals. Importantly, the configurable processor design is described in a design database that has assumptions, incompatibility option specifications, and the effect of configuration options on various distances.

  The example we showed was general and used a hardware goal that was independent of the particular algorithm executed on the processor 60. The described algorithm can also be used to select the optimal configuration for a particular user program. For example, a user program can be run on a cache accurate simulator to measure the number of cache misses for different types of caches having different characteristics such as different sizes, different line sizes and different set associatives. The results of these simulations can be added to a database used by search algorithm 106 that has been written to help select hardware implementation description 40.

  Similarly, user algorithms can be profiled for the presence of certain instructions that can optionally be implemented in hardware. For example, the user algorithm takes a significant amount of time to multiply. Search engine 106 may automatically suggest including a hardware multiplier. Such an algorithm need not be limited to considering one user algorithm. The user can supply a set of algorithms to the system, and the search engine 106 can, on average, select a configuration that is useful for the set of user programs.

In addition to selecting preconfigured characteristics of processor 60, the search algorithm can also be used to automatically select or suggest a user-enabled TIE extension. Given an input goal and possibly an example of a user program written in the C programming language, these algorithms suggest possible TIE extensions. In the case of a stateless TIE extension, a tool such as a compiler is implemented with a pattern matcher. These pattern matchers move expression nodes in a bottom-up manner that searches for multiple instruction patterns that can be replaced with a single instruction. For example, indicate that user C program contains the following statement:
x = (y + z) <<2;
x2 = (y2 + z2) <<2;
The pattern matcher finds that users at two different locations add two numbers and shift the result two bits to the left. The system adds two numbers to the database and adds the possibility to generate a TIE instruction that shifts the result two bits to the left.

  The forming system 50 is always aware of a large number of possible TIE instructions along with a count of how many times the TIE instruction appears. Using the profiling tool, the system 50 also always knows how often each instruction is executed during the entire execution of the algorithm. Using a hardware estimator, the system 50 always knows how expensive the hardware is to execute each potential TIE instruction. These numbers are fed into a heuristic search algorithm to select a set of TIE instructions that may maximize the input goals, ie goals such as performance, code size, hardware complexity, etc.

  The same but more powerful algorithm is used to find TIE instructions that may have state. Several different algorithms are used to detect different kinds of opportunities. One algorithm uses a tool such as a compiler to scan the user program and detect whether the user program requires more registers than are available in hardware. As is known to those skilled in the art, this can be detected by counting the number of register spills and re-stored in a compiled version of the user code. Tools such as compilation suggest a coprocessor with additional hardware registers 98 to the search engine, but have multiple spills and support only operations used in the portion of the user's code to be restored. This tool is responsible for informing the database used by the search engine 106 of the coprocessor hardware cost estimate as well as an estimate of how the user's algorithm has been improved. As described above, the search engine 106 makes a global determination as to whether the suggested coprocessor 98 provides sufficient configuration.

  Alternatively or in addition, the user program checks whether a tool such as compilation uses a bitmask operation to ensure that the user program never has a given variable greater than a given limit . In this situation, the tool suggests to the search engine 106 a coprocessor 98 that uses a data type that matches the user limit (eg, 12-bit or 20-bit or any other large integer). In the third algorithm used in other embodiments used for user programs in C ++, it can be seen that tools such as compilation spend a lot of time operating on user-defined abstract data types. . Although all data type operations are suitable for TIE, the algorithm suggests to search engine 106 to perform all data type operations by the TIE coprocessor.

In order to generate the instruction decoding logic of the processor 60, one signal is generated for each operation code defined in the configuration specification. This code is declared

HDL statement

And

The

Is generated by simply rewriting the file.

  The generation of register interlock and pipeline install signals is also automated. This logic is also generated based on the configuration specification information. If the current instruction's source operand is determined by the destination operand of the previous instruction that did not complete, the generated logic inserts a stall (or bubble) based on the register usage information included in the instruction's iclass statement and latency. To do. The mechanism that performs this stall functionality is implemented as part of the core hardware.

The illegal instruction detection logic is generated by taking a NOR with a separate generated instruction signal ANDed with the field limit of the instruction signal.

  The instruction decode signal and the illegal instruction signal can be used as the output of the decode module and as input of the processor logic written by hand.

  To generate other processor functions, the present embodiment uses a Verilog® description of configurable processor 60 enhanced with the peribase preprocessor language. Peri is a fully functional language that includes complex control structures, subroutines and I / O functions. In an embodiment of the present invention, a preprocessor called TPP (as shown in the source listed in Appendix B, TPP is the periprogram itself) scans its input and preprocessor language (periple in the case of TPP). ) To identify a given line of preprocessor code (these lines are prefixed with a semicolon in the case of TPP), construct a program consisting of the extracted lines and statements, and text on other lines Is generated. The non-preprocessor row has an embedded expression in which an expression generated as a result of the TPP process is substituted. Thus, the resulting program generates source code, ie Verilog® code that describes the detailed processor logic 40 (as will be seen below, TPP is also used to configure the software development tool 30). To be executed.

When used in this context, the TPP is a configuration specification query, conditional expression and Verilog® as well as executing embedded expressions determined by the Verilog® code configuration specification 100 as described above. It is a powerful preprocessing language to allow the inclusion of constructors such as code repetition structures. For example, a TPP assignment based on a database query is likely to be:

Where config get value is a TPP function used to query the config spec 100, IsaMemoryOrder is a flag set in the config spec 100, and Sendian is used later when generating Verilog® code. TPP variable to be done.
The TPP conditional formula is

It may be.

The iterative loop can be performed by a TPP constructor as follows.

Here, Si is a TPP loop index variable, and Sninterrupts is the number of interrupts designated for the processor 60 (config) get Obtained from configuration specification 100 using Value).

Finally, the TPP code can be embedded in the Verilog (registered trademark) formula as follows.

Here, Sninterrupts defines the number of interrupts and determines the width (related to bits) of the xtscenflop module (flip-flop primitive module).
srInterruptEn is the output of a flip-flop that is defined as an appropriate number of bits of wire.
srDataIn W is the input of the flip-flop, but only the relevant bits are input based on the number of interrupts.
srInterruptEnWEn is a flip-flop write enable.
cReset is a flip-flop clear input.
CLK is an input clock of the flip-flop.

For example, the following input

And declaration

To give.

The TPP generates:

  The HDL description 114 thus generated is used at block 122 to integrate hardware for processor implementation using, for example, a design compiler manufactured by Synopsys. Once the component has been routed, this result can be used for wire de-annotation and timing verification at block 132 using, for example, Primetime® from Synopsys. The result of this process is a hardware profile that can be used by the user to supply other inputs to the configuration acquisition routine 20 for other configuration iterations.

  As described with respect to the logic integrator 122, one of the results of configuring the processor 60 is customized that a particular gate level implementation can be obtained by using any of a number of commercial integration tools. A set of HDL files. One such tool is the Design Compiler® from Synopsys. In order to ensure an accurate, high performance gate level implementation, the present embodiment provides the scripts necessary to automate the integration process in the customer environment. The requirement in providing such a script is to support different user integration methodologies and different implementation objectives. In order to handle the first request, this embodiment breaks this script into smaller scripts and functionally completely scripts. One such example is a read script that can read all HDL files associated with a particular processor configuration 60, a timing suppression script that sets timing requirements specific to the processor 60, and gate level netlist placement and routing. It is to provide a script that details the integration results in a way that can be used for. In order to handle the second requirement, the present embodiment provides a script for each implementation purpose. One such example is to provide a script that achieves faster cycle times, a script that achieves minimum silicon area, and a script that achieves minimum power consumption.

  Scripts are also used in other phase processor configurations. For example, once the HDL of processor 60 has been described, the simulator can be used to verify the correct operation of processor 60 as described above with respect to block 132. This is often accomplished by running a number of test programs or diagnostics on the simulated processor 60. Executing the test program on the simulated processor 60 generates an executable image of the test program and generates a display of this executable image that can be read by the simulator 112, and the results of the simulation are used for future analysis. This may require a number of steps such as creating a display of this executable image that can be collected and analyzing the results of this simulation and the like. In the prior art, this was done with a number of discard scripts. These scripts are for simulation environments such as which HDL files should be included, which locations of these files can be in the directory structure, which files are needed for the test bench, etc. Has some built-in knowledge. In modern designs, the preferred embodiment is to describe a script template that consists of parameter substitution. The configuration mechanism also uses TPP to generate a list of files that are needed for simulation.

  Further, the verification process of block 132 often requires the designer to write other scripts that can execute a series of test programs. This is often used to run regression suites that give designers confidence that a given change in the HDL model will not introduce new bugs. These regression scripts were also often discarded to have a number of built-in assumptions about file names, locations, etc. As described above for creating an execution script for a single test program, the regression script is described as a template. This template is constructed by substituting configuration time parameters for actual values.

  The final step in the process of converting the RTL description into a hardware implementation is to use location and route (P & R) software to convert the abstract netlist into a geometric representation. P & R software analyzes netlist connectivity and determines cell placement. The software then tries to draw a connection line between all cells. Clock nets usually deserve special attention and are routed as the last step. Both of these processes are expected to see which cells are close together (known as soft grouping), the relative placement of cells, which nets are expected to have a slight propagation delay, etc. Can be facilitated by providing the tool with some information like

  To facilitate this process and to ensure that the desired performance goals are achieved, ie cycle time, area, power consumption, the configuration mechanism generates a set of scripts or input files for the P & R software To do. These scripts contain information as described above, such as relative placement for cells. The script also includes information such as how many power and ground connections are needed and how they should be distributed along boundaries etc. This script is generated by querying a database containing information on how many soft groups will be formed and what cells should be included in the soft group and which nets are important times . This parameter varies based on which option is selected. These scripts must be configurable depending on the tool used to change the location and route.

  Optionally, the configuration mechanism can request more information from the user and send it to the P & R script. For example, the interface allows the user to have the desired aspect ratio of the final layout, how many levels of buffering should be inserted into the clock tree, on which side the input and output pins are relative or absolute to these pins You can ask what should be on the layout, power and grounding straps etc. These parameters are then sent to the P & R script to generate the desired layout.

  For example, you can even use more complex scripts that allow for more complex clock trees. One common optimization performed to reduce power consumption is to gate the clock signal. However, this makes clock tree integration very difficult because it is very difficult to balance the delays of all branches. The configuration interface can ask the user to use the correct cell for the clock tree and perform some or all of the clock tree integration. The configuration interface has some knowledge of which gate clock is in this design and does this by estimating the delay from the gate of interest to the clock input of the flip-flop. Thus, this interface provides a constraint to the clock tree integration tool to match the clock buffer delay with the gate cell delay. In modern implementations this is done by a generic periscript. This script reads the gate clock information generated by the configuration agent based on which option is selected. Once the design has been placed and routed, a periscript is executed before the final clock tree integration is performed.

  Further improvements can be made to the profile processing described above. In particular, we describe a process that allows a user to obtain similar hardware profile information almost simultaneously without spending time executing these CAD tools. This process has several steps.

  The first step in this process is to separate the set of all configuration options into groups of orthogonal options so that the effect of the options of the hardware profile group is independent of any other group of options. For example, the impact of the MAC16 device on the hardware profile is independent of any other option. Thus, an option group having only MAC options is formed. A more complex example is an option group that includes interrupt options, high-level interrupt options, and timer options, since the impact on the hardware profile is determined by a particular combination of these options.

  The second step is to characterize the impact of the hardware profile of each option group. Characterization is done by obtaining the impact of the hardware profile on the various option combinations of the group. For each combination, this profile is obtained using a pre-described process in which the actual implementation is obtained and its hardware profile is measured. Such information is stored in the estimation database.

  The last step is to obtain a specific formula that calculates the hardware profile by a specific combination of options in the option group using curve fitting and interpolation techniques. Different expressions are used depending on the name of the option. For example, since each additional interrupt vector adds to the hardware for the same logic, we use a linear function to model its hardware impact. In another example, having a timer device requires a high priority interrupt option, so the formula for the hardware impact of the timer option is a conditional formula that includes multiple options.

  It is helpful to provide quick feedback on how architecture choices may affect application runtime performance and code size. Several sets of benchmark programs from multiple application areas are selected. For each region, a database is pre-formed that estimates how different architectural design decisions affect the runtime performance and code size of applications within the region. As users change the architectural design, the database is queried for application areas that create interest for the user or for multiple areas. Since the results of the evaluation are presented to the user, the user obtains an estimate of the trade-off between software advantages and hardware costs.

  The rapid evaluation system can be easily extended to give the user suggestions on how to change the configuration to further optimize the processor. One such example is to associate each configuration option with a set of numbers that indicate the incremental impact of options at various cost distances such as area, delay, and power. Calculating the incremental cost impact for a given option is easily done with a quick evaluation system. It simply requires two calls to the option presence / absence evaluation system. The difference in cost for the two evaluations indicates the incremental impact of the option. For example, the incremental region impact of the MAC16 option is calculated by evaluating the region costs of the two configurations with and without the MAC16 option. This difference is then displayed in the MAC 16 option of the interactive configuration system. Such a system can guide the user towards an optimal solution through a series of single step improvements.

  Moving to the software side of automatic processor configuration processing, this embodiment of the present invention configures software development tool 30 such that software development tool 30 is processor specific. The configuration process begins with a software tool 30 that can be ported to a variety of different systems and instruction set architectures. Tools that can change these goals are widely studied and well known. This embodiment is free software, and uses, for example, a GNU family tool including a GNU C compiler, a GNU assembler, a GNU linker, a GNU profiler, and various utility programs. These tools 30 are then automatically configured by generating a piece of software directly from the ISA description and using TPP to modify the piece of software written by hand.

  The GNU C compiler is configured in several different ways. Given a core ISA description, much of the compiler's machine-dependent logic can be described by hand. This part of the compiler is common to all configurations of the configurable processor instruction set, and changing the goals manually allows fine tuning for best results. However, even for this hand-coded part of the compiler, some code is automatically generated from the ISA description. In particular, the ISA description defines a set of constant values that can be used in the immediate field of various instructions. For each immediate field, a predicate function is generated to test whether a particular constant value can be encoded in the field. The compiler uses these predicate functions when generating code for the processor 60. Automating this aspect of the compiler configuration eliminates the opportunity for discrepancies between the ISA description and the compiler, which allows the ISA constants to be changed with minimal effort.

  Some aspects of the compiler are configured via preprocessing in TPP. For configuration options controlled by parameter selection, the compiler's corresponding parameters are set by TPP. For example, in the compiler, the target processor 60 uses a big endian or little endian byte array, and this variable is set automatically using a TPP command that reads the endianness from the configuration specification 100. TPP conditionally enables or disables the hand-encoded part of the compiler that generates code for any ISA package based on whether the corresponding package is available in config spec 100 Can also be used. For example, code that generates multiply / accumulate instructions is only included in the compiler if the configuration specification includes MAC16 option 90.

  The compiler is also configured to support designer-defined instructions specified by the TIE language. There are two levels of support. At the lowest level, designer-defined instructions are available as macro functions, built-in functions, or inline (external) functions in the compiled code. This embodiment of the present invention generates a C header (standard function of the GNU C compiler) that defines inline functions such as "inline assembly" code. Given the designer-defined operation code and the corresponding operand of the operation code, generating this header file is a simple process that translates to the GNU C compiler inline assembly syntax. Other implementations form a header file containing C preprocessor macros that specify inline assembly instructions. Yet another alternative uses TPP to add built-in functions into the compiler.

  A second level of support for designer-defined instructions is provided by having the compiler automatically recognize opportunities to use instructions. These instructions can be defined directly or automatically by the user during the configuration process. Prior to compiling the user application, the TIE code is automatically inspected and converted to a function equal to C. This is the same step that can be used to enable fast simulation of TIE instructions. Functions equal to C are partially compiled into a tree-based intermediate representation used by the compiler. This indication for each TIE instruction is stored in a database. When a user application is compiled, part of the compilation process is a pattern matcher. User applications are compiled into a tree-based display. The pattern matcher moves bottom-up for each user program tree. At each step of movement, the pattern matcher checks whether the intermediate representation routed to the current point matches any of the TIE instructions in the database. If there is a match, a match is indicated. After completing moving through each tree, the largest sized set of matches is selected. Each maximum match in the tree is replaced with an equivalent TIE instruction.

  The aforementioned algorithm automatically recognizes the opportunity to use a stateless TIE instruction. The additional scheme can also be used to automatically recognize opportunities to use a TIE instruction with a state. The previous section described an algorithm that automatically selects a TIE instruction that may have a state. The same algorithm is used to automatically use CIE or C ++ application TIE instructions. If the TIE coprocessor is defined to have more registers but a limited set of operations, the area of code will determine whether or not these registers are subject to register spinning and the set of operations that these registers can use. Scanned to see if it is only used. If such areas are found, the code in these areas is automatically changed to use coprocessor instructions and registers 98. A conversion operation occurs at the boundary of the region to move the data in and out of the coprocessor 98. Similarly, if the TIE coprocessor is specified to operate with different sized integers, the area of code is checked to see if all the data in this area is accessed as if it were of a different size. Inspected as follows. For the matching area, this code is changed and the glue code is added to the boundary. Similarly, if a TIE coprocessor 98 is defined to execute a C ++ abstract data type, all operations of this data type are replaced with TIE coprocessor instructions.

  Note that both automatically implying the TIE instruction and automatically using the TIE instruction are useful individually. The implied TIE instructions can also be used manually by the user via an embedded mechanism, and utilizing the algorithm can be added to a manually designed TIE instruction or coprocessor 98.

  Regardless of how designer-defined instructions are generated by either inline functions or automatic recognition, the compiler knows the possible side effects of designer-defined instructions so that they can be optimized and scheduled There is a need. To improve performance, conventional compilers optimize user code to maximize desired characteristics such as execution time performance, code size, or power consumption. As is known to those skilled in the art, such optimization includes such as rearranging instructions or replacing certain instructions with other semantically equivalent instructions. In order to fully perform the optimization, the compiler must know how every instruction affects different parts of the machine. Two instructions that read and write different parts of the machine state can be freely rearranged. In conventional processors, the state read and / or written by different instructions is sometimes hardwired into the compiler by a table. In one embodiment of the present invention, it is assumed that the TIE instruction reads and writes all the states of the processor 60 even if estimated to the inner ring. This allows the compiler to generate correct code but limit the compiler's ability and optimize the code when there is a TIE instruction. In another embodiment of the invention, the tool automatically reads the TIE definition and finds what state is read or written by the instruction for each TIE instruction. The tool then modifies the table used by the compiler's optimizer to accurately model the effect of each TIE instruction.

  Like the compiler, the machine dependent part of the assembler 110 includes both automatically generated parts and manually encoded parts composed of TPP. Some features common to all configurations are supported by hand-written code. However, the primary task of assembler 110 is to encode machine instructions, and instruction encoding and decoding software can be automatically generated from the ISA description.

  Because instruction encoding and decoding are useful with different software tools, this embodiment of the present invention groups software and performs these tasks into separate software libraries. This library is automatically generated using information in the ISA description. This library includes a list of operation codes, a function that efficiently maps strings for operation code mnemonics onto the members of the list (stringToOpcode), instruction length for each operation code, number of operands ( Defines a table that specifies numberOfOperand), operand field, operand type (ie, register or immediate) (operandType), binary encoding (encodeOpcode) and mnemonic string (opcodeName). For each operand field, the library provides an accessor function (fieldSetFunction) that encodes the corresponding bit of the instruction word and an accessor function (fieldGetSetFunction) that decodes it. All of this information is readily available in the ISA description. That is, generating library software is simply a matter of converting this information into executable C code. For example, if each entry is an encoding for a particular instruction generated by setting each operation code field to the value specified for this instruction in the ISA description, the instruction encoding is recorded in a C array variable. Is done. The encodeOpecode function simply returns to an array value for a given operation code.

  The library also provides a function for decoding the operation code of a binary instruction (decodeInstruction). This function is generated as a series of nested switch statements in which the outermost switch tests the sub-operation code at the top of the operation code hierarchy, and the nested switch statements test progressively lower sub-operation codes in the operation code hierarchy. Therefore, the code generated for this function has the same structure as the operation code itself.

Given this library for encoding and decoding instructions, the assembler 110 is easily implemented. For example, the instruction coding logic of the assembler is quite simple. Ie

It is equally simple to implement the disassembler 110 that converts binary instructions into a readable form that is very similar to assembly code.

  This disassembler algorithm is used in a stand-alone disassembler tool and also in the debugger 130 to support machine code debugging.

  The linker is not as sensitive to device configuration as a compiler or assembler 110. Many of the linkers are standard, and even machine dependent parts rely primarily on the core ISA description and can be manually encoded for a particular core ISA. Parameters such as endianness are set from the configuration specification 100 using TPP. The memory map of the target processor 60 is another aspect of the configuration required by the linker. In this way, the parameter that specifies the memory map is inserted into the linker using TPP. In this embodiment of the invention, the GNU linker is driven by a set of linker scripts, which are those linker scripts that contain memory map information. The advantage of this approach is that if the target system's memory map is different from the memory map specified when the processor 60 was configured, the additional information can be obtained without reconfiguring the processor 60 and without rebuilding the linker. A simple linker script can be generated later. Thus, this embodiment includes a tool that constructs a new linker script with different memory map parameters.

  In order to single-step execution of instructions one at a time, introduce breakpoints, and perform other standard debugging tasks, debugger 130 provides a mechanism for observing the state of the program as it executes. To do. The program to be debugged can be implemented on either the hardware implementation of the configured processor or the ISS 126. In either case, the debugger presents the same interface to the user. When implementing a program for a hardware implementation, a small monitor program is included in the target system to control user program execution and communicate with the debugger via the serial port. When the program is executed for the simulator 126, the simulator 126 itself performs these functions. The debugger 130 depends on this configuration in several ways. In order to support the decomposer code from within the debugger 130, the debugger 130 is connected to the instruction encoding / decoding library described above. A portion of the debugger 130 that displays the register status of the processor by scanning the ISA description to find which registers are present in the processor 60, and a portion of the debug monitor program and ISS 126 that provides information to the debugger 130 Is generated.

  Other software development tools 30 are standard and need not be changed for each processor configuration. Profile viewers and various utility programs are included in this category. It may be necessary to retarget these tools in order to work on files in a binary format shared by all device configurations of the processor 60, but these tools may be ISA descriptions or configuration specifications. It does not depend on any of the other parameters in the document 100.

  The configuration specification is also used to configure a simulator called ISS 126 shown in FIG. The ISS 126 is a software application that models the functional behavior of a configurable processor instruction set. Unlike its corresponding processor hardware model simulator, such as Synopsys VCS, Cadence Verilog XL, NC simulator, etc., the ISS HDL model is an abstraction of the CPU during execution of its instructions. The ISS 126 runs much faster than the hardware simulation because it does not need to model the transition of each signal for each gate, nor does it need to be registered in a complete processor design.

  The ISS 126 allows a program to be generated for the configured processor 60 to be executed on the host computer. The ISS 126 accurately reproduces the reset of the processor and blocks the action of developing low level programs such as device drivers and initialization code. This is particularly useful when connecting native code to embedded applications.

  The ISS 126 can be used to identify potential problems such as structural assumptions and memory ordering issues without having to download code to the actual embedded target.

  In this embodiment, ISS semantics are represented as using a C-like language literally to build a C operator building block that turns instructions into functions. For example, rudimentary functionality for interrupts such as interrupt registers, bit settings, interrupt levels, vectors, etc. is modeled using this language.

The configurable ISS 126 is used for the following four purposes or goals as part of the system design and validation process:
-Debug software applications before hardware is available;-Debug system software (eg compiler and operating system components);-Compare with HDL simulation for hardware design verification. ISS acts as a reference implementation for ISA, and both ISS and processor HDL are run for diagnostics and applications during processor design verification, and traces from both are compared; and-Analysis of software application performance (This may be part of the configuration process, or may be used for further applications that tune after the processor configuration is selected).

  For all goals, it is necessary for the ISS 126 to be able to load and decode programs created with configurable assemblers 110 and linkers. It is also necessary that the ISS execution of instructions be semantically equivalent to the corresponding hardware execution and compiler prediction. For these reasons, the ISS 126 derives its decoding and execution behavior from the same ISA file used to define the hardware and system software.

  For the first and last goals described above, it is important that the ISS 126 reach the required accuracy as quickly as possible. Thus, the ISS 126 allows dynamic control of the level of detail of the simulation. For example, cache details are not modeled unless needed, and cache modeling can be dynamically switched on and off. Further, before compiling the ISS 126 so that the ISS 126 has little configuration-dependent behavior selection at run time, portions of the ISS 126 (eg, cache and pipeline models) are configured.

  For the first and last goals described above, it is important that, under design (target), if the operating system services are not available to the system from the OS, the ISS 126 provides these services to the application. It is also important that these services are provided by the target OS if it is a relevant part of the debugging process. In this way, the system provides a design for flexibly running these services between the ISS host and the simulation target. The current design relies on a combination of ISS dynamic control (SYSCALL instruction trapping may be switched on and off) and the use of special SIMMCALL instructions to request host OS services.

  The final goal requires modeling some aspects of processor and system behavior where the ISS 126 is below the level specified by the ISA. In particular, the ISS cache model is constructed by generating C code for a model from a Perl script that extracts parameters from the device configuration database 100. In addition, details of instruction pipeline behavior (e.g., interlocks based on register usage and functional unit availability requirements) are also derived from the device configuration database 100. In the current implementation, a special pipeline description file specifies this information in the lexical syntax.

  The third goal requires precise control of interrupting behavior. For this purpose, special unstructured registers in ISS 126 are used to suppress interruptability.

The ISS 126 provides several interfaces to support different goals for its use. -Batch or command line mode (generally used in relation to the first and last goals);-Command loop mode, which is non-symbolic debugging capability, eg breakpoints, watchpoint steps, etc. 4 Provide frequently used debugging capabilities for all three goals; and
-Socket interface that allows the ISS 126 to be used by the software debugger as an execution backend (this must be configured to read and write register states for a specific selected configuration);-Very detailed Scriptable interface that enables efficient debugging and performance analysis. In particular, this interface may be used to compare application behavior for different configurations. For example, at any breakpoint, the state from a run for one configuration may be compared to the state from a run for another configuration, or the state from a run for one configuration may be compared from the run for another configuration. You may make it transfer to a state.

  The simulator 126 has a portion that is manually coded and automatically generated. Except for instruction decode and execution created from tables generated from the ISA description language, the manually coded parts are conventional. These tables start with the primary operation code found in the instruction word to be executed, index into the table with values in the field, and are not defined in terms of a piece of operation code, that is, another operation code Decode the instruction by continuing until an operational code is found. The table then gives a pointer to the code translated from the TIE code specified in the semantic declaration for that instruction. This code is executed to simulate the instruction.

  The ISS 126 can profile the execution of the simulated program. This profiling uses program counter sampling techniques known in the industry. At regular intervals, the simulator 126 samples the PC (program counter) of the simulated processor. The simulator 126 builds a histogram with the number of samples in each code area. The simulator 126 also counts the number of times each edge in the call graph is executed by incrementing the counter each time a call instruction is simulated. When the simulation is complete, the simulator 126 writes an output file that includes both histograms and call graph edge counts in a format that can be read by a standard profile viewer. Since the simulated program 118 does not need to be modified with instrumentation code (as in standard profiling techniques), the profiling overhead does not affect the simulation results and the profiling is totally non-invasive.

  Preferably, the system is made available for hardware processor emulation and software processor emulation. For this purpose, the present embodiment provides an emulation board. As shown in FIG. 6, the emulation board 200 uses a complex programmable logic device 202 such as an Altera Flex 10K 200E to emulate a processor configuration 60 in hardware. Once programmed with the processor netlist generated by the system, the CPLD device 202 is functionally equivalent to the final ASIC product. It offers the advantage of being able to take advantage of a physical implementation of the processor 60 that runs much faster than other simulation methods (such as ISS 126 or HDL) and is periodically accurate. However, it cannot reach the high frequency target that the final ASIC device can achieve.

  This board allows designers to evaluate various processor configuration options and to begin software deployment and debugging early in the design cycle. It can also be used for functional verification of the processor configuration.

  To allow easy software deployment, debugging and verification, the emulation board 200 has several resources available for it. These resources include the CPLD device 202 itself, EPROM 204, SRAM 206, synchronous SRAM 208, flash memory 210, and two RS232 serial channels 212. The serial channel 212 provides a communication link to a UNIX or PC host for downloading and debugging user programs. Considering the CPLD netlist, the configuration of the processor 60 is downloaded to the CPLD 202 through a dedicated serial link to the device configuration port 214 of the device or through the dedicated device configuration ROM 216.

  The resources available for the board 200 can also be configured to some extent. Because the mapping is done through a programmable logic device (PLD) 217 that can be easily changed, the memory map of various memory elements on the board can be easily changed. Further, the caches 218 and 228 utilized by the processor core can be expanded by dividing the tag buses 222 and 224 connected to the caches 218 and 228 to an appropriate size using larger storage devices.

  The use of a board to emulate a particular processor configuration involves several steps. The first step is to obtain a set of RTL files that describe the specific configuration of the processor. The next step is to integrate the gate level netlist from the RTL description using a number of commercial integration tools. One such example is FPGA Express from Synopsys. The gate level netlist can then be used to obtain a CPLD implementation using tools typically provided by vendors. One such tool is Maxplus 2 from Altera Corporation. The last step is to download the implementation onto the CPLD chip of the emulation board, again using the programmer provided by the CPLD vendor.

  Since one of the goals of the emulation board is to support rapid prototype implementation for debugging purposes, it is important that the CPLD implementation process outlined in the previous paragraph is automatic. To accomplish this goal, the files delivered to the user are customized by grouping all related files into one directory. A fully customized integration script is then provided to integrate a specific processor configuration into a specific FPGA device selected by the customer. A fully customized implementation script used by the merchant tool is also generated. Such integration and implementation scripts ensure functionally correct implementation with optimal performance. To read all RTL files associated with a particular processor configuration, include the appropriate command in the script and the appropriate command to assign the chip pin location based on the I / O signal in the processor configuration. Functional accuracy is achieved by including and by including commands to obtain specific logic implementations for certain critical portions of processor logic, such as in gated clocks. In addition, this script improves the performance of implementation by assigning detailed timing constraints to all processor I / O signals and by special handling of certain critical signals. One example of timing limitation is assigning a specific input delay to that signal by considering the delay of one signal on the board. An example of critical signal processing is assigning clock signals to dedicated global wires to achieve low clock skew for CPLD chips.

Preferably, the system also configures a verification suite for the configured processor 60. Most verifications for complex designs such as microprocessors consist of the following flow:
-Build a test bench to stimulate the design and compare outputs within the test bench or using an external model such as ISS 126;-Write diagnostics to generate the stimulus;-Limited Measure the verification coverage using a scheme such as line coverage of the machine coverage HDL, the falling bag rate, the number of vectors moving in the design, etc .; and if the coverage is not sufficient, further diagnostics Further design is performed using tools for writing and possibly generating diagnostics.

The present invention uses a somewhat similar flow, but modifies all components of this flow to account for the configurability of the design. This methodology consists of the following steps:
-Build test benches for specific configurations. The test bench configuration uses a similar approach as described for HDL and supports all the options and extensions supported within it, ie cache size, bus interface, clocking, interrupt generation, etc. Execute the self-checking diagnostic method for a specific configuration of HDL. The diagnostic method itself can be configured to adapt to specific hardware components. The selection of which diagnostic method to execute is also made according to the configuration. -Run pseudo-randomly generated diagnostics and compare processor state after each instruction execution to ISS 126; and-Measuring verification coverage using a coverage tool that measures line coverage along with functional coverage. Furthermore, in order to look for an illegal state, the monitor and the checker are moved along the diagnostic method. All of these can be configured for specific configuration specifications.

  All verification components are configurable. Configurability is put into practical use using TPP.

The test bench is a Verilog® model of the system where the configured processor 60 is located. In the case of the present invention, these test benches include:
-Cache, bus interface and external memory;-External interrupt mechanism and bus error generation;-Clock generation.

  Since almost all of the above features are configurable, the test bench itself needs to support configurability. Thus, for example, the cache size and the number of external interrupt mechanisms are automatically adjusted based on the configuration.

  The test bench provides stimulation to the device under test, processor 60. It is done by providing assembly level instructions (from diagnostics) that are preloaded into memory. In addition, the test bench generates signals that control the behavior of the processor 60, eg, interrupts. Also, the frequency and timing of these external signals can be controlled and automatically generated by the test bench.

  There are two types of diagnostic possibilities. First of all, the diagnostic method uses TPP to determine what to test. For example, one diagnostic has been written to test software interrupts. This diagnostic method needs to know how many software interrupts there are in order to generate the correct assembly code.

Second, the processor configuration system 10 must determine which diagnostic method is appropriate for this configuration. For example, a diagnostic method written to test a MAC unit is not applicable to a processor 60 that does not include this unit. In this embodiment, this is done through the use of a database containing information about each diagnostic method. The database may contain the following information for each diagnostic method:
-If an option is selected, use that diagnostic;-If the diagnostic can't be run with an interrupt;-Does the diagnostic require a special library or handler to run? And ━ If the co-simulation with ISS126 is present, whether or not the diagnostic method can be executed.

  Preferably, the processor hardware description includes three types of test tools: a test generator tool, a monitor and coverage tool (or checker) and a co-simulation mechanism. A test generator tool is a tool that produces a series of processor instructions in an intelligent manner. These tools are pseudo-random test generator sequences. This embodiment uses two types internally: one based on a specially developed RTPG and one based on an external tool called VERA (VSG). Both have the possibility of construction around them. Based on valid instructions for one configuration, they generate a series of instructions. These tools can process newly defined instructions from the TIE, and these newly defined instructions are randomly generated for testing. This embodiment includes a monitor and a checker that measure the coverage of design verification.

  The monitor and coverage tool are tools that are moved alongside the regression run. The coverage tool monitors what the diagnostics are doing and the function and logic of the HDL that it is working on. All of this information is gathered through regression runs and later analyzed to get hints about which parts of the logic need further testing. This embodiment uses several functional coverage tools that are configurable. For example, a machine in a specific restricted state does not necessarily include all states depending on the configuration. Thus, for that configuration, the functional coverage tool should not attempt to check these states or transitions. This is accomplished by making the tool configurable through TPP.

  Similarly, there are monitors that check for illegal conditions that occur in HDL simulations. These illegal states can appear as bugs. For example, on a tristate bus, two drivers should not be on at the same time. These monitors are configurable and add or remove checks based on whether specific logic is included for that configuration.

  The co-simulation mechanism connects the HDL to the ISS 126. This co-simulation mechanism is used to check that the processor state is the same in HDL and ISS 126 at the end of the instruction. Furthermore, the co-simulation mechanism is configurable to the extent that it knows what features are included in each configuration and what state is required for comparison. Thus, for example, a register with a special data breakpoint feature is added. This mechanism needs to know to compare this new special register.

  Instruction semantics specified via TIE can be translated into functionally equivalent C functions for use in ISS 126 and for system designers for use in testing and verification. The instruction semantics in the device configuration database 106 are translated into C functions by a tool that creates a parser tree using standard parser tools, and then translated into code that walks the tree and outputs the corresponding representation in C language. The The translation specifies a bit width for all representations and requires a prepass to rewrite the parse tree and simplify some translations. These translation mechanisms are relatively simple compared to other translation mechanisms from HDL to C, or from C to an assembly language compiler, and can be rewritten by those skilled in the art starting with TIE and C language specifications.

  The benchmark application source code 118 is compiled and assembled using the instrument configuration file 100 and a compiler configured using the assembler / disassembler 100 and simulated using the sample data set 124 to generate the software profile 130. Obtaining this software profile 130 is also provided in the user configuration capture routine for feedback to the user.

  The ability to obtain both hardware and software cost / benefit characterizations for any configuration parameter selection opens up new opportunities for further optimization of the system by the designer. In particular, this allows the designer to select the optimal configuration parameters, which optimize the entire system according to some form of advantage. One possible process is based on a greedy strategy by repeatedly selecting or deselecting configuration parameters. At each step, the parameter with the best impact on overall system performance and cost is selected. This step is repeated until no parameter can be changed to improve system performance and cost. Other extensions include looking at a group of configuration parameters at once, or using a more sophisticated search algorithm.

  In addition to obtaining optimal configuration parameter selection, this process can also be used to configure optimal processor expansion. Due to the large number of possibilities in processor expansion, it is important to limit the number of expansion candidates. One technique is to analyze application software and see only instruction extensions that can improve system performance or cost.

  Having covered the operation of the automated processor configuration system according to this embodiment, an example of a system application for a processor microarchitecture configuration will now be described. The first example shows the advantages of the present invention when applied to image compression.

  Motion evaluation is an important component of many image compression algorithms, including MPEG video and H263 conference applications. Video image compression seeks to use the similarity from one frame to the next to reduce the amount of storage 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 (the image immediately before or after the image to be compressed). Compression of image differences between frames is generally bit more efficient than compression of individual images. In video sequences, distinct image features often move from frame to frame, so the closest correspondence between different frames is often not exactly at the same X, Y position, but somewhat offset. If a significant part of the image is moving between frames, it may be necessary to identify and compensate for that motion before calculating the difference. This fact shows that for distinctly different features, the richest display can be achieved by encoding the difference between successive images, including the X and Y offsets in the sub-image used in the calculated difference. It means that it can be achieved. The offset at the position used to calculate the image difference is called the motion vector.

  The most computationally intensive task in this type of image compression is the determination of the most appropriate motion vector for each block. A common distance for selecting a motion vector is to find the vector with the lowest average difference per pixel between each block of the image to be compressed and a set of candidate blocks in the previous image. A candidate block is a set of all blocks near the location of the block to be compressed. The size of the image, the size of the block, and the neighboring sizes all affect the execution 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. The reference image may be one that precedes or follows the subject image in the video sequence. In either case, it is known that the reference image can be used for the decompression system before the subject image is decompressed. Comparison of one block of the compressed image with the candidate block of the reference image will be described below.

For each block in the subject image, a search is performed near the corresponding position in the reference image. Usually, each color component (eg, YUV) of the image is analyzed separately. Sometimes motion estimation is performed only on one component, especially the luminance. The average difference for each pixel is calculated between the subject image and all possible blocks within the search zone of the reference image. The difference is the absolute value of the pixel value magnitude difference. The average is proportional to the sum of the pixel N ² (N is the size of the block) the total of the pair of blocks. The block of the reference image that produces the smallest average pixel difference limits the motion vector for that block of the subject image.

  The following example shows a simple form of motion estimation algorithm that optimizes an algorithm that uses TIE for a small application-specific functional unit. This optimization results in speedups greater than a factor of 10, making processor-based compression feasible for many video applications. It demonstrates the power of a configurable processor that combines the ease of programming in high-level languages with the efficiency of special purpose hardware.

This example uses two matrices, OldB and NewB, to represent the old and new images, respectively. The size of the image is determined by NX and NY. The block size is determined by BLOCKX and BLOCKY. Therefore, the image is composed of NX / BLOCKX × NY / BLOCKY blocks. The search area of one block is determined by SEARCHX and SEARCHY. The best motion vectors and values are stored in VectX, VectY and VectB. The best motion vectors and values calculated by the base (reference) implementation are stored in BaseX, BaseY and BaseB. These values are used to check the vector computed by the implementation using instruction extension. These basic definitions are captured in the following C code segment.

  The motion estimation algorithm is composed of three nested loops. 1. For each source block in the old image. 2. For each target block of the new image in the area surrounding the source block. 3. Calculate the absolute difference between each pixel pair. The complete code for this algorithm is given below.

Reference software implementation

  While the basic implementation is simple, it fails to take advantage of much of the intrinsic parallelism of this block-to-block comparison. The configurable processor architecture provides two main tools to allow a significant speedup of this application.

  First, the instruction set architecture includes a powerful funnel-like shifting primitive to allow rapid extraction of unaligned fields in memory. This allows the inner loop of pixel comparison to efficiently fetch adjacent pixels from memory. This loop can be rewritten to manipulate four pixels (bytes) simultaneously. In particular, for the purposes of this example, it is desirable to define a new instruction to calculate the absolute difference of four pixel pairs at a time. However, before defining this new instruction, it is necessary to re-implement the algorithm so that such an instruction can be used.

  The presence of this instruction allows for improved inner loop pixel difference calculations such that loop unrolling is equally attractive. The C code for the inner loop is rewritten to take advantage of the new absolute difference sum instruction and efficient shifting. The four overlapping block portions of the reference image can be compared in the same loop. SAD (x, y) is a new built-in function corresponding to the added instruction. SRC (x, y) performs the right shift of the connected state of x and y by the shift amount stored in the SAR register.

Fast version of motion estimation using SAD instructions

This implementation uses the following SAD function to emulate the last new instruction:
Total absolute difference of 4 bytes

To debug this new implementation, the following test program is used to compare the motion vector with the values calculated by the new implementation and the base implementation.
Main test

  This simple test program is used throughout the development process. One important convention that must be followed here is that if an error is detected, the main program must return to 0, otherwise it must return to 1.

  The use of TIE allows for rapid specification of new instructions. A configurable processor generator can fully execute these instructions in both hardware implementations and software development tools. Hardware integration results in optimal integration of new functions into the hardware data path. A configurable processor software environment fully supports new instructions in C and C ++ compilers, assemblers, symbolic debuggers, profilers, and accurate cycle instruction set simulators. Rapid regeneration of hardware and software makes special purpose instructions a quick and reliable tool for application acceleration.

This example executes a simple instruction and uses TIE to perform pixel differentiation, absolute value and accumulation in parallel for four pixels. This simple instruction implements eleven basic operations (which may require separate instructions in conventional processes) as one atomic operation. The following is a complete explanation.

This description represents the minimum steps required to define a new instruction. First of all, a new operation code needs to be defined for the instruction. In this case, the new operation code SAD is defined as a sub operation code of CUST0. As described above, CUST0 is predefined as follows.

  It is easily understood that ORST is a top-level operation code, CUST0 is a sub-operation code of ORST, and SAD is a sub-operation code of CUST0. This hierarchical organization of operation codes allows logical grouping and management of operation code spaces. One important thing to remember is that CUST0 (and CUST1) is defined as the operational code space that the user reserves to add new instructions. The user preferably stays within this assigned operational code space to ensure future reusability of the TIE description.

  The second step in this TIE description is to define a new instruction class that includes the new instruction SAD. This is the case when the operand of the SAD instruction is defined. In this case, the SAD includes three register operands, a destination register arr, and source registers ars and art. As mentioned above, arr is defined as a register indexed by the r field of the instruction, and ars and art are defined as registers indexed by the s and t fields of the instruction.

  The last block in this description gives the formal semantic definition for the SAD instruction. This description uses a subset of Verilog HDL to illustrate combinatorial logic. This block defines exactly how the ISS simulates SAD instructions and how additional circuitry is integrated and added to configurable processor hardware to support new instructions. is there.

  The TIE description is then debugged and verified using the tools described above. After verifying the accuracy of the TIE description, the next step is to estimate the impact of the new instruction on hardware size and performance. As described above, this can be done using, for example, Design Compiler®. Once Design Compiler® is complete, the user can see a report of detailed area and speed reports.

  It is time to configure and assemble a configurable processor that supports the new SAD instruction after ensuring that the TIE description is correct and efficient. This is done using the GUI as described above.

  Next, the motion estimation code is compiled into code for a configurable processor, which processor sets an instruction set to verify the accuracy of the program and, more importantly, to measure its performance. Use the simulator. This is done in three steps: Run the test program using the simulator, run only the base implementation to get the instruction count, and run only the new implementation to get the instruction count .

The following is the simulation output of the second step.

The following is the simulation output of the last step.

  It can be seen from the two reports that a speedup of about 4 times occurred. Note that the configurable processor instruction set simulator can provide many other useful information.

  After verifying the accuracy and performance of the program, the next step is to run the test program using the Verilog simulator as described above. The person skilled in the art will be able to collect details of this process from an appendix C makefile (the associated file is also shown in appendix C). The purpose of this simulation is to further confirm the accuracy of the new implementation and, more importantly, to make this test program part of the regression test for this configured processor.

  Finally, the processor logic can be integrated using, for example, Design Compiler® and placed and routed using, for example, Apollo®.

  This example has taken a simplified illustration of video compression and motion estimation for clarity and simplicity of explanation. In practice, standard compression algorithms have many additional nuances. For example, MPEG2 typically performs motion estimation and performs correction at sub-pixel resolution. Two adjacent columns or columns of pixels can be averaged to produce a set of pixels that are interpolated for an intermediate virtual location between the two adjacent columns or rows. Configurable processor user-defined instructions are also useful here because parallel pixel averaging instructions are easily implemented in three or four lines of TIE code. Averaging between pixels in a column uses efficient array operations of the processor's standard instruction set.

  Thus, incorporating a simple absolute difference sum instruction adds several hundred gates, but improves motion estimation performance by more than 10 factors. This acceleration represents a significant improvement in final system cost and power efficiency. In addition, the seamless expansion of software development tools to include new motion estimation instructions allows for rapid prototyping and performance analysis and the release of complete software application solutions. The solution of the present invention makes application-specific processor configurations simple, reliable and complete, and provides dramatic enhancements in the cost, performance, functionality and power efficiency of the final system product.

  As an example focusing on the addition of functional hardware units, consider the basic configuration shown in FIG. This configuration includes a processor control function, program counter (PC), branch selection, instruction memory or cache and instruction decoder, main register file, bypass multiplexer, pipeline register, ALU, address generator and cache data memory. Including a basic integer data path.

  The HDL is written subject to the presence of the multiplier logic and the “multiplier” parameter is set, and a multiplier device is added as a new pipeline stage as shown in FIG. Changes to special handling may be necessary if it should be supported). Of course, instructions for using the multiplier are preferably added to the new unit.

  As a second example, a complete coprocessor may be added to the basic configuration shown in FIG. 8 for a digital signal processor such as an integration / accumulation unit. This is for register bypass multiplexers for register source and destination decoding from extended instructions, adding appropriate pipeline delays to control signals, register destination logic expansion, and movement from cumulative registers. It entails changes in processor control, such as the addition of control and the addition of a decoding control signal for accumulation / accumulation operations, including the inclusion of accumulation / accumulation units as possible sources for instruction results. In addition, it requires the addition of an accumulation / accumulation unit with additional accumulator registers, an accumulation / accumulation array, and a source select multiplexer for the main register source. Furthermore, the addition of a coprocessor necessitates an extension of the register bypass multiplexer from the accumulation register to incorporate the source from the accumulation register and an extension of the load / alignment multiplexer to incorporate the source from the multiplier result. Necessary. Again, the system preferably adds instructions to use the new functional unit with the actual hardware.

  Another option that is particularly useful in connection with digital signal processors is the floating point unit. For example, such a functional unit that puts the IEEE 754 single precision floating point arithmetic standard into practical use may be added along with instructions for accessing it. The floating point unit may be used in digital signal processing applications such as audio compression / decompression.

As another example of system flexibility, consider the 4 kB memory interface shown in FIG. Using the configurability of the present invention, the coprocessor registers and data path may be wider or narrower than the main integer register file and data path, and the local memory width is the processor or coprocessor width with the widest memory width. It may vary to be equal (memory addressing for reads and writes is adjusted accordingly). For example, FIG. 10 supports 32-bit load operations and storage for a processor coprocessor combination addressing the same array, but the coprocessor supports 128-bit load operations and storage. Shows the local memory system. This can be put into practical use using a TPP code.

Where SBytes is the total memory size accessed as byte B1 byte at byte address A1 using data bus D1 under control of write signal W1 or using corresponding parameters B2, A2, D2, and W2. . Only a set of signals defined by Select is active in a given cycle. The TPP code puts the memory into practical use as a collection of memory banks. The width of each bank is given by the minimum access width, and the number of banks is given by the ratio of the maximum and minimum access widths. Loop A is used to illustrate each memory bank and its associated write signal, namely write enable and write data. The second loop is used to collect data read from all banks on one bus.

  FIG. 11 shows an example in which a user-limited command is included in the basic device configuration. As shown in this figure, a simple instruction can be added to the processor pipeline having the same timing and interface as those of the ALU. Instructions added in this way should not cause any outages or exceptions, should not contain any state, use only two normal source register values and an instruction word as input, and one output value Only have to generate. However, such a restriction is not necessary if the TIE language has provisions for specifying processor states.

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

Of particular interest in another aspect of the invention is the instruction execution unit 96 defined by the designer. This is because it is here that the TIE limited instructions containing these modified processor states are decoded and executed. In this aspect of the invention, a number of building blocks can be added to the language to declare additional processor states that can be read and written by new instructions. These “state” statements are used to declare the addition of processor state. The declaration begins with a keyword state. The next section of the state statement describes the size and number of bits and states, and how the state bits are indexed. Subsequent sections are state names used to identify states in other description sections. The last section of the “state” statement is a list of attributes associated with that state. For example,

Defines three new processor states, DATA, KEYC and KEYD. The state DATA is 64 bits wide and the bits are indexed from 63 to 0. KEYC and KEYD are both 28-bit states. DATA has a coprocessor number attribute cpn indicating to which coprocessor the data DATA belongs.

  The attribute “autopack” indicates that the state DATA is automatically placed in a register in the user register file so that the value of DATA can be read and written by the software tool.

The user_register section is defined to show the state mapping for the registers in the user register file. One user_register section begins with the keyword user_register, followed by a number indicating the register number, and ends with an expression indicating the status bits to be placed on the register. For example,

Specifies that the lower word of DATA is mapped to the first user register file and the upper word is mapped to the second user register file. The next two user register file entries are used to hold KEYC and KEYD values. Obviously, the state information used in this section must match that of the state section. Here, consistency can be automatically checked by the computer program.

  In another embodiment of the present invention, such assignment of status bits to user register file entries is automatically derived using a bin packing algorithm. In yet another embodiment, a combination of manual and automatic assignment can be used, for example, to ensure upward compatibility.

The instruction field statement field is used to improve the readability of the TIE code. Fields are grouped together and are a subset or concatenation of other fields that are referenced by one name. The complete bit set in one instruction is the highest level superset field inst, which can be divided into smaller fields. For example,

Defines two 4-bit fields, x and y, as subfields (bits 8-11, 12-15, respectively) of the highest level field inst, and defines an 8-bit field xy as a concatenation of the x and y fields .

The statement opcode defines an operation code for encoding a special field. An operand used by an operation code defined in this way, for example an instruction field for specifying a register or immediate constant, must first be defined in a field statement and then in an operand statement.
For example,

Defines two new operation codes, acs and adsel, based on the previously defined operation code CUST0 (4'b000 indicates a 4-bit long binary constant 0000). The preferred core ISA TIE specification has the following statements as its basic definition:

Thus, the definitions of acs and adsel cause the TIE compiler to generate instruction decoding logic represented by:

The instruction operand statement operand specifies a register and an immediate constant. However, before defining a field as an operand, it must 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 the value of the constant can be retrieved from a previously defined constant table defined as follows: For example, to encode an immediate operand, the TIE code

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. The last part of the operand statement actually describes the circuitry used to perform the calculations in a subset of Verilog® HDL to describe the combinational circuit, as will be apparent to those skilled in the art. is doing.

  Here, the wire statement defines a set of logical lines named t that are 32 bits wide. The first assign statement after the wire statement specifies that the logic signal driving the logic line is an offsets4 constant shifted to the right, and the second assign statement contains the lower 18 bits of t in the offset field. It is clearly stated that it will be placed. The first assign statement directly specifies the value of the offsets4 operand as a concatenation of offset, 14 repetitions of its sign bit (bit 17), and the subsequent 2-bit left shift.

TIE code for one constant table operand

Uses a table statement to limit the array prime of the constants (the number following the table name is the number of elements in the table) and uses its operand prime_s as an index into the table prime. Encode (note the use of Verilog® statements when defining indexing).

The instruction class statement icclass associates an operation code with an operand in a common format. All instructions defined in the iclass statement have the same format and operand usage. Before defining an instruction class, its components must first be defined as fields, then as operational codes and operands. For example, when building on the code used in the previous example that defines the operation codes acs and adsel, additional statements

Uses an operand statement to define the three register operands art, ars, arr (again, note the use of Verilog® statements in this definition). Next, the iclass statement

Specifies that the operands adsel and acs belong to a common class of the instruction viterbi, which takes two register operands art and ars as inputs and writes the output to the register operand arr.

In the present invention, the instruction class statement “iclass” is modified to allow specification of instruction state access information. It begins with the keyword “iclass”, followed by the instruction class name, followed by a list of operation codes belonging to that instruction class and a list of operand access information, ending with a newly defined list for state access information. For example,

Defines several instruction classes and how various new instructions access their state. The keywords “in”, “out” and “inout” are used to indicate that an instruction in iclas reads, writes, or modifies (reads and writes) its state. In this example, state “DATA” is read by instruction “LDDATA”, states “KEYC” and “KEYD” are written by instruction “STKEY”, and “KEYC”, “KEYD”, and “DATA” are instructions “DES”. Corrected by.

The instruction semantic statement semantic describes the operation of one or more instructions using the same subset of Verilog® used to encode the operands. By defining multiple instructions in one semantic statement, some common representations can be shared and the hardware implementation can be made more efficient. Variables allowed in a semantic statement are operands for operation codes defined in the operation code list of the statement, and are single-bit variables for each operation code specified in the operation code list. This variable has the same name as the operation code, and evaluates to 1 when the operation code is detected. It is used in the calculation section (Verilog® subset section) to indicate the presence of the corresponding instruction.

The first section of the code defines an operation code for a new instruction called BYTESWAP.

Here, the new operation code BYTESWAP is defined as a sub-operation code of CUST0. From the Xtensa (registered trademark) Instruction Set Architecture Reference Manual, which will be described in detail below, CUST0 is defined as follows.

However, it can be seen that op0 and op2 are fields in the instruction. Operation codes are typically organized hierarchically. Here, ORST is a top-level operation code, CUST0 is a sub-operation code of ORST, and BYTESWAP is a sub-operation code of CUST0. This hierarchical structure of operation codes allows logical grouping and management of operation code spaces.

The second declaration declares additional processor states required by the BYTESWAP instruction.

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

The Xtensa® ISA provides two instructions, RSR and WSR, to save and restore special system registers. Similarly, it provides two other instructions, RUR and WUR (detailed below), to save and restore state declared in the TIE. In order to save and restore the state declared in the TIE, a mapping of that state must be specified for entries in the user register file that can be accessed by the RUR and WUR instructions. The following section of the code above specifies this mapping,

The following instruction will save the value of COUNT for a2 and the value of SWAP for a5.

This mechanism is actually used in the test program to verify the contents of the state. In C, the two instructions will appear as follows:

The nested section in the TIE description is a definition of a new instruction class including a new instruction BYTESWAP.

  However, iclas is a keyword and bs is the name of iclas. The next section creates a list of instructions in this instruction class (BYTESWAP). The clause after tan specifies the operands (in this case, the input operand ars and the output operand arr) used by the instructions in this class. The last clause in the iclas definition specifies the state accessed by instructions in this class (in this case the instruction will read state SWAP and read and write state COUNT).

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

  This description uses a subset for Verilog HDL to illustrate combinatorial logic. The instruction set simulator defines exactly how BYTESWAP instructions are simulated and how additional circuitry is synthesized and added to the Xtensa processor hardware to support new instructions Is this block.

In the present invention, when the user-defined state is put into practical use, the declared state can be used as well as other variables for accessing information stored in the state. A state identifier appearing on the right hand side of the expression indicates a read from that state. Writing to the state is done by assigning a value or expression to the state identifier. For example, the following semantic code segment shows how a state is read and written by an instruction.

  For the purpose of explaining examples of instructions that can be implemented in a configurable processor as instructions available through the selection of core instructions and configuration options, Tensilica, Inc. Xtensa®. ) Instruction Set Architecture (ISA) reference manual, revision 1.0, is incorporated herein by reference. Furthermore, the Tensile Instruction Extension Language (TIE) Reference Manual, Revised 1.3, is also here to show examples of TIE language instructions that can be used to put such user-defined instructions into practical use. Incorporated by reference.

  From the TIE description, for example, a program similar to that shown in Appendix D can be used to generate new hardware that executes instructions. Appendix E shows the code for the header file required to support the new instruction as a built-in function.

The configuration specification can be used to automatically generate:
The instruction decode logic of the processor 60;
An illegal instruction detection logic for the processor 60;
· Parts for specific ISAs of assemblers;
• Specific ISA support routines for the compiler;
A specific ISA part of the deassembler (used by the debugger); and a specific ISA part of the simulator.

  FIG. 16 is a diagram showing how to generate a specific ISA portion of these software tools. From the TIE description file 400 created by the user, the TIE parser program 410 generates C code for several programs, and for each of the user-defined instructions and status information, each of the programs is Create a file that is accessed by one or more. For example, the program tie2gcc420 is xtensa-tie. Generate a C header file 470 called h, which contains the built-in function definition for the new instruction. The program tie2isa 430 generates a dynamic connection library (DLL) 480, which contains information about the user-defined instruction format (in the Wilson et al application discussed below, this is effectively the encoding / decoding DLL discussed herein. Is a combination). The program tie2iss 440 generates a performance modeling routine and creates a DLL 490 that includes instruction semantics, which is used by the host compiler to create a simulator DLL that is used by the simulator, as discussed in the Wilson et al. Application. . The program tie2ver 450 creates a description 500 necessary for the user-defined instructions in an appropriate hardware description language. Finally, program tie2xtos 460 creates save / restore code 510 for use by the RUR and WUR instructions.

  An accurate description of the instructions and how they access the state makes it possible to create efficient logic that can be plugged into an existing high performance microprocessor design. The method described in connection with this embodiment of the invention specifically processes these new instructions, which read from and write to one or more status registers. In particular, this embodiment shows how to derive the hardware logic for the status register in context, and as a technique for achieving high performance, all of the microprocessor implementation style that uses the pipeline method. class.

  In pipelined implementations such as the one shown in FIG. 17, the status registers typically overlap many times, and each implementation represents a state value at a particular pipeline stage. In this embodiment, one state is moved to multiple register copies that are consistent with the underlying core processor implementation. Additional bypass and forward logic is also generated in a manner that is consistent with the underlying core processor implementation. For example, to target a core processor implementation consisting of three execution stages, the present embodiment will move one state to three registers connected as shown in FIG. In this implementation, each register 610-630 represents a state value in one of the three pipeline stages. ctrl-1, ctrl-2, and ctrl-3 are control signals used to enable data latching in the corresponding flip-flops 610-630.

  Additional logic and control signals are required to operate multiple copies of the status register consistent with the underlying processor implementation. “With no contradiction” means that the state should behave exactly like the rest of the processor under interrupts, exceptions, or pipeline outages. Typically, a given processor implementation limits certain signals that represent various pipeline states. Such signals are necessary for proper operation of pipelined registers.

  In a typical pipelined implementation, the execution unit consists of a number of pipeline stages. The calculation of one instruction is performed in a number of stages in this pipeline. The instruction stream flows through the pipeline in a sequence that is directed by the control logic. There may be n instructions executed in the pipeline at a given time, where n is the number of stages. In a superscalar processor that can also be implemented using the present invention, the number of instructions in the pipeline may be n · w, where w is the issue width of the processor.

  The role of the control logic is to ensure that interference between instructions is scattered according to the dependency between instructions. When one instruction uses data calculated by the initial instruction, special hardware is required to advance the data to a subsequent instruction without causing the pipeline to stop functioning. If an interrupt occurs, it is necessary to delete all instructions in the pipeline and re-execute later. If the instruction cannot be executed because the input data or computing hardware required by the instruction is not available, the instruction must be disabled. One cost effective way to stall an instruction is to delete the instruction in its first execution stage and re-execute the instruction in the next cycle. The result of this technique is creating invalid stages (bubbles) in the pipeline. This bubble flows through the pipeline along with other instructions. At the end of the pipeline where the instruction is executed, the bubble is discarded.

  Using the above three-stage pipeline example, a typical implementation of such a processor state requires the additional logic and connections shown in FIG.

  Under normal conditions, the value calculated in one stage is immediately determined without waiting for the value to reach the end of the pipeline to reduce the number of pipeline outages introduced by data dependencies. It will be advanced to the next command. This is accomplished by sending the output of the first flip-flop 610 directly to the semantic block so that it can be used immediately by the next instruction. In order to handle abnormal conditions such as interrupts and special cases, the implementation requires the following control signals: Kill_1, Kill_all, Valid_3.

  The signal “Kill_1” indicates that the instruction currently in the first pipeline stage 110 has to be deleted, for example because it does not have the data needed for revenue. Once the command is deleted, it will be tried again in the next cycle. The signal “Kill_all” indicates that all instructions currently in the first pipeline stage 110 must be deleted, for example because their previous instruction caused a special case or an interrupt occurred. ing. The signal “Valid_3” indicates whether the instruction currently in the last stage 630 is valid. Such a condition is often the result of cutting the instructions in the first pipeline stage 610 and causing bubbles in the pipeline (invalid instructions). “Valid — 3” simply indicates whether the instruction in the third pipeline stage is valid or bubbled. Obviously, only valid instructions should be latched.

FIG. 20 shows the additional logic and connections necessary to put the status register into practical use. Furthermore, how the control logic to drive the signals “ctrl-1”, “ctrl-2”, and “ctrl-3” can be constructed so that this state register implementation meets the above requirements. Show. The following is a sample HDL code that is automatically generated to put the status register shown in FIG. 19 into practical use.

  Using the pipelined state register model, when a semantic block specifies a state as its input, the current state value of the state is sent as an input variable to the semantic block. If the semantic block has logic to generate a new value for a state, an output signal is created. This output signal is used as the next status input to the pipelined status register.

  This embodiment allows multiple semantic description blocks, each of which describes the behavior for multiple instructions. Under this unlimited description style, only one subset of semantic blocks can produce the next state output for a given state. In addition, a given semantic block can produce the next state output conditionally depending on which instruction it is executing at a given time. As a result, additional hardware logic is required to combine the next state outputs from all semantic blocks to form an input to the pipelined state register. In this embodiment of the invention, one signal is automatically derived for each semantic block that indicates whether this block has created a new value for that state. In another embodiment, such signals can be left as specified by the designer.

  FIG. 20 shows how the next state outputs of the states from several semantic blocks s1 to sn are combined and how to properly select one for input to the state register. In this figure, op1_1 and op1_2 are operation code signals for the first semantic block, and op2_1 and op2_2 are operation code signals for the second semantic block. The next status output of semantic block i is si (if there are multiple status registers, there are multiple next status outputs for that block). A signal indicating that semantic block i has created one new value for the state is si_we. The signal s_we indicates whether any semantic block produces one new value for that state and is used as a write enable signal as an input to the pipelined state register.

  One way to give more structured description by grouping related instructions into one block, even if the expressive power of many semantic blocks is lower than that of one semantic block I will provide a. Multiple semantic blocks can lead to a simpler analysis of instruction effects because of the more limited range over which the instructions are executed. On the other hand, there are often many reasons for one semantic block to account for the operation of many instructions. Most often, it is because the hardware implementation of these instructions share common logic. Explaining a large number of instructions in one semantic block usually leads to a more efficient hardware design hardware design.

For interrupts and exceptions, it is necessary for the software to restore the state value to and load from the data memory. Such a restore and load instruction can be automatically generated based on the new state and the formal description of the new instruction. In this embodiment of the invention, the logic for the restore load instruction is automatically generated as two semantic blocks, which can then be transferred to the actual hardware iteratively, just like any other block. . For example, from the following state declaration:

The following semantic blocks can be generated to read the values of “DATA”, “KEYC”, and “KEYD” into the general purpose registers.

  FIG. 21 shows a block diagram of logic corresponding to this kind of semantic logic. The input signal “st” is compared with various constants to form various selection signals, which are used to select a bit from the status register in a manner consistent with the user_register specification. Using the previous state declaration, place bit 32 of DATA into bit 0 of the second user register. Therefore, in this figure, the second input of the MUX should be connected to the 32nd bit in the DATA state.

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

  FIG. 22 shows the logic for the jth bit of state S when placed in the kth bit of the ith user register. If the user_register number “st” in the WUR instruction is “i”, the k th bit of “ars” is loaded into the S [j] register, otherwise the original of S [j] The value is recirculated. Furthermore, if no bit of state S is reloaded, signal S_we is enabled.

TIE's user_register declaration reads this state separately from the TIE instruction, specifying a mapping from the additional processor state defined by the state declaration to the identifiers used by these RUR and WUR instructions Write.
Appendix F shows the code that generates the RUR and WUR instructions.

The main purpose of RUR and WUR is for task switching. In a multitasking environment, a number of software tasks share a processor according to some scheduling algorithm. If active, the task state is in the processor register. When the scheduling algorithm decides to switch to another task, the state held in the processor register is saved in memory and the state of the other task is loaded from memory to the processor register. The Xtensa instruction set architecture (ISA) includes RSR and WSR instructions for reading and writing states defined by the ISA. For example, the following code is part of the task “Save to Memory”:

The following code is part of the task “Restore from Memory”.

However, SAR, LCOUNT, LBEG, and LEND are the processor status register part of the core Xtensa (registered trademark) ISA, and ACCLO, ACCHI, MR_0, MR_1, MR_2, and MR_3 are part of the MAC16 Xtensa (registered trademark) ISA option. is there. (Registers are saved and restored in pairs to avoid pipeline interlocks.)
When a designer defines a new state in TIE, the task must be switched in the same manner as the above state. One possibility is that the designer simply proceeds to edit the task switch code (part of which is described above) and then adds RUR / S32I and L32I / WUR instructions similar to the above code. Let's go. However, a configurable processor is most effective when the software is automatically generated and correct by configuration. Thus, the present invention includes a mechanism for automatically increasing task switch code. The following top line is added to the save task.

The following line is added to the restore task.

Finally, the task state area in memory must have additional space allocated for user register storage, and the offset of this space from the base of the task save pointer is defined as the assembler constant UEXCUREG. Is done. This save area is predefined by the following code.

This is changed as follows.

  This code depends on the presence of the tpp variable @user_registers along with a list of user register numbers. This is simply a list made from the first argument of every user_register statement.

  In some more complex microprocessor implementations, one state can be calculated in different pipeline states. Handling this requires several extensions (although simple) to the process described here. First, the specification description language needs to be extended to allow semantic blocks to be associated with pipeline stages. This can be accomplished in one of several ways. In one embodiment, the associated pipeline stage can be explicitly specified in each semantic block. In another embodiment, a pipeline stage range may be specified for each semantic block. In yet another embodiment, the pipeline stage for a given semantic block can be automatically derived depending on the required computational delay.

  The second task in supporting state generation at different pipeline stages is to handle interrupts and identification / outages. This usually involves the addition of appropriate bypass and forward logic under the control of pipeline control signals. In one embodiment, a usage diagram can be generated to show the relationship between when a state is generated and when the state is used. Based on application analysis, appropriate forward logic can be put into practical use to handle common situations, generating interlock logic and decommissioning pipelines for cases that are not handled by forwarding logic. it can.

  The method of modifying the base processor's instruction issue logic depends on the algorithm used by the base processor. However, in general, the instruction issue logic for most processors is that the instruction is whether it is a single issue, a super scalar, a single cycle instruction, or a multi-cycle instruction. Rely only on being tested to issue the following signals: 1. 1. a signal that indicates for each processor state component whether the instruction uses that state as a source; 2. a signal indicating for each processor state component whether the instruction uses that state as a destination; and A signal that indicates for each functional unit whether the instruction uses a functional unit.

  These signals are used to perform issue and cross issue checks on the pipeline and update the pipeline state in the pipeline dependent issue logic. The TIE contains all the necessary information to increase the signal and its expression for new instructions.

  First of all, each TIE state declaration causes a new signal to be generated for instruction issue logic. an instruction in which each in or inout operand or state represented in the third or fourth argument for the iclass declaration is represented in the second argument for the first set of expressions for the specified processor state component An instruction decode signal for is added.

  Second, each out or inout operand or state represented in the third or fourth argument for the iclass declaration is in the second argument for the second set of expressions for the specified processor state component. An instruction decode signal is added to the indicated instruction.

  Third, the logic created from each TIE semantic block represents a new functional unit, a new unit signal is created, and the decode signal for the TIE instruction specified for the semantic block is ORed together to form a third set. Form the formula

  When an instruction is issued, the pipeline status must be updated for future issue decisions. Again, the method of modifying the instruction issue logic of the base processor depends on the algorithm used by the base processor. However, some general considerations are still possible. The pipeline status must return the following status to the issue logic. 4). 4. For each issued instruction destination, a signal indicating when the result is available for bypass; A signal that indicates for each functional unit that the functional unit is ready for execution by another instruction.

The embodiment described here is a single issue processor, where the instructions defined by the designer are limited to a single cycle of logic computation. In this case, the above is considerably simplified. The functional unit does not need to do a check or cross issue check, and no single cycle instruction can pipe ready the processor state component for the next instruction. Thus, the issuing formula is as follows.

  Also in this case, the src [i] pipeready signal is not affected by the additional instruction, and src [i] use is the first set of expressions that are described and modified as described above. In the present embodiment, the fourth and fifth sets of signals are not required. For alternative embodiments that are multi-cycle and multi-issue, the TIE specification description will be augmented with a latency specification description to give the number of cycles for each instruction to send computations in the pipeline.

  A fourth set of signals will be generated at each semantic block pipe stage by ORing the instruction decode signals together for each instruction completed at that stage according to the specification.

By default, the generated logic will be fully pipelined and the TIE generating functional unit will always be ready one cycle after accepting one instruction. In this case, a fifth set of signals for the TIE semantic block is always asserted. If the logic in the semantic block needs to be reused over many cycles, the further specification will specify how many cycles the functional unit is used by such an instruction. In this case, a fifth set of signals will be generated at each semantic block pipe stage by ORing the instruction decode signals together for each instruction ending with the cycle count specified at that stage.
Alternatively, in yet another embodiment, it may be left as an extension to the TIE so that the designer specifies a result ready signal and a functional unit ready signal.

  An example of code processed according to this embodiment is shown in the appendix. For brevity, they will not be described in detail, but will be readily understood by one of ordinary skill in the art upon reviewing the above reference manual. Appendix G is an example of instruction execution using the TIE language, and Appendix H shows what the TIE compiler generates for a compiler that uses these codes. Similarly, Annex I shows what the TIE compiler generates for the simulator, and Annex J shows what the TIE compiler generates for the macro that expands the TIE instruction in the user application. Letter K shows what the TIE compiler generates to simulate TIE instructions in native mode, and Annex L shows what the TIE compiler generates as a Verilog HDL description for additional hardware Yes. Appendix M also shows what the TIE compiler generates as a design compiler script to optimize the above Verilog HDL description and estimate the effect of TIE instruction area and speed on the overall CPU size and performance. Yes.

  As described above, to begin the processor configuration procedure, the user begins by selecting a base processor configuration via the GUI described above. As part of the process, the software deployment system 30 is assembled and sent to the user as shown in FIG. Software deployment system 30 includes four main components, shown in detail in FIG. 6, relating to another aspect of the present invention: compiler 108, assembler 110, instruction set simulator 112, and debugger 130.

  As is known to those skilled in the art, the compiler converts user applications written in a high-level programming language such as C or C ++ into an application specific assembly language. High level programming languages such as C or C ++ are designed to allow application writers to describe their applications in a form that is easy to describe accurately. These are not languages understood by the processor. The application writer does not necessarily have to worry about the special features of the processor used. For many different types of processors, typically the same C or C ++ program can be used with little modification.

  The compiler translates C or C ++ programs into assembly language. The assembly language is closer to the machine language and is directly supported by the processor. Different types of processors will have their own assembly language. Each assembly instruction often represents one machine instruction, but they need not be the same. Assembly instructions are designed to be human readable character strings. Each instruction and operand is a meaningful name or mnemonic that allows a human to read the assembly instructions and easily understand what operations are being performed by the machine. The assembler translates from assembly language to machine language. Each assembly instruction string is efficiently encoded into one or more machine instructions by the assembler, and the machine instructions can be executed directly and efficiently by the processor.

  Machine code can be executed directly on the processor, but the physical processor is not always immediately available. Assembling the physical processor is a time consuming and expensive process. When selecting potential processor configurations, the user cannot assemble a physical processor for each potential selection. Instead, the user is provided with a software program called a simulator. A simulator, ie, a program executed on a general-purpose computer, can simulate the effect of executing a user application on a processor configured by the user. The simulator can mimic the semantics of the simulated processor and can tell the user how fast the actual processor can execute the user's application.

  A debugger is a tool that allows users to find problems interactively with software. The debugger allows the user to execute the program interactively. The user can stop the execution of the program at any time and view the C source code or resulting assembly code or machine code. The user can also examine or modify any or all values of variables or hardware registers at breakpoints. The user can then continue execution, perhaps one statement at a time, perhaps one machine instruction at a time, to perhaps one breakpoint selected by the new user.

  All four components 108, 110, 112, and 130 need to know user-defined instructions 750 (see FIG. 3), and simulator 112 and debugger 130 are additionally user-defined states 752. Must know. The system allows the user access to user-defined instructions 750 via intrinsics added to the user's C and C ++ applications. Compiler 108 must translate intrinsic calls into assembly language instructions 738 for user-defined instructions 750. Whenever written by the user or translated by the compiler 108, the assembler 110 must take new assembly language instructions 738 and encode them into machine instructions 740 corresponding to the user-defined instructions 750. Simulator 112 must decode user-defined machine instructions 740. The simulator 112 must model the semantics of the instruction and model the performance of the instruction on the configured processor. The simulator 112 must model user defined state values and performance implications. The debugger 130 must allow the user to print assembly language instructions 738 that include user-defined instructions 750. The debugger 130 must also allow the user to examine and correct the state values defined by the user. In this aspect of the invention, the user calls the tool, TIE compiler 702, to process the currently possible user-defined enhancement 736. The TIE compiler 702 is different from the compiler 708 that translates the user application into the assembly language 738. The TIE compiler 702 enables the base software system 30 (compiler 708, assembly 710, simulator 712, and debugger 730) that has already been assembled to assemble components that allow the new user-defined enhancement 736 to be used. Each element of the software system 30 uses a somewhat different set of components.

  FIG. 24 is a diagram showing how the specific TIE portion of these software tools is generated. From the user-defined extension file 736, the TIE compiler 702 generates C code for several programs, each of which is one or more software deployment tools for information about user-defined instructions and states. Create a file to be accessed. For example, the program tie2gcc800 is xtensa-tie. Generate a C header file 842 (detailed below) called h, which contains the built-in function definition for the new instruction. The program tie2isa 810 generates a dynamic connection library (DLL) 844/848, which contains information about the instruction format defined by the user (combination of encode DLL 844 and decode DLL 848 detailed below). The program tie2iss 840 generates C code 870 for performance modeling and instruction semantics, which is used by the host compiler 846, as described below, to create a simulator DLL 849 that is used by the simulator 712 as detailed below. . The program tie2ver 850 creates a description 850 necessary for a user-defined instruction in an appropriate hardware description language. Finally, the program tie2xtos 860 creates a save / restore code 810 for saving / restoring a user-defined state for context switching. Additional information about user-defined implementations can be found in the aforementioned Wang et al application.

Compiler 708
In this embodiment, compiler 708 translates intrinsic calls in the user's application into assembly language instructions 738 for user-defined enhancement 736. Compiler 708 performs this mechanism on top of macro and inline assembly mechanisms found in standard compilers such as the GNU compiler. For more information on these mechanisms, see GNU C and C ++ Compiler User Guide, EGCS version 1.0.3.

Consider a user who wants to create a new instruction foo that operates on two registers and returns the result to a third register. The user places an instruction description in a user-defined instruction file 750 in a special directory and calls the TIE compiler 702. The TIE compiler 702 is an xtensa-tie. Create a file with a standard name such as h. This file contains the following definitions for foo:

When the user invokes the compiler 708 in the application, the user tells the compiler 708 the name of the directory with the user-defined enhancement 736 via command line options or via environment variables. The directory is xtensa-tie. h file 742 is also included. The compiler 708 creates a file xtensa-tie.com in the user's C or C ++ application program that is edited as if the user had written the foo definition. h is automatically included. The user includes an intrinsic call in the instruction foo in the user application. Because of this included definition, compiler 708 treats these intrinsic calls as calls to the included definition. Based on the standard macro mechanism provided by compiler 708, compiler 708 handles calls to that macro foo as if the user wrote assembly language statement 738 directly rather than a macro call. That is, based on a standard inline assembly mechanism, the compiler 708 translates the call into a single assembly instruction foo. For example, a user may have a function that includes a call to intrinsic foo.

The compiler uses intrinsic foo defined by the user to translate the function into the following assembly language subroutines.

  If the user creates a new set of user-defined enhancements 736, there is no need to rebuild a new compiler. The TIE compiler 702 simply sends the file xtensa-tie. h742 is created and automatically included in the user's application by the pre-built compiler 78.

Assembler 710
In this embodiment, the assembler 710 uses the encode library 744 to encode the assembly instruction 750. The interface to this library 744 includes the following functions:
・ Translate the simplified memory string of operation code into internal operation code representation;
Providing a bit pattern to be generated for each operation code for the operation code field in machine instruction 740; and, encoding an operand value for each instruction operand and converting the encoded operand bit pattern to machine instruction 740. Insert into the operand field.

  As an example, consider the previous example of a user function that calls intrinsic foo. The assembler takes the “foo a2, a2, a3” instruction and converts it to a machine instruction represented by the hexadecimal number 0x62230. In this case, both the upper 6 and the lower 0 represent operation codes 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. The table is easily generated by the TIE compiler 702, but its expressive ability is limited. For example, when more flexibility is required, such as when representing an operand encoding function, the TIE compiler 702 can generate arbitrary C code to be included in the library 744.

Consider again the example of “foo a2, a2, a3”. All register fields are simply encoded with register numbers. The TIE compiler 702 creates the following function that checks against a legal register value and returns that register number if the value is legal.

If all encoding is simple, an encoding function may not be necessary. One table will suffice. However, the user is allowed to choose a more complex encoding. The following encoding described in the TIE language encodes all operands with a number that is the value of the operand divided by 1024. Such encoding is useful for densely encoding values that need to be multiples of 1024.

The TIE compiler converts the operand coding description into the following C function.

  One table cannot be used for such encoding because the range of possible values for that operand is very large. One table will have to be very large.

In the embodiment of the encoding library 744, one table arranges the operation code simplified storage character string for the internal operation code display. For efficiency, this table may be categorized, or it may be a hash table or other data structure that allows an efficient search. Another table places each operation code in the machine instruction template and its operation code field is initialized to the appropriate bit pattern for that operation code. Operation codes with the same operand field and operand encoding are grouped together. For each operation code in one of these groups, the library has a function to encode the operand values into a bit pattern and another function to insert these bits into the appropriate field in the machine instruction. Including. A separate internal table places each instruction operand for these functions. Result register number is bit of instruction 12. . Consider the example encoded in 15. The TIE compiler 702 generates the following function, which is bit 12. . The value (number) of the result register is set to 15.

  In order to be able to change user defined instructions without rebuilding the assembler 710, the encoding library 744 is implemented as a dynamically connected library (DLL). DLL is a standard method that allows a program to dynamically extend its functionality. Although details about DLL processing vary for different host operating systems, the basic concept is the same. The DLL is dynamically loaded into the running program as an extension of the program code. The runtime linker determines symbolic relationships between the DLL and the main program and between the DLL and other already loaded DLLs. In the case of an encoding library or DLL 744, only a small portion of the code is statically bound to the assembler 710. This code loads the DLL, combines the existing encoded information for the pre-assembled instruction set 746 (which may be loaded from another DLL) with the information in the DLL, and the interface described above Responsible for making the information accessible through functions.

  When the user creates a new enhancement 736, the user calls the TIE compiler 702 for the description of the enhancement 736. The TIE compiler 702 generates C code that defines an internal table and a function that puts the encoded DLL 744 into practical use. The TIE compiler 702 then invokes the host system compiler 746 (which is not the processor being configured, but rather edits the code to be executed on the host) to create the encoded DLL 144 for the user-defined instruction 750. To do. The user calls a pre-assembled assembler 710 with an application with a flag or environment variable that points to the directory containing the user-defined enhancement 736. The preassembled assembler 710 dynamically opens the DLL 744 in that directory. For each assembly instruction, the preassembled assembler 710 uses the encode DLL 744 to look up the operation code concise memory, find the bit pattern for the operation code field in the machine instruction, and encode each instruction operand.

For example, if assembler 710 refers to the TIE instruction “foo a2, a2, a3”, assembler 710 sees from one table that the “foo” operation code translates to number 6 in bit positions 16-23. From one table, assembler 710 finds the encoding function for each register. These functions encode a2 into the number 2, another a2 into the number 2, and a3 into the number 3. From one table, assembler 710 finds an appropriate set function. Set_r_field sets the resulting value 2 to bit position 12 of the instruction. . Put on 15. A similar set function places the other 2 and 3 as appropriate.
Simulator 712
Simulator 712 interacts with user-defined enhancements 736 in several ways. Given a machine instruction 740, the simulator 712 must decode the instruction, that is, decompose the instruction into component operation codes and operands. The user-defined enhancement 736 is decoded via a function in the decode DLL 748 (the encode DLL 744 and the decode DLL 748 can actually be a single DLL). For example, consider the case where a user defines three operation codes; foo1, foo2 and foo3 with encoding 0x6, 0x16, 0x26 in instruction bits 16-23, respectively, and 0 in bits 0-3. The TIE compiler 702 generates the following decode function, which compares its operation code with the operation code of the instruction 750 defined by all users.

Since there are a large number of user-defined instructions 750, it is costly to compare the operation code against all possible user-defined instructions 750, so the TIE compiler uses a hierarchical set of switch statements instead. be able to.

In addition to the decoding instruction operation code, the decode DLL 748 includes a function for decoding instruction operands. This is done in the same way as the encoding of the operands in the encoding DLL 744. First of all, the decode DLL 748 provides a function for extracting operand fields from machine instructions. Continuing the previous example, TIE compiler 702 generates the following functions to extract values from bits 12-15 of one instruction.

Since the TIE description of the operand includes both encoding and decoding specification descriptions, the encoding DLL 744 uses the operand encoding specification description, while the decoding DLL 748 uses the operand decoding specification description. For example, the following TIE operand specification description:

Produces the following operand decode function:

  When the user calls the simulator 712, the user tells the simulator 712 the directory that contains the decoded DLL 748 for the user-defined enhancement 736. Simulator 712 opens the appropriate DLL. Whenever the simulator 712 decodes an instruction, if the instruction is not successfully decoded by a pre-assembled decode function for the instruction set, the simulator 712 calls the decode function in the DLL 748.

  Assuming a decoded instruction 750, the simulator 712 must interpret and model the semantics of that instruction 750. This is done functionally. Every instruction 750 has a corresponding function that allows the simulator 712 to model the semantics of the instruction 750. The simulator 712 internally keeps track of every state of the simulated processor. The simulator 712 has a fixed interface for updating or asking the processor state. As described above, user-defined enhancements 736 are written in a TIE hardware description language that is a subset of Verilog. To model the new enhancement 736, the TIE compiler 702 converts the hardware description into a C function that the simulator 712 uses. Hardware description language operators are translated directly into corresponding C operators. Operations to read or write states are translated into the simulator interface to update or ask for the processor state.

As an example of this embodiment, consider the case where a user creates one instruction 750 to add to two registers. We chose this example for simplicity. In a hardware description language, a user may write additional semantics as follows:

The output register indicated by the built-in name arr is specified as the sum of the two input registers indicated by the built-in names ars and art. The TIE compiler 702 recognizes this description and generates a semantic function used by the simulator 712.

  The hardware operator “+” is translated directly into the C operator “+”. Reading hardware registers ars and art is translated into a call to simulator 712 function call “ar”. Writing the hardware register arr is translated into a call to the simulator 712 function “set_ar”. Since every instruction explicitly increments the program counter pc by the size of the instruction, the TIE compiler 702 generates a call to the simulator 712 function that increments simulatedpc by 3 which is the size of the add instruction.

  When TIE compiler 702 is invoked, TIE compiler 702 creates a semantic function for any user-defined instruction as described above. A table is also created in which all operation code names for related semantic functions are arranged. The tables and functions are edited in the simulator DLL 749 using a standard compiler 746. When the user calls the simulator 712, the user tells the simulator 712 the directory that contains the user-defined enhancement 736. Simulator 712 opens the appropriate DLL. Whenever the simulator 712 is called, the simulator 712 decodes all instructions in the program and creates a table that places the instructions for the associated semantic function. When creating a mapping, simulator 712 opens the DLL and searches for an appropriate semantic function. When simulating the semantics of the user-defined instruction 736, the simulator 712 calls functions in the DLL directly.

  In order to tell the user how long it will take to run the application on the simulated hardware, the simulator 712 needs to simulate the performance effects of the instructions 750. Simulator 712 uses a pipeline model for this purpose. Every instruction executes over several cycles. In each cycle, the instruction uses different resources of the machine. Simulator 712 begins to execute all instructions in parallel. If multiple instructions try to use the same resource in the same cycle, the slower instruction will wait until the resource becomes free. If the later instruction reads the state written by the earlier instruction in a later cycle, the later instruction waits for the written value and gets stuck. Simulator 712 uses a functional interface to model the performance of each instruction. One function is created for every type of instruction. The function includes a call to the simulator interface that models the performance of the processor.

For example, consider a simple three register instruction foo. The TIE compiler may create the following simulator functions:

  A call to pipe_use_ifetch tells simulator 712 that the instruction needs to fetch 3 bytes. Two calls to pipe_use tell simulator 712 that the two input registers are read in cycle 1. A call to pipe_def tells the simulator 712 that the output register will be written in cycle 2. A call to pipe_def_ifetch tells the simulator 712 that this instruction is not a branch and therefore the next instruction can be fetched in the next cycle.

  Pointers to these functions are placed in the same table as the semantic functions. The function itself is edited in the same DLL 749 as the semantic function. When the simulator 712 is called, the simulator 712 creates a mapping between instructions and performance functions. When creating a mapping, simulator 712 opens DLL 749 and searches for an appropriate performance function. When simulating the performance of the user-defined instruction 736, the simulator 712 calls a function in the DLL 749 directly.

Debugger 730
The debugger interacts with the user-defined enhancement 750 in two ways. In order to do this, the debugger 730 must decode the machine instruction 740 into an assembly instruction 738. This is the same mechanism that simulator 712 uses to decode instructions, and debugger 730 preferably uses the same DLL that simulator 712 uses to perform decoding. In addition to instruction decoding, the debugger must convert the decoded instruction into a string. For this purpose, the decode DLL 748 includes a function for placing each internal operation code representation in a corresponding mnemonic string. This can be done with a simple table.

  The user can call a pre-assembled debugger with a flag or environment variable pointing to the directory containing the user-defined enhancement 750. A pre-assembled debugger dynamically opens the appropriate DLL 748.

  In addition, the debugger 730 interacts with a user defined state 752. The debugger 730 must be able to read and correct the state 752. In order to do so, the debugger 730 communicates with the simulator 712. The debugger 730 asks the simulator 712 how large the state is and what the name of the state variable is. Whenever the debugger 730 is asked to print a value for some user state, the debugger 730 asks the simulator 712 for the value in the same way as it charges for a predefined state. Similarly, to modify the user state, the debugger 730 tells the simulator 712 to set the state to a predetermined value.

  Thus, implementation of support for user-defined instruction sets and states according to the present invention can be achieved using modules that define user functionality that is plugged into the core software deployment tool. In this way, a system can be developed in which plug-in modules for a specific set of user-defined enhancements are maintained as a group within the system for ease of organization and operation.

  In addition, the core software deployment tool may be specific to a particular core instruction set and processor state, and a set of plug-in modules for user-defined enhancements can be combined into a number of core software deployment tools present in the system. You may evaluate in relation to.

Claims (10)

A system for designing an expansion processor,
Has a basic instruction set arch te Kucha including a plurality of basic instructions, the defining together basic functions and basic instruction set arch Te Kucha, containing the basic processor design modeled by the basic software deployment tool that supports standard programming model,
In addition to the basic processor design, the basic instruction set architecture, the plurality of basic instructions, and the basic function, a plurality of additional processor functions corresponding to one or more additional processor instructions that are not present in the plurality of basic instructions Means for generating a description of the hardware implementation of the extension processor based on a specified configuration specification;
The basic software development tools in order to obtain a change software deployment tool, based on the configuration specification, and means for changing,
And the modified software deployment tool uses both the one or more additional processor instructions and the plurality of basic instructions.   The system of claim 1, wherein the modified software deployment tool includes a compiler that generates application code based on at least some basic instructions of the plurality of basic instructions as well as at least one of the one or more additional processor instructions.   The modified software deployment tool includes a disassembler adapted to the configuration specifications and decomposing application code including the at least some basic instructions of the plurality of basic instructions and the at least one of the one or more additional processor instructions. The system of claim 2.   The system of claim 3, wherein the modified software deployment tool includes a debugger that examines the application code including the at least some basic instructions of the plurality of basic instructions and the at least one of the one or more additional processor instructions.   The modified software deployment tool includes an instruction set simulator that simulates the application code including the at least some basic instructions of the plurality of basic instructions and the at least one of the one or more additional processor instructions. System.   At least one of the plurality of additional processor functions includes a user-defined state, one of the additional processor instructions, and a user-defined function associated with the user-defined state, wherein the at least one of the plurality of additional processor functions is the The system of claim 1 including at least one of read and write to a user-defined processor state.   The system of claim 6, wherein the modified software deployment tool includes a compiler that generates application code based on at least some basic instructions of the plurality of basic instructions as well as at least one of the one or more additional processor instructions.   The modified software deployment tool is adapted to the configuration specification and includes a disassembler that decomposes the application code including the at least some basic instructions of the plurality of basic instructions and the at least one of the one or more processor instructions. 8. The system of claim 7, comprising:   9. The system of claim 8, wherein the modified software deployment tool includes a debugger that examines the application code including the at least some basic instructions of the plurality of basic instructions and the at least one of the one or more processor instructions.   8. The modified software deployment tool includes an instruction set simulator that simulates the application code including the at least some basic instructions of the plurality of basic instructions and the at least one of the one or more processor instructions. System.

Images