In the last couple of weeks I've been rethinking my ideas for the core of my computer (it is 6809 based). So far I've had a lot of success with using a Xilinx XC95108 in PLCC84 (the "biggest" 5V CPLD that I can get my hands on). The CPLD handles address decoding, read/write gating, bank switching, interrupt control, drives a sounder, etc. The computer has a C64 keyboard controlled with an AVR, and can even play a game I wrote. While I'm tempted to tidy up what I've done so far and draw up a single PCB for the computer, instead of using multiple stacked boards, or I could work on that little Operating System I've been meaning to write, instead I'm drawn back to the core of the computer and see if there is more interesting things that can be done with the CPLD.

So I have been working on a DMA controller. There's quite a few benefits I can see:

General speedups with zeroing memory and memory to memory copies, since writes could be done at clock speed, read->writes at half clock speed.
Pulling disk blocks off the IDE interface.
Writing to the video controller

I've never attempted to use a "real" DMA controller, but have of course scanned datasheets for a few like the MC6844 or the Z8410, just to get a feel for what's involved in implementing one.

I'm sort of pleased with what I've implemented so far. It is a MPU HALTing with bus take over design, and can copy arbitrary 256 byte pages about the place. To avoid completely stealing the busses, the 256 bytes are copied in 4 chunks, with the MPU running in between for the same time as the transfer is done. Thus a 256 byte page can be copied in 128*4 + 128*3 = 896 cycles, still quite a bit faster then the MPU could do the same copy (which is at least 13 cycles per copied byte with the 6809 [ lda b,x; sta b,y; decb; bne ]).

Of course the limitation with the current design is that only whole pages are copied. This makes it useless for reading (or writing) out of IO ports. So I've coded up (VHDL) some improvements to make it use arbitrary addressing and optional byte incrementing, but now I have a massive problem: my CPLD is too small. Has anyone successfully implemented something as complex as a DMAC in a CPLD? Is my coding just too sloppy? (I don't think it is...) One "solution" that should reduce the number of macrocells required by quite a bit would be to "hardcode" addresses for things like the IDE port and memory addresses, reducing the controller to slurping disk blocks in and out of the IDE port, but this seems really horrible as it drastically limits the controller's usefulness.

I'm really interested to hear how others have approached the problem of DMA in their micros, or am I silly for wanting this in mine? Do I have to start looking at FPGAs, something I'm really not that keen on?

And the reason I'm asking here is because you are probably the most knowledgeable folks I've ever come across.

Suggestions, eh?!, etc, are welcome.

_________________
8 bit fun and games: https://www.aslak.net/

Make sure you've read through earlier DMA topics, like
The secret, hidden, transparent 6502 DMA channel and
Cycle-steal DMA controller design

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

To me it sounds like you've have some success with your VHDL coding, which is great! as I'm sure you know.

I can say from my experience I very quickly grew out of CPLDs, only because my primary interest originally was to have a very fast 6502 core controlling a small TFT display with graphics. Your goals are different, but the fact remains CPLDs are extremely limited when compared to FPGAs of similar pin count. I think you will find designing with FPGAs very rewarding. You might not ever look at another CPLD again...

But I think I understand why your not so keen on FPGA design because of the lower voltage levels one is forced to deal with.
All your familiar 5V IC's in your design would be useless, or you would need voltage level translators. But what a pain! One solution is to use a soft core function for a given 5V IC, written in HDL, that could fit inside the FPGA. A free resource is opencores.org. Also I've seen some very intelligent folks share HDL code on the Xilinx forums.

I wish you good luck!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Thank you. I'm still very new to it, and all self taught etc. One thing I've not looked at is simulation and test suits, something I really need to do sooner rather then later, even if it sounds very dry and boring.

It was quite something hooking up the CPLD to the lovely 30 year old MPU and seeing the registers I'd implemented, address decoders, etc "come to life".

