6502.org

Table 1 in http://patpend.net/technical/65816/65c816.txt might be useful.

Edit:

Actually, there's a perverse logic to the presence of VDA and VPA. Collectively, these signals tell the circuit logic when the address bus is valid. Individually, they tell the circuit what it is the MPU is doing. One could easily implement a von Neumann or a Harvard architecture merely by correct usage of these signals. Another possibility is cycle-steal DMA by doing a DMA op when both VDA and VPA are false.
——————————————————————————————————————
EDIT: Cogitation leads me to believe that cycle steal DMA is a pipe dream. There are too few instructions with dead cycles, especially instructions that are most commonly used.

Courtesy of Mouser, I received the above Product Change Notification today. It informs us that, "The W65C816S6 (currently manufactured on a 0.6μm process at Sanyo) has been transitioned to a 0.6μm process currently being used at TSMC for the W65Cxx family."
The Product Change Notification implies there'll be no change in timing, since the '816 data sheet it cites is the same Sept 13, 2010 version we're already familiar with. Also the Sanyo and TSMC are both 0.6μm processes. Nevertheless, if anyone ever does get around to some actual timing tests like those Garth suggested, it'll be worth noting whether it was the Sanyo or TSMC product that was tested.

-- Jeff

I got that same PCN as well. Perhaps the foundry switch is merely a cost consideration and nothing more. It doesn't sound as though the process itself has changed.

WDC has to publish ECNs and PCNs because some of their products are certified for medical usage.

This is very likely the case, TSMC are probably able to bring 300mm wafers and other cost benefits. There is a good chance that the process change might bring incidental performance improvements, even though the node size isn't changing. But fab cost would be the driver.

In another thread...Garth, your reference to speed seems unclear. I hope we're in agreement that the presence or absence of contention is determined by turn-on and turn-off times -- ie; the turn-on and turn-off times of the CPU tri-state data bus drivers as compared to those of the memory & IO devices (or the bus transceiver). These times are specified in ns., not in relation to clock rate. Since clock rate doesn't affect driver turn-on and turn-off times, I submit that a change in clock rate can neither create nor eliminate contention in any given example.

To some that may sound odd, so let's look at the beginning of phase 1 as an example. If the previous cycle was a read then at the beginning of phase 1 the bus gets handed over from memory back to the CPU. Each individual memory-to-CPU handover is an event with potential for contention. The deciding factor, of course, is whether the memory IC "lets go" of the bus before the CPU commences to drive it. IOW the deciding factor is the driver turn-on and turn-off times -- which are delays measured in ns.

If we lower or raise the system clock rate, that'll change repetition rate of the bus handovers, but it doesn't change the severity of the contention each time. So, for example: if all that changes is the oscillator frequency, a system that is free of contention at 1 Mhz will also be free of it at 20 MHz. On the flip side, a system that has a contention problem at 20 Mhz will also have the problem at 1 MHz. Instead of getting 20 million nasty current spikes per second, you get 1 million -- each just as nasty as one of the 20 MHz spikes.
Right -- I mentioned this in the lead post. Another driver turn-on/turn-off figure that's missing from WDC specs is the maximum for tDHR. The omissions aren't trivial. Lacking these figures, we're unable to make a comparison with memory turn-on/turn-off times. To protect against contention we have only seat-of-the-pants reckoning.

On a positive note, how can we assess the situation, and how can we improve it? Some actual experiments would be helpful, assuming the right things are measured. It would also be informative to test '816 samples from different foundries, since the driver turn-on/turn-off times may well be affected by the new process.

I hope it's clear I'm not forecasting doom & gloom -- my comments are in support of understanding the contention issue. The problem might be pretty insignificant, as Garth says. We know that successful '816 systems exist. The question is, to what extent is success reliant on good PCB design and solid supply bypassing -- IOW, contention tolerance? AFAIK nobody's tried to run an '816 on a breadboard.
I agree that a data bus transceiver is a good idea, for two reasons.

• it's easier to make the CPU play nicely with one device (the transceiver) than with several (RAM, ROM, peripherals).
• swapping out the transceiver and replacing it with one from a different logic family is one of the most effective tactics at our disposal. The best transceiver is not necessarily the fastest or the slowest, but the one whose turn-on/turn-off times are similar to those of the '816.

