Jump to content
  • 0

Sending data from Nexys 4 DDR to PC


deltaepsilon3

Question

Hello,

I have a Nexys 4 DDR FPGA, and I want to send data from the FPGA to my PC. The problem is, I am collecting the data (an external signal) at 100 kHz, and UART is too slow to send that in real-time. (To clarify, sending data in real-time is not necessary, but see my second point.) I have two ideas, both of which I am struggling to implement.

1. Ethernet is fast enough to send the data in real-time. However, since I am quite new to FPGAs, I am having trouble with using the Ethernet protocol. I tried following https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-4-ddr-getting-started-with-microblaze-servers/start, but I don't want to implement an entire microcontroller, and it seems difficult to connect it with other VHDL code that I have.

2. I am also considering collecting some data beforehand, then sending it through UART. However, I need to collect at least four seconds of data before sending, and I don't know how to store that much data on the FPGA. I looked at https://reference.digilentinc.com/learn/programmable-logic/tutorials/nexys-4-ddr-sram-to-ddr-component/start for more memory but couldn't find any example code or figure out how to make it work.

Does anyone have any pointers for how I should proceed? Is there any alternative for fast communication between the FPGA and a PC?

Link to comment
Share on other sites

6 answers to this question

Recommended Posts

Hi deltaepsilon3,

You can talk directly to the Ethernet interfaces - here is something for the Arty Board, showing the level of complexity needed

http://hamsterworks.co.nz/mediawiki/index.php/ArtyEthernet

For Gigabit Ethernet it is much the same

http://hamsterworks.co.nz/mediawiki/index.php/GigabitTX

With a bit of experimentation you can replace the data payload with your samples, and implement some form of flow control (so you only send packets when you have data to send.

Mike

Link to comment
Share on other sites

@deltaepsilon3,

Have you considered the debug-bus approach?  I blogged about it recently at zipcpu.com.  If you are a Verilog type, or if you want to be able to simulate your entire design apart from your hardware, you should be able to use the code immediately just about as is.  That will allow you to communicate with your device over UART.  The example program also hooks a block-RAM based scope on board.  Depending upon the number of bits you need, that should at least get you longer than a second.  Not sure if you can get to four seconds with it.

If you want to go for SDRAM, you can still hook the wishbone bus within the debug-bus project to an AXI4 DDR3 MIG SDRAM using a wishbone to AXI bridge, much as I did in my OpenArty distro.  Incidentally, that distro also offers a 10/100 ethernet controller within it that should probably work with the Nexys 4 DDR too (I haven't checked).

@hamster,

Thanks for your Ethernet example, by the way.  While I couldn't use it (I wanted my controller within Verilog, working from a wishbone bus), your example helped me work through some of the struggles I was having.

Dan

Link to comment
Share on other sites

Gentlemen,

As to using Ethernet to send data to a PC. The example that @hamster presents is a good start but if you want to send/receive meaningful data isn't complete. His demonstration uses Wireshark to view packets. This is nice, but hardly a complete solution. What OS you plan on using, what application you want to use, etc.  add complications for gathering and processing your data. If you are doing this on your own you will find that there are a lot of packet types that you may have to deal with; unless you are using MATLAB.  I'm not arguing against using Ethernet but you will have to do some work. There are a number of MAC-less projects in the Project Vault to help with this, including a nice MATLAB oriented example.

The USB-UART bridge on your board should be able to handle up to 3 Mbaud which, not having to deal with the overhead of Ethernet packets, is a fairly competitive option. Python can make building an application pretty easy. You mention that "real time" data collection is not a requirement. Again, there are projects with examples right in the Digilent Project Vault that will get you going quickly.

Link to comment
Share on other sites

@zygot,

So true, so true.

That's why I put a program together here, as part of the OpenArty project, to handle ICMP and ARP and allow the board to be pinged.  It just ... requires a ZipCPU. :D  UDP shouldn't be much harder, I just haven't done it (yet).  So much on my plate ....

As for 3MBaud, I think your estimate may be a touch low.  I've routinely run 4MBaud through the USB-UART link on my Basys3.  I think I even looked up the spec sheet on the FTDI part to suggest it would support 12MBaud (1.2MBytes at 8bits per byte, no parity, 1 stop bit), but I've never run it that fast.  The OpenArty project only runs the serial port at 1MBaud, mostly because of the timing requirements of the memory.  (The UART controller's clock is tied to the system clock, which is defined by the MIG generated memory clock--although it doesn't need to be, it's just how I did it.)

On the other hand, if you could compress the data, you might just manage to get that working in real time.

Dan

Link to comment
Share on other sites

@D@n

Yeah, thanks for the correction. I just haven't needed a UART above 921600... so haven't even tried. My FPGA boards all have a parallel USB 2.0 interface so I use that for collecting a lot of data. If 10-30 MB/s isn't cutting it USB 3.0 on the FMC connector is a cheap alternative unless there's something else using it. The only problem with USB is that data rates get pretty low if you are only sending small amounts of data; and then there's latency which is a concern if there's a control loop between the FPGA board and the PC.

Part of the reason for my post was to point out that implementing an Ethernet interface that plays with an OS isn't easy unless you are prepared to write a driver or are using one from a package like MATLAB. The HDL end, though not obvious is the (relatively) easy part. Wireshark and pinging a device isn't an Ethernet interface.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...