Clock Glitch
I’ve found a rare clock glitch in the Yellowstone hardware, but I’m not sure how to fix it. This seems to be the source of the “mysterious signal glitching” I mentioned in my previous post, that disappeared after some minor changes to the FPGA logic. From what I can tell it no longer affects the Apple IIe, but pops up rarely on the Apple IIgs, wreaking havoc. I’d suspected a glitch for a while, but I never directly observed it happening until increasing the logic analyzer’s sampling rate to 125 MHz and lowering the logic threshold from 3.3V levels to 1.8V levels. The evidence is shown above.
MEMEXP is an internal FPGA signal that should remain high. Q3 is a 2 MHz clock provided by the Apple IIgs. There’s an 8 ns wide glitch pulse shortly after the falling edge of Q3, and this causes MEMEXP to go low when it shouldn’t. In all my tests, the glitch pulse always occurs during the low period of Q3, between 50 to 150 ns after the falling edge.
An important detail: The Q3 shown in this logic analyzer trace isn’t actually the FPGA’s Q3 input, because that’s on a PCB trace without any good place to attach a probe. The trace shows an FPGA output that’s been configured to simply propagate the Q3 input. That should be nearly the same thing, but not exactly identical. To complicate matters further, there’s also some level conversion happening. The Q3 supplied from the Apple IIgs is a 5V signal, and it passes through a 74LVC245 to create a 3.3V signal that’s connected to the FPGA. Behold my awesome diagram:
The previous Yellowstone prototype had a 390 ohm inline resistor between the Apple II’s Q3 signal and the 74LVC245. This is something I copied from the design of Apple’s Liron disk controller, although I don’t understand why it was there. None of the other disk controllers that I examined have a resistor on Q3, and I couldn’t find any documentation about a need for one, so I eliminated the resistor in this second generation prototype. Maybe that was a mistake, and is the reason why I’m seeing clock glitching now.
My hunch is there’s a different explanation. I suspect the glitching is caused by other problems on the board, rather than Q3 itself. Maybe there’s capacitive coupling between Q3 and another nearby signal trace. Or maybe my power and ground supplies are bouncing around whenever there’s a big spike in current, like when a bunch of chip outputs switch simultaneously from low to high, and that creates EM noise everywhere. Or maybe there’s some brief contention on the data bus that creates spikes and noise.
I tried playing around with the the FPGA input buffer settings for Q3, in an attempt to make the problem go away. I tried pull modes of KEEPER, DOWN, and NONE, and hysteresis settings of SMALL and LARGE. Nothing helped.
I’m not sure where to go next. I could try assembling a second board, to see if it’s just an assembly problem with this particular board rather than a general design issue. I could look for a way to get a logic analyzer probe directly on the actual Q3 input, which might require fancy soldering, and might also change the behavior. Or a probe on the 5V version of Q3, directly from the Apple II. I could try to patch a 390 ohm resistor onto the board, but it wouldn’t be clean and might create more clock problems than it solves. Or sprinkle some more capacitors around the board, or other analog magic.
Read 4 comments and join the conversation4 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
Maybe a clue or maybe coincidence: the glitch always occurs while reading a byte from the board’s SRAM chip.
You definitely want to see the analog waveform of the glitch in order to find the source problem and solve the issue.
I don’t think measuring the trace between the buffer and FPGA would be all that interesting, except maybe to verify that the glitch is indeed present. But to do that, you could also configure the FPGA to pass its input signal to another output that’s easier for you to measure.
By the same token, I’m not surprised that changing the FPGA input settings has no effect.
If you’re very desperate, cannot remove the cause of the glitch and the signal is a free-running 2 MHz (i. e. extremely slow for an FPGA) clock, you could sample the signal with an asynchronous much faster clock, filter out any glitches using a simple state machine and then generate a clean 2 MHz signal from that. Your synchronous logic would delay its output so the total delay would be 500 ns. Basically, you can implement any phase shift that will be accurate to about plus or minus the period of your fast clock. Been there, done that with buggy hardware that was already delivered to customers.
Good idea, I had briefly considered making a glitch filter using a faster internal clock. I’ll hold that option as a last resort. I hope to fix the root cause if I can.
I’m thinking that the glitch must be caused by another signal that changes state at the time of the glitch. So what changes state about 50 to 150 ns after the falling edge of Q3, during an SRAM read cycle? The SRAM itself is enabled and begins outputting well before the falling edge of Q3, so I don’t think that’s it.