View unanswered posts | View active topics It is currently Wed Jul 17, 2019 10:35 pm



Reply to topic  [ 266 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 18  Next
 EPiC - A new 68k multi-processor motherboard project 
Author Message

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1202
The thing about slicing your address space up very finely is that you need to take lots of address lines into your decode logic - and yet for high clock speed you need that decode to be fast. With a coarse address space allocation, you only need to use a few bits from the top of the address bus. For example:
- A31 high selects RAM
- A30 high selects I/O
- A29 low selects boot ROM
(I think this only gives you 512M of space for RAM, because the other two areas are mapped more than once, and you can't make use of areas where more than one would be active. You can fix that, at the cost of combining some address bits. The more bits you combine, the more RAM you can have! See for example Garth's simplest 6502 decoding circuit at http://wilsonminesco.com/6502primer/addr_decoding.html)


Thu Jun 05, 2014 7:52 pm
Profile

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
BigEd wrote:
The thing about slicing your address space up very finely is that you need to take lots of address lines into your decode logic - and yet for high clock speed you need that decode to be fast. With a coarse address space allocation, you only need to use a few bits from the top of the address bus. For example:
- A31 high selects RAM
- A30 high selects I/O
- A29 low selects boot ROM
(I think this only gives you 512M of space for RAM, because the other two areas are mapped more than once, and you can't make use of areas where more than one would be active. You can fix that, at the cost of combining some address bits. The more bits you combine, the more RAM you can have! See for example Garth's simplest 6502 decoding circuit at http://wilsonminesco.com/6502primer/addr_decoding.html)


Okay, again with the speed issue... hmm. Is there anything that says you have to use address lines from the top of the bus? Is there any disadvantage to using them from the bottom instead? Just curious.

Also, I'll start reading that link right now. :)


Thu Jun 05, 2014 8:05 pm
Profile

Joined: Tue Dec 11, 2012 8:03 am
Posts: 265
Location: California
Starting at low bits of the address would give you a very chopped-up address map. In fact, starting with A0 would keep even two addresses in a row from going to the same thing-- clearly unworkable. Starting at the top, like A31 if there are 32 address lines, then going down to A30 and A29, no block is less than half a gig in size. It may seem very wasteful to spend that much on I/O, but the advantage is that you can keep the maximum clock speed much higher because there are very few cascaded levels of logic in the decoding circuitry. When you cascade those gates one after another, you have to add up their propagation delays. Fast CPLDs help of course, as they guarantee a maximum from pin to pin, regardless of what you program to be between the pins.

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


Thu Jun 05, 2014 8:20 pm
Profile WWW

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
Garth wrote:
Starting at low bits of the address would give you a very chopped-up address map.


Indeed, but I was thinking of adding a NOR gate to the upper address lines so that the address decoder on the lower bits would only kick in when all the upper bits are clear. If they aren't, then the request goes to DRAM, preventing parts of the I/O memory from appearing on every "page". I spent most of my weekend testing this design out in the simulator using discrete logic chips, and even at my best design there were - lo and behold - no less than 3 levels of logic between the memory and the CPU... obviously not going to work. Yes, I know you guys told me so... but... sometimes I learn better from seeing it in action I guess lol :oops:
Attachment:
File comment: First attempt at address decoding
attempt.png
attempt.png [ 54.36 KiB | Viewed 6351 times ]




Garth wrote:
When you cascade those gates one after another, you have to add up their propagation delays.


Yep, another thing I overlooked before. Thanks yet again for the pointer. :)



Garth wrote:
Fast CPLDs help of course, as they guarantee a maximum from pin to pin, regardless of what you program to be between the pins.


I'm pretty sure I'll have to go the CPLD or FPGA route when I make the jump to the 68060. Normal logic just isn't fast enough for what I want to do. I considered using ECL, but finding that stuff is near impossible.



I've started drawing up some plans for the 68000 test unit which I've decided to attempt first. My latest idea involves attaching a 4-to-16 line decoder to the upper address lines to split the address space into 16 separate blocks. EPROM occupies only the first megabyte, I/O lives in the next meg, video in the next and so on. This leaves a single contiguous block of RAM from wherever the devices end clear up to the top of the memory space.

I'm using 32K SRAM chips in the simulation because it doesn't have the 512KB modules (similar to what Garth used in his 4MB RAM module) in its library. If those are used, the hole in the middle of the address area goes away. And best of all, it's only one level of logic! Nice and speedy. Below is a preliminary sketch of how this should play out, so everyone feel free to let me know if there's some egregious error I've committed. As I always say, I'm far from an expert here.
Attachment:
File comment: Beginning schematic for the 68000 tester board
68000 tester.png
68000 tester.png [ 61.87 KiB | Viewed 6351 times ]


I managed to dig up some old memory chips I got from work and discovered I already have most of what I need for the 68000 starter: a pair of AMD EPROMs (AM27256DC & AM27C512), a Dallas NVSRAM (DS1220AB) and a quartet of Intel D2764s. I've also ordered an EPROM programmer, an EPROM eraser, a pair of MC68681 DUARTs and - of course - the 68000 itself.

I'm looking forward to getting everything in! I'll keep you all posted.


Edit: I guess it helps to actually attach files when you say you're going to, huh?


Mon Jun 09, 2014 4:46 am
Profile

Joined: Tue Dec 11, 2012 8:03 am
Posts: 265
Location: California
The 74159 has open-collector outputs (your pull-up resistors were the tip to prompt me to look it up), so it's not suitable for the speeds you want. The time constant to pull the voltage up will be the pull-up resistor value times the capacitance on the bus; so for example 30pF times 10K is 300ns-- way out of the useful range. Can you use a '154 instead?

I'm sure your CAD will let you create your own components. It would just about have to, since there are so many that are not standards, whether a surface-mount switch or LED or any of countless other things that were just too much to include in the software package.

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


Mon Jun 09, 2014 6:02 am
Profile WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1202
Have you checked the speed (prop delay) of those 4-16 line decoders? Certainly in the past I've seen advice that the 3-8 decoders are not very fast.

Cheers
Ed


Mon Jun 09, 2014 7:30 am
Profile

Joined: Tue Dec 11, 2012 8:03 am
Posts: 265
Location: California
Uh-oh, yep, I don't see the '154 available in any of the faster families! My NSC data books don't have it in 74AC, ACT, AS, ALS, VHC, or ABT. That's not to say another manufacturer wouldn't have it, if you look around. Otherwise, it may have to be programmable logic.

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


Mon Jun 09, 2014 8:24 am
Profile WWW

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
Garth wrote:
The 74159 has open-collector outputs (your pull-up resistors were the tip to prompt me to look it up), so it's not suitable for the speeds you want. The time constant to pull the voltage up will be the pull-up resistor value times the capacitance on the bus; so for example 30pF times 10K is 300ns-- way out of the useful range. Can you use a '154 instead?

I'm sure your CAD will let you create your own components. It would just about have to, since there are so many that are not standards, whether a surface-mount switch or LED or any of countless other things that were just too much to include in the software package.


The resistor delay never occurred to me, but yes this is way too slow for my purpose. I'm only clocking the tester board with a 555 so it's not going to break any speed records, but I still need better times than that! I swapped out the 74159 for a 74154 and all is still well. Thanks, good catch! :)

I believe the simulator does let you create parts but I haven't yet learned how. Back when Fritzing was my go-to CAD program, I made several packages for it but alas this new software is more complex.



BigEd wrote:
Have you checked the speed (prop delay) of those 4-16 line decoders? Certainly in the past I've seen advice that the 3-8 decoders are not very fast.

Cheers
Ed


I have now. Looks like a 74154 will be fast enough for the tester board, but not for the 68060. FPGA, here I come... :o



Garth wrote:
Uh-oh, yep, I don't see the '154 available in any of the faster families! My NSC data books don't have it in 74AC, ACT, AS, ALS, VHC, or ABT. That's not to say another manufacturer wouldn't have it, if you look around. Otherwise, it may have to be programmable logic.


Some of the 74154s I'm finding have speeds in the 30 ns range, but even this should be fast enough to run at 16 MHz or so, which is way faster than I'm planning to have the thing run.


Mon Jun 09, 2014 8:56 pm
Profile
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 180
Some good progress with these ideas, I see! :) My two cents worth:

  • might the 68008 be a better choice for your starter? 8-bit data bus, not 16. Smaller package; less work to wire up. One each RAM & EPROM (not 2 each).

  • Garth has exaggerated slightly in saying the CPLD can do anything in a fixed amount of time. That'll be true for most equations used for address decoding, but you need to check. If you do something too fancy then it'll need 2 or more passes through the logic -- with a corresponding increase in delay. I'm pretty sure that, to respond in a single pass, the equation has to be no more complex than a sum of products -- a bunch of AND gates whose outputs feed an OR gate. (You can go a long way with that.)

  • For fast decode logic, I was delighted recently to learn of the 74LVC family. Example: the 3 ns (maximum :shock: ) 3-input OR; datasheet attached. With this sort of building block, multiple levels of logic become a lot more tolerable!
    Attachment:
    SN74LVC1G332_Rev2006.pdf [953.67 KiB]
    Downloaded 337 times

