Think of a way to tell the TCP server what 1 clock tick is

[thomascobb]

No description provided.

[thomascobb]

Add a dedicated *REG register that counts the currently configured fabric clock for 1 second (using a fixed frequency reference clock) which can be used by the server

[coretl]

But this is constantly changing, how can we use this to format TIME fields?

[coretl]

Maybe add a special star command *TIMEBASE? for this, could be set in state so this persists. Would have to walk through all the time fields and update them if it changed

[tomtrafford]

This is required for the 3.0 release. I will organise a discussion about this.

[tomtrafford]

2 new:

• *CLOCK.TARGET (User specified clock frequency)
• *CLOCK.ACTUAL (Measured clock frequency)

in *REG (Mirrors of SYSTEM registers)

• CLOCK_TARGET
• CLOCK_ACTUAL

The .state file will need to store time field values in RAW

[Araneidae]

Comments from a discussion with @coretl:

• Let's just have the one extra *REG register, NOMINAL_CLOCK. This is maintained by the FPGA to report the clock that is to be reported to the user. The server isn't going to worry about how truthful this is. This will be polled at, perhaps, 1 Hz.
• The clock frequency can be interrogated via *CLOCK_FREQ? ... what units does this report in? Let's say Hz with integer resolution.
• When this frequency changes the server should(?) internally trigger a *CHANGES.CONFIG=S event to reset change reporting for fields that may have changed.

Separately we discussed changing the ext_out SAMPLES field from CAPTURE_MODE_UNSCALED to ..._SCALED32.

[coretl]

After a conversation with @EdWarrick we wondered if changing ext_out SAMPLES to GATE_DURATION might be more descriptive at the same time as changing it from UNSCALED to SCALED32. Thoughts?

[Araneidae]

That seems a reasonable idea.

I'm tempted to suggest that this name change is only made in the field name, so that the PCAP entry in config changes as follows:

-    SAMPLES          ext_out   samples
+    GATE_DURATION    ext_out   samples

In particular, this means that this name change isn't part of the server, and we just need the following diff in PandABlocks-FPGA:

diff --git a/modules/pcap/pcap.block.ini b/modules/pcap/pcap.block.ini
index 54d137d3..dcd184cd 100644
--- a/modules/pcap/pcap.block.ini
+++ b/modules/pcap/pcap.block.ini
@@ -43,7 +43,7 @@ description: Timestamp of last gate high +1 in current capture relative to enabl
 type: ext_out timestamp
 description: Timestamp of capture event relative to enable
 
-[SAMPLES]
+[GATE_DURATION]
 type: ext_out samples
 description: Number of gated samples in the current capture
 

Though hmmm... what about the description now?

[Araneidae]

Ok, I will add a new register *REG.NOMINAL_CLOCK at register offset 24 with the following definition:

If this register is non zero the value returned will be used as the reported clock frequency in Hz, otherwise the standard frequency of 125 MHz will be reported and used.

[coretl]

Though hmmm... what about the description now?

How about "Total duration in seconds that GATE was high for each capture"

[Araneidae]

The problem with this is that the unscaled value is simply number of samples, as before!

[coretl]

I think that it's still fine, the scaled value is what they are requesting to capture, if they choose to get it unscaled they see the raw number of samples and the scale factor to turn it into time in the header

[Araneidae]

This should now be addressed by a number of pull requests:

• PR Change ext_out samples from unscaled to scaled #41 changes scaling of samples
• PR Rename SAMPLES to GATE_DURATION PandABlocks-FPGA#155 renames SAMPLES to GATE_DURATION
• PR Use new *REG.NOMINAL_CLOCK register to define clock frequency #42 uses new *REG.NOMINAL_CLOCK frequency register
• PR Update common/templates/registers_server to match current server version PandABlocks-FPGA#156 adds *REG.NOMINAL_CLOCK to FPGA

Outstanding related issues are:

• Issue Server persistance state should be using RAW values where possible #39 is needed so that the saved duration is seconds is retained over server restarts, even if the clock frequency is changed.
• Issue Add *changes step when timestamp changed #40 is wanted so that changes to reported clock frequency can be seen.

[Araneidae]

This should now be closed by merge 19f58f6.