Hi,
Well one problem that comes up is related to the propagation delay of a logic element such as a gate or flip flop.
The simplest example is if we wire up 10 logic gates in tandem where each gate has a propagation delay of 10ns, the total time for the input signal to reach the output is approximately 100ns, which is 10 times a normal gate delay. Now say we have a second circuit with only one gate, the total delay of that circuit is only 10ns. Now say we drive both inputs of the two circuits with a logic pulse who's duration is 110ns, and say we use a two input AND gate where we get the two inputs from the two circuit outputs, and we look at the output of the AND gate.
What we see is one circuit output takes 100ns to go high while the other circuit output goes high after only 10ns, so for the first 10ns nothing happens, then the second output goes high but that's only one input to the AND gate, then 90ns later the other circuit output goes high so finally after 100ns we have two highs on the input of the AND gate so the AND gate output (which also has a delay of 10ns) will go high 10ns later. So finally at 110ns later the AND gate output goes high. Then the input goes low again. The 10ns circuit gate output goes low at 120ns, then 10ns later at 130ns the output of the AND gate goes low again, and stays there.
So we ended up with an output that went high at 110ns, then went back low again after 130ns, so the output pulse was only 20ns wide.
Now if we had not considered the gate delays, we would have assumed that the two inputs translate to the outputs immediately and the result of the AND appears immediately at the output too. So thinking in these terms, the output would go high at t=0 seconds, and low again at t=110ns, following the input pulse exactly.
So you can see the difference there. 110ns vs 20ns, depending on if we considered the gate delays or not. So understanding the effects of the gate delays is important and testing for this may be necessary at some point too.
Another example is with flip flops connected in a ripple carry fashion. That's where the output of one FF triggers the clock of the next FF in the line. Say we have 32 stages, and the delay is 10ns for each stage. When the first clock triggers the first flip flop, the Q goes high after 10ns. But when the second clock triggers the first FF again, the Q goes low after 10ns, and that triggers the next stage flip flop, but the second FF output Q does not go high for ANOTHER 10ns, so the total delay is twice that of one FF, just like with the gates, but now it only happens during certain states. Unfortunately, if we have 32 flip flops all connected as ripple through counters, that means we have 32 times the delay when the last stage output Q goes low. That's 32 times 10ns or 320ns, and that is considerably longer than we might expect.
The problem here is not the delay itself, but it's effect when it is compared to other parts of the system that operate in parallel rather than in series like that. For example, if we had a set of eight 4 bit latches where we wanted to capture the total count in the FF's at any given time, we'd have to be careful about when we clock the latches (that's when they store the information of the FF's). If we clock it immediately after the last input pulse to the counters, we would actually end up latching the state of the counters BEFORE the last counters had a chance to change state, so we'd be capturing the counter states in the past. But unfortunately it's even worse than that, because some of the counters may have gotten a chance to change state, so we'd be latching an invalid state of the counters. Invalid not to the logic itself, but to the applications requirement.
I've seen this actually happen and the result is a bogus count is collected and displayed.
So one test would be to check the propagation delays of various parts of the circuit to see how they affect the system. During the design phase you always have to be aware of these kinds of delays though. Sometimes the delays are put in there on purpose to achieve some timing goal, but i dont believe that's the best design practice unless it is really necessary.
There's also the tests just to see that the logic is behaving normally. In this case you examine the circuit to determine what SHOULD be seen on the outputs, and then measure what really IS on the outputs, then compare results. That turns up problems too if there are any failed gates, shorts, etc.
I cant help but mention one other very interesting problem that comes up.
Some logic families have outputs that have lower impedance for a 'low' output than for a 'high' output. What this means sometimes is that an output can pull another high output low, but another high output can not pull another low output high. This means test patterns have to be created very carefully depending on the logic family. For example, testing outputs by setting them all to 1's or all to 0's doesnt work because if any pins are shorted you will never detect that, but more to the point, using a pattern of 8 bits of 10101010 isnt enough either because if the second and fourth output on the device package are shorted on the PC board, you'd never detect that. And ditto for 01010101 because that doesnt help either.