all for now,
Jeff

_________________
http://LaughtonElectronics.com


Last edited by Dr Jefyll on Tue Jun 10, 2014 9:33 pm, edited 1 time in total.



Tue Jun 10, 2014 2:32 pm
Profile WWW

Joined: Tue Dec 11, 2012 8:03 am
Posts: 265
Location: California
Dr Jefyll wrote:
ps- Darn! -- it won't let me attach that PDF! :cry: But I link to it in this post on 6502.org. There's a sample decode circuit, too (not 68K related).

Files are limited to 256K, so I PM'ed Dajgoro to ask how big it would be ok to set that, and then I realized your image file is much smaller than that; so I don't know what the problem is. Data sheets will always be larger than 256K.

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


Tue Jun 10, 2014 2:56 pm
Profile WWW

Joined: Tue Dec 11, 2012 8:03 am
Posts: 265
Location: California
Try it again now Jeff.

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


Tue Jun 10, 2014 9:00 pm
Profile WWW

Joined: Tue Dec 11, 2012 3:41 am
Posts: 68
Upload test.


Attachments:
Tue Jun 10, 2014 9:28 pm
Profile
User avatar

Joined: Tue Jan 15, 2013 5:43 am
Posts: 180
That's better! :) I just edited my post, and was able to include ther PDF.

