[NEED HELP] Fast Connection FPGA-PC

[raultricking]

Hi guys, im new at this forum, first of all, thanks for the support :)

im writing here because i want to send data from an nexys 4 ddr FPGA to my computer. i have tryed with UART, MATLAB FPGA DATA CAPTURE ... but i need a very fast connection that allows big ammounts of data to transfer:

i have 4 microphones connected to the fpga, sampling frames of  18 bit at 40kHZ, and i need to record sound and send it to the pc, or directly send it in real time. 

Hope you guys can help me because im stuck in this proyect and i need to solve this!! ?

[PhDev]

Hi @raultricking

I think you should look at these FPGA Ethernet Cores. The cores includes everything you need for Ethernet like TCP/IP, UDP, DHCP and so on.

The cores also have remote boot flash programming and an internal logic analyzer.

There is an example using your board. You will be up and running in minutes ? 

[xc6lx45]

You can probably make this work with UARTs if you use FTDI's own API (not Windows serial).

If I remember correctly, they support officially 3 MBit/s and inofficially a lot more. You need 2.88 MBit/s plus protocol overhead.

The same standard FTDI chip (e.g. .FT2232H) will give you up to 30 MBit/s through its MPSSE (high speed serial) mode. It's easier to connect one externally (e.g. "FTDI mini module" for $20) to the FPGA than to use the on-board FTDI chip of most boards. The latter is feasible (you have to go through the JTAG port) but the external-chip option is much easier to bring up.

If you're after continuous (not burst) capture, setting up a PC for reliable real-time audio is a topic of its own...

[zygot]

I'm not sure if you have a good answer yet or not so I'll add my 2 cents.

Let's see 4 channels of 40 KHz signal with 18-bit resolution: If you do the minimal sampling rate that would be a 4x18x80000 = 5.76 Mb/s continuous data rate. ( I'm assuming that your application can't take advantage of a sub-sampling approach; that is you are processing signals with a  40 KHz bandwidth of interest. If you were doing doppler processing your data rates could go way down though your analog front end complexity might go up considerably) This figure assumes that you are packing samples as efficiently as possible into byte or word sized chunks. [edited] It also assumes that you have 0 overhead in the data stream. There are a lot of good reasons for having some overhead in your data stream. Your board has a 100 Mb/s capable Ethernet PHY so that would appear to be sufficient. Of course you will never get close to that using a normal TCP/IP stack on a PC for a variety of reasons apart from packet overhead. Still, a coarse analysis would be that you have a good chance of success taking @PhDev's advice. You can do better abandoning typical packet structures but that's not a side project for someone in a jam. (I'd have started with data transfer rates, but then again I probably have more experience here ). Another place to look for Ethernet data transfer is in the Project Vault. There's at least one suitable for your board in there. Streaming continuous data to a PC is always more complicated than transferring discontinuous sets of data.

720 KB/s data rates are in the range for a board with an 8-bit USB 2.0 interface ( you can always stuff zeros into the data stream to bump up the data rate though the best way would be to just not worry about packing samples into as few bytes as possible ). I suspect that you are already using all of your PMOD pins so adding an external FTDI device is likely not an option for you. You don't mention if you are restricted to a particular board for your project. Digilent offers quite a few with a fast USB 2.0 interface. In the end, from my experience, this would be the easiest and quickest path to solving the data transfer part of your project. NOTE: Underestimating the PC software effort is almost a certainty, especially if you are starting from scratch.

@xc6lx45's suggestion might be a good option if you have the spare IO to add another interface. You'll have to so some work to get it operational though FTDI has a number of helpful application notes and sample designs to help with that effort. I agree with his advice to use FTDI drivers even for UART applications. Using an MPSSE capable device will require that approach.

For someone in a bind, I'd suggest trying to concentrate on the project elements rather that venture into too many unknown adventures. even when you've done something similar for other projects taking that experience and translating it into a different project isn't always a straight forward venture ( I know this from personal experience )

My rule of thumb for technology companies who want to stay in business to limit the aspects of a time sensitive design project to 1 totally new effort ( better yet invest in new design efforts as an overhead cost of business so that when you want to incorporate this knowledge into a new product you already have a head start ). Trying to complete multiple design efforts for which you have no experience is a good way to break budgets, deadlines, and careers.

[zygot]

Oh, I forgot to mention. While I did address narrow-band processing as opposed to wide-band processing I want to mention another system level design choice. If you can do any processing in the FPGA that reduces the overall data rate to a PC then a simple UART at 921600 might be feasible. I'd always opt for the lowest data rate possible, simplest data interface, lowest latency, and simplest software effort given the constraints of a project time-line and my expertise. I can't help you that.

I am extrapolating from your post that you want to do all of your processing in MATLAB which might constrain your data acquisition options.

[D@n]

@raultricking,

One item I haven't seen mentioned yet is to use a mex file to help with the Matlab ingest.  Basically, matlab allows you to compile and build your own matlab functions in C/C++ to get the speed of the lower level interface without needing to fight with the parser.  The resulting file is a mex file that Matlab will run as its own command.  Even better, using this approach you can still maintain access to all of your favorite matlab internals.  Hence, if the FPGA side of your interface will work but not the Matlab side, then this is where I'd dig to find the problem.

Following @zygot's advice, though, I wouldn't start here, but I might end up here.

Dan