Cycle-steal DMA controller design

[cr1901]

Well then, the whole damn thing might need a level shifter then ... either that, or I have no choice but to use a 5V CPLD or FPGA...

So, what does the 6502.org community- and WDC- do when 5V tolerant parts cease to be made?

[cr1901]

One other thing- I got "A LOT" accomplished tonight with respect to this project. I expect it to take a while overall, however. As always, any breaks on my part do not mean I've given up... not at all. It just means I need to clear my head and switch focus for a bit.

[BigDumbDinosaur]

GARTHWILSON wrote:

Even if transparent DMA is not the hottest-performing, one attraction I see is that it does not upset the timing of other operations you may have going on in a realtime system with hard deadlines.

I have the opinion that DMA would not be appropriate in a system meant to be used for real-time processing. The raison d'être for instructions like STP and WAI is to make the 65C816 perform with alacrity in such an environment. Since DMA is not possible unless the DMAC can be bus master, real-time by inference is also not possible if a DMAC can take control of the bus at unpredictable times, and then generate an interrupt at an unpredictable time.

The implementation of transparent DMA (what the '816 data sheet calls "cycle steal") is efficient only if the DMA is allowed to be bus master for more than one consecutive clock cycle, unless both a read and write can occur in a single cycle. That's just not going to happen with the '816.

[BigDumbDinosaur]

cr1901 wrote:

Quote:

Anything that can respond in 15ns or less will work.

According to the data sheet, at 14Mhz, VDA/VPA is valid after a maximum of 30ns after the falling edge of PHI2 (tADS)... the clock will rise 35ns after the falling edge... that's 5ns prepare the address on the bus to be read! Not enough time... unless, I'm not reading the datasheet correctly, which is always probable.

I'm going to go so far out on a limb that it will appear that I'm flying and say that that 30ns number is bogus. If it were true, operation of the '816 at any speed above 14 MHz would not be possible. Yet, it is possible.

[GARTHWILSON]

Quote:

So, what does the 6502.org community- and WDC- do when 5V tolerant parts cease to be made?

WDC's parts are guaranteed to work at least down to 1.8V, and one of the '816 datasheet graphs implies it will work down to 1V. It just slows them down. Since 7400 and 74LS are still available, I think 74AC and others will be available for a long time, and when those are fading too (like 5V programmable logic is now), I expect WDC will be using a geometry by then that will max out at 3.3V and 33MHz or higher.

[BigDumbDinosaur]

cr1901 wrote:

Well then, the whole damn thing might need a level shifter then ... either that, or I have no choice but to use a 5V CPLD or FPGA...

So, what does the 6502.org community- and WDC- do when 5V tolerant parts cease to be made?

I have no reason to think that 5 volt parts are going to disappear anytime soon. There is far too much hardware still in use with 5 volt silicon, and in many cases, it's not economical to replace such hardware simply because 3.3 volt parts are available and use less juice.

As for CPLDs, Atmel continues to make them in 5 volts and according to what I learned a while ago, will continue to do so for the foreseeable future. POC V2 will use an Atmel 1504AS and POC V3 will use a 1508AS. Both can be programmed via JTAG or with Atmel's programming rig (I have the latter).

atmel_atf1504as.pdf

Atmel ATF1504as CPLD

(680.96 KiB) Downloaded 111 times

atmel_atf1508as.pdf

Atmel ATF1508as CPLD

(690.1 KiB) Downloaded 107 times

[cr1901]

Well, that makes me feel better... 5V it is then.

Well, you may be the first person to test this on physical hardware then ... well, custom hardware anyway. I have no provisions for programming a CPLD outside my dev board... which I just realized is only a 3.3V part... yay!

So... I'm thinking I'll ask someone at WDC where I can buy a soft core so I can at least TEST the controller on real hardware. I was going to build a verilog test bench top-level module using iverilog before using a top-level module for an Altera board to test.

[BigDumbDinosaur]

cr1901 wrote:

Well, that makes me feel better... 5V it is then.

Both Mouser and Digi-Key stock Atmel CPLDs. You may have to purchase their programming rig, since you plan to allocate all pins to a circuit function. You can't program through the JTAG port if the relevant pins are assigned to your logic implementation.

Quote:

Well, you may be the first person to test this on physical hardware then ... well, custom hardware anyway. I have no provisions for programming a CPLD outside my dev board... which I just realized is only a 3.3V part... yay!

Of course, POC V2 is still a paper computer, so don't get too excited yet.

Quote:

So... I'm thinking I'll ask someone at WDC where I can buy a soft core so I can at least TEST the controller on real hardware. I was going to build a verilog test bench top-level module using iverilog before using a top-level module for an Altera board to test.

You'd probably want to talk to David Cramer at WDC on that. I suspect the soft core is not cheap.

[cr1901]

To be perfectly honest- I have no experience programming over JTAG period... the only time I've done it successfully was to create my AT2XT keyboard converter to program the MSP430 in-circuit... which is a serial JTAG called Spy-Bi-Wire. Could someone point me to a resource on how to make a JTAG programming circuit, and what other external tools I will need?

[clockpulse]

cr1901 wrote:

Could someone point me to a resource on how to make a JTAG programming circuit, and what other external tools I will need?

I built this one for Atmel CPLD's and it works fine.
http://www.pyroelectro.com/tutorials/by ... matic.html

I have tested it with the Atmel ATF1504AS and ATF1508AS CPLD's.
Use Atmel software ISP (free), tested with version 6.7

On mine, I removed the 5 - 2.2k pullup resistors for it to operate correctly with my parallel port. (try it first with them)
If you disconnect the 100 ohm resistor that goes to pin 14 of the parallel port and ground it, it will then be recognized as an Atmel ISPMV cable.

[BigDumbDinosaur]

clockpulse wrote:

Use Atmel software ISP (free), tested with version 6.7

You can write the code with Atmel's WinCUPL software. There's a bit of hoop-jumping involved in getting WinCUPL. Contact me via PM if you need help.

[clockpulse]

BigDumbDinosaur wrote:

clockpulse wrote:

Use Atmel software ISP (free), tested with version 6.7

You can write the code with Atmel's WinCUPL software. There's a bit of hoop-jumping involved in getting WinCUPL. Contact me via PM if you need help.

That's true. I should have mentioned that.

I do use WinCUPL 5.30.4 for writing the code (despite it's bugs)

I use ISP 6.7 to program the chips. Which doesn't 'seem' to have any deadly bugs....

[cr1901]

clockpulse wrote:

cr1901 wrote:

Could someone point me to a resource on how to make a JTAG programming circuit, and what other external tools I will need?

I built this one for Atmel CPLD's and it works fine.
http://www.pyroelectro.com/tutorials/by ... matic.html

I have tested it with the Atmel ATF1504AS and ATF1508AS CPLD's.
Use Atmel software ISP (free), tested with version 6.7

On mine, I removed the 5 - 2.2k pullup resistors for it to operate correctly with my parallel port. (try it first with them)
If you disconnect the 100 ohm resistor that goes to pin 14 of the parallel port and ground it, it will then be recognized as an Atmel ISPMV cable.

Tiny problem- I don't have a parallel port on my laptop (don't have a working desktop right now), and I already know that software such as programmers won't work with a USB version.

[BigEd]

I think - but this needs a little research and experimentation - that you can use whatever free tools to put your design into a JTAG sequence encoded in an SVF file, and then play that SVF file using
- an Arduino (actually just a repurposing of the serial chip)
- a Raspberry Pi
- a Bus Pirate
Some links:
http://openschemes.com/2011/10/28/ft232 ... sion-0-11/
http://electronics.stackexchange.com/qu ... programmer
http://dangerousprototypes.com/docs/Bus ... SVF_player

[cr1901]

For those who want me to get to the point, the important part of the post is in italics... this is my first of likely a few 'walls' I've hit while trying to reacquaint myself with the lovely world of hardware design and comp arch... something which was once dear to me, but since then I've gotten lazy and arrogant. I need to keep reiterating- It's been a WHILE since I've done hardware design... but I'll get back into the groove of things... but I do need a bit of a refresher lol.


I've sketched out a potential dummy circuit and timing diagram (will upload later), and I still have no answer whether it's possible to do a memory-to-memory xfer in one clock cycle... just based on a preliminary sketch. Here is a verbal description of the timing:

In my sketch, as soon as VDA and VPA are low, BE is asserted, a small settling time is added* (this part I have trouble with), and then a source address is placed on the bus... source responds with data. The data is latched during the rising edge of PHI2, and the dest address is placed on the bus and data is latched into the destination on the falling edge of PHI2 (the next cycle). Immediately after the falling edge of PHI2, the DMA controller relinquishes control of the bus, gets the hell out of there, de-asserts BE, and waits till VPA and VDA are both low again.


BigEd- in another thread, Garth mentioned you do work on the Visual 6502 project... do you know how the 6502/816 is capable of delaying the assertion of bus signals. For example- in the '816, the Bank Address becomes valid just before the rising edge of PHI2. How does the '816 make sure that it loads Bank Address so far into the negative half of PHI2?

*Problem: I honestly do not remember how to add a small delay in a sequential circuit... it's been so long since I've designed hardware that I'm so used to transitions in data lines only occurring on clock edges. Going back to the delay after "BE" problem... in an ideal world, both BE assertion and the source address could occur instantaneously- i.e. the same logic circuit controls both signals- because the time required for the CPU to tristate is ideally 0 nanoseconds... but this isn't an ideal world, and so the delay is necessary.

Something else bothers me on the '816 timing that I didn't notice before:


Although data to be read in is set up before the falling edge of PHI2, the description of tDHR- Read Data Hold Time- seems to imply that the read data from memory is not latched until a set hold time AFTER the PHI2 falling edge has elapsed. From what I remember about hold time: When the input data finally reaches a register's input, the register requires it's input bus to stay at the same value for a set period of time. This is so that the value can be preserved internally and propagate through to the output (possibly requiring a clock transition before the output appears), before - this is the hold time.

I therefore take the '816 timing diagram to mean that the register which receives the read data value inside the '816 might not even see the read data on it's input until after the falling edge of PHI2 has elapsed. Do I understand this correctly? My prior experience would have told me to expect that the data itself would've been latched during the falling edge itself, and the hold time would've been satisfied prior to the edge- the clock edge would just make sure the new value overwrote the old one. Since read data isn't latched on a clock edge, this must mean that internally, '816 registers are latches which don't require a clock signal to store a new value.

I apologize for the verbose explanation- but I want to actually understand this, since at one time I felt I really DID understand it all.