_________________
http://LaughtonElectronics.com


Tue Jun 10, 2014 9:35 pm
Profile WWW

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
Dr Jefyll wrote:
Some good progress with these ideas, I see! :) My two cents worth:

  • might the 68008 be a better choice for your starter? 8-bit data bus, not 16. Smaller package; less work to wire up. One each RAM & EPROM (not 2 each).

  • Garth has exaggerated slightly in saying the CPLD can do anything in a fixed amount of time. That'll be true for most equations used for address decoding, but you need to check. If you do something too fancy then it'll need 2 or more passes through the logic -- with a corresponding increase in delay. I'm pretty sure that, to respond in a single pass, the equation has to be no more complex than a sum of products -- a bunch of AND gates whose outputs feed an OR gate. (You can go a long way with that.)

  • For fast decode logic, I was delighted recently to learn of the 74LVC family. Example: the 3 ns (maximum :shock: ) 3-input OR; datasheet attached. With this sort of building block, multiple levels of logic become a lot more tolerable!
    Attachment:
    SN74LVC1G332_Rev2006.pdf

all for now,
Jeff


The 68008 is a decent chip in it's own right, but I don't want to stray too far from the 68060. Granted the instruction set and everything is compatible and all, but still... idk. I guess I've always just had a thing for the 32 bit 68k line. Besides, the 68000 is already on its way to my door! :lol:

The 74LVC components are a nice find! I may be able to make them work, or maybe I'll just go with an FPGA for the added flexibility. Decisions, decisions... As someone said earlier, the '060 has a sizable cache setup, so even if accessing RAM is slow, the cache should more than make up for that. I hope.


Tue Jun 10, 2014 11:18 pm
Profile

Joined: Tue Jun 03, 2014 2:40 pm
Posts: 127
Lookie what was on my desk when I got home today. :)


Attachments:
IMG_20140611_191615.jpg
IMG_20140611_191615.jpg [ 334.87 KiB | Viewed 6278 times ]
Wed Jun 11, 2014 11:24 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 266 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 18  Next

Who is online

Users browsing this forum: No registered users and 3 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