I am using 74LS652 octal bus transceivers and registers, in a 4 MHz switching application and I am seeing very peculiar glitching. Here is the focus of the problem:
and that 16 bit Counter is here
and the clock is 4 MHz.
The point of this is to have the output of U8 show only the current or last even number and the output of U9 only the current or last odd number from the counter. I could do that with a transparent level latch, (perhaps if I could get the 74LS373, whose pins are very inconveniently not bus organized), but anyway, it seems like all the controls of the 74LS652 are easily matched and seem to fit perfectly with my counters.
The counters increment on the falling edge of the clock, and this means that the clock behaves essentially as a counter-stage. But the point is that on the rising edge of the clock, if the least significant bit (LSB) is low (even number), the clock will come through U7A to CLKBA (aka CBA in other data sheets) and be saved in the register of U8. Then, when the LSB goes high, SBA (aka SA) is turned on to output this saved value instead of the value on the input lines.
So this should work beautifully, and it does at 1 MHz. But at 4 MHz there is a very strange glitch, seen on the output A4 (Xe4). Here you see the glitch on the output (upper wave) against its input pin (lower wave):
I think it helps if I show some other traces to compare this event. Here is the same against the output on A0, i.e., that bit that is forced to be low, the little spikes being the output just about to go high when the SBA going high will replace the input bit with the stored bit:
To really understand the controlling behavior of this I'm showing this internal schematics from the data sheet. B is the input side (upper side of package) and A is the output side (lower side of package).
SBA goes through this peculiar buffer and NAND gate (the TI data sheet shows two inverters)
but anyway the delay here is so small that we don't get to see a spike up. We do get to see a pretty long spike down though on the odd side, the U9 (I don't have a photo of the trace of that now). Here is a comparison of the A4 of U8 (dirty glitch) against A4 of U9 (clean):
What is peculiar in both, though, is the roof of the square wave is wiggly sloping upward, like stairs. And if I disconnect the clock CLKBA, letting it float, you see this stair behavior in a whole new light:
Strangely, this glitching peak is not seen in the lower bits A3, A2, A1 where you would expect more trouble because it is switching at higher frequency.
Oh, and to make matters worse, if I swap in another make of the chip I might sometimes even get two glitches:
here are two different makes of the same device type that I have:
but its not a broken chip, I swapped out various and the principle problem is always the same.
At 2 MHz that glitching peak merges with the main hump. Notably, while I cannot show it in the scope (at least not right now), I know from other observation that such a glitch is occurring at 2 MHz on A7, the MSB. Only at 1 MHz that A7 glitch does not happen.
What might cause this weird glitch and how might I be able to prevent that? First I thought it's a breadboard issue with capacitance causing slow edges, but I suspect now that even on a perfect PCB I would have this happen.
UPDATE: One hypothesis given in the comments is that the problem might be the CD4040, being rated at 3.5 MHz maximum at 5V only. However, keep in mind that the CD4040 only comes in at the end of the 74LS393, which is per data sheet a "dual 4 bit binary counter" with a maximum input clock rating of 35 MHz. So if I enter that with 4 MHz I am well below that maximum, and at the time the signal goes out to the CD4040, the frequency is down to 250 kHz. So the frequency alone wouldn't be the issue.
But perhaps the delay is the issue you think. Like the CLK is already low, the LSB already toggled to its new value, and then there is a huge delay until the first bit of the CD4040 also flips. It is curious that the trouble starts just exactly at the first counter bit of the CD4040. Per data sheet it has a 180 - 360 ns of propagation delay from it's clock input φ to Q1 (the first counter stage).
Let's see if I can verify that on the scope, yes:
there is clearly a small delay between CD4040 φ input and the Q1 output. But it's even worse when compared with the original 4 MHz CLK input on the '393:
So, I am using the wrong sort of counter I suppose. I should stick to the 74LS161 and apply 4 of them. And then use the inverted clock. I wish there was at least a decent 8-bit binary counter, if not a 16 bit on one chip.