View unanswered posts | View active topics It is currently Fri Mar 29, 2024 1:06 pm



Reply to topic  [ 15 posts ] 
 MMU for the MC68020 
Author Message
Site Admin

Joined: Tue Dec 11, 2012 1:08 am
Posts: 16
As part of my MC68020 computer project I want to have a MMU.
I realize that the MC68030 has an integrated MMU, but that CPU is more expensive and it is much harder to find, anyway I decided to stick with the 68020.
So currently there are two ideas on about how to build it.
In both ideas the MMU also incorporates an MPU(Memory Protection Unit) which contains permissions such as read/write/execute.

The first idea is to have 4x64K rast SRAM ic on the upper 16 bit address lines.
When in not supervisor mode, the upper 16 address but would be remapped to a custom location, and when in supervisor mode, the address space would be linear again by bypassing the whole 4x64k ram ic circuit. The 4x64k ram can only be accessed for write operations in supervisor mode.

The second idea is to have a more traditional approach, and that would be to have a table pointer stored in a register, and when the CPU accesses a memory location it would first load the translated address form the table map stored in ram, and when the resulting address has been loaded, then the memory location can be accesses. The concept is similar to the 80386 MMU.

I plan to try to somehow port some Linux distribution to the machine, so it should be Linux friendly as much as possible.

CPLD and FPGA IC won't be used on the CPU board, only discrete logic and PAL-s.


Dajgoro


Thu Jan 31, 2013 3:51 am
Profile
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Attachment:
68K_MMU.gif
68K_MMU.gif [ 5.83 KiB | Viewed 11485 times ]
Quote:
The first idea is to have 4x64K rast SRAM ic on the upper 16 bit address lines
Hi Dajgoro,
I created a diagram to help illustrate your scheme, but I had trouble with some of the details. You said 4x64K for the SRAM ic, but wouldn't you need it to be wider than 4 bits?

Quote:
when in supervisor mode, the address space would be linear again by bypassing the whole 4x64k ram ic circuit
The bypass is something I didn't show in the diagram. Would you use an actual multiplexer, or would the output of the mapping RAM be a tri-state point that can also be driven by a 74_244 buffer delivering the unmapped bits?

Something else you'll need to include is a data path that allows the mapping ram to be written to.

cheers,
Jeff

http://LaughtonElectronics.com

_________________
http://LaughtonElectronics.com


Sun Feb 03, 2013 6:14 pm
Profile WWW
Site Admin

Joined: Tue Dec 11, 2012 1:08 am
Posts: 16
Quote:
4x64K for the SRAM ic, but wouldn't you need it to be wider than 4 bits?

I wasn't very clear, I meant x4 64k bit ram ic.

I also drew a concept schematic with most of the components, but it is only a sketch in paint, so I didn't upload it.

At the moment I am looking more to the second concept, the one with the translation tables located in ram.
I was thinking about splitting the cpu clock in a two phase clock, and use the first phase to load the translation table value, and the next one to access the memory.


Sun Feb 03, 2013 9:28 pm
Profile
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Quote:
I wasn't very clear, I meant x4 64k bit ram ic.
No problem. I knew something wasn't adding up!! :roll:

Quote:
I am looking more to the second concept, the one with the translation tables located in ram.
I was thinking about splitting the cpu clock in a two phase clock, and use the first phase to load the translation table value, and the next one to access the memory.
More like this, then -- the table lives in the same physical RAM as the data? That could work very well. Of course the two-phase idea means there'll be two memory access delays, so you'll need to keep the CPU clock pretty slow, use wait states or else get some very fast RAMs. Luckily, it's easy and fairly cheap to buy fast RAMs nowadays -- certainly a lot faster & cheaper than when the 68020 came out, I mean. :)

Attachment:
68K_MMU2.gif
68K_MMU2.gif [ 5.79 KiB | Viewed 11456 times ]
http://LaughtonElectronics.com

_________________
http://LaughtonElectronics.com


Mon Feb 04, 2013 2:40 am
Profile WWW

Joined: Tue Dec 11, 2012 3:41 am
Posts: 68
The idea is just like what you have drawn on that picture.
Although the translation table size may vary giving even smaller pages.
The timing wit the phase thing is going to be tight, and I was planing to squeeze all those Garth's ram modules to get the most of the performance out of them. But if the clock rate is too hing, a clock divider could be used before the clock is splitted in two phases.


Thu Feb 07, 2013 9:35 pm
Profile

Joined: Tue Dec 11, 2012 3:41 am
Posts: 68
Another thing that worries me is how complex would it be to port an existing OS such as Linux to a computer that uses such an MMU concept. I do hope of having a proper OS one day on that machine.


Fri Feb 08, 2013 2:27 am
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Another simple idea for memory management is segment registers. It's just a couple of regs like a 74ls670 + adders, and could be tied to the function code outputs of the processor for data vs code.

What are
Quote:
Garth's ram modules
?

_________________
Robert Finch http://www.finitron.ca


Sat Feb 23, 2013 12:42 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Attachment:
File comment: 68000 seg regs
68000 + segment regs.gif
68000 + segment regs.gif [ 9.26 KiB | Viewed 11389 times ]

_________________
Robert Finch http://www.finitron.ca


Sat Feb 23, 2013 1:56 am
Profile WWW

