Delay BGo Signals before use

[dinyar]

Currently we use the BGo signals from TCDS immediately, however they should be delayed by approximately the master latency when used to reset counters etc.

[dinyar]

This will require additions to the uGMT cell.

[dinyar]

Commit 23d1d43ce3a5477b319e790d928e93c53913d561 belongs to this. @thomreis The required BGo delay is now something closer to the master latency (~39 BX).

[thomreis]

What needs to be changed in the cell?

[dinyar]

We'd need to set the register

  <node id="bgo_delay_reg" address="0x8000004" description="Register to set delay (in bunch crossings) for BGo signals." fwinfo="endpoint;width=0">
      <node id="bgo_delay" mask="0x3f" />
  </node>

To a certain value. Ideally this value would be derived from the master latency (i.e. master latency +/- N), but if it's a separate value that's fine too.

[thomreis]

OK, so we need a new command to set this. It can take two parameters: masterLatency and offset/deviation. For masterLatency we can reuse the value that is already present in the configuration.

[dinyar]

Yes, that would be perfect! Thanks!

On Wed, Apr 13, 2016 at 3:55 PM Thomas Reis notifications@github.com wrote:

OK, so we need a new command to set this. It can take two parameters: masterLatency and offset/deviation. For masterLatency we can reuse the value that is already present in the configuration.

— You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub https://github.com/dinyar/uGMTfirmware/issues/344#issuecomment-209452854

[thomreis]

For when do we need this?

[dinyar]

It would be good to have it sometime next week if possible, then we have time to fix the timing. It's not incredibly urgent because I initialize the delay to the master latency at reset.

[thomreis]

Which address table file is this register in?

[dinyar]

(answered via side channel, here for reference:) it's in mp7_payload.xml

[thomreis]

The masterLatency is currently given in frames (e.g. 235 for uGMT). I understand that you want the BGo delay in BX since otherwise the mask 0x3f would be too small as well. How should masterLatencies that are not multiples of 6 be handled?

[thomreis]

I assume also that the BGo delay can never be negative.

[dinyar]

Yes, right. I'd suggest flooring the result of the division. If we "undershoot" we can add one BX in the offset field.

Yes, it can never be negative. Actually it also can't be less than 5 BX, however in the firmware I protect against the situation already (i.e. if a value less than 5 is in the register I disregard it and assume the minimal delay). This shouldn't have any effect in the real world as we're always "far enough" away from TCDS to never need such a small delay.

[thomreis]

The command setBGoDelay is in the trunk but not deployed at P5 yet. Will do this once the new FW is deployed as well.

[dinyar]

In the current implementation we delay the BGOs vs. the data stream. We however require the BGOs to arrive early vs. the data stream. This should be possible to achieve by delaying the BC0 by ~(3564-master latency) and adjusting the bunch counter by the same value.

[dinyar]

The current implementation of the delay causes synthesis to take more than a day. We should fix this.

[dinyar]

Will try to use dedicated FIFOs for the BGO word and the bunch counter for each clock region (should require ~2_4_9 block RAMs).

[dinyar]

Currently implemented alternative:

• Use offset when calculating expected bunch crossing number for error counters
• Generate BC reset signal at correct time based on offset from orbit length

[thomreis]

Online SW setting the BGo delay offset (command: setBGoDelayOffset) is ready to be deployed.