Instructive Microprocessors and Microcomputer Elements
6.6 MOTOROLA 68000 16/32-BIT MICROPROCESSOR FAMILY
Motorola followed its 6800 family by leaping directly to a hybrid 16/32-bit microprocessor architec-ture. Introduced in 1979, the 68000 is a 16-bit microprocessor, due to its 16-bit ALU, but it contains all 32-bit registers and a linear, nonsegmented 32-bit address space. (The original 68000 did not bring out all 32 address bits as signal pins but, more importantly, there are no architectural limita-tions of using all 32 bits.) That the register and memory architecture is inherently 32 bits made the 68000 family easily scalable to a full 32-bit internal architecture. Motorola upgraded the 68000 fam-ily with true 32-bit devices, including the 68020, 68040, and 68060, until switching to the PowerPC architecture in the latter portion of the 1990s for new high-performance computing applications. Ap-ple Computer used the 68000 family in their popular line of Macintosh desktop computers. Today, the 68000 family lives on primarily as a mid-level embedded-processor core product. Motorola man-ufacturers a variety of high-end microcontrollers that use 32-bit 68000 microprocessor cores. How-ever, in recent years Motorola has begun migrating these products, as well as their general-purpose microprocessors, to the PowerPC architecture, reducing the number of new designs that use the 68000 family.
The 68000 inherently supports modern software operating systems (OSs) by recognizing two modes of operation: supervisor mode and user mode. A modern OS does not grant unlimited access to application software in using the computer’s resources. Rather, the OS establishes a restricted op-erating environment into which a program is loaded. Depending on the specific OS, applications may not be able to access certain areas of memory or I/O devices that have been declared off limits by the OS. This can prevent a fault in one program from crashing the entire computer system. The OS kernel, the core low-level software that keeps the computer running properly, has special privi-leges that allow it unrestricted access to the computer for the purposes of establishing all of the rules and boundaries under which programs run. Hardware support for multiple privilege levels is crucial for such a scheme to prevent unauthorized programs from freely accessing restricted resources. As microprocessors developed over the last few decades, more hardware support for OS privileges was added. That the 68000 included such concepts in 1979 is a testimony to its scalable architecture.
Sixteen 32-bit general-purpose registers, one of which is a user stack pointer (USP), and an 8-bit condition code register are accessible from user mode as shown in Fig. 6.11. Additionally, a supervi-sor stack pointer (SSP) and eight additional status bits are accessible from supervisupervi-sor mode. Com-puter systems do not have to implement the two modes of operation if the application does not require it. In such cases, the 68000 can be run permanently in supervisor mode to enable full access to all resources by all programs. The SSP is used for stack operations while in supervisor mode, and the USP is used for stack operations in user mode. User mode programs cannot change the USP, pre-venting them from relocating their stacks. Most modern operating systems are multitasking, mean-ing that they run multiple programs simultaneously. In reality, a microprocessor can only run one program at a time. A multitasking OS uses a timer to periodically interrupt the microprocessor, per-haps 20 to 100 times per second, and place it into supervisor mode. Each time supervisor mode is in-voked, the kernel performs various maintenance tasks and swaps the currently running program with the next program in the list of running programs. This swap, or context switch, can entail substantial modifications to the microprocessor’s state when it returns from the kernel timer interrupt. In the case of an original 68000 microprocessor, the kernel could change the return value of the PC, USP, the 16 general-purpose registers, and the status register. When normal execution resumes, the micro-processor is now executing a different program in exactly the same state at which it was previously interrupted, because all of its registers are in the same state in which they were left. In such a scenario, each program has its own private stack, pointed to by a kernel-designated stack pointer.
The eight data registers, D0–D7, can be used for arbitrary ALU operations. The eight address reg-isters, A0–A7, can all be used as base addresses for indirect addressing and for certain 16- and 32-bit -Balch.book Page 139 Thursday, May 15, 2003 3:46 PM
140 Digital Fundamentals
ALU operations. All 16 registers can be used as index registers. While operating in user mode, it is illegal to access the SSP or the supervisor portion of the status register, SR. Such instructions will cause an exception, whereby a particular interrupt is asserted, which causes the 68000 to enter su-pervisor mode to handle the fault. (Exception and interrupt are often used synonymously in com-puter contexts.) Very often, the OS kernel will terminate an application that causes an exception to be generated. The registers shown above are present in all 68000 family members and, as such, are software is compatible with subsequent 68xxx microprocessors. Newer microprocessors contain ad-ditional registers that provide more advanced privilege levels and memory management. While the 68000 architecture fundamentally supports a 4-GB (32-bit) address space, early devices were lim-ited in terms of how much physical memory could actually be addressed as a result of pin limitations in the packaging. The original 68000 was housed in a 64-pin DIP, leaving only 24 address bits us-able, for a total usable memory space of 16 MB. When Motorola introduced the 68020, the first fully 32-bit 68000 microprocessor, all 32 address bits were made available. The 68000 devices are big-en-dian, so the MSB is stored in the lowest address of a multibyte word.
The 68000 supports a 16-MB address space, but only 23 address bits, A[23:1], are actually brought out of the chip as signal pins. A[0] is omitted and is unnecessary, because it would specify whether an even (A[0] = 0) or odd (A[0] = 1) byte is being accessed; and, because the bus is 16 bits wide, both even and odd bytes can be accessed simultaneously. However, provisions are made for byte-wide accesses in situations where the 68000 is connected to legacy eight-bit peripherals or memories. Two data strobes, upper (UDS*) and lower (LDS*), indicate which bytes are being ac-cessed during any given bus cycle. These strobes are generated by the 68000 according to the state of the internal A0 bit and information on the size of the requested transaction. Bus transactions are triggered by the assertion of address strobe (AS*), the appropriate data strobes, and R/W* as shown in Fig. 6.12. Prior to AS*, the 68000 asserts the desired address and a three-bit function code bus, FC[2:0]. The function code bus indicates which mode the processor is in and whether the transaction is a program or data access. This information can be used by external logic to qualify transactions to certain sensitive memory spaces that may be off limits to user programs. When read data is ready, the external bus interface logic asserts data transfer acknowledge (DTACK*) to inform the micro-processor that the transaction is complete. As shown, the 68000 bus can be operated in a fully asyn-chronous manner. When operated asynasyn-chronously, DTACK* is removed after the strobes are
32 bits
-Balch.book Page 140 Thursday, May 15, 2003 3:46 PM
Instructive Microprocessors and Microcomputer Elements 141
removed, ensuring that the 68000 detected the assertion of DTACK*. If DTACK* is removed prior to the strobes, there is a chance of marginal timing where the 68000 may not properly detect the ac-knowledge, and it may wait forever for an acknowledge that has now passed. Writes are very similar to reads, with the obvious difference that R/W* is brought low, and data is driven by the 68000. An-other difference is that the data strobe assertion lags that of AS*.
Advanced microprocessors such as the 68000 are designed to recognize fault conditions wherein the requested bus transaction cannot be completed. A bus fault can be caused by a variety of problems, including unauthorized access (e.g., user mode tries to write to a protected supervisor data space) or an access to a section of memory that is not filled by a memory or peripheral device. Software should never access areas of memory that are off limits, because the results are unpredictable. Therefore, rather than simply issuing a false DTACK* and continuing with normal operation, the 68000 contains a bus error signal (BERR*) that behaves like DTACK* but triggers an exception rather than continu-ing normal execution. It is the responsibility of external logic to manage the DTACK* and BERR*
signals according to the specific configuration and requirements of the particular system.
Operating the 68000 bus in an asynchronous manner is easy, but it reduces its bandwidth, because delays must be built into the acknowledge process to guarantee that both the 68000 and the interface logic maintain synchronization. Figure 6.12 shows read data being asserted prior to DTACK* and an arbitrary delay between the release of AS* and that of DTACK*. The data delay is necessary to guar-antee that the 68000 will see valid data when it detects a valid acknowledge. The second delay is necessary to ensure that the 68000 completes the transaction, as noted previously. These delays can be eliminated if the bus is operated synchronously by distributing the microprocessor clock to the in-terface logic and guaranteeing that various setup and hold timing requirements are met as specified by Motorola. In such a configuration, it is known from Motorola’s data sheet that the 68000 looks for DTACK* each clock cycle, starting at a fixed time after asserting the strobes, and then samples the read-data one cycle after detecting DTACK* being active. Because synchronous timing rules are obeyed, it is guaranteed that the 68000 properly detects DTACK* and, therefore, DTACK* can be removed without having to wait for the removal of the strobes. 68000 synchronous bus timing is shown in Fig. 6.13, where each transaction lasts a minimum of four clock cycles. A four-cycle trans-action is a zero wait state access. Wait states can be added by simply delaying the assertion of DTACK* to the next cycle. However, to maintain proper timing, DTACK* (and BERR* and read-data) must always obey proper setup and hold requirements. As shown in the timing diagram, each signal transition, or edge, is time-bounded relative to a clock edge.
Read timing allows a single clock cycle between data strobe assertion and the return of DTACK*
for a zero wait-state transaction. However, zero wait-state writes require DTACK* assertion at A[23:1]
-Balch.book Page 141 Thursday, May 15, 2003 3:46 PM
142Digital Fundamentals
roughly the same time as the data strobes. Therefore, the bus interface logic must make its decision on asserting DTACK* based on the requested address when AS* is asserted. If the requested device is operational, DTACK* can be immediately asserted for a fast transaction. Unlike reads, where the microprocessor must wait for a device to return data, writes can be acknowledged before they are ac-tually transferred to the device. In such a scheme, writes are posted within the bus interface logic.
One or two cycles later, when the device accepts the posted write data, the bus interface logic finally completes the transaction without having delayed the microprocessor. If completion of the posted-write transaction takes longer than a few cycles, it could force a subsequent access to the same de-vice to incur wait states. Either a read or a write would be blocked until the original write was able to complete, thus freeing the device to handle the next transaction.
In addition to the basic bus interface, the 68000 supports bus arbitration to enable DMA or other logic to use the microprocessor bus for arbitrary applications. A bus request (BR*) signal is asserted by a device that wants to temporarily gain control of the bus. On the next clock cycle, when the mi-croprocessor is not inhibited by other operations, it asserts a bus grant (BG*) signal and places its address, data, and control signals into tri-state so that they may be driven by the other device. The re-questing device then asserts bus grant acknowledge (BGACK*) to signal that it is controlling the bus, and it is then free to assert its own strobes, address, and data signals.
A variety of interrupts and exceptions are supported by the 68000. Some are triggered as a result of instruction execution and some by external signals (e.g., BERR* or an interrupt request). Exam-ples of instruction exceptions are illegal user mode register accesses or a divide-by-zero error. Most microprocessors that provide division capability contain some type of divide-by-zero error handling, because the result of such an operation is mathematically undefined and is usually the result of a fault in the program. The 68000 contains an exception vector table that is 1,024 bytes long and re-sides at the beginning of memory at address 0. In a multitasking system, the bus interface logic may restrict access to the vector table to supervisor mode only. In such a case, a bus error could be trig-gered if a user mode program, indicated by FC[2:0], tried to write the table. Each of the 256 vector entries is four bytes long and provides the starting address of the associated ISR. The one deviation from this rule is the reset vector, which actually consists of two entries at word addresses 0 and 4.
Upon reset, the 68000 fetches an initial PC value from address 4 and an initial SSP value from ad-dress 0. Vectors 0 through 63 are assigned or reserved by Motorola for various hardware exceptions.
Vectors 64 through 255 are assigned as user interrupt vectors. Like other microprocessors in its cate-gory, the 68000 supports bus vectoring of user interrupts where an external interrupt controller as-serts an interrupt number onto the data bus during an interrupt acknowledge cycle performed by the 68000 in response to an interrupt request. This interrupt number is multiplied by four and used to in-dex into the exception table to fetch the address of the appropriate ISR.
A[23:1], FC[2:0]
-Balch.book Page 142 Thursday, May 15, 2003 3:46 PM