Patent Application
20050149898
1. Field of the Invention
The invention relates generally to the field of semiconductor design and layout and computer automated design (CAD) for semiconductors. More specifically, the invention provides a method for managing the configuration, design parameters, and functionality of an integrated circuit design in which custom instructions and other elements may be arbitrarily controlled by the designer.
2. Description of Related Technology
Several types of computer aided design (CAD) tools are available to design and fabricate integrated circuits (IC). Such computer-aided or automated IC design tools can include modules or programs addressing both the synthesis and optimization processes. Synthesis is generally defined as an automatic method of converting a higher level of abstraction to a lower level of abstraction, and can include any desired combination of synthesis techniques which occur at various levels of abstraction. So-called “behavioral synthesis” is a design tool wherein the behavior (e.g. inputs, outputs, and functionality) of a desired IC are entered into a computer program to design a device that exhibits the desired behavior. Such tools permit IC designers to produce increasingly complex and capable devices, sometimes having logic gate counts in the tens of millions, with few or no errors and in a much shorter time period than would be otherwise possible with manual design techniques such as hand layouts.
Examples of synthesis processes which involve different levels of abstraction include architectural level synthesis and logic level synthesis, both of which may be incorporated into the IC design process.
Architectural level synthesis is primarily concerned with the macrosccpic structure of the circuit; it utilizes functional blocks (including information relating to their interconnections and internal functionality). Architectural level synthesis includes register transfer level (RTL) synthesis, which can have multi-bit components such as registers and operators.
Logic level synthesis, on the other hand, is concerned with gate level design. Logic level synthesis determines a microscopic structure of a circuit and transforms a logic model into an interconnection of instances of library cells. The result of the logic level synthesis is a netlist of logic devices and their interconnections. Logic-level synthesizers (so-called synthesis “engines”) are available from several commercial vendors.
The synthesis process generally begins with the designer compiling a set of IC specifications based on the desired functionality of the target device. These specifications are then encoded in a hardware description language (HDL) such as VHDL® (VHSIC hardware description language) available from IEEE of New York, N.Y., or Verilog® available from Cadence Design Systems, Inc. of Santa Clara, Calif. The specifications define an IC in terms of the desired inputs and outputs, as well as desired functionality such as available memory or clock speed. From the HDL, the designer then generates a “netlist” including a list of gates and their interconnections, which is descriptive of the circuitry of the desired IC. Ultimately, the design is compiled and masks fabricated for producing the physical IC.
Unfortunately, while well suited for simpler devices and single components, the aforementioned prior art approaches to automated IC design suffer several limitations, especially when applied to the design of more complex ICs such as CPU-based processors. These problems stem largely from the requirement that the instruction set be fixed prior to, and not modifiable during, the design and synthesis processes, thereby reducing the flexibility and capability afforded the designer both during and after the design process. These problems are highlighted by the practice of supplying predefined CPU designs to users desiring to integrate a processor into their systems Integrated Circuit design. Specifically, by not being able to consider certain instructions, functions, or components in the design during synthesis, the designer is required to attempt to “backfit” these elements to the design, which often times creates compatibility issues or other problems. This disability also effectively precludes optimization of the design for certain parameters (such as die size or clock speed) since the resulting design necessarily has a higher gate count, and does not have the benefit of customized instructions specific to the desired architecture and functionality. Furthermore, such prior art systems are incapable of automatically assembling a HDL model of the complete processor and simulating its operation, an approach which can greatly increase the efficiency and effectiveness of the design process.
Based on the foregoing, an improved method (and associated apparatus) is needed for managing the configuration, design parameters, and functionality of an integrated circuit design. in which the instruction set can be interactively varied by the user. Specifically, such an improved method would permit the user to add or subtract existing instructions, as well as generate new instructions specifically adapted for use with the design, while retaining the ability to verify the accuracy and correctness of the VHDL model and the subsequent synthesized logic or layout. Additionally, the improved method would allow the user to generate descriptive models of the complete processor as opposed to just individual logic circuits or modules, thereby further enhancing the simulation and synthesis processes. Furthermore, the user could automatically or interactively select various design parameters (such as the existence of a memory interface or peripheral component) during the design and synthesis processes to preclude having to retrofit or modify the design at a later time. This latter ability would greatly enhance the integration of such components into the design, thereby effectively eliminating incompatibilities, and reducing the resulting IC to its smallest possible dimension, clock speed, and power consumption, with the least amount of effort and cost.
The present invention satisfies the aforementioned needs by providing an automated means of managing the configuration, design parameters, and functionality of an integrated circuit design, through the use of an interactive computer program.
In a first aspect of the invention, an improved method for managing the configuration, design parameters, and functionality of an integrated circuit design is disclosed. In one embodiment of the disclosed method, the user inputs information relating to the design hierarchy and HDL library files, and generates a computer program script based on these inputs. Custom instructions and other elements (such as special-purpose registers, new condition code choices, local scratchpad RAM, or a library of multimedia extensions for 3D or DSP applications) may be arbitrarily added to the existing HDL instruction set by the designer as well during the design process. Unlike adding an external ASIC or other component post-synthesis, these instructions become included within the processor instruction and register set so as to eliminate integration problems, and allow maximal optimization based on one or more selected attributes. Ultimately, the generated script is run, and a customized HDL model of the IC is produced based on the user-defined instruction set. This customized HDL model is then used as the basis for further simulation and/or synthesis as desired by the designer. This method further affords the designer the ability to generate an HDL model of the entire IC, thereby greatly enhancing the efficiency of the design process. This ability is especially useful for complex CPU- based processor designs, although it may readily be applied to other types of components.
In a second aspect of the invention, the aforementioned method is further embodied in a menu-driven computer program which may be used in conjunction with a microcomputer or other similar device for designing and managing the configuration of integrated circuits. In one exemplary embodiment, this menu-driven computer program comprises a series of routines or “modules” which perform various sets or groups of related functions. An interactive architecture module gathers information about the designer's system, available libraries, and the design configuration to be generated. A hierarchy generation module assists in ordering logical blocks or entities and routing signals within the design, as well as ultimately generating a netlist. An HDL generation module generates a merged HDL file descriptive of the design. In the exemplary embodiment, these modules are connected together via computer programs scripts or user initiated execution of the individual modules. In yet another embodiment, these modules may also be compiled into one comprehensive program, and bundled with other software tools that facilitate rapid and integrated design of the subject IC on a standard microcomputer.
In a third aspect of the invention, an apparatus for generating, simulating, and/or synthesizing an integrated circuit design using the aforementioned method is disclosed. In a first embodiment, a microcomputer having a microprocessor, display, and input device is used to run the previously described menu-driven computer program, thereby allowing the designer to interact with the program during the design, simulation, and/or synthesis processes. The microcomputer further includes a storage device and network interface to allow for the storage, retrieval, and sharing of information between two or more microcomputers configured with the aforementioned computer program.
In a fourth aspect of the invention, an integrated circuit design depicted in a hardware description language and synthesized using the aforementioned method of the invention is disclosed.
In a fifth aspect of the invention, an integrated circuit fabricated using the aforementioned synthesized design is disclosed. In one exemplary embodiment, the integrated circuit comprises a reduced instruction set CPU (RISC) processor.
In a sixth aspect of the invention, a data storage device adapted for use with a computer system and comprising in part the aforementioned computer program is disclosed.
a is a flow diagram illustrating one specific embodiment of the generalized method of
a-3e collectively comprise a logical flow diagram illustrating one exemplary embodiment of the architecture module of the invention.
a-5h collectively comprise a logical flow diagram illustrating one exemplary embodiment of the method of configuring file extensions as shown generally in
Reference is now made to the drawings wherein like numerals refer to like parts throughout.
As used herein, the terms “computer program,” “routine,” “subroutine,” and “algorithm” are essentially synonymous, with “computer program” being used typically (but not exclusively) to describe collections or groups of the latter three elements. In general, however, all of the aforementioned terms as used herein are meant to encompass any series of logical steps performed in a sequence to accomplish a given purpose.
Also, while the following description relates explicitly to the VHDL environment, it can be appreciated that the general principles and functionality of the present invention may be embodied in other description language environments including, for example, Verilog®.
Background of “ARC™”
In the following discussion, the term “ARC™” (ARC RISC Core) refers to a microprocessor-like central processing unit (CPU) architecture. While the method of present invention can be applied to other types of integrated circuits including, for example, application specific integrated circuits (ASICs ) and field-programmable gate arrays (FPGAs), the microprocessor-like CPU design is chosen to more clearly illustrate the operation and capability of the invention.
As discussed in greater detail below, the present invention takes in one embodiment the form of a computer program having a synthesizable and customizable (i.e., “soft”) macro with a complementary suite of software tools for configuration and hardware-software co-design. This computer program employs the concept of a “system builder” to accomplish much of the desired functionality. In the present context, the ARC system builder refers to that portion or module of the computer program whereby the designer controls the generation of the subject CPU design. In one particular embodiment, the system builder directs the assembly of a series of predefined VHDL based designs along with design elements created by the user (also in VHDL, or whatever other description language is chosen) to produce a new, custom CPU specific to the user's specifications and needs. Hence, the system builder controls the creation and testing of HDL-based synthesizable CPUs. This approach further provides users with a great deal of flexibility in configuring the specific attributes of the resulting CPU.
The ARC System builder is embodied in a series of“scripts” that allows users to build customized ARC systems along with support files for both design simulation and synthesis. A script is more specifically a computer program, often written in a special computer programming language designed for the purpose. Such script languages include for example the “perl” and language commonly employed in UNIX based computer systems as a “scripting language.” There are other languages available to write scripts compatible with the present invention. It is noted that for the purposes of the present discussion, the term “scripts” refers to any series of logical instructions or actions of a computer program which are executed in a predefined order.
When executed, the ARC system builder script produces a series of questions, answered primarily through menus (as illustrated in greater detail below in the exemplary menu structure of Appendix I), the answers to which are used to build the VHDL simulator and synthesis files. An installation script allows several different ARC features to be selected, such as processor cache size and cache line length, size of external memory space to be cached, and clock period/skew. The script creates a working directory for the user, and further generates various VHDL files necessary to support further customized VHDL development.
The term “makefile” as used herein refers to the commonly used UNIX makefile function or similar function of a computer system well known to those of skill in the computer programming arts. The makefile function causes other programs or algorithms resident in the computer system to be executed in the specified order. In addition, it further specifies the names or locations of data files and other information necessary to the successful operation of the specified programs. It is noted, however, that the invention disclosed herein may utilize file structures other than the “makefile” type to produce the desired functionality.
Central to the method of the invention is the concept that one computer program may write another program, which is subsequently executed by the computer system. For example, one script may write a second script that is tailored by user input to perform a specific task. The task is then performed when the second script is executed. This “dynamic scripting” is employed in various aspects of the invention, as further described herein.
Detailed Description of Method
Referring now to
Initially, the hierarchy file specific to the processor design under consideration is edited in the first step 102. Specifically, desired modules or functions for the design are selected by the user, and instructions relating to the design are added, subtracted, or generated as necessary. For example, in signal processing applications, it is often advantageous for CPUs to include a single “multiply and accumulate” (MAC) instruction. This instruction commonly improves system performance and reduces the amount of computer code required to perform signal processing tasks; two desirable characteristics in such systems. Conversely, applications that are essentially logical control oriented in nature have little or no need for such an instruction. Eliminating the instruction from a purpose-built CPU reduces the CPU die size and gate count, also a generally preferred advantage. In still another case, an instruction that is only of value to one specific application may be defined and implemented by designers. In all of these examples, the present invention permits designers a greater degree of control over the CPU design and more flexibility in making design tradeoffs and optimizations.
It should also be recognized that ashen using the system builder of the present embodiment in its most common mode, the hierarchy of design is determined by the script, and a “hierarchy builder” is called by the script builder.
In step 104 of the method of
A makefile is then generated in the third step 106 using the hierarchy file information, library information previously described, as well as additional user input information relating to the desired configuration and attributes of the device. For example, in the ARC system builder, the user is asked to input the type of “build” (e.g., overall device or system configuration), width of the external memory system data bus, different types of extensions, cache type/size, etc., as described in additional detail below with respect to
Next, the makefile generated in the third step 106 is run in a fourth step 108 to create a customized VHDL model. As part of this step, the user is presented with a variety of optional response menus and prompts to further define the VHDL model based on his/her desired attributes.
At this point in the program, a decision is made whether to synthesize or simulate the design (step 110). If simulation is chosen, a separate script (“MTI-make” in the present embodiment) is run in step 112 to generate a separate simulation makefile for use in the simulation. Simulation scripts and makefiles are generally well known to those of ordinary skill in the art, and accordingly will not be discussed further herein. Alternatively, if synthesis is chosen, the synthesis scripp's) (e.g., “synopsys make”) are run in step 114 to generate corresponding synthesis makefiles. After completion of the synthesis/simulation scripts, the adequacy of the design is evaluated in step 116. For example, a synthesis engine may create a specific physical layout of the design that meets the performance criteria of the overall design process yet does not meet the die size requirements. In this case, the designer will make changes to the control files, libraries, or other elements that can affect the die size. The resulting set of design information is then used to re-run the synthesis script.
Note that there are many different criteria that may be used to determine whether or not a design is acceptable. In general, each design will have a different set of criteria used to determine the acceptability of the final design. Die size, power consumption, clock speed, and numerous other factors may constitute alone or collectively design constraints or targets. This great variability in acceptance criteria is one factor that demands the flexibility of the present invention.
If the generated design is acceptable, the design process is completed. If the design is not acceptable, the process steps beginning with step 102 are re-performed until an acceptable design is achieved. In this fashion, the method 100 is iterative. Note that if the simulation path 112 is chosen in order to simulate the operation of the generated design, the user may subsequently run the synthesis scripts per step 114 (dotted line in
Appendix I illustrates the operation of an algorithm utilizing the method of
Appendix II is a list of the VHDL script files used in conjunction with the VHDL embodiment of the algorithm of the present invention.
It is noted that while the source code for the embodiment of the computer program set forth herein is written using AWK, a programming language commonly found on UNIX workstations, but also available on other personal computers, the program may be embodied using any of a number of different programming languages such as, for example, C++. The source code directed to the exemplary AWK embodiment of the invention described herein is set forth in Applicant's aforementioned Provisional U.S. Patent Application No. 60/104,271, which is incorporated herein by reference in its entirety.
Referring now to
Similarly, the step 104 of defining the library location for each VHDL file in
It will be appreciated by one skilled in the relevant art that there are a large number of alternative partitionings or structures of the flowchart of
Referring now to
As shown in
In step 308, the system clock, memory configuration, and cache default values are set based on the technology chosen in step 306 above. If the technology chosen by the user allows a choice of clock speed, the user is prompted (or the selection otherwise obtained) in steps 310 and 312. The clock period is then set per step 314.
Referring now to
Referring now to
Next, in step 340, the system configures the extensions used with the design as specified in step 320 described above.
Referring now to
Referring now to
In step 360, the structural HDL files are generated, along with the synthesis scripts and simulation makefiles. Lastly, the test code required by the chosen extensions is compiled in step 362.
Referring now to
If core verification was requested by the user in steps 406 or 407, the memory values required for such verification are set in step 414, and the register values required by the selected technology and the core verification are set in step 416.
In the case that the technology selected does dictate the bus values, and core verification is not selected, then the register values are set per step 416 previously described.
Referring now to
Referring now to
If a choice of memory extensions is allowed per step 516, the method of
If a memory subsystem does exist in step 524, the desired memory extensions are obtained from the user in step 538.
Referring now to
Referring now to
Returning to step 556, if a RAM sequencer choice is permitted, then the algorithm determines in step 558 whether a synchronous RAM (SRAM) was chosen by the user. If so, the user is prompted in step 560 for the number of RAM sequencer wait states associated with the SRAM. Upon obtaining that information, the algorithm proceeds to step 562 of
Referring now to
If no memory arbiter exists per step 564, then the existence of a sequencer is again determined per step 570. If a sequencer exists, the aforementioned return is executed. If no sequencer exists, the existence of an instruction fetch is determined in step 572. If an instruction fetch exists per step 572, the algorithm proceeds to step 580 of
Referring now to
Referring now to
Referring now to
Referring now to
Referring now to
After the top-level rules have been added, the datafile dependency rules are added to the makefile in step 914. This step 914 is described in greater detail with reference to
Referring now to
Referring now to
Referring now to
Next, for each intermediate block, the HDL is generated in step 1318, and when all intermediate blocks have been generated, the HDL for the top level generated in step 1320. This completes the hierarchy file generation method 1300.
Referring now to
If the line under analysis is classified as a “signal” line, then the signal data is extracted from that line in step 1704 as previously described with reference to
If the line under analysis is an “architecture” line, the architecture of the primary block is set to “data” per step 1718, and the next line analyzed.
If the line under analysis is neither an “architecture” or “signal” line, no action is taken, and the next line in the top level data file is read.
Referring now to
Referring now to
Referring now to
Referring now to
It is again noted that while the following discussion is cast in terms of VHSIC Hardware description Language (VHDL), other languages may be used to practice the method of the invention with equal success VHDL is chosen for the illustrated examples simply for its comparatively wide-spread recognition and ease of use.
As used herein, the term “vhdlgen” refers to VHDL generation, a process within the invention by which the individual VHDL files relating to various aspects or components of the design are merged together to form a common VHDL file descriptive of the overall design.
As shown in
Referring now to
In the case where the signal under examination has not been previously read, the signal's upper and lower bounds, direction, and type are set in step 2620 using information from the input line. The signal's destination list is also cleared. If the signal's direction is “inout”, then the signal's source is set to “entity” in step 2622, and the signal added to the signal list in step 2624. If not, the signal is added to the signal list directly. After the addition of the signal to the signal list in step 2624, the routine proceeds to step 2606 for analysis of the signal's direction as previously described.
Referring now to
Lastly, if the record is classified as “other” in step 2902, then no action is taken and the next subsequent record is read.
After each record has been read from the selected library and analyzed as to type, each entity is examined to determine whether it has an associated entity library per step 2914. If a given entity does have a library, that library is next analyzed in step 2916 to determine if that library has been read before. If so, the next sequential entity is analyzed. If not, the library is added to the library list in step 2918, and then the next subsequent entity analyzed. If the entity has no associated library in step 2914, then the program is aborted per step 2920.
Referring now to
It is noted that while the foregoing description of
Description of the IC Design Apparatus
Referring now to
Description of the Integrated Circuit
Referring now to
It will be appreciated by one skilled in the art that the Integrated Circuit of
It is noted that power consumption of devices such as that shown in
It is also noted that many IC designs currently use a microprocessor core and a DSP core. The DSP however, might only be required for a limited number of DSP functions, or for the IC's fast DMA architecture. The invention disclosed herein can support many DSP instruction functions, and its fast local RAM system gives immediate access to data. Appreciable cost savings may be realized by using the methods disclosed herein for both the CPU & DSP functions of the IC.
Additionally, it will be noted that the computer program as previously described herein can readily be adapted to newer manufacturing technologies, such as 0.18 or 0.1 micron processes, with a comparatively simple re-synthesis instead of the lengthy and expensive process typically required to adapt such technologies using “hard” macro prior art systems.
While the above detailed description and Appendices have shown, described, and pointed out novel features of the invention as applied to various embodiments, it will be understood that various omissions, substitutions, and changes in the form and details of the device or process illustrated may be made by those skilled in the art without departing from the spirit of the invention. The foregoing description is of the best mode presently contemplated of carrying out the invention. This description is in no way meant to be limiting, but rather should be taken as illustrative of the general principles of the invention. The scope of the invention should be determined with reference to the claims.
The following describes and illustrates the operation of the ARC System Builder Program:
Installation Script
Installation script allowing the following ARC features to be selected:
The script creates a working directory for the user, and in it creates the following:
The user can select from 4 different types of build:
After setting up his ARC area, before the user can use the ARC system builder, several environment variables need to be set.
In .cshrc:
ARC_MANCODE is the unique manufacturer code that ARC Cores gives to each ARC licensee, and the ARC_MANVER is that manufacturers additional identity number. Both numbers go on to be stored as part of the identity register.
After setting up the environment, the ARC system builder can be run just by typing system_builder, which is an executable script. A log file (sys_bld.log), which keeps a record of the build selections the user make, is created in the directory that the user specify for the user working directory.
The ARC System builder script when run produces a series of text menus/questions.
Example MENU 1
The above menu shows an example menu. The ‘*’ next to a menu entry indicates that it is selected.
Continue
On all the menus that allow multiple selections 1 is always continue.
Valid selections
In this example menu entry 2 is a valid selection which is currently unselected. Menu entry 7 is also a valid selection, which is selected. Valid selections can be selected and deselected by entering their corresponding menu number. (When menus are initially displayed some valid selections may be pre-selected; these are just recommended selections for this build.)
Mutually exclusive selections (On the same menu)
Selections are mutually exclusive, for example two types of the same extension cannot be selected at the same time. If one menu entry, of a mutually exclusive set, is already selected and the user then selects the another, the first is deselected.
Mutually inclusive selections (Between menus)
Mutually inclusive relationships can exists between menu entries on two separate menus. If this is so, the entry on the second menu is either permanently selected or invalid depending on the state of the first entry.
Permanent selections
In certain circumstances menu entries usually valid select/deselect are permanently selected, e.g. Example menu entry 5. This usually because on a previous menu the user selected a menu entry to which this one is mutually inclusive. Permanent selections can also be active due to the build type.
Invalid selections
As with permanent selections, invalid selections are normal valid select/deselect menu entries, however in this case these options are not available. This is usually due to either mutually inclusive selections on previous menus that were not selected, or this selection is not available on this type of build. Menu entry 6 is an example of an invalid selection.
Example MENU 2
Menu Default
Some menus in the ARC system builder have default selections. On such menus entering nothing, i.e. just pressing enter, will select the default. The default menu entry number is specified next to the requestor. Menu defaults can be more than just numbers, on some questions they can be file paths, y/n etc.
The following describes examples for each of the four types of build available, Base case, Generic, ARCAngel and Core verification.
The first menu the user will encounter for all installations is the one below:
ARC System Build Tool—ARC System install.
(c) 1998 ARC Cores Technologies Ltd.
Generic install
This program is capable of creating a basecase ARC or a complete ASIC for simulation, using MTI and synthesis using Synopsys Design Compiler/Design Expert.
We're going to make:
But first, you must answer some questions:
Please select the type of system you wish to build.
Please select (1):
This menu allows the user to select from four types of build Core (Base case) build, Generic, ARCAngel and Core Verification. We will now example an install of all four types, showing the menus the user will encounter and ‘typical’ responses.
1. Base case
From the first menu we select 1, which is also the default. The ARC system builder will then prompt the user for details about the Core build, i.e. Standard extensions (not including any scratchpad extensions), Direct mapped instruction cache, Load/ST interface to external memory, Host interface and model of external memory.
Instruction/Data Byte Address Selections
Instruction
Fetch memory system byte address bus width
Please select (3):
This menu asks for the number of bits for the instruction fetch address. For the purpose of this example we will select the default of 24 bit (16 Mb), by pressing ENTER.
The external memory system data bus width is 32 bits wide
The external data bus on the ARC is 32-bits wide.
External memory system address bus width (22<address<32)(24):
The external memory system data bus width can range from 22 to 32 bits, 4 Mb to 4 Gb address range, the default on this menu is set to the value of the I-fetch address bus width. We are going to select 29 bits, an address range of 512 Mb. NOTE: Even though the bus width is set to an arbitrary value the memory model for a core build simulation is 128 Kbytes.
Core Register File Selection
The 32×32 register file can be implemented using a synthesized array of d-latches, or by using a three-port (2 read, 1 write) synchronous RAM cell.
Use a synchronous 2r1w RAM for the register file? (y):
For the 32 general purpose registers r0-r31 the user can either use: Synchronous 3-port (2r1w) RAM, (a fast write-through is not required).
Synthesized arrays of d-latches that require a write pulse to be generated.
Standard synthesis script assumes a 90°-delayed clock signal, for the synthesized array of d-latches.
We will use a synchronous 3-port RAM and so we select y.
Fast Load Returns
Enable Fast load returns? (n):
Fast Load returns, if the current instruction does not use register write back then the pipeline is not stalled.
Extensions Builder
Select the extensions to be added to the ARC
The above menu shows all the standard extensions, the user can select different combinations depending on his needs.
We will select the single cycle barrel shifter and the 32×32 multiply. Entering 2 and then entering 4 does this. If we wanted to disable the multiply we could do this by entering 4 again.
Note the user cannot select both types of barrel shifters, in an install, selecting one automatically deselects the other. This also applies to both instances of the 32×32 multiplier, the MAC and both instances of the Scratchpad RAM.
We will now enter 1 to continue.
Technology Selection
Feature size (drawn) of technology in use
The feature size provides timings for DATA/TAG ram and the core registers. Our chosen technology is 1.0?m so we press ENTER to continue.
The default synthesis script is set-up for the 1.0?m LSI—10K library supplied with the Synopsys synthesis tool.
These values are only used to set the timings for the synthesis of RAM models. If an unsupported feature size required the user can select an arbitrary value and following the build change the clock period for the simulation of the VHDL and synthesis scripts to support the new feature size, timings of RAM etc.
Target clock speed in MHz (20)
We will use the default of 20 MHz as we have specified 1.0 ?m technology. Clock speed has a minimum of 1 MHz and a Maximum of 150 MHz.
Clock skew for synthesis (±1.5 ns)
The default of 1.5 ns will be used for this example. Clock Skew has a minimum of 0 and a maximum less than the clock period.
Library for extensions logic? (user)
Here the user can specify a name for his user's library. This name will be used as the VHDL library names and also during the install when creating directories and copying subsequent files to these directories (The directories created are in upper case). The name entered is arbitrary so we will enter ‘Alex’.
Memory Extensions
Do you wish to include a Direct-Mapped Instruction Cache? (y):
If the user enters “no” here the user will build an ARC with no cache, if the user enters “Yes” he will be prompted to for further information about the cache he wants. We will enter “Yes” the default.
Ifetch Modes
Select the instruction Cache Modes.
The first thing the script needs to know is what kind of cache do the user want. It's possible to have a:
NOTE: Standard Cache and Virtual Cache are mutually exclusive, and Mixed Code
RAM is a superset of Standard Cache. We want to try a range of cache sizes to see what cache size best suits our application, therefore we are selecting Virtual Cache
Please select the max size of the Direct Mapped Instruction Cache.
Please select (3):
The Direct Mapped Instruction cache is user definable, using the script the user can select sizes from 4 bytes (1 word), up to 512 k bytes (128 k words). There are shortcuts for 512 bytes to 16 K bytes, but other sizes (larger or smaller) can be entered manually using option 7. For our test 4 K bytes (selection 4) is sufficient.
Please select the min size of the Direct Mapped Instruction Cache.
Please select (3):
Virtual Cache requires a range of possible caches and line lengths so a minimum cache size is required. We will enter 2 512 bytes.
Select a max Cache line length
Please select (3):
The cache line length is the number of words fetched when a cache miss occurs. The script has options for 2, 4, 8, 16, or 32 word lines, the default being 8 words. Selecting 4, will give a cache line length of 16 words, suitable for our test.
Select a max Cache line length
Please select (3):
Virtual Cache requires a range of possible caches and line lengths so a minimum cache line length is required. Entering 1, selects two instruction words. Cache size, line length and external address all determine the size of the tag RAM. Larger cache means more tag words and fewer tag bits. Longer line length means fewer tag words and more tag bits.
Simulation
Selection of the state of the ARC on reset is important since it is preferable to have the system build start on reset while the core build should halt on reset since the host effectively clears the halt bit during simulation. Do you wish to halt the ARC at address location 0 on reset (y):
We have entered ‘y’ here, that means the ARC is halted immediately on reset. Had we selected ‘n’ the ARC starts running the code at address 0 on reset. The default for this is Y on core build and N on generic and ARCAngel builds.
Note you will have to set the status register to the appropriate start address and clear the halt bit through the host interface before running the simulation. You can manually edit “arc_start” in xaux_regs.vhdl so that the ARC is running following a reset.
Having selected ‘y’ the above information message is displayed.
Is your VHDL simulator Model Technologies VSystem? (y):
At ARC Cores we enter ‘y’ as we use MTI VSystem to simulate our VHDL. If the user use a different simulator, select no. The user may set his environment up for his simulator by editing the makefile and other support files, after the install has completed.
Do you wish to use the R.T.L. And SeeCode Application Link (RASCAL)? (n):
RTL And See-Code Application Link, otherwise known as RASCAL™, is an extra utility that connects the Metaware debugger to connect to the Modeltech simulator. This allows the debugger to control the simulation of code on the ARC system model in the MTI simulator for hardware/software co-verification. The default is no which is what we want for this build.
Install Directory
Full path to ARC user working directory (/home/someone/basearc):
At this prompt the user have to specify a destination directory name (with full path). The path must not include/tmp_mnt/etc.
We will select the default, a directory named “basearc” created where we launched the ARC system builder.
What we have built:
The second selection from the first menu is the generic build. This is similar to the base case build however it allows the selection of memory extensions. As described in the generic build certain selections determine which menus the user will see, we are going to make selections in this example that will give access to all menus.
Instruction/Data Byte Address Selections
Instruction
Fetch memory system byte address bus width
NOTE: If you intend to use the PC parallel communications host port do not exceed 24-bits
Please select (3):
This menu asks for the number of bits for the instruction fetch address. For the purpose of this example we will select 22 bit (4 Mb), by entering 1.
NOTE: Later in the build the user will be asked to select a host port for communications with the ARC. The SUN/PC parallel communications host port has maximum of 24-bits, if the user select a value greater than 24-bits in this menu the PC host port will no longer be available.
The external memory system data bus width is 32 bits wide
The external data bus on the ARC is set to 32 bits wide.
External memory system byte address bus width (22<address<32)(22)
The external memory system data bus width can range from 22 to 32 bits, 4 Mb to 4 Gb address range, the default on this menu is set to the value of the I-fetch address bus width. We are going to select 24 bits, 16 Mb address range, which is the maximum valid selection that can be used with the PC/SUN host port. NOTE: Even though the bus width is set to an arbitrary value the memory model for a generic build simulation is 512 Kbytes.
Core Register File Selection
The 32×32 register file can be implemented using a synthesized array of d-latches, or by using a three-port (2 read, 1 write) synchronous RAM cell.
Use a synchronous 2r1w RAM for the register file? (y):
For the 32 general purpose registers r0-r31 the user can either use : Synchronous 3-port (2r1w) RAM, where a fast write-through not required, or Synthesized arrays of d-latches that require a write pulse to be generated.
Standard synthesis script assumes a 90°-delayed clock signal.
We desire a synchronous 3-port RAM and so we select y.
Fast Load Returns
Enable Fast load returns? (n):
Fast Load returns, if the current instruction does not use register write back then the pipeline is not stalled. Our design allows us to take advantage of fast return loads and therefore we enter ‘yes’.
Extensions Builder
Select the extensions to be added to the ARC
Please select:
The above menu shows all the standard extensions, the user can select lots of different combinations depending on his needs.
We will select multi-cycle barrel shifter, Fast Mul/MAC, scratchpad RAM with sliding pointers and swap. Entering 3,7,12 and 8 does this. We really wanted a Normalize extension rather than Swap. We disable Swap by entering 8 again and then enter 10 to select normalize.
Note that the user cannot select both types of barrel shifters, in an install, selecting one automatically deselects the other. This also applies to both instances of the 32×32 multiplier, the MAC and both instances of the Scratchpad RAM.
We will now enter 1 to continue.
Technology Selection
Feature size (drawn) of technology in use
Please select (5):
The feature size provides timings for DATA/TAG ram simulation & synthesis models and the core registers. Our chosen technology is 0.35 ?m so press 1 to continue. If vendor models are to be used the timings these settings produce are not used.
These values are only used to set the timings for the synthesis of RAM models. If an unsupported feature size required the user can select an arbitrary value and following the build change the clock period for the simulation of the VHDL and synthesis scripts to support the new feature size, timings of RAM etc.
Target clock speed in MHz (100)
We will use the default of 100 Mhz as we have specified 0.35 ?m technology.
Clock skew for synthesis (±0.4 ns):
The default of 0.4 ns will be used for this example.
Library for extensions logic? (user):
Here the user can specify a name for his user library. This name will be used as the VHDL library names and during the install when creating directories and copying subsequent files to these directories. The name entered is arbitrary so we will enter ‘sam’.
Memory Extensions
Select the memory extensions to be added to the ARC interface
Please select:
Here the memory extensions for off chip memory are selected. The LD/ST memory controller is not optional, and is therefore permanently selected. To show the full use of the build script we are selecting all memory extensions. To do this there must a ‘*’ next to each number, if not type that number (and pressing enter), finally enter 1 to continue.
The queue depth for the Load/Store Memory Controller is fixed, i.e. 4 deep with a max of 2 stores.
Having continued the above information message is displayed.
Ld/St Memory Controller Select
RAM for local load/store operations.
Please select (3):
The size of RAM to be used for local memory can be specified. We want 8 Kbytes of 32 bit local ram and so enter 4. The local RAM is situated at the top of memory by default (determined by the external address width) and therefore has a base address of [Maximum RAM size−Local RAM size].
I-Fetch Memory Controller Select
type of Instruction Fetch memory system
Please select (2):
There are several different ways in which the instruction fetch memory system can be defined.
We are using the default, 2, Direct Mapped Cache.
Ifetch Modes
Select the instruction Cache Modes.
Please select
The first thing the script needs to know is what kind of cache do the user want. It's possible to have a
We have previously looked at using Virtual Cache to experiment with a range of cache configurations. Using this method we have found a standard cache configuration that gives the required performance to cost ratio for our application. We are therefore selecting Standard Cache.
Please select the max size of the Direct Mapped Instruction Cache.
Please select (6):
The Direct Mapped Instruction cache is user definable, using the script the user can input select sized from 512 bytes (128 words), up to 16 k bytes (4 k words). Other sizes (larger or smaller) can be manually input using option 7. For our test 8 K bytes (selection 5) is sufficient.
Please select the min size of the Direct Mapped Instruction Cache.
Please select (1):
As we are using a virtual cache, it is necessary to specify a lower limit for the cache size. When using a virtual cache it is possible to artificially set the cache to any size between the maximum and minimum using software. For this test we want to test a large range of cache sizes down to the very small, therefore we select 7.
Please enter the min size of the Direct Mapped Instruction Cache in bytes. NOTE: Size must be a power of two also 4<=Size<=16384
Enter Size:
As we are testing a large range of caches we have decided to choose 128 bytes as our minimum cache size. Entering 128 and pressing enter sets this constant. At this menu we can use abbreviations, 16 k for example is the same as entering 16384.
Select a max Cache line length
Please select (3):
The cache line length is the number of words fetched when a cache miss occurs. The script has options for 2, 4, 8, 16, or 32 word lines, the default being 8 words. Typing ENTER here, like all other menus, selects the default, 3, giving a cache line length of 8 words.
Select a min Cache line length
Please select (3):
When using a virtual cache, as with the cache size, the user must also specify a minimum cache line length. 1 will give a minimum line length of 2 instruction words, which is the choice we have made.
Cache size, line length and external address, all go to determine the size of the tag RAM. Larger cache means more tag words and fewer tag bits. Longer line length means fewer tag words and more tag bits.
Host Interface Communications Select
from available host communications ports.
Please select (2):
Host port for I/O communications can be either a dummy VHDL file, which the user can edit to create a user defined communications port, standard PC/SUN or JTAG communications ports. We are selecting 2, PC/SUN, as we are not using our ARC with custom hardware.
Memory Arbitrator Select
the channels that you would like the memory arbitrator to service.
Please select:
How this menu looks is very dependent on the selections that have been made before, as most options are mutually inclusive with other selections. For test purposes we are adding some additional channels 6.
How many additional channels do you want? (1-10):
The user can select from between 1 and 10 extra channels. Enter 5 to give 5 additional channels.
Please select:
The number of additional channels is now displayed next to the option. We enter 1 to continue to the next menu.
RAM Sequencer
Select
the number of wait states for the RAM Sequencer. The script does not allow the user to enter a value greater than 31. If you wish use more than 31 wait states then you will have to edit the appropriate files manually.
How many wait states? (31):
Choose from 0-31 RAM sequencer wait states. The default and the value we are using is 31. This is a good default, as it will produce an ARC that will run with almost any speed memory. For simulation purposes, or if the user know that the ARC the user are building will always use a certain speed RAM, it may be useful to set the default value for the wait states to a smaller number than the maximum 31.
Simulation
Selection of the state of the ARC on reset is important since it is preferable to have the system build start on reset while the core build should halt on reset since the host effectively clears the halt bit during simulation. Do you wish to halt the ARC at address location 0 on reset (n):
We have entered ‘n’ here, that means the ARC starts running the code at address 0 on reset. Had we selected ‘y’ the ARC is halted immediately on reset. The default for this Y on core build and N on generic and ARCAngel builds.
Is your VHDL simulator Model Technologies VSystem? (y):
ARC Cores Technologies we enter ‘y’ as we use MTI VSystem to simulate our VHDL If the user use a different simulator, select no. The user may set his environment up for his simulator by editing the makefile and other support files, after the install has completed.
Do you wish to use the R.T.L. And SeeCode Application Link (RASCAL)? (n):
RTL And See-Code Application Link, otherwise known as RASCAL™, is extra utility that connects the Metaware debugger to connect to the Modeltech simulator. This allows the debugger to control the simulation of code on the ARC system model in the MTI simulator for Hardware/Software Co-Verification.
To include RASCAL we enter y and press enter.
Install Directory
Full path to ARC user working directory (/home/someone/systemarc)
At this prompt the user have to specify a destination directory name (with full path). The path must not include/tmp_mnt/etc.
We will select the default, a directory named “systemarc” created where we launched the ARC system builder.
What we have built
The final build is the ARCAngel. A large number of the selections on the ARCAngel build are chosen automatically due to the nature of the ARCAngel development board. The ARC Angel development board is described in detail in “______”, which is incorporated herein by reference in its entirety.
Fast Load Returns
Enable Fast load returns? (n):
Fast Load returns, if the current instruction does not use register write back then the pipeline is not stalled.
ARCAngel development allows the use of fast return loads and so will our final design, therefore we enter ‘yes’.
Extensions Builder
Select the extensions to be added to the ARC
Please select
The above menu shows all the standard extensions, the user can select different combinations depending on his needs.
Note: The scratchpad RAM and the single cycle barrel shifter are too large to fit on the current ARCAngel FPGA, as are the fast 32×32 multiplier and the fast MUL/MAC. Also a build with all extensions selected will not fit on the current FPGA.
The 24-bit Timer is automatically selected, as it is a common selection on an ARCAngel build. We are using this extension however the user can deselect it by entering the corresponding number. We will also select the Multi-Cycle Barrel shifter and the Small 32×32 multiply. Entering 3 then 4 does this.
Note the user cannot select the fast type of Mul/MAC, in an install, if the user attempt to select it the ARC system builder prompts the user for another response.
We will now enter 1 to continue.
Ifetch Modes
Select the instruction Cache Modes.
Please select:
The first thing the script needs to know is what kind of cache do the user want. It is possible to have a
Selecting 3 allows standard Cache with the extra features of Code RAM and Line locking.
Please select the norm size of the Direct Mapped Instruction Cache.
Please select (3):
The Direct Mapped Instruction cache is user definable, using the script the user can input select sized from 512 bytes (128 words), up to 16 k bytes (4 k words). Other sizes (larger or smaller) can be manually instantiated but for our test 4 K bytes (selection 4) is sufficient.
The ARCAngel has onboard tag-RAM but uses external memory for the cache data-RAMS, so selecting larger cache sizes does not drastically affect the amount of RAM resources available on the Altera device.
Cache line length
Please select (3):
The cache line length is the number of words fetched when a cache miss occurs. The script has options for 2, 4, 8, 16, or 32 word lines, the default being 8 words. Entering 2 will give a cache line length of 4 words, suitable for our test.
Host Interface Communications Select
from available host communications ports.
Please select (1):
Host port for I/O communications can be either a standard PC/SUN or a JTAG communications port. We are selecting 2, JTAG, as we wish to have an ARCAngel that can communicate to a range of host machines via the industry standard JTAG.
Simulation
Selection of the state of the ARC on reset is important since it is preferable to have the system build start on reset while the core build should halt on reset since the host effectively clears the halt bit during simulation. Do you wish to halt the ARC at address location 0 on reset (n):
We have entered ‘n’ here, that means the ARC starts running the code at address 0 on reset. Had we selected ‘y’ the ARC is halted immediately on reset. The default for this Y on core build and N on generic and ARCAngel builds.
Is your VHDL simulator Model Technologies VSystem? (y):
At ARC Cores we enter ‘y’ as we use MTI VSystem to simulate our VHDL If the user use a different simulator, select no. The user may set his environment up for his simulator by editing the makefile and other support files, after the install has completed.
Do you wish to use the R.T.L. And SeeCode Application Link (RASCAL)? (n):
RTL And See-Code Application Link, otherwise known as RASCAL™, is extra utility that connects the Metaware debugger to connect to the Modeltech simulator. This allows the debugger to control the simulation of code on the ARC system model in the MTI simulator for Hardware/Software Co-Verification.
The default of n is selected by simply pressing enter.
Install Directory
Full path to ARC user working directory (/home/someone/arcangel):
At this prompt the user have to specify a destination directory name (with full path). The path must not include/tmp_mnt/etc.
We will select the default; a directory named “arcangel” created where we launched the ARC build script.
NOTE: Even though the bus width is set to 26-bits, the memory model for a ARCAngel build simulation is 512 Kbytes.
What we have built
The Core verification is a build which creates an ARC system and appropriate test files to verify that the ARC VHDL behaves as described in the ARC Programmers Reference manual.
Core Register File Selection
The 32×32 register file can be implemented using a synthesized array of d-latches, or by using a three-port (2 read, 1 write) synchronous RAM cell.
Use a synchronous 2r1w RAM for the register file? (y):
For the 32 general purpose registers r0-r31 the user can either use : Synchronous 3-port (2r1w) RAM, where a fast write-through not required, or Synthesized arrays of d-latches that require a write pulse to be generated.
Standard synthesis script assumes a 90°-delayed clock signal.
We selected a synchronous 3-port RAM and so we select y.
Technology Selection
Feature size (drawn) of technology in use
Please select (5):
The feature size provides timings for DATA/TAG ram simulation & synthesis models and the core registers. Our chosen technology is 0.65?m so press 3 to continue.
Target clock speed in MHz (50)
We will use the default of 50 Mhz as we have specified 0.65 ?m technology.
Clock skew for synthesis (±0.4 ns):
The default of ±0.7 ns will be used for this example.
Library for extensions logic? (user)
Here the user can specify a name for his user's library. This name will be used during the install when creating two directories and copying subsequent files to these directories. The string entered is arbitrary so we will enter ‘tom’.
Simulation
Selection of the state of the ARC on reset is important since it is preferable to have the system build start on reset while the core build should halt on reset since the host effectively clears the halt bit during simulation. Do you wish to halt the ARC at address-location 0 on reset (y):
We have entered ‘y’ here, that means the ARC is halted immediately on reset. Had we selected ‘n’ the ARC starts running the code at address 0 on reset.
The defaults are ‘Y’ for a core build and ‘N’ for generic and ARCAngel builds.
Note you will have to set the status register to the appropriate start address and clear the halt bit through the host interface before running the simulation. You can manually edit “arc_start” in xaux_regs.vhdl so that the ARC is running following a reset.
Having selected ‘y’ the above information message is displayed.
Is your VHDL simulator Model Technologies VSystem? (y):
At ARC Cores we enter ‘y’ as we use MTI VSystem to simulate our VHDL If the user use a different simulator, select no. The user may set his environment up for his simulator by editing the makefile and other support files, after the install has completed.
Install Directory
Full path to ARC user working directory (/home/someone/verifyarc):
At this prompt the user have to specify a destination directory name (with full path). The path must not include/tmp_mnt/etc.
We will select the default, a directory named “verifyarc” created where we launched the ARC system builder.
What we have built:
Once the script has completed the install, the base case/ARCAngel build generates files for simulation and synthesis. The Generic builder can generate files for simulation provided all the required memory extensions are selected. For all types of build the VHDL that the user can modify has been included in the directory ‘./vhdl’
For simulation a makefile is auto-generated to compile all the selected VHDL for the MTI VSystem simulator. Type ‘make’ to build database, see makefile header for information on using the makefile with other simulators. To simulate, simply type ‘coretest’. This runs the Model Technologies simulator from the command line. The behavior of the ARC core is displayed in the form of a pipeline diagram (SEE
Upon conclusion the user is made aware whether the test being simulated passed or failed.
To synthesize, type ‘syn_arc’, which runs the synthesis scripts for Synopsys Design Compiler.
Simulation Display
Example of Pipeline diagram.
The ARCAngel build allows the designer to simulate and synthesize an ARC to the FPGA on the ARCAngel development board so that extensions and other features that have been added can be debugged. The generic build is similar however memory extensions can be added in addition to the core extensions. This build allows the designer to simulate most variations although certain combinations provide ‘Dummy’ blocks for the designer to add their own functionality. The generic system can be *synthesized from auto-generated scripts for the Synopsys Design Compiler. To simulate, simply type ‘asictest’.
To run code in the Generic or ARCAngel builds
First—we need to have produced a Mentor-quicksim format HEX file from the Metaware tools—This has already been done for basecase and extensions test code, since the basecase memory models read these files. The system builds are also capable of reading hex files, however, the user must be aware that test code generated must Upon conclusion (when the ARC has been halted) the user is made aware whether the test being simulated passed or failed. This is accomplished by reading the contents of the Status register via the host port to check whether the Zero flag has been set.
Core Verification system build
The Core verification system defaults to settings that allow the user to simulate, synthesize and verify the ARC core. For more information see the ARC core verification overview document.
4.2 Running Extensions Test Code
When an installation has been completed, the simulation is set up to run the basecase test code. The VHDL reads a file ‘init_mem.hex’ from the working directory that contains a memory image of the test program. Compiling the extensions test source code (testxalu.s) with the script mw.bat created these files.
Memory image Tests
For example, to test an ARC configured with the barrel shifter block, do the following from the working directory:
rm init_mem.hex ln -s $ARCHOME/exts/src/metaware/x_bshift.hex init_mem.hex
Now run the VHDL simulation. To replace the link to the basecase test code:
rm init-mem.hex ln -s $ARCHOME/arc/src/coretest.hex init_mem.hex
Single Step Tests (For Core Build)
The standard testbench runs the code provided in init_mem.hex, and then runs it again, single stepping each of the instructions. Editing the file vhdl/memcon2.vhdl can disable this. Altering the signal assignment of no_step_test to supply the value ‘1’ does this.
Tests (For Generic/ARCAngel Build)
The standard testbench runs code provided in init-mem.hex. Modifying the variable do_pc_test to ‘1’ in glue.vhdl can also set the PC test, provided that the hex file $ARCHOME/exts/src/metaware/aa.hex is used. Note that single step instruction mode for test code can be enabled by modifying the variable no_step-test to ‘0’ in glue.vhdl. The single stepping feature is executed only when the test code has been successfully run in normal operation mode.
To create further additions to the test the user can use the METAWARE HighC compiler. The core build can read the output from the METAWARE tool set directly, i.e. HEX format files. The ARCAngel/generic builds also read the HEX format files output by HighC.
Cache Test Code
Test code has been provided to allow the cache logic to be tested. It must be edited by the user to set the cache size which is in use. Make a subdirectory under his working area, and copy the appropriate files into it:
Now edit the test code file cache.s to set the CACHESIZE variable to the appropriate value, and recompile the code. This will require a certain amount of copying files between PC and Sun systems if the Metaware tools are not available on the Sun system.
The user may now either link cache.hex to init_mem.hex for his specific build, i.e. core or system. The designer can edit the files in the VHDL directory to modify or add features to the ctension core logic:
There are memory extension files that can be edited. Depending on the user's selection, files that can be edited are as follow:
The synthesis scripts and support files can also be edited:—
If additional files are added to the hierarchy then the makefile must be modified to reflect this.
Command Line Parameters
-mti Compile for use with MTI Vsystem.
The present application claims priority to U.S. Provisional Patent Application Ser. No. 60/104,271, entitled “Method and Apparatus for Managing the Configuration and Functionality of a Semiconductor Design” filed Oct. 14, 1998.
| Number | Date | Country | |
|---|---|---|---|
| 60104271 | Oct 1998 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09418663 | Oct 1999 | US |
| Child | 11067086 | Feb 2005 | US |