As a brief update on the DMAC, I've managed to reach a kind of compromise: I can read a page into a page, a byte into a page, a page into a byte and a byte into a byte (256 times...). So it;s sort of useful. I've yet to implement any kind of status register, or interrupt line. And just what I've implemented so far uses about 75% of my largest 108 macrocell CPLD, without niceties like being able to read the registers back. This is obviously not ideal, as it would be great to implement a multi channel controller, with arbitrary source and destination addresses, perhaps even with things like rate limiting.



Well, ignoring the DMAC for the minute, the CPLD I am using has served my little 8 bit micro very well and takes the place of probably a dozen or more 74xx series ICs. I'm not interested in soft cores myself; my interest is in building (hardware and software) an 80s era micro, but removing the burden of masses of glue logic by using contemporary programmable logic instead. Plus I'm very interested to learn some new skills. But I'm very keen on using "classical" ICs for the key components. My desire to implement a DMAC is based on wanting to learn how they work, and to prove to myself that I can do it. I'm also, on exactly the same basis, wanting to learn how I might implement a simple MMU. Here the CPLD would prove utterly useless because of a lack of registers, I think.



Yes indeed. There's the voltage problem, and also the prototyping problem. With the XC95xx CPLDs, I was able to do much of the prototyping on breadboard, with some PLCC44 adapters. This let me test that the 30 year old NMOS parts could be driven by the relatively modern CPLD. I then went ahead and had made up a PCB using the larger 88 pin part, without ever prototyping it, and was amazed that it worked first time (this was a big thing for me ) This next to impossible to replicate with the modern FPGAs because of packaging, number of pins etc.

To "overcome" the voltage issue I've been looking at some older FPGAs. The Spartan 2, for instance, tolerates 5V inputs unlike anything newer. It would mean using an older ISE version though. And of course the protyping stage is interesting because these ICs aren't available in PLCC, only 0.5mm flatpack. This scares me rather a lot. I'm also confused as to comparing a CPLD macrocell with a FPGA logic cell? Are they roughly equivilant? For my desigms, even including MMU and DMAC and all the rest of the glue on a single device, I probably need maybe 400-500 CPLD macrocells and maybe 120 pins, leaving me quite a bit of spares in both.

I also see that Atmel still makes 5V FPGAs (AT10Ks), which is very interesting. They seem impossible to get hold of though, and I have no idea what software to use, or if I need a new programmer etc.

Another thing that is "weird" about FPGAs is that they are runtime programmed. This means, presumaby, that there is a startup delay before the device is useable. I guess I'd need to implement some kind of reset logic to trigger a program of the FPGA while the MPU is stalled?

So while I'd dearly love to use an FPGA in my computer, even by modern standards a trivial one, there remains some large problems....



While that would be a lot of fun, it's a different project to what I'm currently working on.



Thank you! And sorry for the fairly random questions....

_________________
8 bit fun and games: https://www.aslak.net/

If you choose to get into FPGAs you'll have to recognize the fact that you will have to deal with mounting these things. I don't think you can get a Spartan II devboard anymore.
Companies do make adapters, although some are abit expensive.

If you have some time you can check out a thread here that involved the project I had previously mentioned. I used these QFP to PGA adapter sockets extensively. I was also using wirewrap. I never did complete that project... I was still searching.

I'm not an engineer so I can't explain the precise difference between a macrocell and FPGA slices, logic, etc. As an experiment, you can fire up an old version of ISE that supports Spartan II, put your project in, and when you have finally max'd out your CPLD observe the FPGA utilization. I think you will be surprised at how much resources are left over on the FPGA!

I know nothing of Atmel FPGAs. I was put off by my earliest attempts at using one of their 22V10 GALs. They have?/had proprietary programming algorithms.

