Pre-May2016 specification proposal

This is now somewhat outdated, see the parent page for links to the updated specifications etc.

Possible hardware architecture:

We're currently thinking of using an off-the-shelf Xilinx PCIe FPGA card that has standardized expansion headers.

One option is the Kintex UltraScale Eval Board, (~3000$), or fairly equivalently the Kintex 7 Eval Board ($1695) currently used by the Neuropixel project. The cost per card seems very reasonable, it should cost another ~500-1000 for each FMC daughter card (headstage connectors, lvds drivers, power supplies, BNC breakout connectors, ADCs, isolation circuitry).

 This may or may not be part of the final system.
 

Interfaces:

Amplifier <-> breakout board: The actual plug-in (daughter) board that sits on the FPGA board could differ between applications - for instance between intan LVDS for extracellular, atlas probes, etc. , but these can all still use the same form factor and FMC daughter card mezzanine connectors, and possibly re-use much of the same firmware.

Existing standards:
Intan and open ephys are using polarized omnetics nano connectors (5 lvds pairs, gnd and vdd)
neuroseeker ?
Neuropixel ?

Requirements:
On the intan/open ephys side we should keep backwards compatibility, easily done by just adding more miso pairs to the lvds/spi cable standard.

Other I/O <-> breakout board : We'll need a standard for breakout boards for 3.3/5v level logic, and analog input/output.

Existing standards:
Open ephys uses standardized pin layout on HDMI connectors. Works well but very limited channel count
NI uses generic  68-pin VHCDI connectors and cables. Switching to this standard would allow re-use of the fairly common NI or other breakout boards/boxes and cables. These are designed to fit 4 of them on a PCI card.

Open questions:
Ideally re-usable breakout boards for different kinds of i/o (digital in/out analog in/out) - how to divide this between connectors?
How much functionality should we move off to the breakout boards? Could for instance specify a large N of channels of digital I/O via a bus expander and save connector real estate.

Breakout board <-> FPGA eval board:  For practical reasons of cable lengths and connector real estate, but also isolation requirements and data quality (ad and da separation from computer), the headstages and IO connectors might not directly plug into the FMC card that sits on or next to the fpga PCIe card in the conmputer - this means that even though VITA 57 / FMC provides a great standard for daughter boards, we might want to bring high speed digital lines out to extarnal breakout boards, as listed above.

Possible approaches:
Just use VHCDI cables (source) and bring a reasonable subset of FMC pins out to the boards - this provides maximal flexibility and could even mean that the external boards could still be plugged into the FMC connectors if desired.
Or, we could try to use some existing standard for breakout boards, but we'd potentially lose the FMC interchangeability

Hardware standards: It might be useful to standardize the formfactor of the breakout boards - there are multiple existing standards that would sidestep the need for separate case manufacturing etc.
Eurocard (https://en.wikipedia.org/wiki/Eurocard_(printed_circuit_board))
IEEE 1014-1987 (https://en.wikipedia.org/wiki/VMEbus) 

FPGA daughter board / breakout board <-> FPGA eval board: This seems to be solved by the common FMC daughter card standard.

Existing standards:
FMC daughter cards (overview) this seems to be the standard for similar projects, see for example the use of open hardware at CERN (presentation, project list)
neuroseeker ?
NeuroPixel uses FMC board on top of a Kintex 7 eval board as well.
Large existing ecosystem of FMC cards

Current status: Prototypes made (https://github.com/open-ephys/next-gen-system/tree/master/FMC-board/pcb), basic electrical testing looks good. see here for development details
 

Amplifier interface firmware <-> Data on fpga: This could be the standard currently used by the standardized intan SPI via LVDS for existing intan headstages, or some other interface for other probes.
This interface could be somewhat standardized so that the code base for common data such as auxiliary ADC/DAC/TTL in/out could be shared, or we could even split the module for headstage control/communication form another module that deal with DAC/ADC.
Once the data is on an FPGA buffer, it should adhere to a common standard.

Existing standards:
Wishbone (full specification pdf) seems like a well established standard that could serve as a base to cover most use cases
Intan rhythm, open ephys fork
neuroseeker ?
NeuroPixel ?

Data on FPGA <-> FPGA based processing: We should try to keep the data format on the FPGA stable so that developing and sharing  FPGA based processing becomes easier. At least the need to manipulate streams of sampled neural data should be pretty much the same for everyone.

Existing standards:
Wishbone (full specification pdf) seems like a well established standard that could serve as a base to cover most use cases 
Eric Burgiere's project - please fill in some details.
Francesco Battaglia, Christos Strydis, Chris de Zeeuw - please fill in some details.

FPGA clock <-> FPGA clock: Different acquisition systems should be able to synchronize. This will require one high frequency interconnect for sample times or even 'raw' clock synchronization signals, as well as a standard for configuring master/slave devices, and starting/stopping acquisition. This standard would likely be a subset of the FPGA<->API communication standard.

Existing standards:
Likely a pair of SMA connectors on the board, or back of the board (the xilinx board already has a few that might be set up well already).
We'd still need to decide on what signal to use etc.

FPGA <-> PC (firmware & API): DMA via a PCIe card seems like the most future-proof approach here, could be very standardized and re-used across different projects.
This interface could be standardized at the level of a standardized FIFO buffer as well as a basic configuration interface, so that different projects can still use the same API and software across different amplifiers.
If there is a standard interface, such as DMA via PCIe, most possible variants will share enough functionality that it should make sense to use a common API.
The biggest challenge here is that the interface needs to be flexible enough to allow two-way communication between different systems. For instance, implementing closed-loop dynamic clamp that controls current on an intan chip should look almost the same from a host perspective as driving an LED on an analog out channel of the aq. board based on LFP filtering. 
Further, we'll need configuration messages for start/stop, bandwidth etc.

Existing standards:

neuroseeker?
neuropixel is currently using ethernet for acquisition board-PC data transfer. We could fairly trivially integrate this functionality with the ability to run DMA transfers. One option that was bought up by LeafLabs was that it might be easiest to run data trough DMA but stil use ethernet for configuring the card, keeping the DMA protocol very light.

Xilinx DMA example (NWlogic)
http://www.xilinx.com/products/intellectual-property/pcie-dma.html
Pros: Example works out of the box?
Cons:  Licensing?

Xilybus
http://xillybus.com/
Pro: works already (Aaron's rhythm port)
Cons: closed, licensing likely not compatible with wide adoption

Connectal
https://github.com/cambridgehackers/connectal Looks like a pretty sane
http://www.connectal.org/doc/current/ref/ 
Pros: License looks very BSD like
Cons: looks like it supports only linux?

OpenCores pcie DMA core
basically a wrapper for the xilinx pcie core providing 2 fifos and a 40mHz control io
http://opencores.org/project,virtex7_pcie_dma,overview
Pros: Open, uses whisbone, looks fairly simple
Cons:  only recently got driver (https://github.com/lnls-dig/fpga_pcie_driver), prolly linux only for now

OpenCores PCIe SG DMA controller (scatter gather)
The design implements MAC, Physical (Xilinx Hard and Soft IP Cores) and Transaction Layer (Custom Core) of PCIe. 
http://opencores.org/project,pcie_sg_dma (github)
Also see
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5782641&filter%3DAND%28p_IS_Number%3A5782103%29%26pageNumber%3D2
Pros: comes with driver (linux only)
Cons not tested on kintex architecture, but should be portable pretty easily?

Next steps towards evaluating the PCIe hardware:

see separate page for prototype development progress