Thank you for your response.
Unfortunately I can't slow the frequency down much without affecting the operation of the DUT. The false triggering that is occurring is not a function of the frequency anyway. It is due to the amplitude of the ringing after the falling edge of the clock pulse.
The quality of the signals is slightly worse when the DUT is connected. The DUT test board is connected to the terminal boxes through several ribbon cables that are about 1 ft long. I can shorten them some, but the issue is the quality of the signals present at the terminal boxes.
The first scope shot below (scope_23.png) is measured at the DUT test board. The clock signal was slowed down to 2 MHz (4 MHz sample rate), but the ringing and crosstalk is still significant. Ch1 (yellow) is the 2 MHz clock signal (from P0.0). Ch2 (green) is output from P0.3, and it is being held low at the moment. There will be another control signal on this channel, but I wanted to show that the crosstalk from Ch1 is quite significant. Ch3 (blue) is the clock signal after passing through the level shifter. It does a good job of clamping the logic-high level down to about 1.2 V, but the ringing on the logic-low signal is passing straight through. The first positive peak of this ringing is about 525 mV, and it's enough to cause a false trigger on the DUT.
Ch4 (pink) is an output from the DUT (after another level shifter to bring it up to 5V). It is a decoded output from a 2-bit counter in the DUT. There should only be one pulse per every four clock cycles, and its width should be the same as the clock period (500ns in this case). The peak in the clock signal at +826ns caused the counter to advance. The false triggering occurs nearly every clock cycle, and it can be seen that the second pulse on Ch4 has occurred two cycles earlier than it should have.
To put this in perspective, I am attaching another plot (scope_8.png). This was an ealier test using two standalone function generators to create the signals on Ch1 and Ch2. There is very little ringing, and there is no visible crosstalk on Ch2 from Ch1. In this case Ch3 is the same signal as Ch4 was on the other plot. The pulses occur once every four clock cycles as desired. Ch4 on this plot is a signal generated by a circuit on the DUT test board. It is a delayed signal (~375ns) that depends on Ch2 and Ch3. It is also functioning as expected.
When I built the test board for the DUT, I had not used LabView and DAQmx hardware before. I had not considered how to handle the signal anomalies I am seeing. I can make this work if needed, but it in its current state it seems like I would have to add several signal conditioning parts (Schottky diodes, low-pass filters, and possibly Schmitt trigger buffers) to each output from the 6363.
It seems that I am trying to use this NI system a bit beyond the capabilities that it is designed for. The FIFO buffered outputs can only run up to 10 MHz under ideal conditions, and I'm trying generate precise and clean signals at 8 MHz sample rate. I appreciate the power and flexibility of LabView and DAQmx, and I will likely be using it more in the future for other projects. However for this particular project, I'm beginning to feel that I would be better off testing the DUT using an FPGA or a PSoC so that I have more precise control over high frequency signals.
I will discuss this further with my professor. If you think that the 0.5m cables would be a signicant improvement, then I will let him know. Even if they don't end up solving my issues, they may be useful for other projects.
