I discussed this in my thread in newbies about building my first SBC, but lots of ideas are being thrown around and I figured I'd get a thread started here to keep it more organized.

The basic goal is to have a controllable frequency for 2 reasons, A: to be able to push as close to the limit of a particular chip as possible B: to be able to talk to slower devices, like EEPROMs

So far, there have been a couple suggestions:

PLL
VCO controlled by 8 bit DAC + opamp for controlling voltage range
ICS525 clock generator datasheet
(not variable but suggested) clock stretching using the circuit in Garth's primer
wait states (have been discussed quite a bit and lots of good info already)
My current favorite, and a chip I found, the LTC6900 datasheet

There may be a few others I'm missing but these are a good start. I'll probably be implementing the last one in my current design, unless I find something through hole that's just as good.

EDIT: original thread

BluePill board with a piece of firmware -may serve as clock, reset generator and a few peripherals. Parameter settings via USB VCOM, may as well provide 2nd UCB VCOM for 6502 terminal. Look up my SDC_Zero project. It's easy to implement a functionality of any subset of a 6502 computer logic in an STM32F103, up to the whole computer (well, that's maybe not so simple, but definitely possible - proved already).

I'm hoping to solve the issue with ICs rather than a separate board/controller, but I'll keep this in mind for future projects. If you look at the original thread you can see a few pictures I've posted of the board so far, and I'm liking the idea of using the LTC6900 currently (or possibly the LTC1799, which is a better version of the 6900)

What kind of resolution and range? Is 1.0-MHz through 20.0-MHz in 500-kHz increments enough? How do you want to select and display the frequency? Will a set of jumpers do? Or, a pot' (no display)? Or, a Rotary Encoder and OLED display? Or, a push button and a pair of 7-segment displays?

You might consider using one of a number of PIC microcontrollers that come equipped with a 20-bit NCO peripheral module. After connecting power, a crystal, and allocating a clock output pin, an 8-pin version could provide three jumpers to select one of eight frequencies. A 14-pin version would have enough I/O pins to employ any number of select and display options.

Food for thought... Mike

The only problem is I need it to be selectable digitally by the machine so that it can slow itself down to talk to slower components. I could probably take this design and just use some via pins to ground the specific pins that select the clock, but at that point I think it's just about as efficient as using the 6900 and a digital rheostat.

For reference, here's a picture of the schematic for the current solution, and how the chips look on the pcb:


I haven't actually placed this where its going to go, or routed anything for it yet, I've just bee messing with the layout.


EDIT: I see an issue with the schematic, I messed up the bypass capacitor on the 41x2, ignore that for the moment, I was really tired when I added this in this morning.

No, you don't want to do this.
I would rather think of selecting/gating one of two clock signals based on address, the slow one being, say, 8 times slower than the primary one. It could be implemented using a counter. The counter should reset at the end of a fast cycle, CPU clock taken from either bit 0 or bit 3 of a counter. Care must be take to avoid glitches while switching.

Why not just use the design I have with the clock generator controlled by a digital rheostat? Here's the updated final layout:



With a variable clock, I can set the board up while using a slow clock, and then start pushing it until it gets unstable, which could be at an odd number that's not available in an oscillator can (not to mention, I don't have to buy a bunch of oscillator cans to try). Is there an issue with running a clock like this?

As said on pg.8 of LTC DS the switching from one frequency to another by switching on/off a parallel resistor requires roughly 70µs to settle. Hmmm...

Right, I forgot about that part, the 1799 is the same chip, but better, (higher frequency range) and seems to settle in only 25µs. Still very slow, but I wonder if it cleanly stretches or compresses the clock during that time, without any errant spikes.

The worst problem about this is, if it takes 25µs to settle, that means if we need to talk to a slower device, we must wait at least this long before attempting communication.

Maybe the 525 isn't such a bad idea after all?

As suggested upthread, a variable speed might be a good solution for testing out a design for overclocking, but isn't a great idea for accessing slow peripherals. There are techniques for pulse-suppression and techniques for glitch-free switching between clocks. You'd use those if you had a CPU which doesn't allow itself to be stalled, so for a 6502 you need a fancy clock but for a 65C02 you use RDY. (Except, RDY on the 6502 is fine for read accesses, so that's good for booting from ROM.)

It might help to think of a clock as a series of edges. You want to adjust the delay between edges. Just possibly you could cook up some phase-accumulator logic which runs fast enough that it can toggle a flop at the rates you want. But I imagine it would need to run at 100MHz or above, so this would be rather advanced. Indeed if you have a master clock at 100MHz and divide down by 8, 9 , or 10 that gives you 12.5, 11.1 and 10.0MHz. This is not continuously variable, of course.

It's a hazard of PLLs (I think) that when they are adjusted the output frequency might overshoot, which you'd very much want to avoid.

As BigEd already said a PLL might not work the way you wish. Any PLL contains a regulation circuit that averages the VCO frequency to the desired. During transition this causes either over/undershoot or requires an awful long time. The 525 contains a PLL and there are no information about its transient behavior. It might be worse than what LTCs solution offers.

If you wish to have an adaptive clock for e.g. power saving you might use any suggested circuits. Then it doesn't matter how long it take to reach the desired frequency. If you wish to slow down the clock only briefly - accessing slow I/O - then use a switch to select the clock or use the RDY pin to extend the bus cycle (which works for read and write cycles when dealing with CMOS CPUs).

There are delay line products:
https://para.maximintegrated.com/en/sea ... m=del_line

I suppose that the easiest and probably most reliable solution is to use wait states, probably generated by a product linked by BigEd. It's upsetting though, because I feel like there should be a solution to this that isn't incredibly hard or complex, so many systems these days have variable clocks, I would think there would be a good solution out there. Before I completely hang this up and switch over to wait states, I'm looking at some products on Digikey, they have some clock dividers/multipliers/generators that I've been looking through, some of which I've not seen when looking on mouser.

So looking around I've found a couple PLLs, each with their own implementation quirk, that seem to do the job, but not much information on how long it takes to transition frequencies. The most recent one I found is this which requires an external crystal, and operates at fairly high frequencies. The nice thing about it is it's programmable over SPI, so you wouldn't need an intermediary chip like with the 1799.

I need to do some research on how to use PLLs, Garth posted some good info on the other thread about it, and I feel like if there is an answer to this issue, it lies in the use of a PLL. Then again, there may not be a good way to do this, and I may end up having to use wait states.

Re-reading over the thread, and something interesting that I thought of here.

I could put the LTC6900/1799 onto a small board that plugs into a DIP-8 socket, that is connected the way that an oscillator can would be. On initialization, I'd need the LTC to be set to its slowest value, so we can read our program out of EEPROM. After boot up, I could set the clock value via a program command, so that EEPROM is not involved at all, and if I needed to access EEPROM, I could use one of the delay lines you mentioned earlier to hold the RDY line low to extend the time we're talking to the EEPROM. Once I've found the fastest stable clock for the system, I can buy a can that matches that speed, and drop it into the DIP-8 socket that I've been running the LTC board out of. This would let me have my cake and eat it too, as long as the LTC is well behaved during its settle time.

EDIT: I don't necessarily need the slowest value on startup, since the delay line can work at startup as well. But having it reboot to a slow state is probably good practice, in case I get myself into trouble.