One of my other projects, the 6502 Fake Finder, should be able to determine the type of CPU inserted into it, provided it's a pin-compatible 6502 variant. This includes examining various control signals to distinguish between mask and bondout variants of the same CPU core. But the Fake Finder has no provision for checking the CPU's ability to run at high speeds; indeed it deliberately runs the CPU at about 450kHz, to make sampling the control signals reliable even on the slowest speed grades of NMOS 6502.

A different approach is needed to estimate the speed grade of the CPU. The most direct way would be to run the CPU with a variable frequency clock, and ramp it up until it crashes or starts failing a functionality test, then back off. But I intend instead to directly measure the propagation delay from the Phi2 clock edges to the latest valid transition edge of some key output signals. You can already do this by hand if you have a decent oscilloscope, but I do not, so I'm designing a test rig with a built-in readout instead. There will be no conventional RAM or ROM here, only a cycling pattern of test opcodes and data, generated by random logic.

I will need to use two distinct measurement techniques to cover the fastest and slowest speed grades.

At the low end, it is useful to distinguish parts in the 1-6 MHz grades commonly produced by everyone except for WDC, and I believe this can usefully be done using a pair of synchronous shift registers clocked by each edge of a 16MHz master clock (for an effective 32MHz sample rate, about 30ns interval), the CPU itself being clocked at 1MHz. These registers' parallel outputs can be latched synchronously with Phi2, and XOR gates between consecutive samples will then visually highlight where in the cycle the transition occurred.

At the high end, the current WDC parts are rated to 14MHz with clock phases valid down to about 35ns. This calls for much finer timing resolution than can realistically be provided by clocked logic. Instead I could use transparent octal latches, cascading the signal of interest from output to the next input across the bits of, say, three such chips. In 74AC logic at 5V, this should provide roughly 5ns resolution up to about 100ns behind the clock edge. At some defined point in each cycle, the transparent latch is closed to hold the sample, then a second latch captures the stable output of another bank of XOR gates for display.

Not every cycle will produce a level transition on every signal of interest, and there will undoubtedly be some variation in timing between different cycles - but I think this approach will turn an otherwise impossibly fast phenomenon into something which can be observed and characterised with the naked eye.

It will be interesting to see how this goes! I think there are four kinds of possible timing-critical paths:
- pin to pin (such as your clock in to clock out)
- clock to pin (such as SYNC, or address pins)
- Q to D of internal logic (for example incrementing PC from 7FFF to 8000, or decimal add of 1 to 99)
- pin to clock (setup times, such as on the databus during opcode fetch, or operand fetch, or data access)

I would expect to find most of these to be somewhat data-dependent: there'll be a worst kind of opcode, for example, or a worst kind of calculation.

What might be true is that all of these scale up and down together, so that any accessible measurement is a good indication of all of them.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Right, this particular test rig is only designed to measure BigEd's first two criteria. It should be sensitive enough to distinguish the address, data and control setup/hold time differences of different speed grades of the same CPU family. These are clearly related to the clock minimum high/low phase times of each speed grade, which are essentially controlling of the overall clock cycle time.

To cover either of the two latter points, I'd have to incorporate a correctness test for signal outputs based on inputs, as well as varying the clock and data-input timing. The latter would be particularly tricky, because the data setup time of even the lower speed grades is down around 50ns to 30ns, and WDC's is only 10ns! Clock timing could be varied by duty cycle rather than frequency, though, and that might be valuable for investigating internal behaviour. At any rate, I would need to think separately about how to build a test rig to run that sort of test.

As always, the proof of the pudding will be in the eating. Putting a few CPUs of known provenance through this test should help to clarify whether it's sufficient.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Those are definitely interesting devices, though I haven't looked up the prices yet. I think I would probably use them to generate arbitrary clock signals and gating control signals (another octal transparent latch with tristate outputs), rather than delaying the actual data signals.

The remaining problem would still be comparing the signals produced with a ground truth or a computed known-good result. This could in principle be done by running two 6502s in parallel and feeding them the same data, but with modified timings for the CPU under test. For best results, the "master" CPU would have to be of the same type, at least so that instructions have the same cycle counts. Fortunately, an NMOS 6502, a WDC 65C02 and a WDC 65C816 would suffice for this purpose.

Reminds me of the Logic Shrimp logic analyzer from several years ago that clocked data into 256kb serial SPI SRAM chips at 20-MHz. Unfortunately, that would only provide ~50-nanosecond resolution (about ~12-milliseconds of samples after the trigger).

I wonder if you couldn't take advantage of features in faster, more recent PIC microcontrollers? That is, clock the PIC at 64-MHz, use a counter with Fosc as the counter source, send the PHI2 clock signal to the CPU, which might also be used to open the counter gate, and use the transition of the signal under test to close the counter gate. Read and calculate time from the counter registers.

My "blind interface" uses only 11 pin connections to the test 6502 (doesn't require a BE pin only available on WDC chips) and can reset and step the 6502 repeatedly through almost any instruction or state. The PPS (Peripheral Pin Select) feature in the PIC would allow you to move the counter input to any one of several signal pins during a test sequence. That is, setup the test condition/state, select the counter signal input pin, step through the test state to sample and capture your signal transition several times before repeating the sequence for the next signal under test.

Interesting? Yes, no, maybe, huh?