CSL Notebook EntryTo:CSL NotebookDate:October 5, 1981From:Anthony WestLocation:PARC-CSLSubject:Auxiliary Hardware for D-MachinesFile:[Ivy]81CSLN-0050XEROX Attributes:technical, Alto, Computer organization, Communication, Database, Distributedcomputing, Dandelion, Dolphin, Dorado, DES, Cryptography, Encryption, RandomNumber Generators, Noise Diodes, Stable Storage, Atomic Transactions, WWVB,Broadcast Time Standards, Stable Storage, Universal Identifiers, Synchronizing Events,SLC Ethernet, I/O Interfaces, Intel/IEEE Multibus References:[Needham] 81CSLN-0026; [Lampson] 81CSLN-0030;Abstract:This note describes the evolution of the proposal to add to CSL's D-Machines hardwareto support miscellaneous auxiliary functions, such as DES cryptography, random numbergeneration, removable electronic stable storage, a receiver for the WWV broadcast timestandard, and assorted external I/O interfaces.1. IntroductionEarlier proposals suggested that CSL systems be augmented with hardware to enable research in anumber of new areas. This note draws together the suggestions of a number of people on theseissues and summarises the state of the design.Under discussion is hardware for:DES Cryptography Random Number GenerationElectronic Stable StorageReceiver for the WWV Broadcast Time StandardExternal Interfaces2. StrategyThe areas of research which the hardware would enable fall loosely under the heading of DistributedSystems Research. A realistic study environment requires that a significant number of machines willneed the additional hardware, and this implies a considerable investment of funds and effort.Careful thought is required to identify the research benefit this hardware will yield compared withthe investment CSL will have to make in building it.2.1 What is the Purpose?A major research issue in distributed computing is how to provide protection and controlled sharingof information.The provision of high-performance cryptography hardware would enable us to study security issuesin distributed systems. The adoption of the NBS DES algorithm as a federal standard and theavailability of high-speed encryption chips effectively eliminates any other techniques from the]gpi c8q]rX -q5Ur ]q]r -q5`r Yq]r!-q5`qSsr Pq (r6 O=. M0 L57 J2 Gq (rX- Dq(r$1 Cc2# A0& @[/ :Kt 7r_ 5C 4. 0!.,<)',%5 " t r:u Zr0$ J RQ 4 u wrc  ur) D@ 7) y>^ Auxiliary Hardware for D-Machines2domain of discussion. The availability of DES encryption hardware would enable us to build into Cedar facilities forsecure communication (eg. in remote procedure calls) and secure data storage (eg. in databases andAlpine file servers). The project is timely with respect to Cedar's current state - in other words -the Cedar community is an attractive, small, closed user community which could be equipped withcryptography facilities in a uniform fashion.An inherent characteristic of encryption is that it tends to be an all-or-nothing facility. Thus,although we can incorporate it into the new world of Cedar relatively painlessly, it is less simple todo so for services already in operation. It would be attractive to add secure communication toGrapevine, for example, but its large user community is based on Alto's, which are unlikely to haveencryption hardware (ever?).There are approaches by which client machines without the hardware can still use cryptography,however. A low-capability client could get the server to decrypt and send data in the clear for it.Although this approach gives up the prospect of achieving secure communication, cryptography isstill used for authentication. Such machines could encrypt the shorter, less frequent messagesneeded for authentication and requests in software or microcode, and still achieve acceptableperformance. [Mitchell]The question of finding an evolution path to permit secure and unsecure environments to coexist isalso an interesting research issue.Known ways for providing reliable updating of (possibly replicated) information in distributeddatabases depend on the existence of stable-storage for storing critical information. To date, theproperties of such storage have been modelled using discs, often leading to a drastic reduction inperformance. It would be attractive to investigate the effects on performance and systemorganisation of providing high-speed, low-latency electronic stable storage for this purpose. Similarly, proposals for managing the controlled updating of distributed databases requires stampingmessages with unique identifiers for controlling the order of actions. The generation of theseidentifiers is often based on some function of the time-of-day. A number of complicated protocolshave been discussed in the literature for overcoming the variations in each system's notion of whatthe time is. Instead of investing resources in synchronisation algorithms, it would be interesting tostudy alternative strategies based on the availability of a source of accurate time. A receiver for oneof the broadcast time standards is a way of achieving this.Finally, if we are going to build additional hardware for our systems anyway, we might as well availourselves of the opportunity to provide some inexpensive general-purpose experimental input-outputports to enhance the flexibility of our systems.2.2 Which Machines?CSL is gradually phasing out its investment in Alto computers in favour of D-machines. Thisapplies both for personal workstations and servers, in the long run. Thus, the Alto's role in our futureis clear: investment of further hardware effort in the Alto is counter-strategic.In contrast, the role the Dolphin is to play in our future is not clear and CSL does not plan toacquire any more for use as workstations. Since there is no Trident disk controller for the Dolphin,the Alpine and Voice File Servers will have to be implemented on Dorado's. Thus, two majorclients for auxiliary hardware will be Dorado-based, and the projected need for auxiliary hardwareon Dolphins is limited.Considering this, only the decision to equip the Dorado with auxiliary hardware can be justified inCSL at this time. Extension of the Dolphin is not precluded, of course.|frX!G b ^1- ]nur%ur [P ZfV X- U\ T3#C R2- Q+[ Oqr L{-1 JO Is/ ur Gu r$ Fk2+ D q Ar3/ @7# = 7' ;7, :P 8 B  62ur 304 2L$; 0 T /DK -K ,<E# *; 'E & ,6 $0 !Yu .rJ 4qr &Q 3- v)< &5 nK  M ;q5 >[bAuxiliary Hardware for D-Machines3It is conceivable that thought may need to be devoted to the issue of designing appropriateextensions for the DANDELION, but only if CSL actually acquires some for research purposes atsome later date or if a clear need emerges from another direction (eg. SDD).3. DES CryptographyThe ideas about DES encryption hardware derive almost exclusively from the Dolphin prototypebased on the Fairchild chip set [Gifford].The design will implement memory-to-memory encryption, so one set of hardware can be used bothfor secure communication and secure data storage.Since the first prototype was built, AMD have announced a flexible, fast chip implementing DES,the Am Z8068. These devices are readily available and fairly inexpensive (~$135). The mainadvantages of this chip over the Fairchild chip set are:Smaller:one 40-pin package instead of fourFaster:13.6 MBaudMore facilities:multiple key registers, multiple encryption modes (ie. Cipher BlockChaining mode as well as Electronic Code Book mode)Pipelining:with independent input and output ports 3.1 Error DetectionBecause the encryption of data is designed to be a transformation which is difficult to reverse,special consideration has to be given to the issue of how to handle hardware error conditions. If anerror occurs during encryption, either by using an incorrect key or as a result of a hardware failure,recovery is impossible. Erroneous encrypted data cannot be scavenged!Further, there seems to be a inherent difference between encryption for the purposes of securecommunication and encryption for the purposes of secure data storage [Schroeder].With encryption for secure communication, the sink end of a byte-stream decrypts and interprets thereceived data. There is a certain chance that errors will be detected quickly as a result of thedecrypted garbage violating higher-level protocols. Maybe one could intentionally extend this idea to provideerror control.With encryption for secure long-term storage, however, there is no attempt to decrypt or interpretthe semantics of the stored data until retrieval-time, by which time the clear text may have beendiscarded. Thus, the loose error check described above is not available.This implies that users are going to feel much safer about cryptography for secure data storage if thehardware takes great care to detect errors at encryption-time.The hardware paths out to the DES chip and in from it can be parity-checked in the usual way.However, no error-control is performed on data passing through the chip except for the encryptionkeys, which are actually 56 bits with 8 parity bits. All available DES devices indicate key parityerrors.However, simply or-ing the chip's KeyParityError output with other parity failure signals in thesystem's hardware is not appropriate. This is because other parity failures are considered to resultfrom unrecoverable hardware failures and so they halt the Mesa emulator. Thus, it would be quiteeasy for a user to stop the machine by loading an incorrect key. We favour an alternative approachwhere the error signal is presented in a separate parity status register which microcode can readwhen it wants [Gifford].|frX!G b*1 `Z _L [t Xr\ W;qr Tur Rurur O`$; MW LX8Jur"Gur EQur7C3Auu r( >Ju ;rG 950 8C# 6F 3gXu 1 r$uru rq r ..ur- -3 S +3q; *+ 'r$> %|'u r #I K H.ur X Wu rH  euru r .7 ]a .5 UR  uqu ?R[NAuxiliary Hardware for D-Machines4Providing additional protection against DES chip errors or failures can be done by one of thefollowing approaches:a.Decrypt blocks immediately after encryption and compare with the clear text. This needstwo buffers and twice as much time. We consider this approach unsatisfactory.b.Use 2 chips in series, one encrypting and one decrypting. This would ensure that the cleartext entering one chip emerges in a form which the second chip can decrypt back to theoriginal. The comparison of the two versions of the clear-text is done in small units (4words?) in hardware. Performance is reduced since two transformations have to beperformed before the data can be trusted although pipelining is possible. The phase differencebetween the two versions of the clear text implies additional buffering hardware.c.Use 2 chips in parallel, both encrypting. Assuming there are not any known or significantdesign bugs in the IC's, the failure modes we want to guard against are either randomintermittant glitches giving rise to wrong bits, or hard chip failures. If the data outputs ofthe two chips are compared byte-by-byte, differences can be detected. If the comparisonis done after parity regeneration, the Dorado parity protection and the protection gainedfrom this scheme will overlap leaving no holes for errors to sneak in. Performance isbetter (parallelism) and comparison is done in hardware. No additional bufferingrequired.The current preferred favorite is (c) since the DES chips are fairly inexpensive. If a DES hardwarefailure is detected a fault wakes up the fault-handler which invokes retries, etc.3.2 PerformanceA comparison of the estimated performance of the proposed Dorado design (based on the AMDchip) with the performance of the existing Dolphin prototype (based on the Fairchild chip set) ispresented here.Dolphin prototypeDorado proposedDevices usedFairchild 9414AMD Am Z8068DES chips per encrypter41Cost per encrypter$150$135Bandwidth12.8 MBaud13.6 MBaudEncrypt/Decrypt 512 bytes320 mS300 mSNo. of 512 Byte blks per second312533333.3 DES Key GenerationThe security of the a cryptographic system is critically dependent on the unpredictability of thekeys. To use a pseudorandom number generator, even seeded with a truly random number, wouldmake keys unacceptably predicatable. We assume that encryption keys are derived from a trulyrandom number generator. For a DES key, only 56 actual bits have to be generated, the additional8 bits are odd parity bits, distributed 1 bit per byte in the low-order bit.Note that the study of key distribution and authentication systems as a research topic does not require either theencryption hardware or the keys to be genuinely secure - almost any trivial scheme will do. However, it seems worth thetrouble to invest the extra effort to strive for a genuinely secure environment using the best tools available at this time[McDaniel].4. Random Bit GenerationThe auxiliary hardware will include a noise diode and the necessary amplification and digitisation toproduce a stream of fairly random bits. These bits are presented sequentially to the microcode (andthe Mesa software) as a bit in an I/O device status register. An experimental version has been builtand is being added to the Dolphin prototype [Gifford].|frX!G b7& `^Bu1r \NZfu8r X IW^?UQTV)qruRrQPzu(rNCMr="KM JjRHMGb+&E BD A.Qu > :r@ 9T^ 7"t47 1 "t 7 0"t7 ."t7 -"t 7 *"tvr7vr ("t7 %u "ra !3) ?  (9 L ~qX A%S Y"  t r50 u r< N +q r >R]LtAuxiliary Hardware for D-Machines5The distribution will only be fairly random because the output of the comparator will be naturallybiassed towards ones or zeroes by the nature of the hardware. Software is responsible forunbiassing the distribution of 1's and 0's by considering the bits pairwise and calling the pair 01 a 1,and the pair 10 a 0 (say). According to Gifford's measurements, random bits come out of the noise diode at about 20Kbaud.The unbiassing operation is non-deterministic so it will take an indeterminate amount of time toactually accumulate a random number. This is not worrying for DES work since keys do need tobe generated very often, only loaded.However, there may be other applications which need faster random number generation. It isproposed that these numbers will be generated out of a FIFO pool of random bits accumulated bya background Mesa task. It is possible to perform unbiassing and bit-accumulation in hardware, butthere is no clear need to do so. Make your case soon please!5. Electronic Stable StorageA number of distributed system applications would benefit from the availability of removableelectronic stable storage. One example is for bolstering up the weak properties of disk drives into amodel of strong atomicity, namely, either all writes belonging to a transaction work or none do.Keeping state about remote procedure calls to help manage the orphan problem (keeping state aboutwhat is going on in a chain of remote procedure calls when one of the machines crashes) is another.What these applications need most of stable storage is negligable access latency [Mitchell]. One modelof how it would be used is that only small amounts of information will be written into it at any onetime, so the overall bandwidth need not be very high [Lampson]. Thus, small records describingtransaction state transitions, procedure call states, etc. can be written into stable storage withimpunity without significant impact on system performance.Operations on stable storage should be performed synchronously under the control of the Mesaemulator. Having the operation take place asynchronously, possibly resulting in task-switching, isunacceptable for performance reasons [Lampson]. This is simple if the blocks are small.Usually, applications will only write data into the stable storage - reading is only performed forerror recovery (extremely infrequent) or to flush the storage out onto disk occasionally. The size ofthe memory can be quite small - it only has to be large enough to reduce the flushing frequency toan acceptable level perhaps once every few seconds [Lampson].5.1 AddressingThere are two approaches to integrating the stable storage into a system:a.It is part of the memory space. It can be accessed directly using Mesa pointers.b.It is an I/O device. Mesa device interface procedures are provided to access it.The main advantage of making the memory appear in the address space of the system is that Mesaprograms could manage persistent and transient variables and records uniformly. In particular,storage management of the stable storage is simplified.Another advantage is that modelling the strong atomic property for disk drives is simplified. A diskpage can be written into the electronic stable storage and the disk controller can read it directlyfrom the storage to do the transfer [Mitchell]. This conflicts, however, with the conjecture that data will bewritten into stable storage in small units [Lampson].Although intuitively appealing, the engineering of the address-space solution is difficult for D-machines. Even ignoring such issues as cache interactions, there is something to be said forisolating the stable storage from the main memory system somewhat for protection [Lampson].Schemes have been proposed to guard against software failures, however [Needham & Mitchell].|frX!G bP `,. _u rSur ] ur ZfU X=# W^] Uurur R[ Q+6( OL N#q Jt Gr+1 FHf DurC C@*u r AP >$u ru rq r = d ;urqr ::( 8: 5U1u r  3P 2L$q r* /!ur= - Qur ,+7 *q(r 'iu $>rI!<Q c> u ru r # [7 0#B K (#q rq> 5 rD ;@ *'qr 3Gq r >^wAuxiliary Hardware for D-Machines6It has been decided to make the memory appear as an I/.O device. This decision simplifies thepackaging dramatically, as well as avoiding the problems which arise from memory-cacheinteractions.5.2 Candidate TechnologiesA number of technologies might be applicable for the memory design, namely:a.CMOS RAM'sb.Magnetic Core StorageNote that both CCD's and magnetic bubble stores would require external FIFO buffering toachieve the zero-latency property on writes which we require. The hardware is non-trivial if guaranteedbehaviour in the case of machine failure is to be achieved. RAM's can achieve this effect with much lesseffort, bearing in mind that the required size of the memory is small.NMOS RAM offers one advantage over CMOS RAM: higher density. However, this is achievableonly at the expense of going over to a dynamic technology. We only require a modest amount ofmemory and would prefer to avoid the complications of refresh.Static CMOS RAM comes in medium density I/C's (eg. Hitachi HM6116LP-4 = 2K by 8 bits), isfast (down to 120 nS), has very low standby power requirement (less than 50 mA per I/C) and areinexpensive (~$10). The construction of a 16K by 16 memory from 2K by 8 CMOS RAMS wouldrequire 16 I/C's, would consume less than 800 mA on battery standby, and would cost around$200. Small PCB-mountable trickle-rechargeable batteries have capacities of 100 to 2000 mAh,allowing memory data to be retained for between 100 and 1000 hours. This is more than adequatesince our requirement is that the memory should be able to retain data for the longest conceivableholiday period (about 6 days) [Lampson]. Although CMOS seems so attractive, it is by no means clear that core storage is out of the running.There is a certain quaint attraction in finding a use for core memory in our systems. Several companies (eg.Plessey) make small removable core modules designed to be plugged into machines rather like 8-track cassettes. The price is unknown and an enquiry is being made. Core memory retains dataindefinitely without battery backup.5.3 Write ProtectionIt is desirable to incorporate hardware into the memory design to ensure that runaway software doesnot write into the stable storage. In order for software to write a location in stable store, it willhave to first supply the current contents of the word in question. This is relatively easy tomechanise in hardware. Block transfers to stable store only need specify the current contents of thefirst word of the block.5.4 Error Control and RedundancyOperations on stable storage have to be safe. This means two things:a.Getting data in and out must be safe operations.b.It must be safe to keep data in the memory.The path from the computer to the memory can be protected cheaply against random errors etc. byusing standard parity techniques. The interface must have the property that write operations takingplace whjen the power fails on the computer fail detectably, ie. recovery on power up can tell thatthe last write transaction on stable storage was not committed. One technique for doing this is towrite a checksum out as the last word of a block, in much the same way as is used for disk drives.|frX!G b@ `"+#+ _ [u XrKVg' T' P/) O`?q M;r. LXu=r I-,- GB F$> BV @~#)vr >X <\.vr :P 907( 7M 6(q r 2(; 1yq Lr /^ .qI ,$ )u &r7, %,: #8& " U  Zu /rE'0'+ TW d LR $? DN >\4Auxiliary Hardware for D-Machines7To guard against gross physical failures, the memory should be (ie replicated. In the event of onechecksummed copy of the information being incorrect, the other copy can be read for recovery.Fortunately, there is no reason why the two memories cannot be written in parallel, so noperformance penalty is incurred. If hardware is added to compare the contents of words read backfor consistency, there ought to be a way to read and write each memory individually.The memory needs to be removable so that, in the event of system failure, it can be plugged intoanother server to effect recovery. It would be quite acceptable to have to throw a switch beforestarting to change any plugs [Mitchell].5.5 PackagingThe proposed hardware structure is that the auxiliary hardware card carrying the encryptionhardware will plug into the Dorado in the normal way. On this board will be an external businterface capable of driving several external stable memories. These memories are packaged insmall boxes and are linked to the Dorado with flat cable. The memory bus will permit block word-wide transfers over a multiplexed 16-bit wide address/data bus.Packaging the stable storage in external boxes simplifies the transfer of storage from one machine toanother. It also means that not every Dorado need actually have the storage installed.6. Accurate Time-of-Day ServicesThere are a number of activities on the internet which could benefit from the availability of asource of accurate time-of-day information. 6.1 Why?There are two motivations for introducing an accurate source of time into our internet environment:a.A service need.b.A research need.The service need is easy to justify. The notion of time distributed about the internet drifts quite abit. Time servers (which mostly happen to reside in Alto gateways) are polled for the time by aclient, and the client is responsible for choosing the most accurate time (based on the average, orsomething).Time servers derive the time from a free-running crystal clock in the machine. It is not unusual forthe differences in the frequencies of these crystals to cause a variation of several minutes over aperiod of a month or so. Differences of minutes cause peculiar oddities at the user interface to suchdistibuted applications as maintenance of the distributed Grapevine registration database.Protocols already exist to reset one server's idea of the time from another (GateControl). It ispossible to extend these to cause an accurate time server to ram the accurate time down the throatof all the other free-running time servers on the internet at regular intervals. An outage wouldsimply cause the internet to revert to the current situation.The research need is not so easy to justify at this stage. In the earlier proposals, it was suggestedthat, if the hardware was simple, it should be thrown in "for free" to see how it got to be used.Actually, there are a number of research areas which would benefit from being able to generateunique distributed system identifiers. One possible way of generating these is based on knowing afairly accurate time of day. The alternative seems to be making an investment in complicateddistributed synchronisation protocols. The intent is, however, to provide the facility based on the service needs and then see what researchuse it is put to.|frX!G bS `4) _4% ]A \T X V W^ S Uq r Ru Or"9 M%7 L{^ J># Is? FHF DW At >mrI <- 9u 6r<'4:'ur1'ur .33 -3` +I *+ '05 %|d #a "sZ H2/ 20 @[ = F  a (6 L A ( \ M 2 >]8Auxiliary Hardware for D-Machines86.2 How?A number of systems exist which are designed to provide broadcast time standards, of which themost attractive is the WWV service broadcast by NBS. This information is broadcast in variousforms on various frequencies fanging from 60kHz up to satellite transmissions in the UHF band.The 60kHz dialect of WWV is called WWVB and is particularly attractive because it is convenientlyBCD encoded. Also, it appears that this is the WWV transmission which is both easiest to receiveand the transmissions have uniformly high field-strength all over the US (unlike the short-waveversions). The satellite transmissions do not yield quite such accuracy (propagation distance further)and the siting of a suitable antenna is more critical.Ignoring RF issues for a minute, it is possible to derive a time-of-day clock from the received digitalsignal which, after applying some simple corrections, is accurate within 500mS anywhere in the USportion of the internet. Doing better than that may be possible, but may require increasedparanoia. The hardware necessary to do this is sufficiently cheap that one might equip everymachine with an Auxiliary Hardware board with it. Of course, it would be nice not to have to string up antennae all over the office even though it may notbe necessary to have a full quarter-wave dipole!. Yet achieving good reception requires a reasonableantenna especially when one considers that this is a steel-frame building with very noisy contents.60kHz is also a rather close harmonic of 60Hz, which might render the systems subject tointerference from the mains power distribution [Thacker].Commercial WWVB receivers are available which come packaged with good antennae, an RS-232interface and thumbwheel switches to input corrections for propagation delay. These cost about$2500 and it seems adequate to consider equipping the internet with two or three of these toachieve internet-wide time synchronisation within one second. Higher accuracy is available on theEthernets which the receivers are directly connected to, but gateways and leased lines introducenon-deterministic delays.If greater accuracy were required (later), it is possible to contemplate a special path through theEthernet microcode which would reach out to the WWV clock registers and copy the time into anEthernet packet as the packet is actually being transmitted, ie. after deferral and acquisition of theether.Similarly, microcode at a client could recognise such a SetTime packet and reload the client's time-of-day clock directly. More accurate corrections for Ethernet and hardware propagation time couldbe derived from also implementing a microcode-based echo server in the time server allowing aclient to measure its distance from the server.One important requirement for distributed systems is that the unique ID's in the systems aregenerated in a monotonically increasing fashion. Assuming that a client's time of day clock isoccasionally reset from a time server, it must be ensured that the reset cannot allow a duplicatenumber to be generated. One possibility is to receive the time packet into a safe place and (in hardware) reset a"microseconds-since-time-packet-received" counter incrementing at 1 MHz. Some protection is afforded by using a 0.9MHz crystal. You might skip a few ID's, but you'll never have a duplicate [Mitchell].It is currently proposed to purchase two WWVB receivers and plug them into spare Alto's whichwill do nothing other than run the time server protocol. This is to avoid having to dive into thecode for the current Alto gateways, and is regarded as an interim solution! By connecting one ofthese receivers to the local Ethernet (Net #3), our time will be of rather better quality thanelsewhere in the internet and thus, we may not run up against inaccuracy limitations for ourresearch projects quite so soon.|frX!G bu ^rK ]n"< [)5 Zfqr qr- Xqr. W^J U'@ TV6 Q+25 N ?vr MB KF J3 F*(q EQ/r/ CS BIA @.q r =; <:% :1+ 9 N 7M 6 2-6 1UG /u+r' .M +"0ur% )11 (8% &/ #j1+ !ur8 b10 qC }n V rP m9) *7 eL *2 ]6 >VlAuxiliary Hardware for D-Machines97. External InterfacesA number of suggestions have been received to add to the hardware we are building sundryexternal interfaces. These, together with their comments, include:a.SLC (1.5 Mbaud) Ethernet Interface. Devices should be designed to connect to an Ethernet,not to a computer. Thus, one device design can be exploited by any of our machines.However, an SLC Ethernet is unlikely to be of interest to the audio project, and no otherpotential customers exist for it at the moment. It would be better to wait for a 10MbaudEthernet chip to come along and use that. Future systems should permit several 10 MbaudEthernet ports to be installed easily.b.IEEE 488 / GPIB Interface. To allow our machines to control machinery and readinstruments, they have to speak GPIB. However, the major candidate for this interface isICL, and they are already committed to solving this problem with other specia-purposehardware. They will surely not be using Dorado's for this either. If desired, a GPIBinterface could be built up on an external parallel interface, see below.c.Audio Interface Components. The major candidate for research using audio compeonents,the Voice project, has decided to solve this need with purpose-built hardware inEtherphones. No advantage can be perceived for putting audio components on the boardover plugging them into an external parallel interface, see below.d.RS-232 Ports. Numerous devices exist which require RS-232 interfaces. No majoradvantage can be perceived in providing this on the card over via an external parallelinterface, see below.e.Intel Multibus Interface. This is a serious contender. Just about any interesting piece ofhardware, any microprocessor, or any disk controller exists in a Multibus incarnation. Itwould really enhance our ability assemble experimental equipment quickly if we couldexplot the Multibus and, instead of building hardware, simply buy it and plug it together.However, instead of making the Dorado (via the auxiliary card) look like a Multibus master,the preferred solution is to connect to Multibus systems via an Ethernet using either (a) aStanford University 3 Mbaud Ethernet Multibus interface card, (b) an existing Intel 10Mbaud 2-card Multibus interface or, eventually, (c) an Intel LSI 10 Mbaud Multibusinterface card. Between these three options one can realise any configuration and this iscompatible with the idea of making boxes that plug into the Ethernet, not into machines (see(a) above).f.Parallel I/O Bus. Most of the above requirements can be met with a suitable externalparallel I/O bus. It should be simple, reasonable fast, and should offer microtask wakeupfacilities. The fact that the amount of hardware involved to make such an interface is sosmall is a very streong argument in its favour.Note that it is be possible to use the general parallel I/O bus also as the interface for thestable storage. However, it is not yet clear that this is a good idea. The current modelassumes a 16-bit multiplexed address and data bidirectional bus running at about 100nanoseconds. 8. ConclusionFrom the discussion above, our design conclusion is that the board will have the followingcharacteristics:a.DES Cryptography. Two AMD Am Z8068 encryption devices running in parallel willprovide error-checked Electronic Code Book or Cipher Block Chaining encryption at 13.8Mbaud. Keys will be generated from the random number generator, below.b.Random Number Generator. Actually a random bit generator. Based on a noise diode. Willgenerate random bits at about 20Kbaud. These will appear as a bit in a device statusregister to be read by the microcode.|frX!G bt ^rA ]nC [u"r .Y;XJVYUGS& Q+ur5O%4N#UL LKI Hur 0G?,!-/E HD7B Au r+@[A> <u rD:Z9w H7,ur5S4U2716/W.A, *+ur3(<u'#rJ%/#G./!L  ?D t drP  wr,VG )wr* < %` =\2~Auxiliary Hardware for D-Machines10c.Electronic Stable Storage. Based on Hitachi 6116LP4 Static CMOS RAMs. 16K words of16 bits will be packages in a small box and connected into an I/O device interface on theauxiliary card with a flat cable. The design of the interface will allow multiple boxes to beconnected. Battery backup will be provided for at least 10 days of standby operation.d.External Parallel I/O bus. A simple I/O bus with multiplexed address and data lines willbe provided to add on external interfaces. Audio, RS-232, DtoA/AtoD, microcomputerdevices can all be added and addressed over this bus. The bus will provide microtaskwakeup facilities to allow "interrupts" to be serviced directly by Mesa processes. It isunresolved whether to use ths bus as the interface for the stable storage or not.e.Broadcast Time Standards Receivers. More than one commercial receiver will be purchasedto receive the WWVB broadcast time standard. These receivers will be interfaced to theinternet initially via dedicated Alto-1 servers which do nothing else other than respond totime protocol Pups. One of the receivers will be sited on Ethernet #3 to ensure slightlymore accurate time locally than elsewhere in the internet.|frX!G? bwr9`>_I]@ [:wr-Y EX2FVHU*Q Rw r6QNBOXNF)0L: L{<@ TIMESROMAN  TIMESROMAN TIMESROMAN LOGO TIMESROMAN  TIMESROMAN  OLDENGLISH TIMESROMAN    # - 6 ? I S|Wj/Z Xlj AuxNote.bravo TonyWest.PAFebruary 5, 1983 5:38 PM