[feature request] Expose low level SCA functionality

[jsturdy]

Brief summary of issue

This feature will allow low-level functionality of the SCA to be exposed in the SW.

• readback/control of the ADC
• control over I2C of resets
• other possibilities
  • control of the SPI interface?
  • control of the GPIO interface?
  • control of the JTAG interface? (probably not)
  • control of the DAC interface?

Types of issue

• [x] Feature request (request for change which adds functionality)

[evka85]

I think these functions would be nice to have available via RPC:

• readback/control of ADC
• control of GPIO -- this is used to control the FPGA and VFATs resets

I would say that JTAG and SPI are not that critical, but may be nice to have. The SPI interface is only used to talk to the VTRX/VTTX, and actually we haven't used it before because normally it's not necessary to change the VTRX/VTTX parameters, but the idea is that with radiation the laser driver may degrade and in that case it may be necessary to increase the laser driver modulation current to improve the signal. I2C channels 1 and 5 are connected to the VTTXs. JTAG is mostly a debugging tool I would say and I think it would be best if this is not used during operation, because we've seen some strange problems in CSC when accessing JTAG during operation. For debugging one can always just use the python script, so this is not critical. Possible uses are: reading sysmon, and loading firmware, although these functions can be done in other ways: sysmon can be read in OH firmware and then through the OH slow control, and the firmware can be loaded through the PROMless method.

Other SCA modules like SPI, DAC are not used on our OH (disconnected), and are therefore disabled in the SCA configuration. Actually I2C is also disabled by default, so if you want to play with it you'll have to enable it by writing to CRB, CRC, CRD control registers. This can be changed in the CTP7 firmware such that they are enabled by default

[jsturdy]

I think these functions would be nice to have available via RPC:

• readback/control of ADC
• control of GPIO -- this is used to control the FPGA and VFATs resets

OK, sounds good!

The SPI interface is only used to talk to the VTRX/VTTX

I assume from context you meant I2C here?

OH firmware and then through the OH slow control

Right, this is already done, so I don't see a reason to duplicate this functionality through the SCA, unless there is a performance benefit...

Actually I2C is also disabled by default, so if you want to play with it you'll have to enable it by writing to CRB, CRC, CRD control registers. This can be changed in the CTP7 firmware such that they are enabled by default

From an (your) operational point of view, is it better to have this disabled, and only enabled when it's in use? That would be a reason I could see for not changing the FW.

[jsturdy]

Example ADC routines from @evka85 via initial email:

For SCA v2

writeReg(getNode('GEM_AMC.SLOW_CONTROL.SCA.ADC_MONITORING.MONITORING_OFF'), 0xffffffff)
sleep(0.1)

        for ch in range(32):
            sendScaCommand(ohList, 0x14, 0x50, 0x4, ch << 24, False)
            results = sendScaCommand(ohList, 0x14, 0x02, 0x4, 1 << 24, True)
            for oh in range(len(results)):
                res = (results[oh] >> 24) + ((results[oh] >> 8) & 0xff00)
                if (res > 0xfff):
                    printRed("ERROR: ADC returned a reading above 0xfff!!")
                res_mv = ((1.0 / 0xfff) * float(res)) * 1000
                print "Channel %d OH %d: %d counts (%s) = %fmV" % (ch, oh, res, hex(res), res_mv)
            sleep(0.001)

For SCA v1

writeReg(getNode('GEM_AMC.SLOW_CONTROL.SCA.ADC_MONITORING.MONITORING_OFF'), 0xffffffff)
sleep(0.1)

        for ch in range(32):
            sendScaCommand(ohList, 0x14, 0x30, 0x4, ch << 24, False)
            results = sendScaCommand(ohList, 0x14, 0xb2, 0x4, 0, True)
            for oh in range(len(results)):
                res = (results[oh] >> 24) + ((results[oh] >> 8) & 0xff00)
                if (res > 0xfff):
                    printRed("ERROR: ADC returned a reading above 0xfff!!")
                res_mv = ((1.0 / 0xfff) * float(res)) * 1000
                print "Channel %d OH %d: %d counts (%s) = %fmV" % (ch, oh, res, hex(res), res_mv)
sleep(0.001)

Channel map

channel 27: AVCCN (FPGA MGT 1.0V)
channel 30: AVTTN (FPGA MGT 1.2V)
channel 17: 1.0V_INT (1.0V FPGA core voltage)
channel 14: 1.8V (used by the PROM)
channel 24: 1.5V (used by the GBTXs and SCA)
channel 15: 2.5V (used by FPGA I/O and VTRXs/VTTXs)
channels 0, 4, 7, 8 are connected to temperature sensors

• To read those temperature sensors, the SCA ADC current source has to be enabled

@evka85 from the SCA manual I don't understand this part of the routine you listed:

• res = (results[oh] >> 24) + ((results[oh] >> 8) & 0xff00)

At least for the 0x02 transaction type, which states (p53) that the 12-bit return data is found in D[11:8] and D[7:0], is the GEM_AMC firmware (register GEM_AMC.SLOW_CONTROL.SCA.MANUAL_CONTROL.SCA_REPLY_OHN.SCA_RPY_DATA) chopping this up in a way that is not described in the gem_amc_top.xml address table (it doesn't mention any special handling)

[bdorney]

I would propose that this functionality is used to update/re-write the current sca monitoring tools that exist, for example:

https://github.com/cms-gem-daq-project/ctp7_modules/blob/360913c693ae4caa11ed20626bf6cd9595f392db/src/daq_monitor.cpp#L368-L491

Or if the plan is for this new function to go under include/amc/sca.h and src/amc/sca.cpp then I think that new PR should also update getmonOHSCAmainLocal() to use this routine so that the correct values can be reported.

[jsturdy]

Agreed, this functionality should become part of the amc module, but can be compiled/linked into functions in the monitor library as needed. As there is this implementation already, the implementation of the core should ensure to update what @bdorney points out.

[jsturdy]

HDLC

Quick clarification for @evka85: To confirm, for the TX command, if we want to send data as 0xbeef, no action is necessary on the software side to ensure that the byte ordering is correct, yes? TX: [trn ID][ch][len][cmd][data] TX: [0:7][0:7][0:7][0:7][16:31][0:15] Or are the bit reversals covered by the FW during the HDLC transmission (and reception as below)?

However, for the reply, what is stored in the SCA_RPY_DATA register is claimed in the manual to be [16:31][0:15], though from our conversation, I had understood that your understanding is that this is: [7:0][15:8][23:16][31:24] (possibly because of some bit reversal handled in the FW, as hypothesized above) RX: [trn ID][ch][err][len][data] RX: [0:7][0:7][0:7][0:7][16:31][0:15]

[jsturdy]

First bit received from the SCA HDLC frame goes into bit 0 in the processing unit, so the reversal of bits is handled. Byte ordering is done as described in the FW, could be changed, if necessary for maintenance/simplicity.

[lpetre-ulb]

Implemented in the GitLab repository.