🚀 go-pugleaf

In article <5635@shemp.UCLA.EDU> fan@CS.UCLA.EDU (Roy Fan) writes:
>--------------
>
>	This is my first posting, so if there is any mistake, please
>excuse.
>
>	I am doing a project on MMU's, and from reading various uP
>data books, I have several questions:
>
>	The Intel iAPX 286 has an on-chip  MMU.
>	The Motorola 68020 has an off-chip MMU (68851).
>	What are the important deciding factors in designing a MMU
>on-chip or off-chip?
>
>	Three I can think of:  execution speed, chip space, and
>additional support.
>
>	Execution Speed:  In general, on-chip MMU is faster than
>off-chip MMU.
>
>	Chip Space:  Sometimes, there is not enough space for putting
>a MMU on-chip.  Sometimes, a cache is implemented instead of a MMU.
>
>	Additional Support:  If the MMU is on-chip, then some
>additional instructions might be needed.  If the MMU is off-chip, then
>additional pins might be needed.
>
>	It seems that the trend is putting the MMU on-chip.  68020 has
>no on-chip MMU, but 68030 has a subset of MMU.  iAPX 386 has MMU on
>chip, and so is the National Semiconductor 32532 (I haven't read the
>data books yet, so I might be mistaken).  Fairchild Clipper has an
>off-chip MMU.
>
>	Question 1 :  are there any other factors that might affect the
>design of the MMU being on-chip or off-chip?
>
>	Question 2 :  if there is enough space on the chip, would
>everybody put the MMU on-chip?
>
>	Question 3 :  if there is only enough room for either a cache
>or a MMU, which one will prevail?
>
>Roy Fan  fan@cs.ucla.edu

Other factors to be considered in the choice of any MMU scheme:

One should look at the architecure of the MMU i.e., segmented
only, demand paged only, or a combination thereof.

One should look at the amount of overhead needed to support the
MMU i.e., the number of translation tables needed, the amount of
memory space required to support the table descriptors, the
control bits provided, i.e., access, modify, cache inhibit, etc.
flags. Intel does not provide a cache inhibit bit making it tough
to design an external cache where certain pages should not be
cached (e.g., shared memory between two processors in some
multiprocessing schemes).

One should look at the potential for a particular MMU scheme being
incorporated in future generation of processors. You should look
at the 286 MMU and the 386 MMU. They are not compatible. The MMU
in the 68030 is compatible with the 68851 PMMU chip.

As to whether an MMU should be on chip with the CPU depends on
the application. The 68030 is an excellent choice for work
staions and systems which support multitasking and/or multiuser
operating systems. The 68020 is a good choice for the above
when coupled with the 68851 PMMU or the users own MMU. Also the
68020 is an excellent choice for embedded controller applications
(e.g., disk, serial communications, LAN, etc.) which do not
usually require an MMU. THe 68020 and 68030 are object code compatible
which makes the software engineers happy. Also, the cost of the
68020 will be coming down to the point where it will make a lot
of sense to use it in embedded controller applications.


-- Rich Goss
Motorola Western Regional Field Applications Engineer for 68000
Family