When should Φ2 be used over Φ0? (Or: Φ0 vs. Φ2 vs. RWB)

[cjs]

BigEd wrote:

In some systems one might have another clock which rises earlier and gives more time to a memory access. It would of course be necessary to derive that clock in a safe way, such as by using a much higher speed master clock to determine the edges.

I am guessing that someone would do that to, e.g., get more time for a slow memory without having to slow the system clock rate. Fair enough, but not really relevant to the discussion here as far as I can tell, since I'm concerned with systems that don't play such tricks but just do "the usual" and use Φ0/Φ2 for determining when signals from the CPU are safe to use.

Quote:

In the more modern faster parts, it all gets more compressed, and the documentation is lacking. I think I've seen it said that the modern datasheet doesn't really give room for 14MHz operation of a system - but we're saved by the practical observation that we don't seem to see worst-case behaviour.

Well, I'm not sure what you mean by "compressed," but if it doesn't involve changing the timing relationships it shouldn't make a difference, should it?

A W65C02 not being able to run at 14 MHz sounds very odd to me given that they have a 14 Mhz column on the data sheet, and their "F Max vs Vdd" chart goes up to 20 Mhz, with a little cross marked at about 19.5 MHz and 4.2 V.

Looking at the 14 MHz specs (in ns), clock pulse width high and low tPWH = tPWL = 35 min:

Data setup tMDS = 25 max, meaning that it's available at least 10 ns before Φ2↓, and tDHW = 10 min appears to give that another 10 ns after Φ2↓, so that looks no different from the 6810 case in my previous post and data is fine at 14 MHz. (I see now that all these "hold" times are actually holds from the clock edge, which makes things make a lot more sense and really does lock them to that clock edge.)

For the address, address setup time tADS = 30 max, giving at least 5 ns between the address being settled and Φ2↑. The address hold time tAH = 10 min so again, at least 10 ns after Φ2↑.

I guess I need to thank you for forcing me into the data sheets to this depth; it's really been very educational. :-)

Quote:

But to the original discussion, I'm all for a thorough analysis of phi0 vs phi2 and the pitfalls to be avoided.

Ok, so using my newfound skills on the original MOS data sheet...I'm still stuck. I just can't see anything that gives any sort of relationship between Φ0 and Φ2, and all the timings are referenced to Φ2 OUT for the 650x series. (The 651x all reference to Φ2 IN because there is no Φ2 out.)

But I decided to have a look at a 1979 Synertek SY6500 datasheet I happen to have kicking around on paper, and it turns out that it does give this. (Yay!) Fortunately it's already been scanned and is up on 6502.org. The timing diagram is a full page, so rather than paste it here perhaps it's easier just for you guys to go look at page 4 of that scan.

It gives "Φ₀ Neg to Φ₂ Neg Delay" TO2- = 65 ns max (at 1 MHz), and "Φ₀ Pos to Φ₂ Pos Delay" TO2+ = 75 ns. So finally we seem to have some numbers that might tell us how tolerances change between the two. But I wonder if these take into account the much slower rise time of Φ2 compared to a good Φ0 signal.

Anyway, let's just go with Φ0 edges up to 65/75 ns earlier than Φ2 edges. The minimum length of Φ2low (ref "A" to ref "B") isn't directly given, but it looks like we can get it by adding TD = 5 min + TPWHΦ1 + TO1- = 5 min + TD = 5 min. We get TPWHΦ1 from TLΦ0O - 20 = 480 - 20 = 460, so a Φ2 high pulse is minimum 475 ns. Phew! Is that even right? Maybe I'll stop here while someone checks that and I gird myself for the next steps. And go off and read Jeff's stuff again, since it's been a while.

Quote:

...hold time constraints are very important and often overlooked.

Right. I think we have those covered in the hold times from the clock edge I discovered above, right?

[GARTHWILSON]

cjs wrote:

A W65C02 not being able to run at 14 MHz sounds very odd to me given that they have a 14 Mhz column on the data sheet, and their "F Max vs Vdd" chart goes up to 20 Mhz, with a little cross marked at about 19.5 MHz and 4.2 V.

