Sheep64 on Thu 26 May 2022 wrote:
There is a very minor error in the clock circuit which may cause very infrequent error. I have only learned this by reading all of Advanced FPGA Design by Steve Kilts.
On Fri 15 Jan 2021,
I mentioned to jfoucher that I am unnerved about switching clock sources. You provide an example which feels intuitively correct. The best part is that it only switches after both clock sources go high - and, specifically, in the order where the slow clock goes high then the fast clock goes high. That means we never have to consider any other cases, such as clocks in a different phase or clocks going low. It is like a sychro-mesh gearbox for clock frequencies. If I never read Steve Kilts' book, I might have been very inclined to copy your circuit and wonder why I worried about the problem.
However, counter to my intuition, any signal crossing clock domains is potential error and should be checked more thoroughly. This is particularly true if multiple, asynchronous signals are involved. Multiple signals? This is the problem but it is quite minor and may resolve itself. In Speed Select, the Q and /Q outputs of SLOW section of 74HC112 connect to J and K inputs of FAST section of 74HC112. They are always intended to be opposites. Unfortunately, when FAST clocks high, they may be 00 or 11 rather than the intended 01 or 10 due to logic level asymmetry, capacitance, ringing or other cause. In this specific case, the output glitch causes a multiplexer to select one high input rather than the other high input. Therefore, this signal glitch is swallowed by all down-stream logic. Assuming that any latch oscillates or that J or K take precedence in a manner which is not deterministic, this possibly increases the minimum speed ratio between FAST and SLOW to a factor of four plus propagation delay. Maybe. Even with the restricted range of the crystal oscillator and frequency divider (as found in
Episode 23! Out now!!! Don't miss it!!!!!), the minimum FAST frequency and the maximum SLOW frequency may be in a dubious range. Even here, you may switch between FAST and SLOW thousands of times without issue or have individual chips with fortunate properties.
This borderline case can be resolved by increasing the resistor or capacitor around 555 to reduce maximum speed of SLOW oscillator, further restricting range of the frequency divider or connecting spare section of 74HC112 to absorb glitchy output. The latter is the standard FPGA
double flop technique. Indeed, see clock crossing, think double flop. This is the preferred technique because the second FAST flop is guaranteed to have the intended opposite inputs. Unfortunately, that might extend the minimum speed ratio between FAST and SLOW to a factor of six plus propagation delay. Maybe. To reduce the ratio, I considered connecting one of two 74HC112 FAST inputs to a clock further upstream of the symmetric 74x74 FAST clock. That may or may not do anything useful without creating further awkward cases.
Single stepping can be exempted from a double flop. Glitchy signals are guaranteed not to occur when single stepping because your finger will be on another button when selecting clock source. Pressing two buttons simultaneously is undefined behavoir.
Anyhow, it is easy to be an armchair critic and you have my sympathy that it has taken you two hours per day over one year to get to the fun stuff, like 6522 and keyboard firmware. It doesn't help that the 6502 Forum can be a very harsh audience.