There are startup times on Xilinx FPGAs after being powered on, since the logic has to be programmed either from JTAG or from a PROM. But the time is very negligible, maybe ~250ms for a 4Mbit Spartan 6 FPGA PROM.
Also, there is a company out there that does make an FPGA that does not need a boot PROM, I forget right now. I posted somewhere in this section...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Yup, mounting things is going to be interesting. I actually have a Spartan 3 (can't remember the exact part) dev board, with a whole bunch of sensor boards and other goodies I could play with. I've just been too fixated on the 6809 project to have a play with it. Also, these dev boards don't teach you about the "extras" required: EEPROMs, power connections etc.

So to learn about the Spartan II I've bought a 144 pin adapter. I can hopefully cobble something together and get a counter working, or something similar. I can then figure out how to keep the CPU in reset while the FPGA is configured...

The REALLY frustrating thing is for my project a Spartan 1 or X4000 (in 5V!) would do the job very nicely. They can even still be bought. Synthesising the VHDL, and programming them though... Wow. You can download ISE "Classic" which supports the Spartan I but it has no VHDL synthesiser. Apparently back in the day you had to buy this from other companies. Yes, it is accurate to say that interfacing programmable logic with 70s/80s era MPUs is a frustrating experience, unless your designs are trivial enough to fit in a CPLD, though I heard the XC9500s are EOL now.



I thought of that after I posted to you. After making my DMA controller have 16bit source and destination addresses, a 16bit length field, and a choice of flat out or interleaved operation, it fills 163 macrocells. It's still missing some nice stuff, like register readback and an interrupt line, but it fits into a 160 pin XC95216. I couldn't fit the rest of my glue logic in it, and I'm really not keen on the next device up, which is 208 pins...

So, back to the Spartan II. It has two "issues" or rather, things I need to learn about. First it will need 2.5V in the core power lines, and 3.3V in the IO power lines. This isn't much of a problem, just more to do. The second problem is I have no idea what EEPROM to use, or how to program it? And what triggers the FPGA to read it's config from it?



Yes. Just like the old Spartans they seem a bit of a nightmare to actually use. I'm starting to think the modern Xilinx stuff has spoiled me. Which is funny because when I first used ISE I thought it was dreadful. I'll do some more reading about the AT40K parts though, since on paper at least they seem like they should do exactly what I need. But finding what tools to use, what programmer to use, etc is next to impossible for me.



Another thing for me to do then is to find what EEPROM I need for the Spartan II...



I think Microsemi were one of the first, but I think they are more widespread now.

The good news is if I can get this working I can have more programmable logic in my 8 bit micro then I know what to do with: DMA controller, a simple MMU, an IDE controller, sound generators, etc...

_________________
8 bit fun and games: https://www.aslak.net/

Ah, so you are tackling the FPGA, nice!
I believe what you are looking for is on pg.21 & pg.22 of UG161, the Platform Flash User Guide.
You will need a 6-pin JTAG connector wired up to the FPGA/FPGA PROM. Then you'll need a cable that ISE recognizes. You should be able to program either the FPGA direct, or more common is to program the PROM.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

What kind of 144-pin adapter have you purchased? I just remembered the name of the company I used to get mine from. It's a company called epboard. I just went to their sight and it seems they offer a mounting service now. Maybe there is a similar service in the UK, or maybe their shipping charges are reasonable?

Which Spartan II do you have your eye on?
I'm sure you're aware they have a smaller 100-pin version still available.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

This one:

http://m.ebay.co.uk/itm/191131960908

Unfortunately I don't think the 100 pin part will give me enough pins. My XC95108 CPLD already uses about 60 pins, and my MMU and IDE ideas will probably need about another 20. So I'm looking at the XC2S100 in TQFP144. It probably has enough logic to implement five or ten times what I need, though who knows. My MMU ideas could require a few thousand bits on its own. I figure what the hell. Digikey here in the UK stocks them. If I get three I will have one for the adapter, one for the computer board when I eventually (next Xmas......) have it ready and one spare. Just need to figure out what flash I need.

I have the USB platform jobbie and assorted leads. I use they 10way IDC for the CPLDs. I assume that part of the process is much the same, but you are programming an EEPROM?

Thanks for the links! I shall study the doc....

EDIT: digikey stock the 1Mb flash I need too, cool.

_________________
8 bit fun and games: https://www.aslak.net/

Not an EEPROM per se. It is a serial Xilinx FLASH device as I'm sure you will read. Sort of proprietary (as it is made by Xilinx) and abit expensive, but extremely reliable I've found as long as you follow their schematics. And you might not even need all the resistor they spec, at least I didn't on the Spartan 6. I could provide connection details if required.

Another option is to use a generic SPI FLASH IC, which I am currently experimenting with. As a novice though, I would advise using one of their devices for a first time project.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Just a small update on my DMA ideas.

After spending several weeks on and off, trying to figure out a path through the maze, I've eventually settled on an Altera Flex 6000. The EPF6016 is a 5V part, and the 144pin version will give me more then enough IO. Whilst the amount of logic is probably "only" 10-20 times what the XC95108 has, it should easily be enough to incorporate such things as:

DMA controller with arbitrary addressing, optional increments, and bursty or "one shot" modes
A fairly trivial, but sufficently interesting, MMU
IDE interface such that a disk block can be DMA'd to/from a 16bit IDE CF/HDD
All the other stuff from my existing design: address decoding, interrupt routing, simple tone generator

So far the DMAC design, consisting of 3 16bit counters, 1 8 bit counter, equality comparator and other stuff is using about 15% of the logic of the EPF6016. This should hopefully leave me with enough to do all the other things I want to do. Unfortunately the FLEX 6000 doesn't have dedicated RAM, so things like the MMU will be "expensive".

I have to say I much prefer the Altera software. Though I have to use a slightly older version to have Flex 6000 support, so far I like Quartus more then ISE. It's never crashed (a big plus) and the compile diagnostics make more sense too. I can't say I've looked seriously at simulation on either system.

MMU design is roughly as follows:

4KByte pages, meaning 16 pages across the 16bit virtual address bus with a 1MB physical address bus. Thus 16 slots to one of the 256 physical pages can be mapped at any time. The high 4KB page will be constantly mapped to the EEPROM, since it contains interrupt vectors. MMU switching routines will also be in this page. In theory this means 60KB of SRAM can be mapped for a "process", with all IO happening in the context of the "OS". Because the FPGA is a bit "limited" there will only be a single process worth of mapping tables loaded in the MMU at a time. On a context switch, the page table for the next process (or "OS") will have to be updated. To speed things up, this could be done with DMA with the table addresses for each process held in more registers and a single register used to trigger a page table switch to a particular process's page table. That's the rough plan anyway...

Now I think about this further, the DMAC will have to be extended to do DMA in the context of physical memory. Alternatively DMA could be limited to a 64KByte physical "window". Hmm!

I've ordered most of the parts. The FLEX 6000s are fairly hard to find, but utsource.net have them. Just need to order a programmer. To allow me to verify the tool-chain, I'll get a Cyclone dev-board with the programmer. It might be useful for future projects too.

Before getting into the MPU integration, and to learn about the part, I will make up a trivial dev board consisting of an AVR, switches, LEDs etc. This will have the TQFP144 adapter attached.

_________________
8 bit fun and games: https://www.aslak.net/

This reminds me that I'm extremely lazy and have a tendency of coming up with ideas that I don't follow through on (I started the "Cycle-Steal DMA Controller Design" thread).

I'm still interested in a DMA controller design. One that takes advantage of 65816's VDA/VPA pins to do transparent and/or cycle/steal DMA. But I just don't have the provisions to test such a design right now. Additionally, I would have to relearn Verilog (no less than the 4th time I've needed to relearn it- it just doesn't stick :/).

As for an MMU, I've also thought about it in the past. I actually like 256 byte pages, b/c it's the native "page size" of the '816 and 6502. This also means that each process can have a static Direct Page without any penalty of having to reload it each task switch ('816 specifically).

