The MC68000 family and distributed processing

Size: px

Start display at page:

Download "The MC68000 family and distributed processing"

Willa Simpson
6 years ago
Views:

1 The MC68000 family and distributed processing by JOHN F. STOCKTON Motorola Semiconductor Inc. Austin, Texas ABSTRACT The key philosophy today is to build parts that will be upward compatible with multiple processor systems of the future so that there is a migration path from existing single-bus systems to the higher-performance, multiple-local-bus systems of the future. An important parameter of these systems will be system performance, and the need for this performance is increasing faster than vendors can increase single-processor performance. The need for multiple-processor systems is clear in the future. Knowing this, the designers of the MC68000 made sure to include all the necessary hooks into the processor design to support multiple processor architecture in the future. Some features of the existing processor that might not be used often today will become very important to future members of the M C68000 peripheral family. Some of these features and systems will be discussed here. 29

The MC68000 Family and Distributed Processing 31 THE NEED FOR DISTRIBUTED PROCESSING As office-oriented computer systems become more userfriendly, and as more of the operating systems and

3 The MC68000 Family and Distributed Processing 31 THE NEED FOR DISTRIBUTED PROCESSING As office-oriented computer systems become more userfriendly, and as more of the operating systems and applications programs are written in high-level languages, there is a much higher demand placed on microprocessor vendors to keep offering ever increasing amounts of performance for approximately the same cost as before. To meet this higher performance requirement, microprocessor vendors cannot simply rely on single-bus structures to keep increasing performance. The solution to increasing performance will be to rely heavily on multiple processors, each having its own local bus, operating independently. To take advantage of this solution, microprocessor vendors must build in this upgradability early in the design of their microprocessor families. FAMILY PHILOSOPHIES The key philosophy today is to build parts that will be upward compatible with multiple-processor systems of the future so that there is a migration path from existing single-bus systems to the higher-performance, multiple-local-bus systems of the future. The key parameter of systems of the future will be system performance, and the need for this performance is increasing faster than single-bus processor systems can increase their performance. The need for multiple-processor systems is clear in the future. Knowing this, the designers of the MC68000 made sure to include all of the necessary hooks into the processor design to support multiple-processor architectures in the future. Some features of the existing processor that might be used often today will become very important to future members of the MC68000 peripheral family. Some of these things will be discussed specifically here. The MC68000 was specifically designed to support highlevel languages; the register set of the processor was intentionally kept general-purpose, with no dedicated registers that compilers have a difficult time using. Each register was defined so that it could be used as a pointer register as well as a data register. Special-purpose instructions were added to increase efficiency of procedure calls and re-entrant routines. These in~tructions were the "link," "unlink," "load effective address," and "push effective address" instructions. As well, instructions were added to streamline context switches via the "move multiple" instruction, which can stack any portion of the register set onto the stack with one single instruction. Operating system support was also an important design consideration in the design of the MC Distinctions like user/supervisor separation were included to help increase system reliability without a large amount of software overhead. Another important feature is the "TEST-AND-SET" instruction, which allows for truly indivisible read-modify-write cycles on the local bus, even when there are multiple bus masters. This instruction depends heavily on the asynchronous nature of the bus, since it is possible to lock out other accesses by maintaining ownership of the bus control lines. Because of this, it is possible to keep other bus masters off and make the read-modify-write cycle truly indivisible. Another important philosophy was that the processor extensively checks to insure that only legal instructions are being executed, that word operations occur on word boundaries, and that users do not try to execute privileged instructions. The new family of peripherals will also consistently support these philosophies. One very important philosophy that the supports is the notion of an address space. The function code lines and the bus grant acknowledge (BGACK) lines form four additional address lines that are used to indicate which address space is currently being used. The Memory Management Unit (MC68451) uses these function codes to provide translation and protection according to the current address space in use. These function codes are shown in Figure 1. The advantage of using these is that all transfers can take place in logical space and be mapped and privilegechecked by the Memory Management Unit, thus increasing system reliability. The family of peripherals will all consistently support the asynchronous bus structure of the as well. These philosophies will allow systems to be built with the MC68000 family FC3 FC2 FCI FCO STATE RESERVED USER PGM USER DATA RESERVED RESERVED SUPV PGM SUPV DATA IAK CODE BUS SLAVE SPACE Figure I-Support of bus masters and bus slaves in logical and physical memory space by function codes supported by the family

32 National Computer Conference, 1982 that will be upward expandable and not require redesigning to keep increasing performance in the future.

