2
\$\begingroup\$

I'm doing this project called "High data rate logger".

The requirements for this project is to sample the 2 analog signals simultaneously.

  • 2x channel 14-bit ADC
  • Store 60 MSps (mega samples per second), which is roughly 250 MBps sustained write speed
  • Storage medium must be able to accommodate 500 GB to 1 TB worth of data

Storage medium:

M.2 PCI-Express is the latest interface for SSDs (solid state drive). But I am not sure if I can interface an SSD to FPGA through PCIe 2.0 x4 (PCI express generation 2, with 4 lanes) Interface, because of its complications.

A host that can interface with the above cards:

Since I am not able to find a processor which has parallel LVDS input lines to be interfaced to ADC, I am thinking to proceed with an FPGA.

But at the other end I have to interface a storage medium like SSD,or SD cards, or NAND flash memory or any other possible solution.

There are many solutions for storage medium with required memory as well as speed. But the problem is interface. Some common memory interfaces are: PCI express, SATA III (6Gbps), SD card interface, etc.

Therefore I would request anybody to suggest which interface would be feasible, easier and better to interface using FPGA.

If an appropriate standard interface is selected, I could go ahead with selecting an FPGA and designing a data logger.

\$\endgroup\$
  • 1
    \$\begingroup\$ Build the ADC+FPGA into a PCIe card (this sort of thing is available off the shelf) and put it in a PC. Have software transfer from memory-mapped PCI to disk. You may want to compress data on the card to save bandwidth and storage. \$\endgroup\$ – pjc50 Sep 18 '14 at 9:44
  • \$\begingroup\$ There are cards that have similar requirements already, such as the Noctar SDR. \$\endgroup\$ – Simon Richter Sep 18 '14 at 9:59
  • 2
    \$\begingroup\$ I've spent a significant amount of time writing software that talks to a fancy usb-3 spectrum analyser. I can save a raw datastream at 140 MBytes/sec to a SSD in python. Using a PC for this sort of thing is very much a good idea, and it should be very viable. \$\endgroup\$ – Connor Wolf Sep 18 '14 at 11:35
  • \$\begingroup\$ Also, USB-3.0 is an option here as well. That would be much more plug+play then PCI-e, though the driver development may be more involved. \$\endgroup\$ – Connor Wolf Sep 18 '14 at 11:37
  • 1
    \$\begingroup\$ @pjc50 I don't think I can use a PC in order to store the data on SSD. Actually, this entire system goes on Flight. It should be as compact as possible. \$\endgroup\$ – Vicky Sep 22 '14 at 9:15
2
\$\begingroup\$

We've just built a logger with a data rate of that order of magnitude. The data are captured on an FPGA and then sent over to a PC using USB3.0 which then writes it to disk.

Assuming your logging latency is not critical (which it usually isn't) I imagine you could do the same.

If you use an Opal Kelly FPGA board, the HDL interfaces and driver development are very straightforward. I have no connection other than as a satisfied customer!

Alternatively, using a PCIe plugin card with the Xillybus driver provides another straightforward HDL and driver experience. 250MB/s is pushing it for a single lane of PCIe, but as you say a x4 interface will be OK.

Or the full-custom approach of building it all from scratch is of course open to you if you have time, but no money. I'd still build something to interface to a PC though, rather than trying to go direct to disk from the FPGA.

\$\endgroup\$
  • \$\begingroup\$ Xillybus driver is very expensive. I would prefer building it from scratch. For building it from scratch I would like to know which interface would be less complicated: 1) FPGA-SSD : PCIexpress 2) FPGA-SSD : SATA III 3) FPGA-SD Card : SDXC and SDXC-I (UHS-I) 4) FPGA-SD card : CompactFlash or any other recommended solution??? \$\endgroup\$ – Vicky Sep 22 '14 at 14:46
  • \$\begingroup\$ What do you mean by building from scratch? You want to write your own IPs for SATA and SDHC? \$\endgroup\$ – FarhadA Sep 23 '14 at 9:43
  • \$\begingroup\$ @Vicky "which interface would be less complicated"? - FPGA-SSD (SATA III) is a straight forward implementation if you have a working transceiver/physical layer. The command layer is a ATA8 command set which only needs to implement a hand full of commands, the other commands are outdated, for compatibility or for CompactFlash or ATAPI devices. The transport and link-layer FSMs are given in the SATA standard and can be reduced if you spare some features. But the physical layer is hard to debug and need good skills in FPGA and multi clock domain design. \$\endgroup\$ – Paebbels Sep 26 '14 at 18:42
  • \$\begingroup\$ @Vicky FPGA-SSD (PCIe): I don't know any FPGA dev. board or ext. board which connects a FPGA to a SSD by PCIe (SATAe, M.2) => so there is no test system. I'm not even sure if M.2 SSD cards use the PCIe link. PCIe IPCores can be created by core generators form FPGA vendors, which generate usable code, but you have to write the very complex transaction layer (credit based flow control, reordering, ...), a DMA engine and a command layer on top of this. In contrast to SATA, I think you can't spare so many features to reduce implementation work. \$\endgroup\$ – Paebbels Sep 26 '14 at 18:51
  • \$\begingroup\$ @Vicky FPGA-SD card (CF): Who want's to implement a legacy protocol? CompactFlash is IDE. Or do you mean CFast? - This is also SATA for the compact flash form factor :) \$\endgroup\$ – Paebbels Sep 26 '14 at 18:54
1
\$\begingroup\$

Alternative strategy: build your own mass storage device.

Have the FPGA write directly to a collection of NAND Flash chips. Don't forget the readback-and-verify phase! You should also be able to arrange to pre-erase the entire array before starting capture (erase is slower than write), and keep your own badblocks list. You can write to multiple chips in parallel if this is required for the write bandwidth. Again, I strongly recommend some form of compression; gzip is suitable for streaming and is lossless.

You can then present a USB interface to a PC which exposes the entire capture as a block device, or a filesystem containing a single "magic" file for the entire capture.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.