cms-gem-daq-project / optohybridv2 Goto Github PK

Using firmware version: optohybrid_top_16-06-2016.bit
Using Web DAQ
Clock Source: GTX recovered clock
Sequence: Start all VFATs -> Apply Default Parameters -> Threshold scan on VFAT12. First attachment (VFAT12_ThreshScan_FW_16-06-2016.png)

Notice long tail in threshold scan distribution

Using firmware version: optohybrid_top_23-03-2016-I2C.bit
Using Web DAQ
Same clock source as above
Same sequence as above
No tail in threshold scan for VFAT12. See second attachment (VFAT12_ThreshScan_FW_23-03-2016)

Is the I2C clock running when it shouldn't be in the optohybrid_top_16-06-2016.bit firmware? Note this firmware has the expanded SBIT functionality for the cosmic stand.

Using firmware version: optohybrid_top_16-06-2016.bit
Clock source: GTX recovered clock.

Sequence: Start all VFATs -> Apply default parameters to all VFATs
Use VFAT2s I2C to set VThreshold1 = 255 for all VFATs

Using 2 oscilloscopes to monitor output copper SBIT singles from HDMI-to-LEMO card

Tektronix (TK) Scope
J3 -> CH1
J1 -> CH2
J4 -> CH3
J5 -> CH4

R&S Scope
J6 -> CH1
J7 -> CH2
J8 -> CH3
J9 -> CH4

For "TDC SBit Mode" = Single VFAT2


No DC offset observed in waveforms

For "TDC SBit Mode" = iPhi sector
Large DC Offset observed on Channel 1 & 4 (J6 & J9) of R&S scope

For "TDC SBit Mode" = iEta sector
Large DC Offset observed on Channel 4 (J5) of Tektronix (TK) scope

Since thresholds of all chips in these three cases were set to 255 believe this is a problem in the output baseline voltage. Having this DC offset change depending on output SBIT mode is not desired. Can it be fixed to by 0V (as in the Single VFAT2 mode)?

Due to the OH we have in 904 constantly resetting, some extra debugging would be probably useful.
Having a timer that counts the number of seconds since the last time the FPGA reset would probably be the simplest, most useful thing that can be monitored intermittently.

There are two sources of mismatch between the OTMB and OH.

1st question: How do we group the 8 clusters into a packet?

OTMB is using:
packet0 = cluster3 & cluster2 & cluster1 & cluster0
packet1 = cluster7 & cluster6 & cluster5 & cluster4

OH is using:
packet0 = cluster0 & cluster1 & cluster2 & cluster3
packet1 = cluster4 & cluster5 & cluster6 & cluster7

I'm somewhat partial to the OTMB method because cluster0 is in bit0, which seems nice, but either one is fine as long as we agree. Could even do:

packet0 = cluster0 & cluster2 & cluster4 & cluster6
packet1 = cluster1 & cluster3 & cluster5 & cluster7

The 2nd question: what order do we transmit the packets's frames (each packet is split into 4 separate frames).

The OTMB is using:

frame0 = packet[7:0] & FRAME_SEP;
frame1 = packet[23:15];
frame1 = packet[39:24];
frame2 = packet[55:40];

The OH is using:
frame0 = packet[55:48] & FRAME_SEP;
frame1 = packet[47:32];
frame1 = packet[31:16];
frame2 = packet[15:0];

I'm again somewhat partial to the OTMB method because bit0 is in frame 0, which seems nice, but again I don't think it really matters as long as we agree on something.
It should be easy to change on either end.