FIFO queue delay compensation

[daykin]

Here is some rough support for software delay compensation on our cPCI EVR units (new in FW version 1402000b). Documentation of this functionality detailed here: cPCI-FIFO.pdf

Of particular note is drvem.cpp line 1075. Is there a macro/better way to manipulate 4 bits in a 32-bit register? Any suggestions welcome.

[mark0n]

Background: DC-capable hardware allows automatic delay compensation by measuring round-trip times on bidirectional links. A variable-length FIFO at the input of each receiver applies the required delay to synchronize the event streams on multiple EVRs. Older hardware like the cPCI-EVR-300 doesn't have support for measuring round-trip times. However, even on this hardware implementing an adjustable lenght receive FIFO can be useful. For example this allows outputs on multiple EVRs operating in flip-flop mode (one event code forces output high, another event code forces the output low) to be synchronized (good enough to adjust for different fiber length; note that the delay needs to be measured manually to determine the required FIFO length; potential drifts cannot be compensated automatically).

The firmware mentioned above adds the variable-length receive FIFO. This PR exposes the corresponding delay-control register to allow manual adjustment.

[mark0n]

@jpietari we noticed that writing 1 to the decrement bit causes the link to drop out for a short time. It automatically comes back but after that DCIntValue is back to its original value. Are we using it the wrong way or could this be a firmware issue?

I guess we also need a mechanism in the driver that automatically writes to the increment/decrement bit until we reach the setpoint. @jpietari can you confirm?

[mark0n]

@jpietari are you intending to include this feature in the stock cPCI-EVR-300 firmware? If so we might want to add the feature to the existing evr-cpi-300.db file rather than creating a new file evr-cpi-300dc.db.

[jpietari]

Hi Martin, yes you have found a bug. The writing into the delay compensation FIFO is done with twice the rate of the event clock and I was using the wrong clock to de-assert the write enable to the FIFO. For some reason this worked with my earlier test setup. I will email the new firmware to you.

The FIFO will not make its way into the stock firmware as there is the problem that you have to adjust the FIFO depth by software - you cannot be certain of the startup delay value and this will change with temperature, supply voltage, event clock frequency etc. If you are lucky it will always come up with the same value but there will be combination where the delay can vary by one event clock cycle.

[jerzyjamroz]

@daykin , @mark0n is this PR still valid?

[ttkorhonen]

As far as I know, @mark0n is not working in this field anymore. Maybe @daykin can comment. I would be hesitant to merge this, at least without changes. As @jpietari commented above, the feature will not make it in the stock firmware so the use would be limited to the FRIB firmware. Also, the code uses a register address that is free at the moment but is not reserved either. This could, even if the likelihood is admittely low, result in surprises later if the register address is used for some other function.

[daykin]

I think this can be closed, as mentioned above it will not be in stock F/W. We can maintain it as a patch for FRIB firmware.