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.
Login
Register
FAQ
Search
... either that, or I have no choice but to use a 5V CPLD or FPGA...
... 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!
