This page is meant as a working document to spec out the requirements and specifications for the next iteration of hardware interfaces for electrophysiology.
see separate page for prototype development and some documentation
see the github repository for all design and source files.
...
The whitepaper provides a good introduction to the full standard proposal.
basic overview of the components that are defined in the standard. Data sources, and software are not defined, or constrained by the standard.
Aims:
Higher channel count: >1000 channels sampled at >=30kHz, (1024 channels at 30kHz at 2 byte/sample is ~62MB/s)
Low latency: ~1ms, ideally capable of <1ms round trip to and from host PC, so that higher level languages can be used for closed-loop experiments. If we want to target dynamic clamp applications we should aim for a <50us loop capability.
Flexibility: Should be as modular and expandable as possible.
Cross platform: At least Windows and Linux, future move to RTOS should be considered.
Open Questions
What PCIe driver can be used long-term?
We currently use xillybus, which works amazingly well but has two potential downsides:
- not clear how far it is compatible with RTXI like latencies
- closed source, could become a problem down the road
- not easily commercially usable for small companies due to license
We already defined an API that makes switching between interfaces much easier, but this should be resolved asap.
One of the options would be to outsource the development of a driver and firmware - likely expensive and not totally clear on what license we'd get.
Definitely check what the CERN cards use.
Outsource
- Fee for service company, like tier one?
- check if xenomai could do it? Thye already have the RTOS part covered
Existing standards:
EPEE
EPEE is an efficient and flexible host-FPGA PCIe communication library. EPEE suports various generations of Xilinx FPGAs with up to 26.24 Gbps half duplex and 43.02 Gbps fullduplex aggregata throughput in the PCIe Gen X8 mode (tested in Xilinx VC707 evaluation board).
http://cecaraw.pku.edu.cn/Eng_EPEE.html
Riffa
link > Riffa, ( github.)
Pro: cross platform
Cons: ?
Xillybus
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 wishbone, looks fairly simple
Cons: only recently developed a driver (https://github.com/lnls-dig/fpga_pcie_driver), probably 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 progressOur PCIe based acquisition system is ONIX, see documentation here: https://open-ephys.github.io/onix-docs/