An address bus glitch during TADS will not affect chip selects if they are fully qualified by VDA and VPA. There seems to be some sort of illogical resistance around here to that, despite WDC themselves advising to do so in the data sheet
That's interesting, does it mean the 65C816 will unassert them at the start of every cycle, when phi2 goes low, then only reassert them later in the cycle when the address and bank are valid?
I still worry that the OP is running into a race between the ending of the previous cycle and starting the new one, due to phi1 feeding straight into the latch while other signals go through the PLDs. It wouldn't even matter the clock speed and would explain why using a slower latch would seem to work around the problem. I would probably want to just delay that clock signal a bit though. It would ensure that VPA/VDA would have time to drop and have that change propagate through the PLDs as well before the latch is activated.
In my VGA circuits I often have two completely different addresses going onto a bus at different halves of a clock cycle, and even if the RAM is specified to not require a specific address hold time, it has often still been necessary to shorten the WE pulses so that there is a slight delay before the address bus gets switched over.
That's interesting, does it mean the 65C816 will unassert them at the start of every cycle, when phi2 goes low, then only reassert them later in the cycle when the address and bank are valid?
I don't think so. From experimentation they hold their value from the previous cycle for about 10ns into the new cycle (after PHI2 goes low). This seems to apply to all the '816s outputs (RWB etc...) except for the Bank Address appearing on the Data pins which takes about 2ns longer.
i.e. (at 5V) the '816 is pretty much done 12ns after PHI2 goes low. I say pretty much done because some opcodes might take longer but I made a couple of mistakes in my test circuit and couldn't fully finish testing. I feel I should have been able to get an '816 running stably at 40MHz (12.5ns half cycle) but never managed it with a complex program.
I don't think so. From experimentation they hold their value from the previous cycle for about 10ns into the new cycle (after PHI2 goes low). This seems to apply to all the '816s outputs (RWB etc...) except for the Bank Address appearing on the Data pins which takes about 2ns longer.
I see - so in the OP's circuit from the time the clocks change at the end of a write cycle, the AC latch could respond as quickly as 2ns later, passing the old data bus value through to the bank bits, while the PLD could take 7ns to propagatethe clock change and turn off the RAM WE/CE pins - and VPA/VDA would maybe take even longer to update as they depend on the 816's response time to the phi2 signal as well as the PLD.
Maybe qualifying by VPA and VDA should also be done, but I would definitely want to delay updating that latch a while longer, eg by taking an inverted phi2 from the PLD instead of using phi1 from the clock circuit.
I'm interested because I've also been thinking of making something with the 65C816, I read up on it after one of BDD's previous posts, and it'd be good to try to get as much as possible right to begin with!
An address bus glitch during TADS will not affect chip selects if they are fully qualified by VDA and VPA. There seems to be some sort of illogical resistance around here to that, despite WDC themselves advising to do so in the data sheet
That's interesting, does it mean the 65C816 will unassert them at the start of every cycle, when phi2 goes low, then only reassert them later in the cycle when the address and bank are valid?
AndrewP wrote:
I don't think so.
Unless BE is driven low, the 65C816 continuously drives all outputs. BE affects the data bus, address bus and RWB, and when low, puts the buses and RWB into the high-Z state.
There are two periods in which timing hinkiness can definitely get you during a write operation: TBAS and TMDS. If your latch opens before TBAS expires, there is a narrow window during which your decoding logic and, in particular, the SRAM, might see an effective address change. Depending on how quickly the RAM reacts to the rise of /WD, a wild write might occur.
I used to think that having the Ø1 clock transition at the exact time Ø2 transitions, as would be the case if both clocks are coming from the Qs of the same flop, would minimize 816 timing hazards. I now believe Ø1, as seen by the latch, should go high a few nanoseconds after Ø2 goes low. That, coupled with the latch’s response time to LE, would, so my logic goes, keep A16-A23 stable during TBAS.
Quote:
I still worry that the OP is running into a race between the ending of the previous cycle and starting the new one, due to phi1 feeding straight into the latch while other signals go through the PLDs. It wouldn't even matter the clock speed and would explain why using a slower latch would seem to work around the problem. I would probably want to just delay that clock signal a bit though. It would ensure that VPA/VDA would have time to drop and have that change propagate through the PLDs as well before the latch is activated.
You could probably prove your theory by reinstalling the AC573 and inserting a non-inverting 74AC gate in between Ø1 and the latch’s LE input to add some delay. If you have a dual-channel scope, you could observe LE and the latch’s A16 output, with the scope’s sweep triggered when Ø2 goes low. As it is the fall of Ø2 at the MPU that commences the next cycle, if A16 changes before about 12ns after the fall of Ø2, you likely have a race condition. If you see that, try observing RWB and A16 to see which changes first.
Quote:
In my VGA circuits I often have two completely different addresses going onto a bus at different halves of a clock cycle, and even if the RAM is specified to not require a specific address hold time, it has often still been necessary to shorten the WE pulses so that there is a slight delay before the address bus gets switched over.
You need the absolute minimum prop delay between Ø2 and /WD. /WD needs to go high ASAP after Ø2 goes low. The 7.5ns TPD1 of the CPLD may actually be too long to drive /WD high before the expiration of TBAS. I use the below circuit, which places one gate delay between Ø2 and /WD:
/WD lags Ø2 by the TPLH of the AC00, which will not exceed 6.6ns at 5 volts, according to the TI data sheet (the AC00 that controls /WD in my POC V1.3 unit consistently reacts to Ø2 in less than 4ns, according to the logic analyzer). A CPLD might achieve that 6.6ns, but that is not guaranteed.
One other caution concerning PLDs of any kind. Their outputs are TTL, not CMOS. While some testing I’ve done has indicated that an unloaded PLD output will reach four volts in a five volt system, I’ve also observed that VOH deteriorates to the 3.5 volt range with loading, which is at the minimum voltage considered to be a CMOS logic one. While the inputs of CMOS devices present almost no load when quiescent, a change of state will momentarily load the PLD, especially due to the charging of parasitic capacitance. Hence the PLD’s output may quickly rise to the 2.4 volt level specified in the data sheet, but may be slower in continuing up into CMOS logic one territory. Something to keep in mind as you chase timing devils.
That makes sense and it's interesting about the voltage levels. Another approach I've used in this sort of case is to delay the phi2 input to the MPU - in my last case by adding a redundant OR gate i believe. For example you could have the PLD outputting all the control signals as well as phi1, and place an ACT inverter between that and the MPU's phi2 input. This way the control signals are ended before the MPU is invited to begin the next cycle. The other edge of phi2 is less important for the 6502 but if guess for the 65C816 you'd need to not delay the rising edge (as much) or feed the delayed phi2 back into the PLD to control things things there.
An address bus glitch during TADS will not affect chip selects if they are fully qualified by VDA and VPA. There seems to be some sort of illogical resistance around here to that, despite WDC themselves advising to do so in the data sheet
That's interesting, does it mean the 65C816 will unassert them at the start of every cycle, when phi2 goes low, then only reassert them later in the cycle when the address and bank are valid?
I still worry that the OP is running into a race between the ending of the previous cycle and starting the new one, due to phi1 feeding straight into the latch while other signals go through the PLDs. It wouldn't even matter the clock speed and would explain why using a slower latch would seem to work around the problem. I would probably want to just delay that clock signal a bit though. It would ensure that VPA/VDA would have time to drop and have that change propagate through the PLDs as well before the latch is activated.
Delaying the clock was actually my next plan if the latch swap hadn't fixed it. It would've required some serious bodge wire hackery though, or a respin of the board. At the time I was just assuming it was the latch being too fast in general; I hadn't thought of the fact that the CPLD is gonna add ~7ns between phi2 and the chip selects. That's a really good catch.
At that point I'd rather just start designing the next iteration (jrc-2) and make that board instead, using lessons from this board. The next iteration is going to use a larger CPLD (84-pin, probably an old Lattice part because I have a bunch of 5V ones here). At that point I'm probably going to try moving the latch inside the CPLD. I had this mostly working on a very old breadboard iteration of the design.
I do want to try updating the equations to add VDA and VPA, as was suggested. But my JTAG adapter (Atmel ATDH1150USB) was not seeing the chips on the board; in fact it wasn't seeing a brand new one on an ATF1504 dev board either. I need to spend some time diagnosing that issue.
For now I'm just happy it's apparently working, which means I can get back to writing firmware.