When I was working on a design for work in the 1990's, I pointed out the timing discrepancy in WDC's '816 data sheet to Bill Mensch, and all he could say was basically "Try it. We know it works," because the SuperCPU was being sold running at 20MHz with the 14MHz '816, and they apparently had no problems with yield and few or no problems in the field. Forum member "plasmo" got a W65C02 running at 33MHz last month, almost 2½ times the spec, and before that, forum member "Windfall" got an '816 going at 24MHz at 3.3V, three times the 8MHz it's guaranteed to do at that voltage. So fortunately, the reality is that the timing margins are much better than the data sheet lets on.

[cjs]

I certainly believe that, like many, many other parts out there, the W65C02 will run faster than the specs say it will. My question is about the data sheet strongly implying that it should run at 14 Mhz but the specs on that data sheet actually saying that it won't run at 14 MHz. I.e, the 14 MHz column is nonsense because that contains only the information that it cannot run at that speed. (If I'm interpreting you guys right.)

What is the timing issue that, according to the spec sheet, prevents it from running at 14 MHz?

[kernelthread]

From what I can see, the W65C02S datasheet worst case timings are just about OK for 14MHz operation. At 14MHz with a 50% duty cycle, each clock phase lasts 35.7ns. For read cycles, the address becomes valid at most 30ns after the falling clock edge and the data must be valid 10ns before the next falling clock edge, so you have 31.4ns to retrieve the data from memory. If you have the RAM CS lines asserted all the time and use OE to select the RAM, this should be achievable. Write cycle timings are a bit tighter - the write data becomes valid up to 25ns after the rising clock edge, and a quick look at a fast RAM datasheet (IS61C1024) says that the RAM wants the write data valid 8ns before the rising edge of WE. So it's close, but possible.

What isn't possible according to the datasheets is to use a W65C02S CPU running at 14MHz with a W65C22S VIA also clocked at 14MHz. As already said, the CPU address bus becomes valid up to 30ns after the falling clock edge, which is 5.7ns before the rising edge. But the VIA wants its CS and RS lines stable 10ns before the rising edge of the clock.

[drogon]

kernelthread wrote:

From what I can see, the W65C02S datasheet worst case timings are just about OK for 14MHz operation. At 14MHz with a 50% duty cycle, each clock phase lasts 35.7ns. For read cycles, the address becomes valid at most 30ns after the falling clock edge and the data must be valid 10ns before the next falling clock edge, so you have 31.4ns to retrieve the data from memory. If you have the RAM CS lines asserted all the time and use OE to select the RAM, this should be achievable. Write cycle timings are a bit tighter - the write data becomes valid up to 25ns after the rising clock edge, and a quick look at a fast RAM datasheet (IS61C1024) says that the RAM wants the write data valid 8ns before the rising edge of WE. So it's close, but possible.

What isn't possible according to the datasheets is to use a W65C02S CPU running at 14MHz with a W65C22S VIA also clocked at 14MHz. As already said, the CPU address bus becomes valid up to 30ns after the falling clock edge, which is 5.7ns before the rising edge. But the VIA wants its CS and RS lines stable 10ns before the rising edge of the clock.

And yet:

Has been running on my desk for over a year now at 16Mhz... (Ok, That's an '816 but the 65C02 on the board before it was also at 16Mhz). Sometimes you just have to suck it and see...

-Gordon

[GARTHWILSON]

I think what I emailed Bill Mensch about (as mentioned above) was the bank byte on the '816 not being guaranteed to be valid in time for the 573's setup time before phase 2 rises at 14MHz, let alone to get the signal through the address decoding in time for the various things hanging on the bus. In spite of the lack of guarantee though, they do work, and WDC said recently that they test the 14MHz parts at 20MHz.

As for data being valid earlier, it should not matter, as long as it's valid in time for the memory or other device's setup time before phase 2 falls (which may mean a WR\ in the case of memory). On the '816, it cannot be valid before phase 2 rises, regardless of speed, since that's when the '816 is putting out the bank byte on the data bus. (I sure wish they had just gone with a 48-pin DIP originally and given it 8 more address lines, non-multiplexed!)

[BigDumbDinosaur]

cjs wrote:

I certainly believe that, like many, many other parts out there, the W65C02 will run faster than the specs say it will.

If you examine the FMAX vs VDD curve in the data sheet, you will see the 65C02 can run well beyond the 14 MHz rating, even without running VDD at the maximum ratings level (which is a bad idea if device life matters). From a hobbyist's perspective, that published curve can be taken at face value. On the other hand, if the C02 is to be used in a commercial product in which stability over the full temperature range is paramount, then the 14 MHz at 5 volts specification should be considered the safe limit.

