Synchronization problem using external trigger

[Pat Carr]

We had a schedule conflict last Friday. We'll be doing the tests today. Thanks for your understanding.

[Pat Carr]

The trigger input timing can be tweaked to compensate for delays in components, cabling, etc.
Using Register 0x16 is how you set the input delay element.

We did reproduce your issue in a RevF board, and using this register fixed it.
Writing 0x110 to register 0x16 applied a proper delay compensating the timing of the trigger. Your setup may be different and you may need to try other values.

Register 0x16: Fine trigger calibration input delay.
Bit 9- Delay reset: resets the idelay element to zero.
Bit 8- Increment delay: sets the idelay to increment taps (zero will decrement).
Bits 5:0- Amount of taps: each tap applies a 72ps delay to the input.

Your application should first reset the idelay element by writing 0x200 and then writing the proper delay increments, in our case 0x110.

[AQAV]

Thanks for the measurement and instructions for configuring the register.

Following your suggestions, we tested the Rev.F board by writing different delay increments, we scanned the whole delay increments from 0x000 till 0x13E with the step of 2, unfortunately we could not find the proper delay increments completely solve the phase jump issues. For certain delay increments, the phase jump chance was less, but it still happened.

On the other hand, we did the some random delay increments changes for two Rev.E boards, the phases were not influenced by this parameter and always stable.

[Pat Carr]

I'd suggest checking the trigger input rise time. It could be too slow compared to the clock, to be confusing the edge detection circuit in the logic.

[AQAV]

Thanks for the reply, Pat.

We have checked the trigger rise time, it is around 1ns. Many different efforts have been made to improve and adjust the trigger and clock relationship. But that did not solve the phase problem.

You can find the report in the attachment.

In your measurement, the phase instability is completely removed after writing 0x110 in register 0x16? is that possible it just coincidently happened from statistics point?

[AQAV]

Here is the measurement report.

[Pat Carr]

A new beta version has been released that fixes this issue. Please see X5-400MDevKit.zip in:
http://www.innovative-dsp.com/cgi-bin/dlWindowsBeta.cgi?product=X5-400M

[AQAV]

Thanks Pat, for all efforts.

We want to use the new BSP for MATLAB based design. But it happened that:
When I tried to use the MATLAB/BSP supported Framework Logic, in folder: X5_400M_r7.6\400M\matlab\rev_e\Logic, I encountered error like:

[Pat Carr]

In the interest of expediency, we released this version without synchronizing the BSP release. The BSP will be updated shortly.
Please test with Snap on your set up and let us know.

[AQAV]

We have tested new bitstream file with SNAP for our 4 boards, two RevF boards work well, which have phase issue with old bitstream file;

But, one of the two RevE boards still encounter phase jump, around 1/3 chances from statistic point. That board works perfect with the bitstream file for r7.4.

[Pat Carr]

Can you specify which channel is showing a phase difference? Since the external trigger is sampled on channel 1's sample clock, it should be always aligned on channel 1, on RevE and RevF boards.

[AQAV]

We measured and calculated the relative phase between Ch1 and Ch2, since that is the parameter we take care about, thus we can not specify which channel is showing the phase difference.

[Pat Carr]

[Pat Carr]

A new beta release r7.7 has been issued that addresses this variation in RevE boards. I extensively tested it on 2 RevE and one RevF boards.
This new release should hit our beta site shortly. The Matlab BSP has been updated as well.

[Pat Carr]

Just to re-confirm, a new beta version r7.7 was released last week that fixes this issue. Please see X5-400MDevKit.zip in:
http://www.innovative-dsp.com/cgi-bin/dlWindowsBeta.cgi?product=X5-400M