I'll be keeping my eye on this thread/as well as my old one.

Hi!

Came across this and figured I'd chime in. While I've done some bigger FPGA projects I too tend to gravitate to mature (sounds better than 'older') technology. I've primarily been working with Altera's line of CPLD's and FPGA's. In particular the EPM7128SLC-84 (note you'll want to use the 'S' version so you can use JTAG) that you can buy on ebay for about $4 and EPF10k10, which is a 570LE FPGA with 6144 bits of RAM, which can be a bit of a challenge. The PLCC version can be had for about $10 on ebay whereas the TQFP version comes in at $6 or so. The only downside I've come across with PLCC-84's is the lack of pins as you only have about ~60 pins free.

For prototyping, I bought a bunch of wire-wrap pins and created my own PLCC wire-wrap socket. Works like a charm although the pins are a little narrow.

With regards to your DMAC, why are you limiting yourself to 256 byte pages? I've done a bunch of them for graphics and what not and it's, at least for me, a nice and simple solution. If you're using a 6502 btw, you can use phi1/2 to schedule your transfers, which is *really* nice.

-Yvo

Just a quick interjection...suppose two CPLDs are used, one to act as the system glue logic and another dedicated to DMA activity. The DMA CPLD could be treated as a second processor, containing only the logic needed to make it act as a DMA controller (DMAC).

Taking a hint from the "RAM expander" design that was made for the Commodore 64 and 128 machines (and was very efficient, with a transfer rate of 1 MB/sec—not bad for mid-1980s silicon), let the DMAC's "registers" appear somewhere in the I/O block and address it like any other I/O silicon. When the DMAC is told to initiate a copy/transfer, negate the MPU's BE and RDY inputs to get it to halt and relinquish the buses—the DMAC would take over at that point. I think the overall logic would be more manageable than trying to cram it all in a single device.

The only real negatives I can think of right now are increased PCB real estate and power consumption.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

So my previous PL experience is with XIlinx XC95xx CPLDs. My micro uses a 95108 in PLCC84 to good effect; glue logic, interrupt routing, 16bit IDE latches, tone generator etc. These parts are nice: 5V, easily solderable etc. But of course limited in terms of logic.

Current plan is to give up with the Altera Flex 6000 but use them to make a dev-board for learning purposes. I discovered (after ordering) that the Flex 6000 does not support any re-programmable flashes, only OTP ones. None the less I have some in TQFP144 which I plan to use in a DIY dev board. Sadly I haven't yet mastered SMT soldering, and have ruined one while attempting to attach it to a 100mil adapter board. More practise, and some decent magnification equipment required I think!



Yeah, I did a similar thing, but (nasty I know) with breadboards.

My thinking was to get some of the EPF10K20, again in TQFP144, since there are reprogrammable flashes available for those. But my experience with soldering similar TQFP parts makes me reconsider this idea. I may be better off giving up with the TQFP Flex 6000 parts completely and going for the EPF10k10 in PLCC84 and making a dev board around that. Like you say, the problem is the number of pins required. I need to tally up my pin requirements and see what my options are, once I come to actually working on my new micro board. One option could be to use two of them, or a small CPLD for the core glue and a FPGA for the DMAC/MMU.



The DMAC design wouldn't be limited to 256 pages; that was my old prototype in the XC95108. Current DMAC design (on paper) uses arbitrary addressing on the "hardware" address side of the MMU, with source/dest/counter and increment/decrement flags.

I'm actually using a 6809. There's more about my computer on my blog. AFAICT it's not possible to interleave DMA without doing some fancy tricks, though the 6809E variant may make this possible or at least easier. Even a halting DMAC is pretty powerful, since it can do byte transfers in a single clock, which is about 8-9 times the speed of the MPU. I haven't looked very closely at these details yet, since I want to get an FPGA dev board up and running first



I have indeed thought about doing this (an early design for my current computer, which uses a XC95108/PLCC84 used two XC9572/PLCC44), and it would absolutely work. The problem, as you say, is board space and "duplication" of busses. Even the DMAC requires most signals present in the "core" of the glue logic, though it does depend where I put the peripheral components (interrupt routing, IDE latches, etc). I think for such a design I would absolutely have to go to 4 layer boards, something I know next to nothing about.



You are quite possibly correct. Also consider that in my idealised design I want: DMAC, MMU, address decoding, IDE latches, interrupt routing, tone generator, kitchen sink, ... all in one device.

I think I may need to revisit my plans, though I haven't yet given up with mastering TQFP 0.5mm soldering...

Thanks both of you for your comments!

_________________
8 bit fun and games: https://www.aslak.net/