U.S. patent application number 11/067086 was filed with the patent office on 2005-07-07 for method and apparatus for managing the configuration and functionality of a semiconductor design.
Invention is credited to Hakewill, James Robert Howard, Khan, Mohammed Noshad, Plowman, Edward.
Application Number | 20050149898 11/067086 |
Document ID | / |
Family ID | 34197395 |
Filed Date | 2005-07-07 |
United States Patent
Application |
20050149898 |
Kind Code |
A1 |
Hakewill, James Robert Howard ;
et al. |
July 7, 2005 |
Method and apparatus for managing the configuration and
functionality of a semiconductor design
Abstract
A method of managing the configuration, design parameters, and
functionality of an integrated circuit (IC) design using a hardware
description language (HDL). Instructions can be added, subtracted,
or generated by the designer interactively during the design
process, and customized HDL descriptions of the IC design are
generated through the use of scripts based on the user-edited
instruction set and inputs. The customized HDL description can then
be used as the basis for generating "makefiles" for purposes of
simulation and/or logic level synthesis. The method further affords
the ability to generate an HDL model of a complete device, such as
a microprocessor or DSP. A computer program implementing the
aforementioned method and a hardware system for running the
computer program are also disclosed.
Inventors: |
Hakewill, James Robert Howard;
(Radlett, GB) ; Khan, Mohammed Noshad; (Edgware,
GB) ; Plowman, Edward; (Gamlingay, GB) |
Correspondence
Address: |
GAZDZINSKI & ASSOCIATES
Suite 375
11440 West Bernardo Court
San Diego
CA
92127
US
|
Family ID: |
34197395 |
Appl. No.: |
11/067086 |
Filed: |
February 25, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11067086 |
Feb 25, 2005 |
|
|
|
09418663 |
Oct 14, 1999 |
|
|
|
6862563 |
|
|
|
|
60104271 |
Oct 14, 1998 |
|
|
|
Current U.S.
Class: |
716/102 ;
712/E9.035; 712/E9.05; 712/E9.062; 712/E9.079; 716/103; 716/104;
716/106 |
Current CPC
Class: |
G06F 30/30 20200101;
G06F 30/00 20200101; G06F 30/327 20200101; G06F 9/30145
20130101 |
Class at
Publication: |
716/018 ;
716/019; 716/011 |
International
Class: |
G06F 017/50 |
Claims
1-51. (canceled)
52. A computer-implemented method of producing at least a portion
of an integrated circuit design, said design including at least one
of a processor or processor peripheral device, the method
comprising the following acts performed by a computer process:
receiving one or more inputs from a user for at least one
customized parameter of the processor or processor peripheral;
generating a customized description language model based on the
least one customized parameter, said act of generating including
the act of modifying at least one prototype description by
substituting or modifying values in the at least one prototype
description, or merging additional descriptions based on the at
least one customized parameter; and generating test code associated
with the customized description language model based at least in
part on the at least one customized parameter; wherein the
customized description language model includes both functional and
structural description language elements for the processor or
processor peripheral.
53. The method of claim 52, wherein said act of merging additional
descriptions comprises merging at least one extension comprising a
predetermined logical function.
54. The method of claim 52, wherein said act of merging additional
descriptions comprises merging at least one custom instruction.
55. The method of claim 52, wherein said one or more inputs
comprise at least one input selected from the group consisting of
(i) overall device or system configuration, (ii) width of the
external memory system data bus, and (iii) cache type/size.
56. The method of claim 52, wherein said act of generating test
code comprises generating configuration register test code.
57. The method of claim 52, wherein said act of generating test
code comprises generating test code based at least in part on one
or more extensions added to said customized description language
model as part of said act of generating said model.
58. The method of claim 52, wherein said processor or processor
peripheral comprises a RISC processor, and said description
language model comprises a VHDL model.
59. The method of claim 58, further comprising causing a first
computer program to write a second computer program adapted to
perform a specific task based at least in part on said user inputs
during said act of generating a customized description language
model.
60. The method of claim 59, further comprising executing said
second program to perform said task.
61. The method of claim 52, further comprising evaluating the
acceptability of said description language model using at least
said test code.
62. The method of claim 52, further comprising testing the
customized description language through simulation or synthesis
using said test code; and if a different testing outcome is
desired, receiving one or more additional inputs and generating a
second customized description language model.
63. The method of claim 52, wherein the method further comprises
conducting a hardware/software co-verification.
64. The method of claim 63, wherein the act of conducting a
hardware/software co-verification further comprises using a
debugger to run software using at least a portion of the
description language model.
65. The method of claim 52, wherein the method further comprises
conducting a core verification as part of the act of generating a
customized description language model.
66. Apparatus configured to produce at least a portion of an
integrated circuit design, said design including at least one of a
processor or processor peripheral device, the apparatus having at
least one computer program comprising: a first module adapted to
receive one or more inputs from a user for at least one customized
parameter of the processor or processor peripheral; a second module
adapted to generate a customized description language model based
on the least one customized parameter, said generating of said
model including modifying at least one prototype description by
substituting or modifying values in the at least one prototype
description, or merging additional descriptions based on the at
least one customized parameter; and a third module adapted for
automated generation of test code associated with the customized
description language model based at least in part on the at least
one customized parameter; wherein the customized description
language model includes both functional and structural description
language elements for the processor or processor peripheral.
67. The apparatus of claim 66, wherein said apparatus further
comprises a processor, display device, internal memory, and input
device.
68. The apparatus of claim 66, wherein said one or more inputs
comprise at least one input selected from the group consisting of
(i) overall device or system configuration, (ii) width of the
external memory system data bus, and (iii) cache type/size.
69. The apparatus claim 66, wherein said test code comprises
configuration register test code.
70. The apparatus of claim 66, wherein said test code is generated
based at least in part on one or more extensions added to said
customized description language model as part of said act of
generating said model.
71. The apparatus of claim 66, wherein said processor or processor
peripheral comprises a RISC processor, and said description
language model comprises a VHDL model.
72. The apparatus of claim 66, further comprising a first computer
program which writes a second computer program adapted to perform a
specific task based at least in part on said user inputs.
73. The apparatus of claim 72, wherein said apparatus further
automatically executes said second program to perform said
task.
74. The apparatus of claim 66, further comprising a module
configured to evaluate the acceptability of said description
language model using at least said test code.
75. The apparatus of claim 66, further comprising a module adapted
to test the customized description language through simulation or
synthesis using said test code; wherein if a different testing
outcome is desired, said apparatus is further configured to receive
one or more additional inputs and cause generation of a second
customized description language model.
76. The apparatus of claim 66, further comprising a module adapted
to conduct a hardware/software co-verification.
77. The apparatus of claim 76, wherein the act of conducting a
hardware/software co-verification further comprises using a
debugger to run software using at least a portion of the
description language model.
78. The apparatus of claim 66, further comprising a module adapted
to conduct a core verification as part of the generation of said
customized description language model.
79. A computer-implemented method of generating a hardware
description language (HDL) model of an integrated circuit design,
said design including at least one of a processor or processor
peripheral device, the method comprising the following acts
performed by a computer process: receiving one or more inputs from
a user for at least one customized parameter of the processor or
processor peripheral; generating a customized description language
model based on the least one customized parameter, said act of
generating including the act of modifying at least one prototype
description by substituting or modifying values in the at least one
prototype description, or merging additional descriptions based on
the at least one customized parameter; and generating test code
associated with the customized description language model based at
least in part on the at least one customized parameter; wherein the
customized description language model includes both functional and
structural description language elements for the processor or
processor peripheral; wherein said act of merging additional
descriptions comprises merging at least one custom instruction; and
wherein said act of generating test code comprises generating test
code based at least in part on one or more extensions added to said
customized description language model.
80. The method of claim 79, wherein said acts of generating both
comprise generating via an automated process.
81. The method of claim 80, wherein said one or more inputs
comprise at least one input selected from the group consisting of
(i) overall device or system configuration, (ii) width of the
external memory system data bus, and (iii) cache type/size.
82. The method of claim 80, wherein said act of generating test
code comprises generating configuration register test code.
83. The method of claim 80, wherein said processor or processor
peripheral-comprises a RISC processor, and said description
language model comprises a VHDL model.
84. The method of claim 80, further comprising causing a first
computer program to write a second computer program adapted to
perform a specific task based at least in part on said user inputs
during said act of generating a customized description language
model.
85. The method of claim 84, further comprising executing said
second program to perform said task.
86. The method of claim 79, further comprising evaluating the
acceptability of said description language model using at least
said test code.
87. The method of claim 79, further comprising testing the
customized description language through simulation or synthesis
using said test code; and if a different testing outcome is
desired, receiving one or more additional inputs and generating a
second customized description language model.
88. The method of claim 79, wherein the method further comprises
conducting a hardware/software co-verification.
89. The method of claim 88, wherein the act of conducting a
hardware/software co-verification further comprises using a
debugger to run software using at least a portion of the
description language model.
90. The method of claim 80, wherein the method further comprises
conducting a core verification as part of the act of generating a
customized description language model.
91. A method of producing at least a portion of an integrated
circuit design, said design including at least one of a processor
or processor peripheral device, the method comprising: receiving
one or more user inputs for at least one configuration parameter of
the processor or processor peripheral; generating a customized
description language model based on the least one configuration
parameter, said act of generating including the act of modifying at
least one of an existing description by substituting or modifying
values in the at least one existing description; and generating
test code associated with the customized description language
model; wherein the customized description language model includes
both functional and structural elements for the processor or
processor peripheral.
92. The method of claim 91, wherein said functional and structural
elements comprise functional description language elements and
structural description language elements, respectively.
93. The method of claim 91, wherein said act of substituting or
modifying comprises merging at least one additional description
based on the at least one configuration parameter.
94. The method of claim 91, wherein said method is performed
interactively using a computer program.
95. The method of claim 94, wherein said act of receiving comprises
selecting at least one extension for inclusion within said design,
said at least one extension being selected before said act of
generating a customized description language model is
performed.
96. The method of claim 91, wherein said act of receiving comprises
selecting at least one extension for inclusion within said
design.
97. The method of claim 96, wherein said at least one extension is
selected before said act of generating a customized description
language model is performed.
98. The method of claim 93, wherein said act of merging at least
one additional description comprises merging at least one extension
comprising a predetermined logical function.
99. The method of claim 93, wherein said act of merging additional
descriptions comprises merging at least one custom instruction.
100. The method of claim 91, wherein said one or more inputs
comprise at least one input selected from the group consisting of
(i) overall device or system configuration, (ii) width of the
external memory system data bus, and (iii) cache type/size.
101. The method of claim 91, wherein said act of generating test
code comprises generating configuration register test code.
102. The method of claim 91, wherein said act of generating test
code comprises generating test code based at least in part on one
or more extensions added to said customized description language
model as part of said act of generating said model.
103. The method of claim 91, further comprising causing a first
computer program to write a second computer program adapted to
perform a specific task based at least in part on said user inputs
during said act of generating a customized description language
model.
104. The method of claim 103, further comprising executing said
second program to perform said task.
105. The method of claim 91, further comprising evaluating the
acceptability of said description language model using at least
said test code.
106. The method of claim 91, further comprising testing the
customized description language through simulation or synthesis
using said test code; and if a different testing outcome is
desired, receiving one or more additional inputs and generating a
second customized description language model.
107. The method of claim 91, wherein the method further comprises
conducting a hardware/software co-verification.
108. The method of claim 107, wherein the act of conducting a
hardware/software co-verification further comprises using a
debugger to run software using at least a portion of the
description language model.
109. Apparatus configured to produce at least a portion of an
integrated circuit design, said design including at least one of a
processor or processor peripheral device, the apparatus having at
least one computer program comprising: a first module adapted to
receive one or more user inputs for at least one customized
parameter of the processor or processor peripheral; a second module
adapted to generate a customized description language model based
on the least one customized parameter, said generating of said
model including modifying at least one existing description by
substituting or modifying values in the at least one existing
description; and a third module adapted for automated generation of
test code associated with the customized description language
model; wherein the customized description language model includes
both functional and structural elements for the processor or
processor peripheral.
110. The apparatus of claim 109, wherein said functional and
structural elements comprise functional description language
elements and structural description language elements,
respectively.
111. The apparatus of claim 109, wherein said substituting or
modifying comprises merging at least one additional description
based on the at least one configuration parameter.
112. The apparatus of claim 109, wherein said first module is
further adapted to receive a user selection of at least one
extension for inclusion within said design, said at least one
extension being selected before said act of generating a customized
description language model is performed.
113. The apparatus of claim 109, wherein said apparatus further
comprises a processor, display device, internal memory, and input
device.
114. The apparatus of claim 109, wherein said one or more inputs
comprise at least one input selected from the group consisting of
(i) overall device or system configuration, (ii) width of the
external memory system data bus, and (iii) cache type/size.
115. The apparatus claim 109, wherein said test code comprises
configuration register test code.
116. The apparatus of claim 109, wherein said processor or
processor peripheral comprises a RISC processor, and said
description language model comprises a VHDL model.
117. The apparatus of claim 109, further comprising a second
computer program which writes a third computer program adapted to
perform a specific task based at least in part on said user
inputs.
118. The apparatus of claim 117, wherein said second computer
program is integrated with said computer program, and said third
program is automatically executed to perform said task.
119. The apparatus of claim 109, further comprising a module
configured to evaluate the acceptability of said description
language model using at least said test code.
120. The apparatus of claim 109, further comprising a module
adapted to test the customized description language through
simulation or synthesis using said test code; wherein if a
different testing outcome is desired, said apparatus is further
configured to receive one or more additional inputs and cause
generation of a second customized description language model.
121. The apparatus of claim 109, further comprising a module
adapted to conduct a hardware/software co-verification.
122. The apparatus of claim 121, wherein the act of conducting a
hardware/software co-verification further comprises using a
debugger to run software using at least a portion of the
description language model.
123. The apparatus of claim 109, further comprising a module
adapted to conduct a core verification as part of the generation of
said customized description language model.
124. Storage apparatus, comprising: storage media configured to
store at least one computer program; and at least one computer
program stored on said media and configured to produce at least a
portion of an integrated circuit design, said design including at
least one of a processor or processor peripheral device, the at
least one computer program comprising: a first module adapted to
receive one or more user inputs for at least one customized
parameter of the processor or processor peripheral; a second module
adapted to generate a customized description language model having
both structural and functional elements and based on the least one
customized parameter, said generation of said model including
modification of at least one existing description by substituting
or modifying values in the at least one existing description; and a
third module adapted for automated generation of test code
associated with the customized description language model.
125. A method of enabling the generation of at least a portion of
an integrated circuit design, comprising: providing at least one
computer program stored on said media and configured to produce at
least a portion of an integrated circuit design, said design
including at least one of a processor or processor peripheral
device, the at least one computer program comprising: a first
module adapted to receive one or more user inputs for at least one
customized parameter of the processor or processor peripheral; a
second module adapted to generate a customized description language
model having both structural and functional elements and based on
the least one customized parameter, said generation of said model
including modification of at least one existing description by
substituting or modifying values in the at least one existing
description; and a third module adapted for automated generation of
test code associated with the customized description language
model; and enabling said computer program so that it may be
operated on a computerized device.
Description
[0001] 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.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] 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.
[0004] 2. Description of Related Technology
[0005] 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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.RTM.
(VHSIC hardware description language) available from IEEE of New
York, N.Y., or Verilog.RTM. 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. FIG. 1 illustrates
a typical prior art IC design and fabrication approach.
[0010] 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.
[0011] 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.
SUMMARY OF THE INVENTION
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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.
[0017] 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.
[0018] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] FIG. 1 is a flow diagram illustrating a typical prior art
integrated circuit design and synthesis method.
[0020] FIG. 2 is a flow diagram illustrating the general integrated
circuit design and synthesis method of the invention.
[0021] FIG. 2a is a flow diagram illustrating one specific
embodiment of the generalized method of FIG. 2.
[0022] FIGS. 3a-3e collectively comprise a logical flow diagram
illustrating one exemplary embodiment of the architecture module of
the invention.
[0023] FIG. 4 is a logical flow diagram illustrating one exemplary
embodiment of the method of determining the memory and register
configuration of the system under design as shown generally in FIG.
3c herein.
[0024] FIGS. 5a-5h collectively comprise a logical flow diagram
illustrating one exemplary embodiment of the method of configuring
file extensions as shown generally in FIG. 3c herein.
[0025] FIG. 6 is a logical flow diagram illustrating one exemplary
embodiment of the method of setting up the cache structure as shown
generally in FIGS. 5b, 5c, and 5d herein.
[0026] FIG. 7 is a logical flow diagram illustrating one exemplary
embodiment of the method of setting up the load/store interface
structure as shown generally in FIG. 5d herein.
[0027] FIG. 8 is a logical flow diagram illustrating one exemplary
embodiment of the method of setting up the register transfer
language (RTL) link structure as shown generally in FIG. 3d
herein.
[0028] FIG. 9 is a logical flow diagram illustrating one exemplary
embodiment of the method of generating a new script according to
the invention.
[0029] FIG. 10 is a logical flow diagram of one exemplary
embodiment of the method of building a libraries list as shown
generally in FIG. 9.
[0030] FIG. 11 is a logical flow diagram of one exemplary
embodiment of the method of adding the libraries list to the system
"makefile" as shown generally in FIG. 9.
[0031] FIG. 12 is a logical flow diagram of one exemplary
embodiment of the method of adding datafile dependency rules to the
system "makefile" as shown generally in FIG. 9.
[0032] FIG. 13 is a logical flowchart illustrating one exemplary
embodiment of the method of hierarchy file generation according to
the invention.
[0033] FIG. 14 is a logical flowchart illustrating one exemplary
embodiment of the method of reading input files in accordance with
the hierarchy file generation method of FIG. 13.
[0034] FIG. 15 is a logical flowchart illustrating one exemplary
embodiment of the method of reading hierarchy files as shown
generally in FIG. 14.
[0035] FIG. 16 is a logical flowchart illustrating one exemplary
embodiment of the method of reading top level entity data files as
shown generally in FIG. 14.
[0036] FIG. 17 is a logical flowchart illustrating one exemplary
embodiment of the method of reading primary block data files as
shown generally in FIG. 14.
[0037] FIG. 18 is a logical flowchart illustrating one exemplary
embodiment of the method of identifying and integrating new signals
into the block data files as shown generally in FIG. 17.
[0038] FIG. 19 is a logical flowchart illustrating one exemplary
embodiment of the method of verifying data integrity as shown
generally in FIG. 13.
[0039] FIG. 20 is a logical flowchart illustrating one exemplary
embodiment of the method of adjusting signal types relative to the
block data files as shown generally in FIG. 13.
[0040] FIG. 21 is a logical flowchart illustrating one exemplary
embodiment of the method of checking for "in" or "out" signals as
shown generally in FIG. 20.
[0041] FIG. 22 is a logical flowchart illustrating one exemplary
embodiment of the method of generating the merged hardware
description language (HDL) file according to the invention.
[0042] FIG. 23 is a logical flowchart illustrating one exemplary
embodiment of the method of reading the HDL control file as shown
generally in FIG. 22.
[0043] FIG. 24 is a logical flowchart illustrating one exemplary
embodiment of the method of reading the HDL top level entity data
file as shown generally in FIG. 22.
[0044] FIG. 25 is a logical flowchart illustrating one exemplary
embodiment of the method of reading the HDL dependency data file as
shown generally in FIG. 22.
[0045] FIG. 26 is a logical flowchart illustrating one exemplary
embodiment of the method of processing the signal record as shown
generally in FIG. 25.
[0046] FIG. 27 is a logical flowchart illustrating one exemplary
embodiment of the method of processing the signal list into groups
as shown generally in FIG. 22.
[0047] FIG. 28 is a logical flowchart illustrating one exemplary
embodiment of the method of verifying data integrity as shown
generally in FIG. 22.
[0048] FIG. 29 is a logical flowchart illustrating one exemplary
embodiment of the method of reading the library file as shown
generally in FIG. 22.
[0049] FIG. 30 is a logical flowchart illustrating one exemplary
embodiment of the method of writing the HDL file as shown generally
in FIG. 22.
[0050] FIG. 31 is a perspective view of one exemplary embodiment of
an integrated circuit design apparatus according to the
invention.
[0051] FIG. 32 is a top plan view illustrating the layout of one
exemplary embodiment of a processor-based integrated circuit
designed using the method of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0052] Reference is now made to the drawings wherein like numerals
refer to like parts throughout.
[0053] 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.
[0054] 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.RTM..
[0055] Background of "ARC.TM."
[0056] In the following discussion, the term "ARC.TM." (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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] Detailed Description of Method
[0063] Referring now to FIG. 2, one embodiment of the generalized
method of the invention is described. While this description is
presented in terms of an algorithm or computer program running on a
microcomputer or other similar processing device, it can be
appreciated that other hardware environments (including
minicomputers, workstations, networked computers, "supercomputers",
and mainframes) may be used to practice the method 100.
Additionally, one or more portions of the computer program may be
embodied in hardware or firmware as opposed to software if desired,
such alternate embodiments being well within the skill of the
computer artisan.
[0064] 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.
[0065] 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.
[0066] In step 104 of the method of FIG. 2, the technology library
location for each VHDL file is defined by the user. The technology
library files in the present invention store all of the information
related to cells necessary for the synthesis process, including for
example logical function, input/output timing, and any associated
constraints. In the present invention, each user can define his/her
own library name and location(s), thereby adding further
flexibility.
[0067] 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 FIGS. 3a-3e. It will be recognized
that such user input may be in the form of an interactive software
prompt, or alternatively may occur using command line parameters,
by accessing a pre-built configuration file, or a concurrently
running application or other computer program resident on the
designer's system or another system linked thereto. Many other
methods of input are also possible, all of which are considered to
be within the scope of the invention.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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 FIG. 2) if
desired to synthesize the logical design into a physical
structure.
[0072] Appendix I illustrates the operation of an algorithm
utilizing the method of FIG. 2. In Appendix I, several explicit
examples illustrating various menu structures, design
considerations, and user input options are presented. Note that
these examples are merely illustrative of the general process
performed by the user in practicing the method of the present
invention using the VHDL software embodiment set forth herein.
[0073] Appendix II is a list of the VHDL script files used in
conjunction with the VHDL embodiment of the algorithm of the
present invention.
[0074] 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.sup.++. 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.
[0075] Referring now to FIG. 2a, one specific embodiment of the
general method of FIG. 2 is described. In this embodiment, certain
steps of the method depicted in FIG. 2 are separated into
constituent parts for illustration purposes. For example, step 102
of FIG. 2 is separated into an interactive ("Wizard.TM.") component
and a hierarchy generator ("hiergen") component (not shown). The
interactive component of step 102 provides substantially all of the
direct user interaction control. Through a series of questions
answered by the user, the program selects the relevant design
elements necessary to realize the user's design. Portions of this
information are used by the hierarchy generator to create a
makefile script that is executed to build the HDL hierarchy.
[0076] Similarly, the step 104 of defining the library location for
each VHDL file in FIG. 2 corresponds to the steps of (i) creating a
working directory 204, (ii) copying files from a master database
206, and merging the selected extension VHDL modules into
placeholder files 208. The remainder of method 100 depicted in FIG.
2a generally parallels that of FIG. 2.
[0077] 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 FIG. 2, each of which results in the
same or similar sets of scripts, makefiles, and other design data
for a given set of input data. Further, it may be advantageous for
additional data or partitionings to be selected in order to utilize
commonly available tools for executing portions of the method 100.
Also, the order of performance of several of the individual steps
present in the method of FIG. 2 (and FIG. 2a) may be permuted
without departing from the invention as disclosed herein.
[0078] Referring now to FIGS. 3a-3e, one embodiment of the
architecture functionality of the invention ("ARChitect.TM.") is
described in detail. The architecture module essentially gathers
information about the designer's system, including for example,
specifications from the designer's libraries, and assembles this
information for later use by other modules within the program. The
output of the ARChitect.TM. process is an HDL synthesizable model
of the IC under design.
[0079] As shown in FIG. 3a, the process 300 specifically employed
by the ARChitect.TM. module comprises a series of steps, the first
of which is initializing the program and setting default values
302. Next, a destination directory is created in step 304 for the
HDL (in this case VHDL) files to be generated in subsequent steps.
In step 306, the technology/feature size is obtained from the user
(or another source, as previously described). For example, the user
may desire a 0.18 micron process for their design.
[0080] 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.
[0081] Referring now to FIG. 3b, the process 300 continues with
steps 316 and 318, wherein the clock skew is selected (or otherwise
defaulted). The extensions logic library name/location is then
obtained from the user in step 320. As used herein, the term
extensions" refers to a set of predetermined logical functions. For
example, extensions within the ARC system may include rotate,
arithmetic and logical shifts within the barrel shifter, small
multi-cycle multiply, MAC function, swap function (for swapping
upper and lower bytes), timer interrupt, and the like. Lastly, in
steps 322-328, the need or user desire for a memory subsystem such
as a scratchpad RAM is analyzed (based on the user's technology
choice), and the memory subsystem values are set accordingly.
[0082] Referring now to FIG. 3c, the method 300 continues with step
330, wherein the user's manufacturer code (specific to each user
entity) and version are obtained from the user. In step 332, the
memory bus and register file configuration required for the design
are determined; see the discussion of FIG. 4 herein for further
details of this process. Once the memory/register configuration is
determined; the user is prompted in step 334 to determine if the
use of fast load returns is desired. As used herein, the term "fast
load returns" refers to the condition in which the processor
initiates a load operation but continues other execution before the
load has been confirmed as being completed. Steps 336-338 allow the
user to enable/disable this functionality, respectively, as
desired.
[0083] Next, in step 340, the system configures the extensions used
with the design as specified in step 320 described above. FIGS.
5a-5h depicts this process in greater detail, as discussed further
below. The user's choice of technology (step 306) is then examined
in step 342 to determine if clock gating is allowed; if so, the
user is prompted for a clock gating flag in step 344.
[0084] Referring now to FIG. 3d, the user is next prompted for a
series of inputs including the desired reset action (i.e., "halt"
or "run") per step 346, simulator choice (step 348), and pipeline
display options (step 350). In step 352, the setup parameters for
the register transfer link (RTL) and SeeCode Application Link
("RASCAL.TM.") are defined, as discussed in greater detail below
with reference to FIG. 8. RASCAL.TM. is a utility module available
from ARC Cores, Ltd. that connects the debugger module to the MTI
simulator. This connection allows the debugger to control the
simulation of code on the IC system model in the MTI simulator for
hardware/software co-verification. The output directories for the
files are then created in step 354.
[0085] Referring now to FIG. 3e, the configuration is compiled, the
core configuration registers and configuration register test code
are set up per step 356. Next, in step 358, the functional HDL
files are generated by (i) copying prototype files; (ii)
substituting chosen and calculated values where required; and (iii)
merging in the HDL where required. Note that in the illustrated
embodiment, only the prototype files actually required for the
selected configuration are copied.
[0086] 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.
[0087] Referring now to FIG. 4, one exemplary embodiment of the
method of determining the memory and register configuration of the
system under design as shown generally in step 332 of FIG. 3c is
described. The method 400 comprises an initial determination in
step 402 of whether the bus parameters are dictated by the
technology previously chosen in step 306 (FIG. 3a). If the chosen
technology requires specific bus values, these values are set in
step 404. If not, (or alternatively, after setting the bus values
in step 404), it is next determined whether core verification was
requested by the user (steps 406, 407). If not, and the technology
selected does not dictate the bus values, then the user is prompted
to provide the desired bus widths in step 408. The memory values
appropriate to the selected bus width are then set in step 410, and
the user prompted for the desired register file configuration in
step 412.
[0088] 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.
[0089] 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.
[0090] Referring now to FIGS. 5a-5h, one exemplary embodiment of
the method of configuring file extensions as shown generally in
step 340 of FIG. 3c herein is described. As illustrated in FIG. 5a,
the method 500 comprises first choosing one or more extensions
library files in step 502 based on the technology initially
selected and the memory subsystem configuration previously
discussed. In step 504, the chosen extensions library file(s) are
read. A list of available extensions compatible with the selected
technology, memory subsystem configuration, and core verification
choices is then built in step 506. Next, the user is prompted for
specific core extension choices and associated parameters in step
508. Specifically, extensions include core registers, ALU
extensions that provide more operations, auxiliary registers,
condition codes, FIFO (first in-first out memory), increasing the
number of pending load/stores that may be issued, and interrupts.
After the user input has been received in step 508, each of the
user core extension choices is analyzed to determine if it is
compatible with the other choices made by the user (step 510). If
so, the values required by those user selected core extensions are
set in step 512. Note that the selection of some extensions will
require the selection of other extensions which are needed for
support functions. If not, the extension algorithm 500 is aborted
in step 514, and restarted. It will be recognized that step 510
herein may be accomplished interactively, such that when the user
is making selections in step 508, they will be immediately apprised
of the compatibility of the extensions chosen. Alternatively, the
method 500 may be structured such that the system will not allow
incompatible choices, either by prompting the user to make another
selection, or only presenting the user with compatible choices to
choose from. (such as on a display menu). Many other approaches are
possible as well.
[0091] Referring now to FIG. 5b, the method 500 continues with step
516, wherein the user's choice of technology is examined to
determine whether it permits the choice of memory extensions
(versus core extensions, as previously described). If no choice of
memory extensions is allowed, the required memory extension values
are set per step 518, the cache values set up per step 520, and the
load/store interface configuration set up per step 522.
[0092] If a choice of memory extensions is allowed per step 516,
the method of FIG. 5c is utilized. As shown therein, the existence
of a memory subsystem is next determined in step 524. If no memory
subsystem exists, values consistent with no memory interface are
set in step 526. Next, the user is queried if an instruction cache
is desired in step 528; if no, the values for a core build only
(i.e., no memory interface) are set in step 530. If yes, a cache
random access memory (RAM) and direct mapped cache controller
(DMCC) are added (step 532), "instruction fetch" extension is added
to list of selected extensions (step 534), and the cache is set up
(step 536), as further described with reference to FIG. 6
herein.
[0093] If a memory subsystem does exist in step 524, the desired
memory extensions are obtained from the user in step 538.
[0094] Referring now to FIG. 5d, the method 500 continues by
setting up the load/store interface in step 540. The method of step
540 is described in greater detail with respect to FIG. 7 herein.
Upon completion of step 540, the algorithm determines in step 542
whether an instruction fetch was selected by the user. If so, the
algorithm again determines whether a memory subsystem exists (step
544); if so, the user is queried in step 546 as to the type of
instruction fetch system desired. If the type of instruction fetch
system is a "cache", the algorithm then adds a cache RAM and DMCC
to the configuration per step 548, and sets up the cache in step
550 as in step 536 previously described. If the type of instruction
fetch selected in step 546 is a "dummy", then the algorithm
proceeds to step 552 of FIG. 5e. Note that if no instruction fetch
was selected in step 542, or no memory subsystem exists in step
544, the algorithm proceeds to step 552 as well.
[0095] Referring now to FIG. 5e, the method 500 continues with step
552 in which the initial choice of technology by the user (step
306) is examined to determine whether the choice of a memory
arbiter is allowed. If yes, the existence of a memory subsystem is
then determined in step 554. If no choice of memory arbiter is
allowed, or if there is no memory subsystem, the algorithm then
determines whether the choice of RAM sequencer is allowed for the
chosen technology in step 556. Note that in step 544, if a memory
subsystem is allowed, then the algorithm queries the user to
specify the memory arbiter and channels desired.
[0096] 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 FIG. 5f. Similarly, if no choice
of RAM sequencer is permitted by the technology in step 556, the
algorithm proceeds to step 562.
[0097] Referring now to FIG. 5f, the extensions selection algorithm
continues at step 562, wherein again the existence of a memory
subsystem is determined. If a memory subsystem does exist, the
existence of a memory arbiter is queried in step 564. If a memory
arbiter exists, then the existence of a memory sequencer is
determined in step 566. If a memory sequencer exists, the existence
of an instruction fetch is determined in step 568. After step 568,
the algorithm executes a branch return back to step 342 of FIG. 3c.
If no memory subsystem exists per step 562, a branch return to step
336 of FIG. 3c is also executed. If no sequencer exists per step
566, the algorithm proceeds to step 574 of FIG. 5g. If no
instruction fetch exists per step 568, then the algorithm proceeds
to step 576 of FIG. 5g.
[0098] 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 FIG. 5h. If not, then step 582 of FIG. 5h
is selected.
[0099] Referring now to FIG. 5g, step 574 comprises adding a dummy
SRAM sequencer. After the dummy sequencer has been added, the
algorithm determines whether an instruction fetch exists in step
578. If yes, a branch return is executed. If no, a dummy
instruction fetch interface is added per step 579. If no
instruction fetch exists per step 572 of FIG. 5f, an instruction
fetch channel is added to the arbiter per step 576 of FIG. 5g, and
a dummy instruction fetch interface added per step 579.
[0100] Referring now to FIG. 5h, step 580 comprises adding an
miu(1) (external memory instruction fetch) interface for addressing
external memory during instruction fetch. Alternatively, in step
582, an miu(4) interface and cache default values are added. Upon
completion of step 580 or step 582, the algorithm determines in
step 584 whether slide pointers or a scratch RAM was chosen by the
user. If either was chosen, a scratchpad RAM is added per step 586,
and slide pointers added to the build (as appropriate per steps 588
and 590.
[0101] Referring now to FIG. 6, one exemplary embodiment of the
method 600 of setting up the cache as previously discussed with
respect to FIGS. 5b, 5c, and 5d herein is described. In a first
step 602, the type of instruction cache to be used is obtained from
the user. In the illustrated embodiment, the user may specify cache
size, memory width, line size, and operation mode (such as debug
and bypass), although other choices are possible. Next, in step
604, the values for the chosen cache type are read and stored as
appropriate for later use.
[0102] Referring now to FIG. 7, one embodiment of the method 700 of
setting up the load/store interface per FIG. 5d herein is
described. First, the load/store memory controller size is obtained
from the user per step 702; the values associated with the selected
controller size are then obtained from the appropriate file and
stored in step 704.
[0103] Referring now to FIG. 8, one exemplary embodiment of the
method 800 of setting up the register transfer language structure
(e.g., RTL and SeeCode Link, or RASCAL.TM.) as shown generally in
FIG. 3d herein is described. The method 800 first determines in
step 802 whether a core verification was selected by the user; if a
core verification was selected, a branch return to step 354 (FIG.
3d) is executed. If no core verification was selected, the method
800 then determines what simulator choice has been made by the user
in step 804. If no choice has been made, the system "testbench"
function (a simulation environment with test vectors) is set to
"standalone" mode, and the RTL and SeeCode Link disabled per step
806. If some choice (other than "none") has been made, the user is
prompted in step 808 to determine whether the aforementioned RTL
link is desired; if not, the testbench function is set per step
806. If the RTL link is desired, the existence of a memory
subsystem is again determined per step 810, and the values for
either a generic build with the RTL link (step 812) or the core
build with RTL link (step 814) set as appropriate. Upon completion
of the RTL setup method 800, a branch return to step 354 is
executed.
[0104] FIG. 9 illustrates one exemplary embodiment of the method
900 of generating a new script according to the invention. First,
the hierarchy file representative of the physical hierarchy of the
design is read per step 902. Next, the applicable library file is
read in step 904. In step 906, a list of the libraries used in
conjunction with the design is built, as described in greater
detail with reference to FIG. 10 herein. After the libraries list
is built, an output makefile is created in step 908, and the
constant headers written to the created makefile. In step 910, the
aforementioned libraries list is added to the makefile as described
in detail with reference to FIG. 11 herein. Next, the "top-level"
rule is added to the makefile in step 912. As used herein, the
top-level rule relates to those rules specified by the hardware
description language (such as VHDL or Verilog), although it will be
appreciated that others rule bases may be used.
[0105] 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 FIG. 12
herein. Lastly, the physical hierarchy generation control file rule
is added to the makefile to complete the latter.
[0106] Referring now to FIG. 10, one exemplary embodiment of the
method 1000 of building a libraries list as shown generally in step
906 of FIG. 9 is described. In a first step 1002, each block
present in the design is analyzed; if the read block's library is
presently within the libraries list (step 1004), the next block is
read and similarly checked. Note that as used herein, the term
"block" refers to a logical entity having a particular function,
such as an adder or multiplier. If the required block library is
not in the list, that library is added per step 1006. This process
1000 is repeated until all blocks have been analyzed and the
presence of their required libraries verified in the libraries
list.
[0107] Referring now to FIG. 11, one exemplary embodiment of the
method 1100 of adding the libraries list to the system "makefile"
as shown generally in step 910 of FIG. 9. Specifically, the method
1100 comprises reading each library per step 1102, and writing the
library name and path to the aforementioned makefile per step 1104.
The algorithm returns to step 912 of FIG. 9 when all of the
required library information has been added to the makefile.
[0108] FIG. 12 illustrates one embodiment of the method of adding
datafile dependency rules to the system "makefile" as shown
generally in step 914 of FIG. 9. Specifically, each block is read
in step 1202, and the dependency rules are written to a file in
step 1204 to extract that block from its library. When all
dependency rules have been written, the algorithm returns to step
916 of FIG. 9. This completes the script generation process
900.
[0109] Referring now to FIG. 13, one exemplary embodiment of the
method 1300 of hierarchy file generation according to the invention
is described. In step 1302, the library file name and top level
block name are obtained. Next, in step 1304, the input files are
read as described in detail with respect to FIG. 14 herein. Next,
the integrity of the data read is verified in step 1306; see FIG.
19 for additional detail. Then, for each intermediate block, a
subsumption map is built (step 1308). In step 1310, an I/O list is
built for each intermediate block as further described with
reference to FIG. 20 herein.. In step 1312, the "in", "out", and
"inout" signals are written to a new data file for each block; the
block ID and architecture type are also written thereto. Next, the
HDL (e.g., "VHDLgen") control file for each block is written in
step 1314. The foregoing three steps 1310, 1312, 1314 are
subsequently performed for each intermediate block until all blocks
have been processed; at this point, the HDL control file for the
top level is written in step 1316.
[0110] 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.
[0111] FIG. 14 illustrates one embodiment of the method 1400 of
reading input files (step 1304) in accordance with the hierarchy
file generation method of FIG. 13. First, the hierarchy file is
read in step 1402. Next, the data file for the top level entity is
read per step 1404. Then, for each primary block, the data file is
read per step 1406. FIGS. 15, 16, and 17 illustrate these steps
1402, 1404, 1406 in detail.
[0112] FIG. 15 illustrates one exemplary embodiment of the method
1500 of reading 5 hierarchy files as shown generally in step 1402
of FIG. 14. For each line in the hierarchy files, the associated
block and list of dependent blocks is read in step 1502 and each
added to the block list in step 1503. When all such lines have been
read, the block list is then split into a separate (i) primary
block list and (ii) intermediate block list, in step 1504.
[0113] Referring now to FIG. 16, one exemplary embodiment of the
method 1600 of reading top level entity data files as shown
generally in step 1404 of FIG. 14 is described. First, each line of
the top level data file is analyzed in step 1602 to determine
whether it describes a signal. If so, then the signal data is
extracted from each line per step 1604. In the illustrated
embodiment, signal data includes, without limitation, "id," "upper
bound," "lower bound," "type," and "direction" information. Next,
in step 1606, the direction of the signal in each line determined
to have a signal present is analyzed; if the signal is outbound,
the top level of the hierarchy is added as the destination of the
signal, and the signal source set to "unknown" per step 1608. If
the signal is not outbound, the signal's destination list is
cleared, and the source of the signal set to the top level per step
1610. This process 1600 is repeated for each line in the top level
data file until all lines have been analyzed.
[0114] FIG. 17 illustrates one exemplary embodiment of the method
1700 of reading primary block data files as shown generally in step
1406 of FIG. 14. Initially, for each primary block, each line of
the associated top level data file is analyzed in step 1702.
[0115] 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 FIG. 16. If the signal has
been read before by the algorithm, and the values associated with
the signal match those previously read, the signal is connected to
the primary block per step 1710. If the signal has not been
previously read, it is added to the signal list per step 1708, and
then connected to the primary block. Note also that if the signal
has been read before but the current values do not match those
previously read, then the algorithm aborts per step 1716.
[0116] 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.
[0117] 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.
[0118] Referring now to FIG. 18, one embodiment of the method 1800
of identifying and integrating new signals into the block data
files as shown generally in FIG. 17 is described. Initially, the
signal type is determined in step 1802. Signal types in the present
embodiment include "in", "out", and "inout". If the signal is an
"in" signal, the signal's source is set to "unknown" in step 1804;
the block is then added as the destination of the signal per step
1805. If an "out" signal, the signal is examined to determine if a
source already exists (step 1806); if yes, the algorithm 1800 is
aborted. If no, the signal's destination list is cleared and the
signal's source set to "block" per step 1808. If the signal's type
is "inout", then the block is set as the destination in step
1805.
[0119] Referring now to FIG. 19, one exemplary embodiment of the
method 1900 of verifying signal data integrity as shown generally
in FIG. 13 is described. First, in step 1902, each signal is
examined to determine if it has an associated destination. If so,
the existence of an associated source is then checked in step 1904.
If both source and destination exist for all signals, the routine
is terminated. If no destination is present for one or more signals
in step 1902, a list of signals without destinations is printed per
step 1906. If all signals have destinations but one or more signals
do not have a source, a list of signals without sources is printed
per step 1908.
[0120] Referring now to FIG. 20, one exemplary embodiment of the
method 2000 of building an I/O list relative to the block data
files as shown generally in FIG. 13 is described. For a given
block, the lists of "in", "out", and "inout" signals are first
cleared per step 2002. Each signal is then checked to determine if
it is an "inout" signal relative to the block in step 2004, as
described in greater detail with reference to FIG. 21 herein. For
each signal with a source inside the subsumption, the signal is
checked in step 2006 to determine if it has a destination outside
the subsumption. If so, the signal is added to the "out" list per
step 2008, and the next signal analyzed. If the signal under
analysis has no source inside the block, or all of its destinations
are inside the subsumption, then the signal is checked to determine
if it has an source outside of the subsumption in step 2010. If so,
and it has at least one destination inside the subsumption (step
2012), then the signal is added to the "in" list per step 2014, and
the next signal subsequently analyzed.
[0121] FIG. 21 is a logical flowchart illustrating one embodiment
of the method 2100 of checking for "in" or "out" signals as shown
generally in FIG. 20. For a given block and signal, the signal type
is checked in step 2102 to determine whether the signal is an
"inout" type`; if the signal is not an "inout" type, the algorithm
returns to FIG. 20. If it is an "inout type, the signal's source is
checked in step 2104 to determine if it is outside of the block,
then whether it has destinations inside the block (step 2106). If
both conditions are met, the signal is added to the inout list per
step 2108. If either one of the conditions is not met, the signal's
source is checked in step 2110 to determine if it is inside of the
block; if so, then the destination is checked in step 2112 to
determine if it is outside of the block.
[0122] Referring now to FIG. 22, one exemplary embodiment of the
method 2200 of generating the merged hardware description language
(HDL) file according to the invention is described.
[0123] 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.
[0124] 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.
[0125] As shown in FIG. 22, the vhdlgen method 2200 comprises first
reading a control file (step 2202), followed by reading the top
level data file (step 2204). These steps 2202, 2204 are described
in greater detail with reference to FIGS. 23 and 24, respectively.
After the top level data file is read, each dependency present is
analyzed by reading the dependency data file (step 2206), as
further illustrated in FIG. 25. After each dependency data file has
been read, the signal list is processed in step 2208 into a
plurality of groups (FIG. 27), the data integrity verified in step
2210 (FIG. 28), the associated library file read in step 2212 (FIG.
29), and the "merged" VHDL file written in step 2214 (FIG. 30).
[0126] Referring now to FIG. 23, one exemplary embodiment of the
method 2300 of reading the HDL control file as shown generally in
step 2202 of FIG. 22 is described. Initially, the library file name
is read from the control file in step 2302. Next, the top level
entity name is read from the control file in step 2304. The control
file is then examined in step 2306 to detemnine if it is at end of
file (eof); if so, the routine is terminated and returns to step
2204 of FIG. 22. If not, the first dependency entity name is read
from the control file in step 2308 and added to the list of
dependent blocks in step 2309. If additional dependencies exist,
they are subsequently read and added to the list of dependent
blocks until the eof condition is met, at which point the routine
returns to step 2204 of FIG. 22.
[0127] FIG. 24 illustrates one exemplary embodiment of the method
2400 of reading the HDL top level entity data file as shown
generally in step 2204 of FIG. 22. Specifically, each record in the
top level data file is examined in step 2402 to determine if it is
a "signal" record; if so, the signal's upper bound, lower bound,
direction, and type are set from the input record in step 2404. The
signal's destination list is also cleared. Next, each signal's
direction (i.e., "in", "out", or "inout") is determined in step
2406; if the direction of a given signal is "out", then the
signal's source is set to "unknown", and "PORT" is added to the
signal's destination list in step 2410. If the signal is "in" or
"inout", then the signal's source is set to "PORT" in step 2412.
Lastly, in step 2414, the signal is added to the signal list, and
the next record in the top level data file subsequently read.
[0128] FIG. 25 illustrates one exemplary embodiment of the method
2500 of reading the HDL dependency data file as shown generally in
FIG. 22. For a given entity, each record in the data file is read
and the type of record determined in step 2502. If the record is a
"signal", data from the signal record is then processed in step
2504 (see FIG. 26 for additional detail on this step). After the
data has been processed, the signal is added to the entity's signal
list in step 2506, and the next record read. Conversely, if the
record read is an "architecture" record, then the architecture of
the dependency for that record is set per step 2510, and then a
subsequent record read. When all records have been read, the
routine is terminated in favor of step 2206 of FIG. 25.
[0129] FIG. 26 illustrates one embodiment of the method 2600 of
processing signal record as previously discussed with respect to
FIG. 25. For the chosen entity, the algorithm 2600 first determines
in step 2602 whether the signal being examined has been read
before; if so, the signal's type and bounds are next examined to
determine whether they match the previous occurrence of the signal
(step 2604). If so, the signal's direction is next analyzed in step
2606 to determine its type. If the signal is an "out" signal, the
source of the signal is then analyzed in step 2608 if a source
exists, the routine is aborted per step 2610. If not, the signal's
source is set to "entity" per step 2612. Conversely, if the signal
is an "out" or "inout" signal, then the entity is added to the
signal's destination list per step 2616.
[0130] 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.
[0131] FIG. 27 illustrates one exemplary embodiment of the method
2700 of processing the signal list into groups as shown generally
in FIG. 22. Specifically, for each signal, the signal's source is
first determined in step 2702; if the signal source is "PORT", then
no further analysis of that signal is required, and the next signal
is analyzed. If the signal's source is "unknown", then the signal
is added to the list of signals with no source in step 2704, and
the next signal analyzed. If the signal source is ""other", the
signal is then analyzed in step 2706 to determine if any
destinations are specified. If there are no destinations specified,
the signal is added to the list of signals without destinations per
step2710. If the signal does have one or more destinations, these
destinations are then examined in step 2712 to determine if any are
destinations other than "PORT". If so, then the signal is added to
the list of intermediate signals per step 2716. Next, in step 2718,
the destinations of the signal are again examined to determine if
any of these destinations are "PORT"; if yes, the signal is further
added to the list of signals requiring output drives in step
2720.
[0132] Referring now to FIG. 28, one exemplary embodiment of the
method 2800 of verifying signal data integrity as shown generally
in FIG. 22 is described. First, in step 2802, each signal is
examined to determine if it has an associated destination. If so,
the existence of an associated source is then checked in step 2804.
If both source and destination exist for all signals, the routine
is terminated. If no destination is present for one or more signals
in step 2802, a list of signals without destinations is printed per
step 2806. If all signals have destinations but one or more signals
do not have a source, a list of signals without sources is printed
per step 2808.
[0133] FIG. 29 illustrates one embodiment of the method 2900 of
reading the library file as shown generally in FIG. 22 herein. For
each record present in the given library file, a determination is
first made in step 2902 as to what type of record is under
analysis; if the record is a "library id", then the status of
setting the "worklib" flag is determined in step 2904. If the flag
has not been set, it is set from the present record per step 2906.
If it has been set, then the next subsequent record is read from
the library. If the record is an "entity" record, the "entity id"
and "library id" are extracted from the record in step 2908, and
the entity's library name is set to "library" in step 2910.
[0134] Lastly, if the record is classified as "other" in step 2902,
then no action is taken and the next subsequent record is read.
[0135] 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.
[0136] Referring now to FIG. 30, one exemplary embodiment of the
method 3000 of writing one or more HDL files as shown generally in
FIG. 22 is described. The VHDL file is written in a sequence of
steps that conform to the specification for VHDL format. It is
noted that other HDL languages may employ differing formats that
result in some information becoming unnecessary, or required in a
different order. The first step 3002 of the illustrated method 3000
comprises writing the VHDL file header to a VHDL file. Next the
list of libraries and packages used is written to the VHDL file in
step 3004. Next the entity declarations are written to the VHDL
file in step 3006. Subsequently the architecture information is
written to the VHDL file in step 3008. In the next step 3010, VHDL
component declarations are written to the VHDL file. The list of
intermediate signals is then written to the VHDL file in step 3012,
and VHDL configuration statements are written to the VHDL file in
step 3014. Then, in step 3016, all component instantiations are
written to the VHDL file. Finally, output drives are written to the
VHDL file in step 3018. This completes the hardware description
language file generation process.
[0137] It is noted that while the foregoing description of FIGS.
2-30 refers to specific embodiments of the various aspects of the
method of the invention, various substitutions, alterations,
permutations, additions, and deletions may be made to the disclosed
method. For example, certain routines disclosed herein may be
selectively employed, or the order in which they are employed with
respect to other routines varied. Similarly, individual steps
within each of the routines may be modified as required by the
particular application.
[0138] Description of the IC Design Apparatus
[0139] Referring now to FIG. 31, an exemplary apparatus capable of
implementing the method of FIGS. 2-32 is described. A stand-alone
microcomputer system 3100 of the type well know in the computer
arts, having a processor 3102, internal or external storage device
3104, display device 3106, internal memory 3108, and input device
3110, is used. The algorithm 100 of FIG. 2, embodied in the form of
a computer program reduced to machine readable object code as is
also well known in the art (not shown), is loaded into the storage
device 3104 and memory 3108 of the system 3100 and run on the
processor 3102 based on inputs provided by the user via the input
device 3110. Alternatively, the computer program may reside on a
removable storage device (not shown) such as a floppy disk or
magnetic data cartridge of the type well known in the art. The
display device 3106, which may comprise for example a cathode ray
tube (CRT), liquid crystal display (LCD), thin film transistor
(TFT), or plasma display, provides the user with a variety of
visual information including representations of the program's menu
structure, and the status and output of various routines or modules
running within the program. See Appendix I for one exemplary
embodiment of the menu structure used in conjunction with the
aforementioned computer program. Wile the illustrated embodiment is
a microcomputer, it will be recognized that other computer types
and architectures may be used with equal success, For example, a
networked minicomputer system or client/server arrangement wherein
data or libraries relating to the design are not resident on the
local system 3100 may be employed, or alternatively, a plurality of
different computers may be used to run parts of the computer
program in parallel. Many varying architectures and
equipment/software configurations may be substituted, consistent
with the general aims of providing an automated, interactive design
process.
[0140] Description of the Integrated Circuit
[0141] Referring now to FIG. 32, an exemplary integrated circuit
developed using the above-described method of the present invention
is disclosed. As shown in FIG. 34, the integrated circuit 3200 is
an ARC microprocessor-like CPU device having, inter alia, a
processor core 3202, on-chip memory 3204, and an external interface
3206. The device is fabricated using the customized VHDL design
obtained using the present invention (step 108 of FIG. 2) which is
subsequently synthesized into a logic level representation, and
then reduced to a physical device using compilation, layout and
fabrication techniques well known in the semiconductor arts. As
previously noted, the designs for a wide variety of other types of
integrated circuits (including, for example, ASICs and FPGAs) can
be synthesized using the method and apparatus set forth herein.
Hence, the CPU-based device of FIG. 32 is merely exemplary of such
devices.
[0142] It will be appreciated by one skilled in the art that the
Integrated Circuit of FIG. 32 may contain any commonly available
microcontroller peripheral such as serial communications devices,
parallel ports, timers, counters, high current drivers, analog to
digital (A/D) converters, digital to analog converters (D/A),
interrupt processors, LCD drivers, memories and other related
peripherals. Further, the Integrated Circuit may also include
custom or application specific circuitry that is specifically
developed to solve a specific applications problem or meet the
needs of a single application. The present invention is not limited
to the type, number or complexity of peripherals and other
circuitry that may be combined using the method and apparatus.
Rather, any limitations are imposed by the physical capacity of the
extant semiconductor processes which improve over time. Therefore
it is anticipated that the complexity and degree of integration
possible employing the present invention will further increase as
semiconductor processes improve.
[0143] It is noted that power consumption of devices such as that
shown in FIG. 34 is significantly reduced due in part to a lower
gate count resulting from better block and signal integration.
Furthermore, the above-described method provides the user with the
option to optimize for low power (or use a low power silicon
process such as Xemics for example). The system may also be run at
a lower clock speed, thereby further reducing power consumption;
the use of one or more custom instructions and/or interfaces allows
performance targets to be met at lower clock speeds.
[0144] 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.
[0145] 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.
[0146] 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.
APPENDIX I
[0147] The following describes and illustrates the operation of the
ARC System Builder Program:
[0148] Installation Script
[0149] Installation script allowing the following ARC features to
be selected:
[0150] ?Extensions required
[0151] ?Cache size
[0152] ?Cache line length
[0153] ?Size of external memory space that is to be cached.
[0154] ?Clock period
[0155] ?Clock skew
[0156] ?Synthesized d-latches or 3-port RAM for register file
[0157] ?Type of technology being used.
[0158] ?Manufacturer code and version number information
[0159] The script creates a working directory for the user, and in
it creates the following:
[0160] VHDL for the extensions selected
[0161] VHDL for a direct mapped I-cache configured to user's
specification
[0162] VHDL test-bench for testing basecase operation and external
interfaces
[0163] VHDL structure to link together all required modules
[0164] Configuration files for Synopsys Design Compiler
[0165] Memory image file containing basecase test code
[0166] Synthesis script for Synopsys Design Compiler v3.4b or
above
[0167] Makefile--set up for the Model Technologies VSystem/VHDL
simulator, but can be altered for use with other simulation
environments.
[0168] The user can select from 4 different types of build:
[0169] Core Build
[0170] Generic System Build
[0171] Altera Build (for ARCAngeI.TM. development board)
[0172] Core Verification System
[0173] After setting up his ARC area, before the user can use the
ARC system builder, several environment variables need to be
set.
[0174] In .cshrc:
[0175] Set ARCHOME environment variable, base of the arc install
tree. Add bin directories to path. Set other environment variables
such as ARC_MANCODE and ARC_MANVER and ARCASIC. (If these variables
are not set the build script will ask for them at run time.)
[0176] e.g.
[0177] setenv ARCHOME/apps/ARC Cores
[0178] setenv ARC_MANCODE <Users Manufacturer code>
[0179] setenv ARC_MANVER <Users selected version number>
[0180] set path=(SARCHOME/arc/bin $path)
[0181] 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.
[0182] 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.
[0183] The ARC System builder script when run produces a series of
text menus/questions.
[0184] Example MENU 1
[0185] 1. Continue.
[0186] 2. Valid selection.
[0187] 3. * Mutually exclusive.
[0188] 4. Mutually inclusive.
[0189] --* Permanently selected.
[0190] N/A Invalid selection.
[0191] 7. * Valid selection
[0192] Please select
[0193] The above menu shows an example menu. The `*` next to a menu
entry indicates that it is selected.
[0194] Continue
[0195] On all the menus that allow multiple selections 1 is always
continue.
[0196] Valid selections
[0197] 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.)
[0198] Mutually exclusive selections (On the same menu)
[0199] 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.
[0200] Mutually inclusive selections (Between menus)
[0201] 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.
[0202] Permanent selections
[0203] 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.
[0204] Invalid selections
[0205] 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.
[0206] Example MENU 2
[0207] 1. Selection 1.
[0208] 2. Selection 2.
[0209] 3. Selection 3.
[0210] 4. Selection 4.
[0211] Please select(3):
[0212] Menu Default
[0213] 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.
[0214] The following describes examples for each of the four types
of build available, Base case, Generic, ARCAngel and Core
verification.
[0215] The first menu the user will encounter for all installations
is the one below:
[0216] ARC System Build Tool--ARC System install.
[0217] (c) 1998 ARC Cores Technologies Ltd.
[0218] Generic install
[0219] 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.
[0220] We're going to make:
[0221] 1. The directory structure
[0222] 2. The structural VHDL levels
[0223] 3. A personalized version of the cache config package
[0224] 4. An optional external memory interface
[0225] 5. Synopsys RAM models for the cache RAMs
[0226] 6. Synthesis scripts
[0227] 7. A simulation makefile
[0228] But first, you must answer some questions:
[0229] Please select the type of system you wish to build.
[0230] 1. Core build with selected extensions
[0231] 2. Generic System Build with selected core/memory
extensions
[0232] 3. Altera Build for ARCAngel Development Board
[0233] 4. Core Verification System.
[0234] Please select (1):
[0235] 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.
[0236] 1. Base case
[0237] 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.
[0238] Instruction/Data Byte Address Selections
[0239] Instruction
[0240] Fetch memory system byte address bus width
[0241] 1. 22 bit (4 Mb)
[0242] 2. 23 bit (8 Mb)
[0243] 3. 24 bit (16 Mb)
[0244] 4. 25 bit (32 Mb)
[0245] 5. 26 bit (64 Mb)
[0246] Please select (3):
[0247] 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.
[0248] The external memory system data bus width is 32 bits
wide
[0249] The external data bus on the ARC is 32-bits wide.
[0250] External memory system address bus width
(22<address<32)(24):
[0251] 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.
[0252] Core Register File Selection
[0253] The 32.times.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.
[0254] Use a synchronous 2r1w RAM for the register file? (y):
[0255] 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).
[0256] Synthesized arrays of d-latches that require a write pulse
to be generated.
[0257] Standard synthesis script assumes a 90.degree.-delayed clock
signal, for the synthesized array of d-latches.
[0258] We will use a synchronous 3-port RAM and so we select y.
[0259] Fast Load Returns
[0260] Enable Fast load returns? (n):
[0261] Fast Load returns, if the current instruction does not use
register write back then the pipeline is not stalled.
[0262] Extensions Builder
[0263] Select the extensions to be added to the ARC
[0264] 1. Continue
[0265] 2. 32.times.32 Barrel shifter--rotate, arithmetic and
logical shifts--1 cycle
[0266] 3. 32.times.32 Barrel shifter--rotate, arithmetic and
logical shifts--Multi-cycle
[0267] 4. Small multi-cycle 32.times.32 Multiply
[0268] 5. Faster (& larger) 32.times.32 Multiply
[0269] 6. 16.times.16 Multiply/Multiply Accumulate function with 36
bit accumulator--Fast
[0270] 7. 16.times.16 Multiply/Multiply Accumulate function with 36
bit accumulator--Slow
[0271] 8. Swap function--swaps upper and lower 16 bits of 32 bit
word
[0272] 9. MIN/MAX function--32 bit precision
[0273] 10. Normalize function--finds first bit set in 32 bit
word
[0274] 11. 24-bit Timer which counts to limit and then generates an
interrupt
[0275] N/A A Scratchpad RAM
[0276] N/A A Scratchpad RAM with Sliding Pointers
[0277] Please select
[0278] The above menu shows all the standard extensions, the user
can select different combinations depending on his needs.
[0279] We will select the single cycle barrel shifter and the
32.times.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.
[0280] 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.times.32 multiplier,
the MAC and both instances of the Scratchpad RAM.
[0281] We will now enter 1 to continue.
[0282] Technology Selection
[0283] Feature size (drawn) of technology in use
[0284] 1. 0.35 um
[0285] 2. 0.5 um
[0286] 3. 0.65 um
[0287] 4. 0.8 um
[0288] 5. 1.0 um
[0289] Please select (5):
[0290] 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.
[0291] The default synthesis script is set-up for the 1.0?m
LSI.sub.--10K library supplied with the Synopsys synthesis
tool.
[0292] 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.
[0293] Target clock speed in MHz (20)
[0294] 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.
[0295] Clock skew for synthesis (.+-.1.5 ns)
[0296] 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.
[0297] Library for extensions logic? (user)
[0298] 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`.
[0299] Memory Extensions
[0300] Do you wish to include a Direct-Mapped Instruction Cache?
(y):
[0301] 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.
[0302] Ifetch Modes
[0303] Select the instruction Cache Modes.
[0304] 1. Continue
[0305] 2. Standard Cache with debug and cache bypass
capability.
[0306] 3. Virtual Cache
[0307] 4. Mixed Code RAM/Icache space & Cache line lock
[0308] The first thing the script needs to know is what kind of
cache do the user want. It's possible to have a:
[0309] 1. Standard Cache
[0310] 2. Virtual cache allows a user to dynamically resize the
cache in software.
[0311] 3. Mixed Code RAM/Icache space with Line locking
[0312] NOTE: Standard Cache and Virtual Cache are mutually
exclusive, and Mixed Code
[0313] 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
[0314] Please select the max size of the Direct Mapped Instruction
Cache.
[0315] 1. 0.5 k bytes, 128 words
[0316] 2. 1 k bytes, 256 words
[0317] 3. 2 k bytes, 512 words
[0318] 4. 4 k bytes, 1024 words
[0319] 5. 8 k bytes, 2048 words
[0320] 6. 16 k bytes, 4096 words
[0321] 7. Other size
[0322] Please select (3):
[0323] 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.
[0324] Please select the min size of the Direct Mapped Instruction
Cache.
[0325] 1. 0.5 k bytes, 128 words
[0326] 2. 1 k bytes, 256 words
[0327] 3. 2 k bytes, 512 words `4. 4 k bytes, 1024 words
[0328] -8 k bytes, 2048 words
[0329] -16 k bytes, 4096 words
[0330] 7. Other size
[0331] Please select (3):
[0332] Virtual Cache requires a range of possible caches and line
lengths so a minimum cache size is required. We will enter 2 512
bytes.
[0333] Select a max Cache line length
[0334] 1. 2 instruction words
[0335] 2. 4 instruction words
[0336] 3. 8 instruction words
[0337] 4. 16 instruction words
[0338] 5. 32 instruction words
[0339] 6. Other
[0340] Please select (3):
[0341] 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.
[0342] Select a max Cache line length
[0343] 1. 2 instruction words
[0344] 2. 4 instruction words
[0345] 3. 8 instruction words
[0346] 4. 16 instruction words
[0347] -32 instruction words
[0348] 6. Other
[0349] Please select (3):
[0350] 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.
[0351] Simulation
[0352] 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):
[0353] 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.
[0354] 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.
[0355] Having selected `y` the above information message is
displayed.
[0356] Is your VHDL simulator Model Technologies VSystem? (y):
[0357] 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.
[0358] Do you wish to use the R.T.L. And SeeCode Application Link
(RASCAL)? (n):
[0359] RTL And See-Code Application Link, otherwise known as
RASCAL.TM., 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.
[0360] Install Directory
[0361] Full path to ARC user working directory
(/home/someone/basearc):
[0362] At this prompt the user have to specify a destination
directory name (with full path). The path must not
include/tmp_mnt/etc.
[0363] We will select the default, a directory named "basearc"
created where we launched the ARC system builder.
[0364] What we have built:
[0365] I-fetch address bus width 24-bit
[0366] external address bus width 29-bit
[0367] register file 3-port RAM
[0368] Fast Load returns `no`
[0369] Extensions Single Cycle Barrel shifter
[0370] Small multi-cycle 32.times.32 multiply
[0371] Clock speed 20 MHz
[0372] Clock skew 1.5 ns
[0373] Technology size 1.0 ?m
[0374] Users library name `alex`
[0375] Direct mapped instruction Virtual
[0376] Max/Min instruction cache size 4K bytes 512 bytes
[0377] Max/Min Cache line length 16 instruction words 2 instruction
words
[0378] Halt ARC on Reset? `yes`
[0379] Destination directory/home/user/basearc
[0380] Simulator=MTI? `yes`
[0381] RASCAL `no`
[0382] 2. Generic
[0383] 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.
[0384] Instruction/Data Byte Address Selections
[0385] Instruction
[0386] Fetch memory system byte address bus width
[0387] 1. 22 bit (4 Mb)
[0388] 2. 23 bit (8 Mb)
[0389] 3. 24 bit (16 Mb)
[0390] 4. 25 bit (32 Mb)
[0391] 5. 26 bit (64 Mb)
[0392] NOTE: If you intend to use the PC parallel communications
host port do not exceed 24-bits
[0393] Please select (3):
[0394] 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.
[0395] 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.
[0396] The external memory system data bus width is 32 bits
wide
[0397] The external data bus on the ARC is set to 32 bits wide.
[0398] External memory system byte address bus width
(22<address<32)(22)
[0399] 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.
[0400] Core Register File Selection
[0401] The 32.times.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.
[0402] Use a synchronous 2r1w RAM for the register file? (y):
[0403] 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.
[0404] Standard synthesis script assumes a 90.degree.-delayed clock
signal.
[0405] We desire a synchronous 3-port RAM and so we select y.
[0406] Fast Load Returns
[0407] Enable Fast load returns? (n):
[0408] 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`.
[0409] Extensions Builder
[0410] Select the extensions to be added to the ARC
[0411] 1. Continue
[0412] 2. 32.times.32 Barrel shifter--rotate, arithmetic and
logical shifts--1 cycle
[0413] 3. 32.times.32 Barrel shifter--rotate, arithmetic and
logical shifts--Multi-cycle
[0414] 4. Small multi-cycle 32.times.32 Multiply
[0415] 5. Faster (& larger) 32.times.32 Multiply
[0416] 6. 16.times.16 Multiply/Multiply Accumulate function with 36
bit accumulator--Fast
[0417] 7. 16.times.16 Multiply/Multiply Accumulate function with 36
bit accumulator--Slow
[0418] 8. Swap function--swaps upper and lower 16 bits of 32 bit
word
[0419] 9. MIN/MAX function--32 bit precision
[0420] 10. Normalize function--finds first bit set in 32 bit
word
[0421] 11. 24-bit Timer which counts to limit and then generates an
interrupt
[0422] 12. A Scratchpad RAM
[0423] 13. A Scratchpad RAM with Sliding Pointers
[0424] Please select:
[0425] The above menu shows all the standard extensions, the user
can select lots of different combinations depending on his
needs.
[0426] 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.
[0427] 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.times.32
multiplier, the MAC and both instances of the Scratchpad RAM.
[0428] We will now enter 1 to continue.
[0429] Technology Selection
[0430] Feature size (drawn) of technology in use
[0431] 1. 0.35 um
[0432] 2. 0.5 um
[0433] 3. 0.65 um
[0434] 4. 0.8 um
[0435] 5. 1.0 um
[0436] Please select (5):
[0437] 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.
[0438] 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.
[0439] Target clock speed in MHz (100)
[0440] We will use the default of 100 Mhz as we have specified 0.35
?m technology.
[0441] Clock skew for synthesis (.+-.0.4 ns):
[0442] The default of 0.4 ns will be used for this example.
[0443] Library for extensions logic? (user):
[0444] 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`.
[0445] Memory Extensions
[0446] Select the memory extensions to be added to the ARC
interface
[0447] 1. Continue
[0448] --* Load/Store memory controller
[0449] 3. * Instruction fetch memory controller
[0450] 4. * Host interface for communications with ARC
[0451] 5. * Arbitration unit for memory accesses
[0452] 6. * RAM Sequencer
[0453] Please select:
[0454] 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.
[0455] The queue depth for the Load/Store Memory Controller is
fixed, i.e. 4 deep with a max of 2 stores.
[0456] Having continued the above information message is
displayed.
[0457] Ld/St Memory Controller Select
[0458] RAM for local load/store operations.
[0459] 1. No Local RAM
[0460] 2. 512.times.32 bit of Local RAM
[0461] 3. 1024.times.32 bit of Local RAM
[0462] 4. 2048.times.32 bit of Local RAM
[0463] 5. 4096.times.32 bit of Local RAM
[0464] Please select (3):
[0465] 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].
[0466] I-Fetch Memory Controller Select
[0467] type of Instruction Fetch memory system
[0468] 1. Dummy I-fetch unit for User Definition
[0469] 2. Direct Mapped Cache
[0470] Please select (2):
[0471] There are several different ways in which the instruction
fetch memory system can be defined.
[0472] 1. Dummy I-fetch, creates a template VHDL file for the user
to edit.
[0473] 2. Direct mapped cache.
[0474] We are using the default, 2, Direct Mapped Cache.
[0475] Ifetch Modes
[0476] Select the instruction Cache Modes.
[0477] 1. Continue
[0478] 2. Standard Cache with debug and cache bypass
capability.
[0479] 3. Virtual Cache
[0480] 4. Mixed Code RAM/Icache space & Cache line lock
[0481] Please select
[0482] The first thing the script needs to know is what kind of
cache do the user want. It's possible to have a
[0483] 1. Standard Cache
[0484] 2. Virtual cache allows a user to dynamically resize the
cache in software.
[0485] 3. Mixed Code RAM/Icache space with Line locking
[0486] 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.
[0487] Please select the max size of the Direct Mapped Instruction
Cache.
[0488] 1. 0.5 k bytes, 128 words
[0489] 2. 1 k bytes, 256 words
[0490] 3. 2 k bytes, 512 words
[0491] 4. 4 k bytes, 1024 words
[0492] 5. 8 k bytes, 2048 words
[0493] 6. 16 k bytes, 4096 words
[0494] 7. Other size
[0495] Please select (6):
[0496] 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.
[0497] Please select the min size of the Direct Mapped Instruction
Cache.
[0498] 1. 0.5 k bytes, 128 words
[0499] 2. 1 k bytes, 256 words
[0500] 3. 2 k bytes, 512 words
[0501] 4. 4 k bytes, 1024 words
[0502] 5. 8 k bytes, 2048 words
[0503] --16 k bytes, 4096 words
[0504] 7. Other size
[0505] Please select (1):
[0506] 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.
[0507] 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
[0508] Enter Size:
[0509] 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.
[0510] Select a max Cache line length
[0511] 1. 2 instruction words
[0512] 2. 4 instruction words
[0513] 3. 8 instruction words
[0514] 4. 16 instruction words
[0515] 5. 32 instruction words
[0516] 6. Other size
[0517] Please select (3):
[0518] 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.
[0519] Select a min Cache line length
[0520] 1. 2 instruction words
[0521] 2. 4 instruction words
[0522] 3. 8 instruction words
[0523] --16 instruction words
[0524] --32 instruction words
[0525] 6. Other size
[0526] Please select (3):
[0527] 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.
[0528] 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.
[0529] Host Interface Communications Select
[0530] from available host communications ports.
[0531] 1. Dummy Host Communications Port
[0532] 2. Standard PC/SUN Parallel Communications Port
[0533] 3. JTAG Communications Port
[0534] Please select (2):
[0535] 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.
[0536] Memory Arbitrator Select
[0537] the channels that you would like the memory arbitrator to
service.
[0538] 1. Continue
[0539] --* Load/Store channel for external memory accesses.
[0540] --* Host Interface channel for debugging and data
downloading.
[0541] --* Instruction fetch channel for I-cache.
[0542] --* Local Scratch-pad RAM channel for burst
reads/writes.
[0543] 6. Additional Channels
[0544] Please select:
[0545] 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.
[0546] How many additional channels do you want? (1-10):
[0547] The user can select from between 1 and 10 extra channels.
Enter 5 to give 5 additional channels.
[0548] 1. Continue
[0549] --* Load/Store channel for external memory accesses.
[0550] --* Host Interface channel for debugging and data
downloading.
[0551] --* Instruction fetch channel for I-cache.
[0552] --* Local Scratch-pad RAM channel for burst
reads/writes.
[0553] 6. * Additional Channels(5)
[0554] Please select:
[0555] The number of additional channels is now displayed next to
the option. We enter 1 to continue to the next menu.
[0556] RAM Sequencer
[0557] Select
[0558] 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.
[0559] How many wait states? (31):
[0560] 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.
[0561] Simulation
[0562] 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):
[0563] 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.
[0564] Is your VHDL simulator Model Technologies VSystem? (y):
[0565] 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.
[0566] Do you wish to use the R.T.L. And SeeCode Application Link
(RASCAL)? (n):
[0567] RTL And See-Code Application Link, otherwise known as
RASCAL.TM., 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.
[0568] To include RASCAL we enter y and press enter.
[0569] Install Directory
[0570] Full path to ARC user working directory
(/home/someone/systemarc)
[0571] At this prompt the user have to specify a destination
directory name (with full path). The path must not
include/tmp_mnt/etc.
[0572] We will select the default, a directory named "systemarc"
created where we launched the ARC system builder.
[0573] What we have built
[0574] I-fetch address bus width 22-bit
[0575] External address bus width 24-bit
[0576] Register file 3-port RAM
[0577] Fast load returns `yes`
[0578] Extensions Multi-cycle barrel shifter.
[0579] Fast Mul/MAC.
[0580] Scratchpad RAM with sliding pointers.
[0581] Technology size 0.35 ?m
[0582] Clock speed 100 MHz
[0583] Clock skew 0.4 ns
[0584] Users library name `sam`
[0585] Memory Extensions Load/Store memory controller
[0586] Instruction fetch memory controller
[0587] Host interface for communications with ARC
[0588] Arbitration unit for memory accesses
[0589] RAM Sequencer
[0590] Ld/St memory size 8 Kbytes.
[0591] Type of I-Cache Direct Mapped Cache
[0592] I-Cache mode Virtual Cache
[0593] I-cache size, Max/Min 8K bytes 128 bytes
[0594] Cache line length Max/Min 8 instruction words 2 instruction
words
[0595] Host communication port Standard Sun/PC
[0596] Arbitration Channels Load/Store channel for external memory
accesses
[0597] Host I/f channel for debugging and data downloading
[0598] Instruction fetch channel for I-cache
[0599] Local Scratch-pad RAM channel for burst
[0600] reads/writes
[0601] Additional Channels (5)
[0602] Ram Sequencer Wait states 31
[0603] Halt ARC on Reset? `no`
[0604] Destination directory/home/user/systemarc
[0605] Simulator =MTI? `yes`
[0606] RASCAL? `yes`
[0607] 3. ARCAngel
[0608] 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.
[0609] Fast Load Returns
[0610] Enable Fast load returns? (n):
[0611] Fast Load returns, if the current instruction does not use
register write back then the pipeline is not stalled.
[0612] ARCAngel development allows the use of fast return loads and
so will our final design, therefore we enter `yes`.
[0613] Extensions Builder
[0614] Select the extensions to be added to the ARC
[0615] 1. Continue
[0616] 2. 32.times.32 Barrel shifter--rotate, arithmetic and
logical shifts--1 cycle
[0617] 3. 32.times.32 Barrel shifter--rotate, arithmetic and
logical shifts--Multi-cycle
[0618] 4. Small multi-cycle 32.times.32 Multiply
[0619] N/A Faster (& Larger) 32.times.32 Multiply
[0620] N/A 16.times.16 Multiply/Multiply Accumulate function with
36 bit accumulator--Fast
[0621] 7. 16.times.16 Multiply/Multiply Accumulate function with 36
bit accumulator--Slow
[0622] 8. Swap function--swaps upper and lower 16 bits of 32 bit
word
[0623] 9. MIN/MAX function--32 bit precision
[0624] 10. Normalize function--finds first bit set in 32 bit
word
[0625] 11. * 24-bit Timer which counts to limit and then generates
an interrupt
[0626] N/A A Scratchpad RAM
[0627] N/A A Scratchpad RAM with Sliding Pointers
[0628] Note the multi-cycle barrel shifter has been selected along
with the 24-bit timer.
[0629] These have been selected as part of the standard Altera
configuration, however, the system will still function correctly
without them.
[0630] Please select
[0631] The above menu shows all the standard extensions, the user
can select different combinations depending on his needs.
[0632] 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.times.32 multiplier and the fast MUL/MAC. Also a build with all
extensions selected will not fit on the current FPGA.
[0633] 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.times.32 multiply. Entering 3 then 4 does this.
[0634] 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.
[0635] We will now enter 1 to continue.
[0636] Ifetch Modes
[0637] Select the instruction Cache Modes.
[0638] 1. Continue
[0639] 2. *Standard Cache with debug and cache bypass
capability.
[0640] 3. Virtual Cache
[0641] 4. Mixed Code RAM/Icache space & Cache line lock
[0642] Please select:
[0643] The first thing the script needs to know is what kind of
cache do the user want. It is possible to have a
[0644] 1. Standard Cache
[0645] 2. Virtual cache allows a user to dynamically resize the
cache in software.
[0646] 3. Mixed Code RAM/Icache space with Line locking
[0647] Selecting 3 allows standard Cache with the extra features of
Code RAM and Line locking.
[0648] Please select the norm size of the Direct Mapped Instruction
Cache.
[0649] 1. 0.5 k bytes, 128 words
[0650] 2. 1 k bytes, 256 words
[0651] 3. 2 k bytes, 512 words
[0652] 4. 4 k bytes, 1024 words
[0653] 5. 8 k bytes, 2048 words
[0654] 6. 16 k bytes, 4096 words
[0655] Please select (3):
[0656] 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.
[0657] 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.
[0658] Cache line length
[0659] 1. 2 instruction words
[0660] 2. 4 instruction words
[0661] 3. 8 instruction words
[0662] 4. 16 instruction words
[0663] 5. 32 instruction words
[0664] Please select (3):
[0665] 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.
[0666] Host Interface Communications Select
[0667] from available host communications ports.
[0668] 1. Standard PC/SUN Parallel Communications Port
[0669] 2. JTAG Communications Port
[0670] Please select (1):
[0671] 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.
[0672] Simulation
[0673] 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):
[0674] 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.
[0675] Is your VHDL simulator Model Technologies VSystem? (y):
[0676] 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.
[0677] Do you wish to use the R.T.L. And SeeCode Application Link
(RASCAL)? (n):
[0678] RTL And See-Code Application Link, otherwise known as
RASCAL.TM., 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.
[0679] The default of n is selected by simply pressing enter.
[0680] Install Directory
[0681] Full path to ARC user working directory
(/home/someone/arcangel):
[0682] At this prompt the user have to specify a destination
directory name (with full path). The path must not
include/tmp_mnt/etc.
[0683] We will select the default; a directory named "arcangel"
created where we launched the ARC build script.
[0684] NOTE: Even though the bus width is set to 26-bits, the
memory model for a ARCAngel build simulation is 512 Kbytes.
[0685] What we have built
[0686] Fast Load retums? `yes`
[0687] Extensions Multi-cycle barrel shifter.
[0688] 24-bit timer.
[0689] Small 32.times.32 multiplier
[0690] Direct mapped instruction cache size 4K bytes
[0691] Cache line length 4 instruction words
[0692] Host interface controller JTAG
[0693] Ram Sequencer SRAM 0 Wait states
[0694] Halt ARC on Reset? `no`
[0695] Destination directory/home/user/systemarc
[0696] Simulator=MTI? `yes`
[0697] RASCAL? `no`
[0698] 4. Core Verification System
[0699] 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.
[0700] Core Register File Selection
[0701] The 32.times.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.
[0702] Use a synchronous 2r1w RAM for the register file? (y):
[0703] 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.
[0704] Standard synthesis script assumes a 90.degree.-delayed clock
signal.
[0705] We selected a synchronous 3-port RAM and so we select y.
[0706] Technology Selection
[0707] Feature size (drawn) of technology in use
[0708] 1. 0.35 um
[0709] 2. 0.5 um
[0710] 3. 0.65 um
[0711] 4. 0.8 um
[0712] 5. 1.0 um
[0713] Please select (5):
[0714] 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.
[0715] Target clock speed in MHz (50)
[0716] We will use the default of 50 Mhz as we have specified 0.65
?m technology.
[0717] Clock skew for synthesis (.+-.0.4 ns):
[0718] The default of .+-.0.7 ns will be used for this example.
[0719] Library for extensions logic? (user)
[0720] 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`.
[0721] Simulation
[0722] 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):
[0723] 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.
[0724] The defaults are `Y` for a core build and `N` for generic
and ARCAngel builds.
[0725] 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.
[0726] Having selected `y` the above information message is
displayed.
[0727] Is your VHDL simulator Model Technologies VSystem? (y):
[0728] 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.
[0729] Install Directory
[0730] Full path to ARC user working directory
(/home/someone/verifyarc):
[0731] At this prompt the user have to specify a destination
directory name (with full path). The path must not
include/tmp_mnt/etc.
[0732] We will select the default, a directory named "verifyarc"
created where we launched the ARC system builder.
[0733] What we have built:
[0734] Technology
[0735] Feature Size 0.65 um
[0736] Clock Speed in MHz 50 MHz
[0737] Clock Skew in ns .+-.0.7 ns
[0738] Halt ARC on Reset? `yes`
[0739] Destination directory/home/user/verifyarc
[0740] Simulator =MTI? `yes`
[0741] 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`
[0742] As default the test code is linked to the tests: -Core/
[0743] Generic & ARCAngel builds: init_mem.hex
[0744] Core Verification build : testscript.hcs*
[0745] Type of Tests Hex Directories
[0746] ALU and
[0747] interrupts
[0748] Core_b
[0749] Extension Core
[0750] Interfaces
[0751] Core_x
[0752] Extension
[0753] interfaces
[0754] Ext_x
[0755] Host interface hm
[0756] Auxiliary logic Aux_x
[0757] Base Case
[0758] 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 FIG. 3) that shows the state of the
processor as it processes each instruction. The user is made aware
when host interface accesses are taking place, in addition to
Load/Store from external memory. NOTE: The code will be executed
twice for the default set-up since it is run in normal mode and
also in single step mode where each instruction is single stepped
through the pipeline. The single step feature is only executed upon
successful conclusion of the test code in normal operational
mode.
[0759] Upon conclusion the user is made aware whether the test
being simulated passed or failed.
[0760] To synthesize, type `syn_arc`, which runs the synthesis
scripts for Synopsys Design Compiler.
[0761] Simulation Display
[0762] Example of Pipeline diagram.
[0763] #12975 ns: Z 000001A0 7FFFFFFF ---------- ---------- ------
--
[0764] #13025 ns: Z 000001A0 7FFFFFFF ---------- ----------
---------- --
[0765] #13075 ns: Z 000001A0 601F7C00 mov ---------- ----------
--
[0766] #13125 ns: Z 000001A4 80000000 80000000 mov ----------
--
[0767] #13175 ns: Z 000001A8 48000100 rlc.f---------- mov --
[0768] #13225 ns: Z 000001AC 601FFE00 mov rlc.f ---------- wb: r0
.fwdarw.80000000
[0769] #13275 ns: Z 000001B0 48000100 rlc.f mov rlc.f --
[0770] #13325 ns: Z CV 000001B4 57E07A01 sub.f rlc.f mov wb r0
.fwdarw.00000000
[0771] #13375 ns: Z CV 000001B8 7FFFFFFF nop sub.frlc.fwb: r0
.fwdarw.00000000
[0772] #13425 ns: Z 000001BC 7FFFFFFF nop nop sub.fwb : r0
.fwdarw.00000001
[0773] #13475 ns: Z 000001 C0 FFFFFFFF ---------- nop nop --
[0774] #13525 ns: Z 000001C0 FFFFFFFF ---------- ----- nop --
[0775] Empty slots Long Immediate
[0776] Stage 4--Writeback
[0777] to
[0778] core register
[0779] Condition
[0780] Code
[0781] Flags
[0782] Data Word
[0783] Program
[0784] Counter
[0785] Opcodes in pipeline stages1-3 Simulation
[0786] Time Stage 4
[0787] Generic Build & ARCAngel Builds
[0788] 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`.
[0789] To run code in the Generic or ARCAngel builds
[0790] 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.
[0791] Core Verification system build
[0792] 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.
[0793] 4.2 Running Extensions Test Code
[0794] 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.
[0795] Memory image Tests
[0796] x_bshift.hex 32 bit barrel shift/rotate block
[0797] x_minmax.hex MIN and MAX instructions
[0798] x_mul64.hex 32.times.32 scoreboard multiplier with 64-bit
result
[0799] x_mulmac.hex 16-bit Multiply/Multiply-accumulate function
with 36-bit accumulator
[0800] x_norm.hex Normalize (find-first-bit) instruction
[0801] x_swap.hex SWAP instruction
[0802] x_ldstram.hex Local LD/ST RAM
[0803] x_timer.hex 24-bit timer counter
[0804] x_scratch.hex Scratch Pad RAM.
[0805] x_slide.hex Scratch Pad RAM with sliding pointers.
[0806] x_all.hex All extensions together.
[0807] For example, to test an ARC configured with the barrel
shifter block, do the following from the working directory:
[0808] rm init_mem.hex ln -s
$ARCHOME/exts/src/metaware/x_bshift.hex init_mem.hex
[0809] Now run the VHDL simulation. To replace the link to the
basecase test code:
[0810] rm init-mem.hex ln -s $ARCHOME/arc/src/coretest.hex
init_mem.hex
[0811] Single Step Tests (For Core Build)
[0812] 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.
[0813] Tests (For Generic/ARCAngel Build)
[0814] 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.
[0815] 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.
[0816] Cache Test Code
[0817] 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:
[0818] llama>mkdir src
[0819] llama>cd src
[0820] llama>cp SARCHOME/exts/src/metaware/cache.* .
[0821] llama>cp $ARCHOME/exts/src/metaware/macros.s.
[0822] llama>chmod+w cache.s
[0823] 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.
[0824] llama>cache.bat
[0825] 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:
[0826] -xalu. vhdl Extension alu functions.
[0827] xdefs.vhdl Extension instruction opcodes, auxiliary
registers and other constants.
[0828] xrctl.vhdl Extension co for pipeline flow.
[0829] xaugs_regs.vhdl Auxiliary registers.
[0830] xcore_regs.vhdl Core registers.
[0831] There are memory extension files that can be edited.
Depending on the user's selection, files that can be edited are as
follow:
[0832] -sram_seq.vhdl RAM sequencer.
[0833] mc_sys.vhdl Memory arbitration unit.
[0834] mc_arc.vhdl Ld/st memory controller.
[0835] dmcc.vhdl Direct mapped cache controller.
[0836] i_fetch.vhdl Dummy instruction fetch.
[0837] miu.vhdl External memory i/f unit.
[0838] The synthesis scripts and support files can also be
edited:--
[0839] synopsys-dc.setup Technology-specific setup
[0840] user_synopsys_dc.setup ARC-specific setup. Included by
above
[0841] scripts/elaborate.dc Elaboration of VHDL.
[0842] scripts/analyse.dc Analysis of VHDL.
[0843] scripts/do_all.dc Complete synthesis of design.
[0844] Hierarchy Generation
[0845] If additional files are added to the hierarchy then the
makefile must be modified to reflect this.
[0846] Command Line Parameters
[0847] NAME
[0848] system_builder--builds ARC VHDL files for simulation &
synthesis.
[0849] SYNOPSYS
[0850] system_builder ARCgui [-parameters]
[0851] DESCRIPTION
[0852] The system builder
[0853] REQUIRED PARAMETERS
[0854] -build_type [value] core, generic, altera,
core_verification
[0855] -ifetch_addr [value] 19-26
[0856] -ext_addr [value] 19-32
[0857] -tech [value] Feature size. e.g. 0.35 um
[0858] -ck_speed [value] Clock speed in MHz e.g. 100
[0859] -ck_skew [value] Clock Skew .+-.value in ns.
[0860] -ext_lib [value] Name to be used for ext. library.
[0861] -local_ram [value] Amount of Local load/st RAM
[0862] -ifetch_system [value] dummy, Direct Mapped Cache
[0863] -cache_size [value] Cache size
[0864] -cache_line_length [value] Cache Line length
[0865] -add_chan [value] Additional channels
[0866] -wait_states [value] Ram sequencer wait states
[0867] -install_dir [path] Where destination dir is to be
created
[0868] -install_name [dir name] Name of the destination
directory
[0869] OPTIONAL PARAMETERS
[0870] -register_file Use synchronous RAM cell register file.
[0871] -cache Cache enabled
[0872] -ldst_cont load/store controller
[0873] -hostif_cont host interface controller
[0874] -host_port [value] PC,dummy
[0875] -ifetch_cont I-fetch memory controller
[0876] -arbitrator Memory Arbitrator
[0877] -ram_seq Ram sequencer
[0878] -sram_chan Ram Sequencer Memory Arbitrator channel
[0879] -halt Halt the ARC on reset
[0880] -mti Compile for use with MTI Vsystem.
1 List of Script files system_builder anARChy.awk The main script.
Called by system_builder arc_mti_inst Installation for ModelTech
VHDL simulator xentity entity.awk Extract inputs + outputs from a
VHDL file. extant Does a file exist already? header.vhdl VHDL
header. Used by vhdlgen.awk. hiergen Generate a hierarchy. Calls
vhdlgen. hiergen.awk called by makefile (makegen)
make_arc_sys_struct Specific script for generating a hierarchy.
makegen Generate makefile for building hierarchy makegen.awk calls
hiergen, vhdlgen etc. mti_make Generate VHDL compilation makefiles
mti_make.awk synopsys_make Generates Synopsys synthesis scripts
synopsys_make.awk up_xent Update entity datafile. (makegen
makefile). vhdlcopy Copies generated VHDL to user's vhdl/dir
vhdlgen Generate a structural vhdl file based on a hierarchy
definition. vhdlgen.awk vhdlmerge.awk Merge extension data into a
placeholder. dat/apex.hier Sample hierarchy file. (Ignore %%..%%
keywords) dat/apex.mg Control file for hierarchy builder
dat/library.list Sample library definition file.
sample/placeholder/xalu.vhdl sample/placeholder/xaux_- regs.vhdl
Standard ARC extension placeholder files. Note - ARCPRAGMA's
sample/placeholder/xcoreregs.vhdl sample/placeholder/xrctl.vhdl
sample/extension/xaIu.vhdl Extension files for SWAP instr.
sample/extension/xrctl.vhdl Merged into placeholders.
* * * * *