Support the CAENels FMC-Pico-1M4

[coretl]

@Araneidae is writing support for this, and it looks like it would be useful on beamlines to have support for this as it is substantially cheaper than a TetrAMM and we could synchronize it easier

[Araneidae]

The manufacturer's documentation can be found here: FMC-Pico-1M4.

The interface to such a block should be pretty straightforward. First of all, we need a name; how about FMC_PICO_1M4? Next, we need some fields:

Name	Type	Description
START	bit_mux	Initiates capture if ADC is idle and START = 1. Note that if START is held high then capture will free run at approximately 850kHz.
STROBE	bit_out	Single tick pulse high marks completion of ADC capture and start of valid data. This will be strobed somewhere between 1.1 and 1.2 µs after capture is initiated.
DATA1, DATA2, DATA3, DATA4	pos_out	ADC captured data. These values are 20 bits.
GAIN1, GAIN2, GAIN3, GAIN4	write enum	Select between high and low gain for each input channel.

Is this interface compatible with other similar blocks? Do we care that START is only sampled when the ADC is idle? Is a single clock data strobe suitable for other applications? Do we put the valid data bits in the top or the bottom bits of the 32-bit position (sign extended as appropriate)?

Note that the ADC capture frequency is somewhat unpredictable if allowed to free run, and it is probably better to use a clock of known frequency (less than 850 kHz) to drive START. Note also that the front end to this ADC has a built in 25kHz filter, so high sample frequencies are unnecessary.

[Araneidae]

One implementation complication is worth noting. The FMC readout must be clocked at a predictable frequency (over SPI) and so must be driven by a clock with a known frequency. The current design of PandA now allows for multiple master clock frequencies, and the master clock at 125 MHz is a little slow if we want to drive the FMC at its highest capture frequencies. Therefore we should probably use a fixed higher speed clock for the FMC interface. I believe we already have a 200 MHz reference clock in the design, this would be suitable.

Note also that each channel of the ADC has calibration information giving scaling and offset measurements for each channel in each gain. This can be read from the IPMI EEPROM in userspace, but at present we have no mechanism for communicating this information back to the firmware. Implementing this functionality may be more difficult.

[coretl]

The current ADC block takes a different approach, it is always capturing at 1MHz (I think it has a 200kHz low pass filter internally), then the value is captured and averaged by PCAP. The thought is that the clock rate is high enough with respect to the trigger rate (10kHz max) that we don't need to synchronize the clock rate, and can rely on synchronized signals to PCAP to give us Min/Max/Mean that corresponds to a single detector frame.

Do you think the same approach would work here?

For parameter naming, we use GAIN1..GAIN8 enums: https://github.com/PandABlocks/PandABlocks-FPGA/blob/f67231e2dead9e8a47f4de5bb14d00d6747bbb1f/modules/fmc_acq427/fmc_acq427.block.ini#L12-L20

And VAL1..VAL8 for data: https://github.com/PandABlocks/PandABlocks-FPGA/blob/f67231e2dead9e8a47f4de5bb14d00d6747bbb1f/modules/fmc_acq427/fmc_acq427.block.ini#L92-L96

The output is so 32-bit full scale gives +-10V VAL. Each step in GAIN shifts the output by one place, so the 5V gain will produce +-5V VAL

[Araneidae]

Unfortunately we can't predict the actual gains for high and low gain for the FMC-Pico-1M4 as this will depend on the ordering options selected (high gain can range from 1 to 110 µA full scale, low gain from 0.5 to 20 mA full scale!) Guess we'll have to name the GAINx options "Low" and "High".

Regarding free running operation I suggest tying START=1 and just ignoring STROBE if not wanted.

For a first version I suggest we don't worry about reading calibration settings yet.