Last night I overclocked my w65c02 to 25.175 MHz!

_________________
Thanks for playing.
-- Lord Steve

Recently I have whipped up a circuit to test 65C02 stability. A babysitting microcontroller initializes some RAM, then lets the 65C02 run the program in the RAM. After some delay, the microcontroller then reads the RAM and verifies that the output is correct. However, the program is awfully simplistic; I want something better. (NOTE: the W565C02 begins to have intermittent failure around 28 MHz, in this set up.)

What do you folks think would be a good verification test program that a 65C02 was running stably? I'm pushing for 25 MHz. (Yes, I know it's not rated for that. Thank you.)

_________________
Thanks for playing.
-- Lord Steve

I expect that if it's not crashing, the chance that something else is going wrong in the processor is slim. If it sometimes misreads or misexecutes op codes, you'll get a crash. And if data loads and stores have any kind of problem, any substancial program will have addresses stored in data space too so again it'll go to wrong addresses and crash. If you get past that, something that handles a lot of data (like an FFT) should be a tell-tale. Of course if the I/O fails first, it shouldn't be long before that shows up.

I've sometimes wondered what the real speed limits would be if you go all-out-- like:

use multi-layer PC board with power and ground planes, maybe even burried capacitance
use the smallest SMT parts to reduce inductance (65c02 in PQFP, not even PLCC)
use the maximum safe operating voltage (the absolute max table lists 7V)
use a Peltier device to bring the temperature way down
find the best clock duty cycle (which may not be exactly 50%)
use a programmable delay line to find the best clock timing to memory and I/O
etc

The exercise would mostly be academic since even if you got to 40MHz, that's hardly twice what can be reached with more conventional means, but it would be interesting. Of course all of that could be a total waste if the user then proceeds to run inefficiently written code with it.

I'd be interested to know what you used for I/O, what your RAM speed was, etc..

I know the processor design enthusiasts have a way to verify the operation of all op codes on their "inventions." Perhaps Rob Finch will remember where that is posted. I'm on the 65GZ032 Yahoo listserv as well as Rob's processor design listserv (both of which have been dormant since I moved to a new computer).

I tried to keep it simple. The CPU was a 40-pin DIP W65C02. The only IO was the RAM which served as program and data memory. I only used 256 bytes of the RAM. It was a 15ns 32Kx8 SRAM. You know the kind--old 486 motherboard ilk. The clock source was either a 1 or 25MHz crystal or a programmable clock that the babysitting microcontroller used. That's it. Purred like a kitten at 25 MHz, intermittent errors at 28 MHz, never worked at 30 or 33 MHz. I want to say again, though, it prolly wasn't the best stress test, and it wasn't a long test. I like the FFT idea; I will try to remember that in the future. 25 MHz was my goal, so I'm happy thus far.

Are Peltiers small enough to stick on a PQFP? Do they have to have a fan? The idea about finding the best clock duty cycle is interesting. How would you do that?

_________________
Thanks for playing.
-- Lord Steve

I'm surprised that a DIP could operate at all at that speed. That's good to hear. I take it that since the RAM seems to be the only thing the processor is connected to, there's no address-decoding logic to cause propagation delays. Still, the 15ns memory might be a bottleneck because of the processor's required read data setup time.

I've seen Peltier devices down to less than 1/4" square. It's not necessary to have a fan, but the hot side of it will do better with a heat sink on it. Another possibility would be to use a Peltier device large enough to cover the entire board, and use a compressible, thermally-conductive material between the board and the Peltier. That way the same device cools all the ICs, even if they're not all the same height off the board. Bergquist's "Gap Pad" seen at www.bergquistcompany.com is such a material. We use it in a couple of our products to transfer heat from a linear regulator to the product's actual aluminum case for heat sinking. You can get info on Peltier device manufacturers at http://www.peltier-info.com/manufacturers.html

I suppose there are several ways the duty cycle could be varied. One would be to use digital delay line ICs along with other logic, giving different delays to rising and falling edges of the clock source. Another might work something like PWM, starting with a triangle wave and varying the threshold to a comparator. Although the concept for the latter is simple, making it work well at such speeds might be a bit of a challenge. Having an accurate triangle wave shape would not be inperative though.

A programmable delay line I kept an ad on is the Maxim DS1023S, which gives 256 steps, with step size as small as 1/4 ns.

With both the duty cycle and the clock advance or delay to the various parts of the circuit, experimentation will of course be necessary to find the optimum settings, since this is beyond the scope of manufacturer-supplied info.

Yep, no decoding. I will try to keep that in mind as well at prototyping time, cuz I do need decoding. Thank you for all the info.

_________________
Thanks for playing.
-- Lord Steve