By: Ornstein

Stewart: September 11, 1981 4:32 PM

ETHERPHONE II

The Etherphone II consists of two (perhaps three) physical pieces:

1. A telephone unit

2. A microprocessor unit

Note 1. As with a traditional phone, there may also be an external speaker and microphone; for simplicity we will ignore these here.

Note 2. We sometimes refer to the microprocessor unit itself as the Etherphone.

The telephone sits on the desk; the microprocessor unit fits in a shoebox underneath the desk.

The microprocessor unit can be logically separated into two parts:

Part 1 interfaces directly to the phone and to the regular phone line and has to do with audio switching (handset - speaker - mike), analog/digital conversion, reading the keypad, etc.

Part 2 consists of all the digital parts - interface to the Ethernet, the microprocessor itself, packetizing and de-packetizing the digitized voice, encryption, etc.

Bob Belleville is currently building hardware that corresponds to Part 1 and we are hoping simply to utilize that. His device is planned to sit directly underneath the telephone and interface to it. (It is the possible third physical piece mentioned above.) If we directly copy his hardware, packaging and all, we will end up with some unnecessary things (most notably a tiny tape recorder). However it would save us considerable work. If we can’t use his device directly (not ready in time or not suitable), we will at least be able to copy relevant parts of his design into our microprocessor unit. For the present we are assuming we’ll be able to utilize his device. [See [Iris]<Belleville>Voice81-2.memo ].

Hardware

Figure *** shows a block diagram of the Etherphone II. In order to get under way without delay, we decided not to wait for either Alan Bell’s or Intel’s or AMD/Mostek’s proposed 10 Mbit Ethernet controllers. Instead we decided to use the 1.5 Mbit SLC chip designed by the MEC for use in the Lotus copier program. We understand that this chip can run faster than it’s 1.5 Mbit advertised speed. Vir Dhaka says that the limiting factor in the design has been fixed, and that 3 Mbit chips will be available soon. We have in hand a number of the 1.5 Mbit chips and are planning to put up a Gateway between the Parc (3 MB) Ethernet and a special 1.5 Mbit local Ethernet. (Boggs claims a single jumper on the Alto backpanel can halve the speed of one of its Ethernet controllers). If the 3 Mbit chips become a reality before we’re ready to go, we will forget the Gateway.

Choice of the SLC biased our choice of microprocessor. The SLC was designed to talk to an Intel 8085 bus. We might, therefore, simply have chosen to use an 8085, an 8 bit machine. But there is a faster, more modern machine, the 8088 which internally is a (16 bit) 8086 but externally (its bus) looks (approximately) like the 8 bit 8085. We might have used an 8086 but did not feel that the additional potential bus bandwidth (16 bit bus vs. 8 bit bus means twice as fast) was worth the additional complexity in bus hardware. The 5 MHz 8088 completes a bus cycle in 4 clock cycles, a byte every 800 ns, which gives 10 Mbit/s bus bandwidth. That is insufficient for the 10 Mbit Ethernet, but by the time there are 10 Mbit Ethernet controllers, there will be faster versions of the 8088. There is, in fact, a planned 8 MHz version of the 8088 although most of the peripheral chips won’t run that fast. Alternatively, we could go to the 8086 16 bit bus and still run the same software.

The bandwidth argument goes as follows:

Digital voice will be at 64 Kilobits (8 Kilobytes) per second. A typical sample (from the person speaking) traverses the bus four times:

1. coming from the phone A/D into memory
2. from memory to encrypter
3. from encrypter back to memory
4. from memory to the outgoing ethernet

In the worst case, both members of a phone call may talk at once. So the bus must service 8 x 64 Kilobits = 256 Kilobits per second. Of course this is average speed and we haven’t included the processor’s use of the bus to run program (occasionally). However, even for a 5 MHz machine, 256 KBits seems like a small part of its bus bandwidth.

The SLC includes its own quite nice channel logic. It will use a DMA channel only to multiplex its bus access requests with those of the other devices; other than that it doesn’t need any DMA facilities since it handles the bus itself. The SLC has independent DMA controllers for transmit and receive. Each controller interprets a chain of control blocks in memory.

We are planning to use the Advanced Microdevices Z8068 encrypt/decrypt chip. This chip can run very fast so we will have to slow it down to prevent it from hogging the bus. It will operate through use of two DMA channels, one for input and one for output.