Joined: Tue Dec 11, 2012 8:03 am
Posts: 285
Location: California
robfinch wrote:
Another simple idea for memory management is segment registers. It's just a couple of regs like a 74ls670 + adders, and could be tied to the function code outputs of the processor for data vs code.

What are
Quote:
Garth's ram modules
?

They're shown near the top of the front page of my website, http://wilsonminesco.com/ . The data sheet is linked there too.
It's 4Mx8 10ns 5V SRAM, with four 512Kx8 SRAM ICs on each side. The pin header is hobbyist-friendly, with sockets that can go into perfboard with holes on .100" centers.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Sat Feb 23, 2013 2:21 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
robfinch wrote:
It's just a couple of regs like a 74ls670 + adders, and could be tied to the function code outputs of the processor for data vs code.
OK, the '670 is a dual-port register file. Using five abreast you get four 20-bit words. The Read Port of the register file is addressed by the CPU function code outputs, and the selected 20-bit word is added (by the five '283 4-bit adders) to the high 20 bits of the CPU address bus.

What has me wondering is the choice to use FC0 and FC1, but to ignore FC2. Is that what you intended? No distinction between User and Supervisor?
Attachment:
68020 Address Space Encodings.gif
68020 Address Space Encodings.gif [ 11.06 KiB | Viewed 11386 times ]

cheers,
Jeff
http://LaughtonElectronics.com

_________________
http://LaughtonElectronics.com


Sat Feb 23, 2013 3:27 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
What has me wondering is the choice to use FC0 and FC1, but to ignore FC2. Is that what you intended? No distinction between User and Supervisor?


That's what I was thinking, but FC2 could be included in decoding because there's room for four regs in the '670. It would give a different code/data segment for supervisor mode, which might be useful. One might also want to zero the outputs ('and' gates) of the 670's on reset.
Another approach would be to use 2x '612's (for 24 bits) which have more memory and tie the read address to high order four bits of the address bus to select the seg register, instead of using the function codes.

Since the MMU is taking a clock cycle anyways, maybe both segmentation and paging could be implemented.

_________________
Robert Finch http://www.finitron.ca


Sat Feb 23, 2013 4:22 am
Profile WWW
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 189
Quote:
the choice to use FC0 and FC1, but to ignore FC2...
It seemed like maybe you'd made a typo -- that FC1 is the one you meant to ignore. Actually, that could maybe work! :) IOW, the offset would be selected solely by FC2 and FC0:
  • Address space 0 and 2 would use the same offset (User Program)
  • Address space 1 and 3 would use the same offset (User Data)
  • Address space 4 and 6 would use the same offset (Supervisor Program)
  • Address space 5 and 7 would use the same offset (Supervisor Data / CPU Space)

If the "reserved" spaces are unused then there's very little conflict -- just the business of 5 and 7 (Supervisor Data Space and CPU Space) sharing an offset.
Quote:
One might also want to zero the outputs ('and' gates) of the 670's on reset.
Instead of AND gates, another option is to tri-state the '670 outputs on reset and rely on pullup (or pulldown) resistors to provide a known value until things get initialized.

_________________
http://LaughtonElectronics.com


Sat Feb 23, 2013 4:46 am
Profile WWW

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Attachment:
File comment: Larger Image
68020 + segment regs.gif
68020 + segment regs.gif [ 13.98 KiB | Viewed 11374 times ]


This could probably be done in a CPLD,it's only four regs and an adder, 20 bits wide.

_________________
Robert Finch http://www.finitron.ca


Sat Feb 23, 2013 8:26 am
Profile WWW

Joined: Tue Dec 11, 2012 3:41 am
Posts: 68
Thing is that it would be good when we could have pages about 8k big. Also when task switching, in a static design all registers must be rewritten. So I think that using translation tables in ram is a better way to go.
I need to find a Linux expert, because we can come up with millions of designs for an MMU, but what is the best for porting Linux to the machine?


Sat Feb 23, 2013 8:58 pm
Profile

Joined: Sat Feb 02, 2013 9:40 am
Posts: 2095
Location: Canada
Quote:
but what is the best for porting Linux to the machine?


I suspect something that looks like a standard 680xx series MMU (68451?) would make the port easier. I believe also there's a port for Linux to 68k systems without an MMU.
It may be worth checking out the ports of Linux to machines like the Mac / Amiga / Atari St to see what MMU hardware they use. Otherwise emulating the paging system in the x86 series processors may be the way to go.

Maybe a high-speed microcontroller could be used to emulate an MMU that way the MMU can be altered just by updating software.
How fast is the '020 running ? Suppose there was a 200MHz microcontroller executing eight or ten instruction to translate an address.

You mentioned using static RAM modules. For that small of a memory a dual port RAM like the AM2130 / CY7C130 could be used as a mapping RAM.
All 32 address bits of the '020 don't have to be used. Some of the high order bits could be left unconnected.


Quote:
Also when task switching, in a static design all registers must be rewritten


Being able to update a single pointer register is nice. Note that with a mapping RAM it's also only a single register that needs to updated - the task id register.

Segment registers allow a finer grained memory addressing than paging does, they could map right down to a word. Many architectures include both segment regs and paging hardware. Linux on an x86 box would have to code to deal with segment registers, part of the reason I suggested including them.

_________________
Robert Finch http://www.finitron.ca


Sun Feb 24, 2013 9:12 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 15 posts ] 

Who is online

Users browsing this forum: YandexBot and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software