Re: MRF Delay Compensation Function

[Jukka Pietarinen via Tech-talk <tech-talk at aps.anl.gov>]

Hi,

The reason the target delay has to be longer than the sum of the 
physical and internal delays is that if the target delay is shorter than 
possible the EVR is still trying to shorten the delay. When the delay 
error is greater than one event clock this is done by skipping a write 
to the delay compensation FIFO - this is to speed up the initial locking 
time and this can lead to an event being missed. During normal operation 
the delay error is always much less than one event clock cycle and the 
adjustment is done by phase shifting the event clock and no events are lost.
The above applies to the delay compensation mode. The current (DC) EVRs 
are capable of a running in non-delay compensated mode (compatible with 
the EVG-230) and in this case the "target delay" value is the actual 
delay of the delay compensation FIFO. The target delay value defaults to 
0x00080000 which means there are eight events in the FIFO and there is a 
safe margin from the FIFO getting empty.
There are also flags that indicate if the delay target is too short or 
too long. I now see that the system could be improved by adding limits 
to both the lower and higher end of the FIFO that stop adjusting beyond 
the FIFO empty and full states.
I will address the lock indication issue - this might be related to the 
event clock frequency which for ESS is 88.0525 MHz, I cannot recall 
seeing this issue on the VME boards running at an 142.857 MHz event clock.
Best Regards,
Jukka

On 2/20/20 5:55 PM, Timo Korhonen via Tech-talk wrote:
> Hi,
>
> On 20/02/20 15:40, "Shen, Guobao" <gshen at anl.gov> wrote:
>
>      > the target delay must always be set so that it is greater than the physical delay, including internal delays. Otherwise some events will be missed
>      
>      That's interesting and good to know.
>      It seems a firmware issue. Did you get any response from Jukka?
>
> This is not a firmware issue in the sense that it could be "corrected" by some change in the firmware. It is by nature of the delay compensation system; the system simply cannot go back in time.
>
> I got some information related to occasional unlocking of the delay compensation feedback loop that we have seen a few times in the lab.
> In essence, Jukka is able to reproduce the issue although it seems to be very rare.  The current assumption, as far as I understood, is that this is probably due to some threshold settings in the Xilinx DCM (Digital Clock Manager) being set too low. Also, as well as I understand, this does not cause any jumps in the delays. There will be updates to this but I think this is a very minor issue.
> (sorry that this is missing some context for tech-talk readers; it would take a lot of text to replicate the whole discussion here. We can post a summary later if there is interest.)
>
>
> Best regards,
>
> Timo
>      
>      > We are starting the commissioning phase soon so we will have better results.
>      
>      Would love to know your experience.
>      
>      Thanks,
>      Guobao
>      
>      On 2/20/20, 2:40 AM, "Javier Cereijo García" <javier.cereijogarcia at ess.eu> wrote:
>      
>          Hi all,
>          
>          Yes, here at ESS we have done some tests in the lab in the past,
>          although they were quite simple. I can share what we have learnt. These
>          tests were done using mTCA-EVR-300 and mTCA-EVM-300, not VME.
>          
>          The first feeling is that everything works as expected, and changing the
>          target delay works smoothly, as well as changing the length of the
>          optical fiber. There is one thing though that seems strange to me, and
>          it is that the target delay must always be set so that it is greater
>          than the physical delay, including internal delays. Otherwise some
>          events will be missed. Even when using a 230-series EVG with the delay
>          compensation disabled on the EVR side the target delay needs to be set
>          correctly.
>          
>          We didn't perform any complex jitter test, although monitoring the "DC
>          lock" shows that it gets unlocked from time to time, usually recovering
>          quickly. We didn't worry too much at that moment, the measured delay
>          wasn't changing that quickly, I think that the lock monitor is quite
>          sensitive. I can't recall from the top of my head if we were using the
>          EVM's fractional synthesizer or an external RF source, so this may
>          easily disappear in a more stable environment.
>          
>          We are starting the commissioning phase soon so we will have better results.
>          
>          Best regards,
>          
>          Javier
>          
>          On 19/02/2020 18:17, Michael Davidsaver wrote:
>          > On 2/18/20 10:43 AM, Shen, Guobao via Tech-talk wrote:
>          >> Hi all,
>          >>
>          >> Is there anyone who has been using MRF EVM-300 delay compensation function for any purpose, in the lab, test stand, real machine, etc?
>          > ESS did some testing as well.
>          >
>          >> If yes, would you mind to share us your experience?
>          > As I recall, it worked well on a test stand.  My personal knowledge ends there.
>          >
>          >
>          >> Thanks,
>          >>
>          >> Guobao
>          >>
>          >>
>          >>
>          >> --------
>          >>
>          >> Guobao Shen
>          >>
>          >> gshen at anl.gov <mailto:gshen at anl.gov>
>          >>
>          >> Controls Group Leader
>          >>
>          >> Advanced Photon Source
>          >>
>          >> Argonne National Laboratory
>          >>
>          >> 9700 S. Cass Avenue, Lemont, IL 60439
>          >>
>          >>
>          >>
>          >>
>          >>
>          --
>          Javier Cereijo García
>          
>          Embedded System Engineer
>          HW&I group, ICS division
>          European Spallation Source ERIC
>          
>          Mobile: +46 (0)72 179 23 34
>          E-mail: javier.cereijogarcia at ess.eu
>          
>          
>      
>