Experimental Physics and
Industrial Control System

Jukka Pietarinen via Tech-talk <tech-talk at aps.anl.gov> · Fri, 21 Feb 2020 10:26:14 +0200

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System