Quote:

My question is about the data sheet strongly implying that it should run at 14 Mhz but the specs on that data sheet actually saying that it won't run at 14 MHz. I.e, the 14 MHz column is nonsense because that contains only the information that it cannot run at that speed. (If I'm interpreting you guys right.)

WDC data sheets have a long history of publishing ambiguous or outright incorrect information. While the 14 MHz column timing values don't make a whole lot of sense when considered against the clock cycle time (~35ns per phase), WDC does guarantee that the device will run at that speed. It is likely the stated timing values are wrong for current devices and reflect the performance of the older 1.0µ geometry that WDC used years ago.

The timing values for the 65C816 seem even more suspect. POC V1.2 ran at 20 MHz, and that was with 100 percent discrete logic. POC V1.3 is running at 16 MHz, also with discrete logic. The clock speed limit is due to a sub-optimal aspect of the glue logic. According to the data sheet, neither POC unit should work at those speeds. However, observing the behavior of the 816 with the logic analyzer says the data sheet timing specs are wrong, and not by an insignificant amount.

[BigDumbDinosaur]

GARTHWILSON wrote:

...WDC said recently that they test the 14MHz parts at 20MHz.

Yep! That was said in an E-mail message that I received from David Gray at WDC:

• ...our TSMC .6u parts are actually tested to 20MHz on our testers...

Quote:

On the '816, it cannot be valid before phase 2 rises, regardless of speed, since that's when the '816 is putting out the bank byte on the data bus. (I sure wish they had just gone with a 48-pin DIP originally and given it 8 more address lines, non-multiplexed!)

A PLCC52 package would be even better, since there would be more VCC and ground pins. Plus the PLCC footprint is generally more space-efficient than a DIP.

Dealing with the MUXed bank bits in discrete logic is a little tricky...timing can be tight, and there's the ever-present risk of data bus contention if things aren't right. Circuit design would be so much easier if those were on separate pins.

[GARTHWILSON]

BigDumbDinosaur wrote:

A PLCC52 package would be even better, since there would be more VCC and ground pins. Plus the PLCC footprint is generally more space-efficient than a DIP.

Further, the PLCC connections are shorter, resulting in less inductance between the board and the die. I do have some 816's here in PLCC and PQFP but I have not put those to work yet.

[BigDumbDinosaur]

GARTHWILSON wrote:

BigDumbDinosaur wrote:

A PLCC52 package would be even better, since there would be more VCC and ground pins. Plus the PLCC footprint is generally more space-efficient than a DIP.

Further, the PLCC connections are shorter, resulting in less inductance between the board and the die. I do have some 816's here in PLCC and PQFP but I have not put those to work yet.

When I started with the POC project I did layouts with both PDIP and PLCC. The PLCC layout took up what I estimated to be about 20 percent less PCB real estate. Plus the routing was easier.

[cjs]

The discussion here is veering well off-topic, since what one can or can't do with a particular manufacturer's modern part is not at all relevant to whether in general it's safe always to use Φ0 over Φ2 (even on older parts). And in particular, I do not welcome "well, this worked for me" examples because I am already aware of plenty of those, and they're clearly not helpful to answering the question. Helpful examples would be the exact opposite: examples of where it didn't work in an otherwise reasonable design.

So perhaps you guys can move your discussion of the off-topic stuff to another thread? A good (though not perfect) heuristic to ask yourself when posting to this thread is, "Does this apply to NMOS parts from various manufacturers built between 1975 and 1980?"

That said, examples of where timing is weird or hard to interpret on WDC's (or anybody's) data sheets are welcome, since those give insight into what we should be looking at to try to answer the original question. For example, when WDC says they no longer test the timing constraints between clock inputs and outputs, it would be useful to know what those timing constraints were that they used to test.

[GARTHWILSON]

cjs wrote:

The discussion here is veering well off-topic, [...] So perhaps you guys can move your discussion of the off-topic stuff to another thread? A good (though not perfect) heuristic to ask yourself when posting to this thread is, "Does this apply to NMOS parts from various manufacturers built between 1975 and 1980?"