4 32 National Computer Conference, 1982 that will be upward expandable and not require redesigning to keep increasing performance in the future. In the future, as mentioned previously, the two things that will need processor performance will be high-level languages, and user-friendly software. The high-level languages place a high demand on systems because of their inefficiencies relative to assembly language programming and the protection and checking that they offer at run time. A fairly efficient compiler today still produces between 2 and 2.5 times as much code as a comparable program written in assembly languages. Many times the compiler-generated code can be optimized, but the ratio still rarely drops below 2. As more of the operating systems are written in high-level languages, these inefficiencies are carried along and compounded, since both the application program and the operating system are much larger than they need to be. These performance degradations are the cost of easing demands on programmers and making software more portable. The other thing that will affect system performance will be user-friendly software, which has extensive error checking/recovery, and user aids in the sense of online documentation and "help" commands. These things were not a problem previously, because the available processors simply did not have enough performance. Now microcomputers offer performance comparible to minis and low-end mainframes, so it is reasonable to employ these practices. The problem now is that the growth of inefficiency is faster than the increase of system performance offered by microprocessor vendors. The solution is to get on a faster performance growth curve than single-processor systems can offer. The way to do this is obviously to depend on multiple processors, each having its own local resources, and a communication mechanism between each two elements. To take full advantage of this, the problem being solved must be highly parallel; fortunately, today in the office environment, the problems are fairly parallel. Additionally, in an effort to reduce the cost of CRT. terminals, by using microprocessors with local resources as the heart of the CRT controller design, the basis of a distributed processing system has been established. Tightly coupled multiprocessor systems will be developed for solving specific problems that are limited in scope, and both moderately and loosely coupled systems will be developed because of economic pressures. WAYS TO SOLVE THE PERFORMANCE PROBLEM As previously mentioned, multiple processors will offer the raw performance required to do the job in the future, but their interconnection topology is a critical issue. The basic three ways to use multiple processors are (1) tightly coupled, (2) moderately coupled, and (3) loosely coupled. The tightly coupled systems typically share one instruction bus and rely on each processor's taking a large number of internal cycles for each external (bus) cycle. The moderately coupled systems have multiple processors, each with its own resources on its own local bus, and depend on some mechanism for communications with the rest of the system. Usually this mechanism is a high-speed DMA channel or a dual-ported mailbox. Each solution offers a fairly high bandwidth communications channel to the processor. The loosely coupled processors depend again on multiple processors, each with its own resources; but this time the communications mechanism is a serial data communications link, which typically has about one-tenth of the bandwidth of the moderately coupled solution. The loosely coupled solution does have the advantages of allowing each processing node to be some distance from the other nodes. WHY NOT TIGHTLY COUPLED SYSTEMS? There are several disadvantages to tightly coupled multiprocessor systems, the main one being that the system quickly becomes bus-bound. Figure 2 shows a typical tightly coupled system block diagram. Each processor added competes for an ever smaller percentage of the available bus bandwidth until there is none left. An example of this would be to try to tightly couple two MC68000s. Each MC68000 executes on the average 5 cycles internally for each 4 external cycles. The fact that the average instruction time is close to what the bus cycle time is means that one uses between 80% and 90% of the available bus bandwidth. The MC68000 makes better use of the bus than many other processors, and because each processor will try to get as much of the available bandwidth as possible, the addition of a second processor on the bus would allow it to have a maximum of 20% of the bus bandwidth. The second processor would at best be running at 25% of the throughput that it could have if it were on its own local bus. The net improvement in performance resulting from the addition of the second processor would be at best a 25% increase, and more than likely would not be more than 10% because of bus arbitration overhead. In some instances it does make sense to tightly couple processors on one local bus, but this is the case when the second processor can execute some particular instructions much faster than the current processor. An example of this would be the addition of a floating-point coprocessor, which can do floating-point calculations an order of magnitude faster than the current MC68000 can. The effect on performance is positive in this instance rather than negative because there is an inherent isolation in what each processor would be trying to do, so processors would not compete heavily for the bus. The guideline for deciding to add a coprocessor to the system should be that the problem be isolated well enough that the communications overhead would not be more than 10% of the total time taken to solve the problem. This insures that the additional performance of the dedicated coprocessor is not offset by the communications overhead of the addition. The trend in the future will be for processors to take fewer cycles on the average for each instruction, thus trying to occupy 100% of the available bus bandwidth. When the processor has instructions that execute that quickly, performance improvements must then come from providing more memory bandwidth. This is usually done by either adding a hierarchial memory scheme or widening the bus interface. These trends will help the problem; but the message is still clear that the bus is a scarce resource and that the way to get more performance in the future is not to try to tightly couple processors, except when they do not compete for memory bandwidth resources. Another way of soiving the performance problem is to depend on a loosely coupled network of processors, all commu-

