open-ephys / onix-fmc-host

FMC board to acquire from ONIX headstages and breakout boards

ONIX FMC Host

This card provides a host interface for serialized headstages and miniscopes, as well as general purpose analog and digital IO. It is a VITA-57.1 compliant module that uses high pin-count FMC connector. In combination with a base FPGA board (e.g. Numato Lab Nereid, it provides host PC communication for the following:

• Two deserailizers for any multifunction headstage conforming to the ONIX serialization protocol
• 12x 16-bit, +/-10V analog outputs or inputs. Direction selected via analog switch controllable over the FMC connector. Analog inputs are separated into 2 simultaneously sampled 6-channel banks.
• Analog output are always looped back using the analog inputs.
• 3x high speed LVDS input pairs
• 2x high speed LVDS outputs pairs
• 2x high speed, arbitrary logic-level, singled-ended Hi-Z or 50-ohm clock inputs
• 1x high speed single ended, 50-ohm clock output
• 4x MLVDS input or output trigger lines

onix-fmc-host's Issues

VITA-57 FRU requirement

According to the FMC standard, FMC mezzanine modules must provide hardware definition information that can be read by an external controller on the FMC Carrier platform (most of the time the FPGA on the carrier). We should do this for this board. More info is here:

https://wiki.analog.com/resources/tools-software/linux-software/fru_dump

https://fmchub.github.io/projects/FMC_FRU_EEPROM_PROGRAMMER/Datasheet/FMC_FRU_EEPROM_PROGRAMMER_datasheet.html

https://opalkelly.com/tools/fmceepromgenerator/

Having our host gateware read this would be a good idea as well.

Low-level hardware failure in specific computer(s)

In one specific computer, there seems to be a low-level hardware failure that can be replicated in the C program.
The computer is a pretty beefy puget systems machine, shouldn't have any intrinsic issues with power etc. The machine is also spec'd for 2 big GPUs and I replicated the issue with one GPU removed.

Steps taken to replicate:

• Use FMC host in specific PC, no external hardware needs to be connected.
• Turn on a analog io stream in bonsai (or in console app?) (could be anything but this seems to work to generate some load)
• Run the liboni-test program, set print frequency to 100.000 ( 'D' '100000'), then turn on logging ('d')
• Wait for updates to stop 😢
• If using a firmware that outputs memory usage on the FMC, read dev_idx 10, reg_addr 4, to see if memory usage keeps going up ('r' '10 4'), In my case the value keeps going up.

In another, much lower spec, PC the same FMC with the same drivers etc. ran for 2 days without issues 🤷.

Next steps: try another FMC board in the puget systems PC to see if it's a specific interaction of that FMC and that PC.

Hypotheses so far: power instability on PCIe? This would likely be a numato related issue?

PCIe bracket requires redesign

• RGB LEDs are not really visible on most computers
• Users report that that part that the screw fits into is too thick for most computers
• The labels are very difficult to read