The ENDOT Package

by TDT

  1. First, the appropriate files are formed.

In the most general case:

a. One or more .isp (isp') files

(different names; same extensions)

b. One .t (topology) file

(trivial if one .isp file; complex if many .isp files)

c. One .m (meta-micro) file

(one jumbo case statement)

d. One .i file

(information related to linking and loading)

e. One or more .b (benchmark) files

(any extension allowed)

Only this, and nothing more! [Poe66]

2. Second, the formed files are treated with appropriate tools:
    1. Hardware tools
    2. Software tools
    3. Postprocessing and utility tools

Finally, the simulator is completed.
  1. Third, the simulator is run, and the statitics about the analysed architecture(s) are collected.
  2. Fourth, if needed, a silicon compiler is run, etc...

 

ENDOT

  1. Hardware Tools

1.1. ISP' Language

1.2. ISP' Compiler - ic

1.3. Topology Language

1.4. Ecologist - ec

1.5. Simulation Command Language

1.6. Simulator - n2

2. Software Tools

2.1. Meta-assembler - micro

2.2. Meta-loader - the linker/loader

2.2.1. Interpreter - inter

2.2.2. Allocator - cater

2.3. Minor programs

2.3.1. mdump

2.3.2. merge

2.3.3. mas = micro + cater

2.3.4. mkmem

3. Postprocesing & Utility Tools

3.1. Statements counter - coverage

3.2. General purpose post-processor - gpp

3.3. Help utility -nhelp

3.4. Build utility - build

3.5. VHDL translator - icv

 

THE N.2 DESIGN PROCESS

  1. Idea!!!
  2. Hardware (and Software) design
  3. Simulation
  4. Analysis
  5. IF design <> ok THEN

GOTO Step 2
  1. End

With N.2 your design iterations

become painless!!!

 

HARDWARE TOOLS

  

ISP' language

Purpose:

DESCRIPTION OF THE HARDWARE SYSTEMS

ISP' program:

  1. Declaration section
  2. Behavior section

 

Declaration section:

- CONTAINS STRUCTURE DECLARATIONS.

- STRUCTURES: ALL ISP' NAMED OBJECTS.

- STRUCTURE TYPES:

  1. MACRO
  2. PORT
  3. STATE
  4. MEMORY
  5. FORMAT
  6. QUEUE

MACRO subsection: names which are used to give

convenient easily remembered names to objects.

PORT subsection: names which are used for

communication with outside world.

STATE subsection: internal names of the ISP' model

that can store information.

MEMORY subsection: same as a state, except that

memory can be initialized.

FORMAT subsection: convenient names for

inconvenient names; typically subranges of states.

QUEUE subsection: names which are used for

synchronization with outside world.

 

Behavior section:

- CONTAINS ONE OR MORE PROCESSES.

- PROCESS:

  1. PROCESS DECLARATION
  2. PROCESS BODY

- PROCESS BODY: SET OF ISP' STATEMENTS.

- ISP' STATEMENTS: PROCESS EXECUTES ALL

ITS INDEPENDENT STATEMENTS

CONCURENTLY.

- next AND delay STATEMENTS: CAN BE USED TO FORCE SEQUENTIAL EXECUTION

WITHIN A PROCESS

EXAMPLES:

- main: OPERATES IN A COUNTINUOUS LOOP.

- when: WAITS FOR AN EVENT.

- procedure: SAME AS A SUBROUTINE IN A HLL;

main process INVOKES A procedure.

- function: SAME AS A FUNCTION IN A HLL.

 

Example: "wave.isp"

 

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.

 

 

File "cntr.isp"

 

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 clocked counter in the ISP' language.

 

 

ic - The ISP' Compiler

 

Purpose: COMPILES ".isp" SOURCE FILES

INTO ".sim" OBJECTS FILES

- input: ".isp" file

- output: ".sim" file

 

 

wave.isp ---> ic ---> wave.sim

 

cntr.isp ---> ic ---> cntr.sim

 

 

Topology Language

Purpose: DESCRIBES LINKS

BETWEEN THE ".sim" FILES

Topology program:

    1. SIGNAL SECTION
    2. PROCESSOR SECTION
    3. MACRO SECTION
    4. COMPOSITE SECTION
    5. INCLUDE SECTION

 

- SIGNAL SECTION: IF EXISTS, CONTAINS A SET

OF SIGNAL DECLARATIONS

 

- SIGNAL DECLARATIONS:

signal_name [<width>][,signal declarations]

 

 

- PROCESSOR SECTION: CONTAINS A

PROCESSOR DECLARATION.

PROCESSOR DECLARATION:

processor_name = "filename.sim"

[time delay = integer;]

[connections signal_connections;]

[initial memory_name = l.out;]

- MACRO SECTION: USER'S CONVENIENT NAMES

FOR TOPOLOGY OBJECTS.

  

- COMPOSITE SECTION: THIS SECTION

MAY CONTAIN SET OF THE

TOPOLOGY LANGUAGE DECLARATIONS

IN THE FOLLOWING FORMAT:

begin

declaration {declaration}

end

 

- INCLUDE SECTION: SIMPLE INCLUDING OF

THE FILE WHICH CONTAINS

TOPOLOGY LANGUAGE DECLARATIONS.

 

File "clcnt.t"

 

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 the topology language description of the connection between the clock generator and the clock counter, described in the wave.isp and cntr.isp files, respectively.

 

 

ec - The Ecologist

 

Purpose: COMPILES ".t" SOURCE FILES

INTO ".e00" FILES

- explicit input: ".t" file

- implicit input: ".sim" file(s)

- optional implicit input: "l.out" file

(derived by the software tools)

-output: ".e00" file (object file)

 

 

clcnt.t ----------->

wave.sim -------> ec -----> clcnt.e00

cntr.sim -------->

[l.out ------------>]

 

 

n2 - The Simulator

 

 

Purpose: SIMULATION OF THE DESCRIBED

HARDWARE SYSTEM.

  

- input: ".sim" & ".e00" files

- optional input: "l.out" file

(derived by the software tools)

- output: if exists, ".txt" file

wave.sim ------->

cntr.sim --------> n2 [ -----> clcnt.txt]

clcnt.e00 ------->

[l.out ------------>]

 

 

Simulation Command Language

  

Purpose: CONTROLLING THE FLOW

OF SIMULATION

Some basic simulator commands:

- run: STARTS OR RESUMES THE SIMULATION.

- quit: EXIT THE SIMULATOR.

- time: QUERIES THE SIMULATION "CLOCK"

TO OBTAIN THE ELAPSED UNITS

OF SIMULATION TIME.

- examine structures: QUERIES THE

CONTENTS OF THE STRUCTURES.

- help keyword: PROVIDES AN

ON-LINE REFERENCE.

- deposite value structure: SETS THE

CONTENTS

OF THE STRUCTURE WITH

THE VALUE FIELD.

- monitor structures & alert structures:

PROVIDES A VARIETY OF CAPABILITIES

FOR GETTING INFORMATION

DURING SIMULATION..

 

begin

* create/directory [.n2]

copy vl$a:[n2]nmpc.uof *.*

** edit wave.isp

edit cntr.isp

ic wave.isp

ic cntr.isp

edit clcnt.t

“ ec -h clcnt.t

” n2 -s clcnt.txt clcnt.e00

end

 

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 VMS operating system, on the BUEF78 machine (VAX 11/785), at the School of Electrical Engineering, University of Belgrade, Serbia, Yugoslavia.

 

 

Installation of ENDOT package on systems

running SCO UNIX

    1. Login as root
    2. cd /usr
    3. tar xv n2.tar.Z (extract)
    4. uncompress -v n2.tar.Z
    5. tar xvf n2.tar (extract)
    6. rm n2.tar
    7. cd n2
    8. tar xvf nmpc.uof
    9. cp nmpc.uof /usr/USERNAME

Sequence of operations for simulation of the

clocked counter

    1. vi wave.isp
    2. vi cntr.isp
    3. ic wave.isp
    4. ic cntr.isp
    5. vi clcnt.t
    6. ec -h clcnt.t
    7. n2 -s clcnt.txt clcnt.e00

 

SOFTWARE TOOLS

 

metaMicro

Purpose: ASSEMBLING AN ASSEMBLER PROGRAM.

- input: METAMICRO ASSEMBLER SOURCE FILE AND ASSEMBLER PROGRAM

- output: ".n" FILE

arch.m -------> |

   ---> | ---> micro ---> arch.n

program.m -> |

- arch.m: CONTAINS DEFINITION OF THE

ASSEMBLER INSTRUCTIONS AND

Begin-end Section:

begin

include program.m$

end

- program.m: CONTAINS ASSEMBLER

PROGRAM

- arch.n: OBJECT FILE.

 

 

inter - the Interpreter

 

 

Purpose: DESCRIPTION OF THE

INSTRUCTION WORD;

ADDRESS

RESOLUTION AND RELOCATION.

- input: LINKER/LOADER SOURCE FILE

- output: ".a" FILE

arch.i -----> inter ------> arch.a

- arch.i:CONTAINS DEFINITIONS OF THE

INSTRUCTION WORD AND

INFORMATION FOR THE

ADDRESS RESOLUTION AND RELOCATION.

- arch.a: OBJECT FILE.

 

 

cater - The Allocator

 

 

Purpose: LINKING THE ".n" AND ".a" FILES;

RESOLVING ADDRESS & ALLOCATION.

 

- input: ".n" & ".a" files

- output: "l.out" file

- l.out: MEMORY IMAGE FILE

arch.n --> |

   | ---> cater ---> l.out

arch.a --> |

 

Postprocessing & Utility Tools

 

coverage - ANALYZES PROCESSOR

STATEMENTS BY USAGE,

HIGHLIGHTING THE

UNEXECUTED STATEMENTS

gpp - ANALYZES PROCESSOR

STRUCTURES

BY VALUE, PROVIDING STATISTICAL,

GRAPHICAL, OR COMPARATIVE

PRESENTATION OF RESULTS.

nhelp - ON-LINE HELP.

build - MANAGING OF THE SOURCE FILES.

icv - TRANSLATING ISP' MODELS INTO VHDL

 

Papers from the Open Literature:

  1. Rose, C.W., Ordy, G. M., Drongowski, P. J.,

"N.mpc: A Study in University-Industry Technology Transfer"

IEEE Design & Test of Computers, February 1984, pp 44-56.
  1. Rose, C. W., "System Design Tools - A Paradigm Shift,"

Endot Corporation Internal Report, 1986.
  1. Gay, F., "Funcitonal Simulation Fuels System Design,"

VLSI Design Technology
  1. Kong, S., Wood, D., Gibson, G., Katz, R., Patterson, D.,

"Design Methodology of a VLSI Multiprocessor Workstation,"

VLSI Systems, February 1987.
  1. Bozanic, D., Fura, D., Milutinovic, V., "Simulation of a Simple RISC Processor,"

Application Note, No. D#001/VM,

TD Technologies, Cleveland Heights, Ohio, U.S.A., 1993.
  1. Petkovic, Z., Milutinovic, V., "Simulation of the Intel i860 RISC Processor,"

Application Note, No. D#003/VM, TD Technologies,

Cleveland Heights, Ohio, U.S.A., 1994.
  1. Milicev, D., Petkovic, Z., Milutinovic, V., "Simulation Study of Uniprocessor Cache Memories,"

Application Note, No. D#004/VM, TD Technologies,

Cleveland Heights, Ohio, U.S.A., 1994.
  1. Tomasevic, M., Milutinovic, V., "Using N.2 in a Simulation Study of Snoopy Cache Coherence Protocols for Shared Memory Multiprocessor System," Application Note, No. D#002/VM,

TD Technologies, Cleveland Heights, Ohio, U.S.A., 1993.

 

WORKLOAD CHARACTERIZATION

Important Reference:

Ferrari, D., Computer Systems Performance Evaluation, Prentice-Hall, Englewood

Cliffs, New Jersey, U.S.A., 1978.

Introduction:

Workload of a computer system has been defined as the set of all inputs (programs, data, commands, etc... ) that the system receives from its environment

In measurement experiments, the system is driven by a model of the workload which is just a sample of the real production workload.

The major question is how representative this sample is. Other important characteristics of a workload are:

  1. simplicity of construction,
  2. usage cost,
  3. reproducibility,
  4. compactness, and
  5. system independence.

 

Types of Workload Models:

  1. Natural workload model: A sample job stream taken from a production workload, and used to drive the system at the very time it was produced.

2. Artificial workload model: All other cases.

2.1. Non executable:

2.1.1. Defined via statistical distributions of relevant parameters.

2.1.2. Usage: In analytical studies.

2.1.3. Typical forms: Probabilities of various instructions

(instruction mixes), memory accesses,

procedure nesting depths, etc...

2.1.4. Relevant issues: Mean values, variances, correlations,

autocorrelations, etc...

2.1.5. Standard instruction mixes: Flynn (MLL), Knuth (HLL), etc...

2.2. Executable:

2.2.1. Defined via one or more programs.

2.2.2. Usage: In empirical studies.

2.2.3. Typical forms: Synthetic jobs (parametric programs) and

benchmarks (semantic programs).

2.2.4. Relevant issues: application orientation, etc...

2.2.5. Standard ones: See the PC magazines, etc...

Synthetic job approaches:

Buchhulz (fixed flowchart with variable parameters)

Kernigham + Hamilton (similar but more sophisticated)

Archibald + Baer (the most widely cited

computer architecture paper in 80's )

Benchmark types:

Extracted

Created

Standard (application dependent)

 

The DARPA/Stanford benchmarks:

 

The DARPA/Stanford Benchmark Package

consists of thirteen PASCAL programs:

 

  1. ackp.p
  2. bubblesortp.p
  3. fftp.p
  4. fibp.p
  5. intmmp.p
  6. permp.p
  7. puzzlep.p
  8. eightqueenp.p
  9. quickp.p
  10. realmmp.p
  11. sievep.p
  12. towresp.p
  13. treep.p

These programs are located on ed machine,

and the full path name of their directory is:

/a/mips/bench

 

  back to front page