5 The MC68000 Family and Distributed Processing BIT MICROPROCESSOR 1 MCllOOO 1881T MICROPROCESSOR 2 MC88000 DATA DATA 1211( RAIl ADDR ADDR 128K RAM DATA LOCAL BUS 2 DATA loot ROM ADDR REO REO ACK " ACK ADDR BOOT ROM ~~ ~,---~~PCL,..._I-~DONE '-40-+-~ DTC DMAC MC68450 DMAC MC68450 GAB RIW, GBA RIW. BUS TRANSCEIVERS Figure 2-Tightly coupled multiple system nicating over a serial data communications link. This topology works particularly well when the problem to be solved is highly parallel and isolated, with a low communications requirement. An example of this would be a distributed word processing system, where editing is done locally, with a local processor and local memory resources, and a datacom line to link the work station to a file server or a printer. The system performance in this instance is much higher than previously, because the problem is parallel enough to allow concurrent operations. It is intuitively known that this solution works best in applications like distributed word processors but starts to suffer from contention problems when the application is heavily dependent on the distant resources. An example of this second application might be an airline reservation system, where the time spent editing the data locally is small in comparison to the time required to transmit it. Figure 3 is a block diagram of a loosely coupled multiprocessor system. Yet another solution has the advantages of the loosely coupled topology and does not suffer from the low bandwidth interconnection between processing elements. This is the moderately coupled system. In this instance each processor is still on its own local bus, but the interconnection to the other processors is done through either a dual-port RAM or a DMA channel. This approach again lends itself to problems that are inherently concurrent, but does not suffer as much when the problems are communications-dependent. Figure 4 shows a typical moderately coupled multiprocessor system. Motorola has two products that depend on this topology to allow for concurrent processing. These products are the MC68120 Intelligent Peripheral Controller and the MC68122 Cluster Terminal Controller. I MC68000 I I W680""... uu I ~ LOCAL RESOURCES I-- LOCAL RESOURCES SERIAL DATA SERIAL DATA I...-- COMM COIfoI - INTERFACE INTERFACE -') I I HIGH SPEED SERIAL DATA LINK Figure 3--Loosely coupled processor topology THE MC68120 INTELLIGENT PERIPHERAL CONTROLLER 'S- The MC68120 Intelligent Peripheral Controller is a generalpurpose peripheral controller that consists of an 8-bit CPU, 2 Kbytes of read-only-memory, 128 bytes of RAM, a 16-bit timer, a serial communications interface, and 23 parallel I/O lines. These I/O lines can be used to connect to peripherals directly, or, more importantly, can be used to form an MC6800-type bus that can be used for general-purpose I/O processing. With the in this mode, I/O burdens can be removed from the central CPU and more time can be devoted to instruction processing, resulting in increased performance

6 34 National Computer Conference, 1982 BAM IN A MC68000 LOCAL BUS IIC 000.,... ", 8R, 80 ADDRESS 8US DATA 8US I I I BOACI( t:j I/O ~ IIC 8R D8R7,... Ba DB07, ", 80 'If 8R IIce'''62 I 8aACK BAli ~ DISK 8R D8Re CONTR " 80 OBoe,.... /' I 80ACK 8R D8R6 ~ / CRTC... i.- 80 D805, I' 'OOACK r BaACK Figure 4-Moderately coupled multiprocessor topology due to the parallelism. Communications is done through the dual-port RAM that is on board the 68120, and access permission is controlled via the six semaphore registers. Each register contains a bit that indicates whether the resources it describes are currently in use and a bit that identifies which processor (master or slave) used it last. These registers are set up under software control to correspond to common resources between the MC68000 and the MC68120 and are not strictly limited to the dual-port RAM. Figure 5 is a block diagram of the MC68120 connected in a system with a private bus, acting as an 110 processor. 11 lit IIICIIbPRoCEISO 1 -=--,. lit -=-- ~z The Cluster Terminal Controller The MC68122 Cluster Terminal Controller is an example of an MC68120 that has been programmed to act as an interface processor between a cluster of terminals and a host processor. The CTC uses the private bus to communicate with multiple Asynchronous Communications Interface Adapters and the dual-port RAM as a message buffer. The CTC can support four terminals at 9600 baud, or as many as 32 at 300 baud. This restriction comes about as a result of using the dual-ported RAM as a mailbox mechanism. If the mailbox were larger, a correspondingly larger number of terminals could be supported; however, it was found that this ratio of terminais to processors was quite acceptable. The performance advantage Figure 5-System block diagram of an MC68120 being used as an 1/0 processor is obvious, since now the Cluster Terminal Controller has effectively reduced the number of interrupts to the host system from around 4000 per second to 60 per second. Assuming that the interrupt latency of the system was around 30 microseconds per interrupt and the return overhead was around 20 microseconds per interrupt, the operating system

7 The MC68000 Family and Distributed Processing 35 overhead can be reduced from 19% to 3% (this calculation assumed four terminals each running at 9600 baud, shipping average buffers of 64 characters through the dual-port RAM buffer). The performance increase speaks for itself in this instance. Figure 6 shows the Cluster Terminal Controller in a typical system environment. MC88122 TYPICAL SYSTEM CONFIGURATION SUMMARY In summary, the processors and peripherals of tomorrow will be more performance-oriented and will have to be well thought out so that they can be upwardly expanded without requiring a major system redesign. In this situation the customer will be in a critical position, since it will become increasingly more difficult to mix vendors' parts and the vendor will have a stronger influence over the customer's system. For these reasons the customer should give special consideration Figure 6-Block diagram of the ere system to the vendor chosen to make sure that there is a consistent, well-thought-out growth path from current products to the products of the future.

Computer-System Organization (cont.)

Computer-System Organization (cont.) Interrupt time line for a single process doing output. Interrupts are an important part of a computer architecture. Each computer design has its own interrupt mechanism,