It's ok to request; but I think the OT part got started from your first two posts on this page which referenced 14MHz CMOS parts which did not exist yet in the 1975-1980 period. We all tend to make comments on things that might qualify as rabbit trails but perhaps are not worthy of a separate topic, but sometimes it can get out of hand. Sometimes the OP enjoys it, and sometimes not, and we should be sensitive.

[cjs]

GARTHWILSON wrote:

...I think the OT part got started from your first two posts on this page which referenced 14MHz CMOS parts which did not exist yet in the 1975-1980 period.

Ah, I probably wasn't quite clear enough above that such 14 MHz parts are still on topic as far as the Φ0 vs. Φ2 relationships go; if one cannot substitute Φ0 for Φ2 in either a 14 MHz WDC W65C02S or in a 1975 MOS 6502 (or in anything else) we've found a case of interest. If there's anything in the timing relationships of any of these parts that might help illuminate the main question, I'd love to hear about it. (I don't expect the WDC parts to be particularly important since they explicitly say, "Don't ever use Φ2 out," but there are a lot of data hiding in those datasheets that I don't completely understand.)

It's the extened repitition of examples of "I got X to work for this particular part" stuff I'm trying to avoid since not only are such examples very well known and completely expected, but they provide no illumination as to whether or not there are cases where one cannot substitute Φ0 for Φ2.

In other words, when asking "where does this break?", answers of "well, it works over here" aren't very helpful. (In most cases, anyway.)

[gfoot]

cjs wrote:

It's the extened repitition of examples of "I got X to work for this particular part" stuff I'm trying to avoid since not only are such examples very well known and completely expected, but they provide no illumination as to whether or not there are cases where one cannot substitute Φ0 for Φ2.

Early NMOS datasheets tended to specify timings relative to phi2 not phi0, and although I don't recall seeing an explicit delay listed, it's impossible for there to not be one, and if you want to go strictly by the datasheets, in theory it's unbounded.

The main practical impact that I can see this delay could have is that the data hold times are specified relative to phi2 not phi0, so for example during a write operation in the Rockwell datasheet there's a minimum 30ns hold after phi2 falls before it releases the data bus. If you were driving the data bus externally during phase 1, and timing this based on phi0 rather than phi2, then you'd need to account for not only the 30ns hold time but also the delay between phi0 and phi2.

It is all really academic though because in practice I highly doubt that the old datasheet authors characterized these things that accurately, as evidenced by Garth's comments. If they did bother to specify a limit on the delay, it would probably be so small that it wouldn't matter even in theory. Personally I think old (and some new) datasheets need to be taken with a very large pinch of salt!

[cjs]

gfoot wrote:

Early NMOS datasheets tended to specify timings relative to phi2 not phi0...

For the 6502, 03, 04, 05 and 06, yes. But the original MOS datasheet ("1976 prelim") also gives timings for the 6512, 13, 14 and 15 that are relative to ϕ2 input (because there is no ϕ2 output; ϕ2 input here is on the same pin as and seems to me the same thing as ϕ0) and of course the 6501 would have been the same. That's part of the original question I asked: is there something different about the way the internal clock chips do timing from the external clock ones?

Quote:

...and although I don't recall seeing an explicit delay listed, it's impossible for there to not be one, and if you want to go strictly by the datasheets, in theory it's unbounded.

Actually there is a bound on some early (pre-1980) data sheets, as I posted above:

cjs wrote:

But I decided to have a look at a 1979 Synertek SY6500 datasheet I happen to have kicking around on paper, and it turns out that it does give this. (Yay!) Fortunately it's already been scanned and is up on 6502.org.

Quote:

The main practical impact that I can see this delay could have is that the data hold times are specified relative to phi2 not phi0, so for example during a write operation in the Rockwell datasheet there's a minimum 30ns hold after phi2 falls before it releases the data bus. If you were driving the data bus externally during phase 1, and timing this based on phi0 rather than phi2, then you'd need to account for not only the 30ns hold time but also the delay between phi0 and phi2.

Ah! I'd not quite grasped this yet in my analysis, but that looks like an easier place to start than the direction I was going in the post I quoted above.

Quote:

If they did bother to specify a limit on the delay, it would probably be so small that it wouldn't matter even in theory.

That's kind of my hope. My instincts say that, with all these similar chips (6501, 6512, 6510, etc.) accepting only external clocks and working fine with those, there's no reason the chips with internal clocks ought not be the same. But I've been burned before by "logic" based on my misunderstandings of how things really work.