It was discovered that in release 4.1, the external trigger is misaligned with respect to the ADC data.

Due to differences between the time required for the delivery of the data (which needs to be digitized, serialized, delivered to the FPGA and de-serialized before it becomes available) and the delivery of the trigger pulse (which only goes through a synchronizer inside the FPGA), the external trigger arrives earlier than the data.

This was acknowledged in release 4.0, when in case of external triggers, the driver would program the FPGA to introduce 3 delay cycles to the trigger, to align it with the data.

However, during recent lab measurements, it was discovered that the correct value for this delay is 5.

This was measured by using an Agilent 33600A function generator to generate a -5V/+5V square wave, together with a trigger out signal. The difference between the trigger signal and the zero crossing of the square wave signal was measured with an oscilloscope to be 5ns. When acquiring the data with the FMC-ADC, the zero value would appear 2-3 samples after the external trigger. After disabling the software correction of 3 cycles, the zero value appears 5-6 samples after the external trigger, revealing the true delay between the two paths. Given the 5ns "error" from the function generator (half a sampling clock period), a correction value of 5 clock cycles should be used to align external trigger and data.

This should not be implemented anymore in software. Instead, with the new trigger logic in place (see also #8 (closed)), this delay should be handled in the gateware because it will be much harder for the software to know when to introduce it, in case of logically OR'ed triggers.