Is this recommendation your own advice, or based on WDC doc? It seems at odds with two of my points above. If there's authoritative information I've overlooked I'd be grateful if you can direct me to it.

cheers
Jeff

(I was disappointed to see on a recent datasheet the bus release time for a slow EEPROM was not well-characterised: for a device with access time 450ns the release time was specced as min 0ns and max 100ns. In their defence, it's not easy to characterise release time - you need another driver and to measure contention, or measure current into a load. On the positive side, I'd say that turning off the drivers is a very simple and direct operation for the chip to perform, so release times should be pretty low in practice. Instrumenting a real '816 system could be illuminating. The bank address outputs are readily arranged to be 00, so reading FF or perhaps opcode EE would arrange for a near worst-case.)

Those are my recommendations, which are based on the fact that the bus transceiver's prop time will result in the state of the data bus being skewed relative to the states of Ø2 and RWB. As Ø2 approaches the maximum, said skew will likely become critical in trying to make a clean transition from capturing the bank address, during which time the transceiver is (should be) in the high-Z state, to data read/write.

Consider that the worst-case prop time for the 74ABT245 is 4.6ns input to output, which number assumes that the 74ABT245 is already in the active state. However, during Ø2 low, the transceiver must be in the high-Z state to avoid contention as the '816 emits the bank address. When Ø2 goes high, the 74ABT245 must switch from high-Z to active, and since that high-Z to active transition time is 6.3ns worst-case, which is nearly 25 percent of the available Ø2 high time at 20 MHz, it becomes clear that the transceiver needs to be as fast as possible if the device at the other end of the wire is going to see data in a timely fashion.

At 7.2ns, the active to high-Z worst-case time of the 74ABT245 is slightly longer than the high-Z to active time, but still quick enough to assure that the data bus is unencumbered before the next bank address is emitted by the '816.

Note that the transceiver's data direction input also has to be configured prior to data becoming valid. However, as RWB becomes valid about the same time that the address bus becomes valid, there is ample setup time for data direction.

In my insanity- err, eagerness, I offered to be a guinea pig for testing a 14 MHz DIP '816 in a small design... if I can find a discrete part that is similar to the 8088's clock generator (which required a 33% duty cycle clock), I could test it and see what happens. But let me get the circuit built first .
I thought the circuit shown in the datasheet that demuxes the data and address buses served as a transceiver/buffer already (ignoring propagation delay)?

Also, I apologize in advance for the stupid question, but... this bus cycle diagram doesn't apply immediately after reset, correct? Otherwise during the first cycle PHI2 is low after reset, the '816 could in theory be reading garbage value from the data bus, since it didn't output an address during the previous cycle when PHI2 was high (while reset was still occurring).

It does, but that's only for the bank byte, not the data or A0...A15.


I have not experimented with releasing the RST\ line in different parts of the clock cycle to know if it puts a bank byte out in the first half of the first cycle after RST\ is released, but it wouldn't matter anyway, because the first couple of clock cycles are internal operations anyway, before the first bus transfers.

This "zero dead time" is in theory, correct (i.e. if the outputs/inputs from each clock cycle instantaneously appeared on the bus)?

In the DMA controller thread I started, Garth and I are going back and forth about timing, and basically:

I'm having trouble understanding how everything on the 65816 bus can happen in such a short time (particularly in less than one half-period, where there is no clock reference) and in the correct order, and reliably (i.e. hold time for data bus is sufficient, bus switches direction at the correct times). Right now, my questions CPU-side only, but they are relevant to this thread in examining timing.

In retrospect, I kind of threw my thread about DMA off track with my questions (I wish I could merge it with this thread), but for those interested in more timing discussion, page 2 and 3 are pertinent.

Daryl, what was the power supply current, and how did the data bus lines and the processor's power supply pins look on a fast 'scope? (You too BDD with the POC.)

I should have documented that, because now I cannot remember the current. I want to say around 350-400mA for the whole board. I don't have a fast enough scope to make useful measurements, so none were ever made.

Daryl