Chapter Three: An introduction to hardware description languages
3.2. ENDOT and ISP’
In order to realize a simulator of a processor using the ENDOT package and the ISP’ language, basically, one has to create the following files:
.isp
The file with an arbitrary name and the extension .isp contains the processor description, as well as the description of the program and data memory. If so desired, two files can be created—
one for the processor, and one for the program and data memory. In the latter case, the two .isp files must have different names. In the general case, one can have more .isp files (processor(s), memory(ies), peripheral(s), etc…).
.t
The file having the .t extension describes the structure of the simulated system. If a single .isp file contains the descriptions of the processor and the memory, the .t file is rather trivial in ap-pearance, and contains only the mandatory part which defines the clock period duration, and the names of the files which contain the translated description of the system, plus the assembled test program that will be executed (an example follows). If, on the contrary, there are two (or more) .isp files, containing separate descriptions of the processor and the memory, then the .t file must contain a detailed description of the external connections between the two .isp files. The term
“external connections” refers to the pins of the processor and memory chips, whose descriptions are given in the two mentioned .isp files. In the case of a multiprocessor system with several pro-cessor chips, several memory modules, and other components, the .t file can become quite com-plex, because it contains the description of all the connections between the .isp files in the system. To this end, a separate topology language has been developed, but it transcends the field of interest of this book.
.m
The file having the .m extension contains the information needed to translate the assembly language instructions into the machine language. It includes a detailed correspondence between the assembly and the machine instructions, as well as other elements, which will be mentioned later.
.i
The file with the .i extension contains the information necessary for loading the description of the system into the memory, and for connecting the different parts of the system description.
.b
Apart from the aforementioned files, the designer has to create the file with the program that is going to be executed. This file can have any name and any extension, but the extension .b is usual, with or without additional specifiers (.b1, .b2, …). It is assumed that the test program is written in the assembly language of the processor that is being simulated.
The ENDOT package contains three groups of software tools: hardware tools, software tools, and postprocessing and utility tools. Using these tools, one first creates the executable simulation file (applying the tools on the five files mentioned earlier in this passage), and then he (or she) analyzes the results, by comparing them to the expectations, that were prepared earlier.
The hardware tools are: (a) the ISP’ language, (b) the ISP’ compiler—ic, (c) the topology lan-guage, (d) the topology language compiler—ec (ecologist), (e) the simulator—n2, and (f) the si-mulation command language.
The software tools are: (a) meta-assembler—micro, (b) meta-loader, that comes in two parts:
the interpreter—inter, and the allocator—cater, and (c) a collection of minor programs.
The postprocessing and utility tools are: (a) statement counter—coverage, (b) general purpose postprocessor—gpp, (c) ISP’ to VHDL translator—icv, and (d) a collection of minor programs.
As stated earlier, the ENDOT package greatly simplifies the road that one has to travel in an attempt to transform an idea of a new architecture into an analysis of the results of the simula-tion, even if the architecture is a very complex one. This will be shown through a simple exam-ple, preceded by some short explanations.
The ISP’ program has two basic segments: the declaration section, and the behavior section.
The declaration section contains the definitions of the language constructs used in the behavior section. There are six different sub-sections that can appear in the declaration section of an ISP’
program:
macro
This sub-section is used to define easy-to-remember names for the objects in the program. It is highly recommended that this sub-section type is used frequently in professional ISP’ program-ming.
port
This sub-section is used to define the names of objects that will be used for communications with the outside world. They are typically related to the pins of the processor, memory, or some other module (chip), whose description is given within some .isp file.
state
This sub-section is used to define the names of sequential objects (with memory capability), but without the possibility of defining their initial values. These objects are typically the flip-flops and the registers of the processor. One should be aware that the state of most flip-flip-flops and registers is undefined immediately after the power-up.
memory
This sub-section is also used to define the names of sequential objects (with memory), but with the possibility of defining their initial values. It is most frequently used to define the memory for programs and data. One should be aware that the contents of the ROM memory is fully defined immediately after the power-up.
format
This sub-section is used to specify the names for fields within the objects with memory. Typi-cally, it is used to define the fields of the instruction format.
queue
This sub-section is used to specify the objects used for synchronization with the external logic.
The behavior section contains one or more processes. Each process has a separate declaration part, followed by the process body, made up of the ISP’ statements.
The ISP’ statements inside a block execute in parallel, as opposed to the traditional high-level languages, which execute statements in sequence. For example, the sequence
a = b;
b = a;
leaves both a and b with the same value in a traditional high-level language program. The ISP’
language would, on the other side, interpret this sequence of statements as an attempt to swap the values of the variables a and b. This is a consequence of the inherent parallel execution in ISP’.
If, for some reason, there is a need for the sequential execution of two statements, the state-ment next, or some complex statestate-ment that contains it, should be inserted between them. One of these complex statements is delay. It contains two primitives, the first primitive introduces the sequentiality into the execution stream and is referred to as next, the second primitive is a state-ment that updates the clock period counter and is referred to as counter-update.
The ISP’ language supports four different process types:
main
This process type executes as an endless loop. This means that the process is re-executed once it has completed, continuing to loop until the end of the simulation. This is precisely the manner in which processor hardware behaves, fetching instructions from the moment it is powered, to the moment the power is cut off, or to the moment when some special instruction or event is encoun-tered, such as HALT, HOLD, WAIT, etc…
when
This process type executes once for each occurrence of the specified event.
procedure
This process type is the same as subprogram or procedure in a traditional high-level language.
It is used to build a main or when process in a structured, top-down manner.
function
This process type is the same as function in a traditional high-level language.
port
CK 'output;
main CYCLE :=
(
CK = 0;
delay(50);
CK = 1;
delay(50);
)
Figure 3.1. File wave.isp with the description of a clock generator in the ISP’ language.
port
CK 'input, Q<4> 'output;
state
COUNT<4>;
when EDGE(CK:lead) :=
(
Q = COUNT + 1;
COUNT = COUNT + 1;
)
Figure 3.2. File cntr.isp with the description of a clocked counter in the ISP’ language.
Figures 3.1 and 3.2 show simple examples of clock generator and counter in the ISP’ language.
A brief explanation follows. Readers are encouraged to browse through the original documenta-tion that is shipped with the ENDOT package, after the reading of this book is over.
Figure 3.1 shows the wave.isp file, describing the clock generator in terms of the ISP’ lan-guage. Its declaration section contains the definition of the output pin, which carries the clock signal. The behavior section makes sure that the duration of the logic level “zero,” as well as the duration of the logic level “one,” are exactly 50 time units. The actual duration of the time unit will be specified in the .t file.
Figure 3.2 shows the cntr.isp file which describes the clocked counter in the ISP’ language. Its declaration section contains the following definitions: (a) the definition of the input pin (CK), through which the clock signal is fed into the module; (b) the definition of the four output pins (Q), which lead the four-bit result out; and (c) the definition of the internal register which holds the current clock period count (COUNT).
The behavior section makes sure that one is added to the previous count on every leading (pos-itive) edge of the clock signal, and writes this value into the internal register COUNT and the output pins Q. Keyword LEAD is a part of the ISP’ language, and it denotes the leading edge of the signal.
The files wave.isp and cntr.isp contain the source code written in the ISP’ language, and now is the time to generate the files wave.sim and cntr.sim, which contain the object code. The ISP’
compiler ic does that job.
The next step is to create the .t file using the topology language. This step is important, be-cause we have to define the connections between the descriptions in the .sim files. A program in topology language contains the following sections:
signal
This section contains the signal declarations, i.e., it specifies the connections between the ob-jects contained in the .sim files. A general form of the signal declaration, described using the original ENDOT package terminology looks like this:
signal_name[<width>][, signal_declarations]
This means that we first specify the signal name, then the signal width (number of bits), and the two are followed by optional declarations which will not be discussed here.
processor
This section contains the declaration of one processor, i.e., of one element of the system, whose description is contained in one .sim file. The .t file can contain many processor sections, one for each .sim file. A general form of the processor declaration looks like this:
processor_name = "filename.sim";
[time delay = integer;]
[connections signal_connections;]
[port = signal_name[, signal_connections];]
[initial memory_name = l.out]
In short, we have to define the processor name (mandatory), then we (optionally) define:
(a) specific time delays; (b) signal connections; and (c) initial memory contents. An example is given later in the book.
macro
This section contains the easily remembered names for various topology objects, if necessary.
composite
This section contains a set of topology language declarations. A general form of this section is:
begin
declaration [declaration]
end
Therefore, the declarations are contained inside a begin-end block. Readers should consult the original ENDOT documentation for further insight.
include
This section is used to include a file containing the declarations written in the topology lan-guage. For details, refer to the original ENDOT documentation.
Figure 3.3 shows the file clcnt.t, which defines the topology of the system composed of the wave.sim and cntr.sim files, and the associated hardware components.
The signal section defines the connections between the files wave.sim and cntr.sim, while the two separate processor sections define the details of the incorporation of the files wave.sim and cntr.sim into the system.
signal CLOCK, BUS<4>;
processor CLK = "wave.sim";
time delay = 10;
connections CK = CLOCK;
processor CNT = "cntr.sim";
connections CK = CLOCK, Q = BUS;
Figure 3.3. File clcnt.t with a topology language description of the connection between the clock generator and the clock counter, described in the wave.isp and cntr.isp files, respectively.
The following step is the creation of two object files containing the description of the system.
To this end, we use the ecologist (ec). The input files are: (a) the .t file; (b) all the .sim files; and (c) the l.out file, if the system contains a pre-defined program. The output file has the extension .e00, and it contains the object code that represents the entire system.
In the case of the example analyzed here, the input files are:
clcnt.t wave.sim cntr.sim
The output file is:
clcnt.e00
For simulation we use the program n2. The required input files are .e00, all the .sim files, and the optional file l.out; if we want to record the simulation results for later processing, the usual extension given to the output file is .txt.
In our example, the input files for the n2 are:
wave.sim cntr.sim clcnt.e00
The output file, if we want to create it, is:
clcnt.txt
During the simulation, we use the simulation command language. We will briefly mention on-ly some of its commands (a detailed list is available in the ENDOT documentation):
run
This command starts or continues the simulation.
quit
This command ends the simulation, and exits the simulator.
time
This command prints the current simulation time on the terminal (the number of clock periods that have elapsed since the beginning of the simulation).
examine structure(s)
This command gives the user a means of gaining insight into the contents of different struc-tures. For example, we can see the contents of a register after the simulation was interrupted.
help keyword
This command enables the user to get on-line help on the specified keyword.
deposit value structure
This command enables the user to change the contents of specified structures. For example, we can set the contents of a register to a specific value, after the simulation was interrupted.
monitor structure(s)
This command enables the user to gain insight into the contents of various structures, at the same time setting the break points. The details are given in the ENDOT manuals.
The presented example contains only the hardware elements, and only the hardware tools have been described so far. In general, more complex systems include both software and hardware components, and we will discuss the existing software tools in the following paragraphs.
If the test program was written in the assembly language of the processor that is to be simu-lated, it has to be translated into the machine language of the same processor. This process can be done using a program called metamicro. The input files for this program are: the .m (containing the description of the correspondence between the assembly and machine instructions), and the .b (containing the test program). The output file is .n (containing the object code of the program).
The file .m, apart from the description of the correspondence between the assembly and the ma-chine instructions, also contains the specification of the file with the test program, in the begin-end section, with the following general form:
begin
include program.b$
end
There is one more file that has to be prepared. It has the extension .i, and it contains the infor-mation for the linker/loader, which describes the method of resolving addresses during the link-ing and loadlink-ing process. This file is first interpreted uslink-ing the program inter. The input file is .i, and the output file is .a, which contains the executable object code, before the linking and load-ing process. The linkload-ing and loadload-ing are done usload-ing the program cater. The input files for the ca-ter are .n and .a, and the output file is l.out, containing the object code of the program, ready to be executed.
After the execution of the test program is over, one can analyze the results of the simulation, using the aforementioned postprocessing and utility tools. The reader is advised to try them out, and to learn more about them using the help and the documentation that comes together with the ENDOT package.
Figure 3.4. The sequence of operations that have to be executed in order to perform an ENDOT simulation, assuming that the environment is the UNIX operating system.
*.isp *.sim
Figure 3.5. A typical sequence of ENDOT system program calls for the case of (a) making and (b) running the model of a stored program machine.
simulation: clcnt (snapshot = 00) date created: Fri Mar 24 20:51:29 1995 simulation time = 0
> monitor write stop CNT:Q breakpoint: triggered on write into structure Q tag 1
> examine CNT:Q this enables one to see the contents of a structure CNT:Q = 0 X (port data)
> run this runs the simulation, until the first breakpoint is reached 500
> quit after the simulation is over, we return to the UNIX system
Figure 3.6. A sample simulation run using ENDOT package.
Figure 3.4 shows a possible sequence of operations that have to be carried out during a suc-cessful ENDOT session, in the case of our clocked counter example. The details of Figure 3.4 should be quite clear by now. One more thing to remember is that the programs included in the ENDOT package have various command line options. The option -h (hardware) in the command line of the program ec, specifies that we intend to simulate only the hardware. The alternatives are: -s, if we simulate only the software, and -b if we simulate both hardware and software. The option -s in the command line of n2 specifies that the output is saved in a (script) file with the specified name (clcnt.txt).
It is strongly recommended that the readers try out this example, using a computer. A sample simulation run using ENDOT package is given in Figure 3.6. After that, it would be wise to try out the complete processor simulation of an educational RISC machine, e.g., the one described in [BožFur93]. Simulation will not be treated any further in this book. Here, we only show a typical sequence of ENDOT system program calls for the case of making and running the model of a stored program machine (Figure 3.5).
In addition to the above mentioned simulator, there are many more in existence at the User Li-brary of ENDOT, including several popular 16-bit, 32-bit, and 64-bit microprocessors. A detailed insight into their structure can enhance the reader’s understanding of the process of creating a professional simulator of a commercial microprocessor.
The ISP’ language and the ENDOT package have been used not only in the RISC/MIPS projects of DARPA (for GaAs and silicon versions of the processor), but in the development of a number of more or less known processors. These tools have been used in the development of the Motorola 68000 and other members of its family [RosOrd84], various Gould (now Encore) su-perminicomputers [Gay86], as well as in the design of the famous SPUR processor at the Univer-sity of California at Berkeley, which is one of the descendants of the original RISC I and RISC II processors.
Figure 3.7. List of benchmark programs, written in Pascal (.p), used during the “MIPS for the Star Wars” project, to compare different solutions to the problem, submitted by different teams competing in the project.
We now return to the “MIPS for Star Wars” project, which represents the basis for this book.
Let us assume that we have completed the ENDOT simulators for several different new architec-tures, and that our goal is to determine which one is the best, by executing certain test programs (before we make an attempt to realize it using appropriate VLSI design tools). To this end, in the project “MIPS for Star Wars,” the programs listed in Figure 3.7 were used. Of all the realized
“candidate architectures,” only one was chosen for the VLSI implementation. That architecture was selected according to the criterion of the shortest execution times for the benchmarks from
“candidate architectures,” only one was chosen for the VLSI implementation. That architecture was selected according to the criterion of the shortest execution times for the benchmarks from