We plan to use the Intel 8237 DMA part (which has a convenient "autoinitialize" feature that restarts data transfer at the beginning of a buffer when the buffer fills/empties). Each DMA part offers 4 independent channels and the parts can be cascaded using one of the channels. Two chips thus provide 7 channels.

Digitized voice arrives from (and/or goes to) the codec at one 8-bit sample every 125 ms. We will use DMA channels to get it into the memory. In fact we are thinking of using two channels for each direction. We’ll assign two buffers to two DMA channels for (say) codec input. When the first buffer fills from the codec, the hardware will swap channels and the codec will start filling the second buffer. The first will be autoinitialized in preparation for refilling from its beginning, but will remain inactive (until after the second has finished filling). Meanwhile an interrupt causes the program to deal with the first buffer (passing it through the much faster encryption chip before the codec channel swap again needs the first buffer).

So the 8 DMA channels (two chips) we expect to use are:

Codec In A
Codec In B
Codec Out A
Codec Out B
To Encrypter
From Encrypter
SLC (DMA cascade for bus access request only)
DMA cascade (for second DMA chip)

In addition to a small amount of bootstrap ROM we expect to utilize about 4 K bytes of ROM (RAM during development) for program and 4 K bytes of RAM for buffers. Our present intentions are to use mostly RAM and to include sufficient ROM for an Etherboot loader and perhaps teleswat functions. We are planning to use only static memories.

We intend to have two RS-232 interfaces (there is a convenient dual channel compatible chip). One channel will be for controlling the audio-handling hardware (Belleville’s hardware). The other is for communicating with a mother ("Midas") Alto and will be used only when developing programs.

We will use the Intel 8259 interrupt controller which includes priority logic and interrupt vectoring.

We have in hand an SDK-86 (borrowed from Belleville) which is a small Intel 8086 prototyping kit including a monitor in ROM. We are able to speak to the 8086 from an Alto via DLS and an RS-232 interface included on the board. The ROM monitor on the board knows how to display and modify memory and registers, how to set breakpoints (hexadecimal), and how to load a program in Intel hexadecimal absolute loader format.

We plan to experiment with the more complex peripheral chips by wiring them up on a wire-wrap board and connecting them to the 8086 with ribbon cable to a wire-wrap Augat board. (The SDK-86 includes bus drivers for an external bus.) Our plan is to try to replace the 8086 with an 8088 while retaining the bootstrap/monitor ROMS. Once we understand the operation of the DMA parts, the SLC, and perhaps the Encryption chip, we will build a complete 8088 system on a Dorado stitchweld board. Mike Overton has completed a chassis holding a single Dorado board. The reason for the two level prototyping structure is to avoid too many reweldings of the stichweld board.

We have not selected a keyboard/display for the Etherphone IIB. We may try to obtain or borrow a Sunrise for the task.

Software

We plan to use the 8086 assembler, linker/loader, and C compiler developed by Bill Duvall for Bob Belleville’s Cub project. The assembler is free, but the C compiler is not owned by Xerox, although several groups (Belleville, Webster) are using it. A license will be $1000, including some degree of support. The compiler is not quite Unix version 7 compatible, it lacks things like bit fields in structures.

Since our debugging will have to be at the level of assembler listings, hexadecimal breakpoints, and load maps, we will try to keep the program in the Etherphone very simple.

Some portions of the grant universities’ C Pup package may be useful for the Etherphone software. Bcpl to C transliteration is straightforward and we already have a working bcpl Etherphone 0 program on the Alto.

Support

We have a friendly Intel salesman, who is providing samples for most of the stuff we need and supplying us with some very useful application notes and gotcha sheets on the various parts.

Bob Belleville has been very helpful in lending us the SDK-86, supplying us with all the useful parts of his Cub software, and to some extent, in incorporating some of our needs into his thinking for the "voice box."

We have had good conversations with Simon Lau, an engineer working for Belleville on the voice box.

We (finally) located the right people at MEC and have learned enough about the SLC to be confident that we can make it work. In particular we now understand the assumptions that the SLC makes about the design of the rest of the microprocessor system.

Bill Duvall has an office in building 96 and will be close enough to help with development tool problems, at least for a while.

Dave Boggs has agreed to help in setting up a 3 Mbit to 1.5 MBit Ethernet gateway, should we need one.