Can the per-byte delay adjustment be adjusted in real-time for the PG3ACAB and PG3AMOD? Is it glitch-free?

Can the per-byte delay adjustment be adjusted in real-time for the PG3ACAB and PG3AMOD? Is it glitch-free?

Yes, the delay lines can be changed in real-time. This enables characterization to happen at a very high rate, without having to start and stop the PG each time.

Because the changes to the delay lines are asynchronous to the data contained in the delay line (imagine a long piece of wire with a movable tap point), it is possible to cross through a clock edge and generate a glitch. The only way to guarantee that a "glitch" is not generated is to move the tap less than a rise time. Since the tap positions can be changed in 20pS steps, this is possible (but tedious). When running slower than 29 MHz and trying to get delays longer than 10nS, this can become an issue as one of the delay lines has a tap size of 2 ns (user sees continuous 20 ps steps). If you are unlucky, you can generate a very narrow glitch.

There are a couple of applications where this glitch would cause a problem: situations where the vector width is greater than 8 bits AND the vector must remain coherent. Often users with wide vectors only move the delay lines at the setup of the pattern and then don't move them in real time. No problems in these cases. Furthermore there are many different situations that, if not carefully thought out, may cause the particular application some trouble. For example, if you need to adjust 4 of them "together": we cannot do this simultaneously. If the jump in time is substantial, the data on the byte being moved relative to the other byte may be out-of-sync until all delay lines are updated. Something to consider! We are working to improve the glitch situation. If you have a concern, please contact us and we can see how to maximize your productivity.