Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!seismo!brl-adm!brl-sem!ron
From: ron@brl-sem.UUCP
Newsgroups: comp.arch
Subject: Re: HELP!!!  I need references for the HEP.
Message-ID: <655@brl-sem.ARPA>
Date: Thu, 26-Feb-87 13:09:21 EST
Article-I.D.: brl-sem.655
Posted: Thu Feb 26 13:09:21 1987
Date-Received: Sat, 28-Feb-87 06:44:34 EST
References: <3178@wateng.UUCP>
Distribution: comp
Organization: Electronic Brain Research Lab
Lines: 83
Keywords: Heterogenous Element Processor, references

In article <3178@wateng.UUCP>, hmthaker@wateng.UUCP (Hemi M. Thaker) writes:
>      I am currently taking an "Advanced Computer Architecture"
> course, and am doing a project on the Denelcor HEP (Heterogenous
> Element Processor) machine.

I work for the U.S.Army Ballistic Research Laboratory.  It is because
of BRL the HEP was even built at all.  We had one of the few ones ever
delivered (there were about 7 in total).  I helped with the UNIX port
and some of the I/O system work done later.

>         1) Architectural Description
The HEP is a Multiple Instruction, Multiple Data Stream computer.  The
computer consists of one or more modules called PEMs.  Each PEM could
support 8-12 (depending on how define things) tasks.  Tasks are what
UNIX people think of as processes.  Each task can have some larger number
of "processes" which are parallel executions of the same code using the
same data and instruction memory, but with different register sets.
A hardware device called the SFU scheduled all these processes to try
to keep all aspects of this machine as busy as possible.  Even in the
worst case, each PEM can execute eight UNIX process streams simoultaneously.
Each intstruction stream running at about a MIP.

Memory is divided into four parts:
	REGISTER MEMORY, a block of registers is available per PEM that
	the operating system can divide up among the processes as it sees
	fit.
	TABLE MEMORY (or CONSTANT MEMORY), more registers, but not writable
	to the user process.  Since HEP is a load/store type machine, having
	certain constants always available in register is useful.
	PROGRAM MEMORY, this is ECL RAM that holds the program being
	executed.
	DATA MEMORY, data memory is ECL RAM.  Unlike the other three
	types, data memory is available to all PEMs from through the
	"switch" (described below).  Data Memory locations also have
	a semaphore bit called the "FULL/EMPTY" bit.  The HEP memory
	referencing instructions can cause the process to be deselected
	until this bit is set appropriately.

Unfortunately, all this is allocated with a single base register per
type of memory.  Makes UNIX-style stacks kind of fun.

Multiple PEMs and the I/O systems are interconnected by the "switch."
The switch is a packet switch which contains 64 bits of control information
(address, full/empty bit, etc) and the 64 bit word.

>         2) Pros and Cons of this architecture

The architecture above, as well as few other things, make this thing
really excell for UNIX.  Unlike vector processors, we find that it's
a little bit easier to get applications cranking along on the HEP.  The
switch caused some problems though, generally the way things were handled,
it became loaded too easily.  Most of the problems we had were with the
original DENELCOR I/O system notions, not with the machine architecture
itself.

>         3) Specific Applications
>         4) Reasons behind WHY they (Denelcor) chose this architecture.

The machine was originally designed to solve partial-differential equation
problems for hydrocode problems.  Originally the machine was going to be
an analog computer, then a hybrid, and finally they decided to just go
for a slick all digital architecture.  About the only thing we really got
running on the thing before it was canned was Mike Muuss's ray tracing
packages.  Ray tracing consumes a lot of processor time and a bit of memory
but is very applicable to parallel processing (each ray is just another
process).

>         i) Proceedings of the Workshop of Parallel Processing Using
>            the Heterogenous Element Processor, March 20-21, 1985.
Never seen this.
>        ii) Heterogeneous Element Processor Principles of Operation,
>            Publication #9000001, Denelcor, Inc. 1981
I have one, I guess if you sent me your name, I could xerox it for you.
You probably don't need the whole thing.  Most of it describes each
instruction in detail.  The neat parts about the memory synchronization
and SFU are in the beginning.

I could go more into other things like the I/O but you are probably
not intersted in that.  Let it suffice to say that it used a high
speed buffer and lots of dedicated UNIBUSes.

The UNIX was pretty slick to, I'd be willing to go into that if you
want to hear.