Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
9 years ago

Fast data tranfer to PC

Hallo,

I am trying to implement a new project where I want to use an FPGA as a kind of DAQ system. Basically the FPGA is reading about 70 sensors sending asynchronously with a maximum bit rate of 125kbits/s each. The final goal is to fed the measured data to a pc. I have a DE0-Nano SOC and I was thinking using Ethernet or USB communication. The main problem as I am mainly a hardware guy is that is very difficult to start with this board for both interfaces (I don't know which of them is easier). Does anybody have an idea what it would be the simplest solution for my application. If I want to use Ethernet what it would be the easiest way to start with?

Thanks.

10 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Using an Ethernet is good and universal way to send data to PC, however it would require more than just hardware and low level software. The easiest way using FPGA would probably be by implementing NIOS II soft core processor and software TCP/IP stack (also some kind of real time OS would be needed together with the TCP/IP stack). I think Altera provides such an example as a template design using uC-OS for DE0-Nano SOC. You should have in mind that uC-OS with it's TCP/IP module has relatively expensive licenses.

    You can also check some kind of additional controller between the board and the PC which has already developed drivers. For example FTDI's chips like FT2232H (http://www.ftdichip.com/). Particularly this one provides USB to MPSSE interface with ready to use drivers for the PC. They say it can achieve up to 30Mbsp. However here you would need to make additional hardware.

    Victor
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Why don't you read the thread listed at the bottom of this page, "Fast & Large block data transfer over USB - DE1/DE2?".

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    You don't need a full TCP implementation to send data to a PC over Ethernet. Your board could use UDP packets picked up by the PC. You would need software on the PC to pick up the data, but not a windows device driver. Even so, this is a substantial software undertaking. Also, think about using an SD card to store the data from the FPGA. It's way simpler than Ethernet, USB or PCI express.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Thank you all for your answers. So far the easiest solution seems to be USB to UART. The DE0-Nano board has already integrated FT2232R chip so no additional hardware implementation required. To make a correction in my first post each sensor has a speed of 690kbits/s. Correct me if I am wrong, but if I have 70 sensors then I will need 70*690=48.3Mbit/s so if I use the FT2232R it would be sufficient for my application cause offeres rates up to 3Mbaud/s.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    I don't follow your calculation. You need 48.3Mbits/s. The FT2232, I believe, will give you ~30Mbits/s (I don't know what 3Mbaud/s means, or where it came from). You don't seem to have enough bandwidth with the FT2232.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hello ctzof,

    I do not totally agree that USB is the simplest solution to your problem.

    I have studied USB PC side and FPGA side, at this time it seems rather complex to me.

    There is however a bare metal solution to your problem that might be interesting:

    - UDP messages are really simple in structure, there is no handshake as with TCP it is fire and forget.

    Therefore it is possible to create a valid UDP message using simple VHDL/VERLOG code.

    (http://www.tcpipguide.com/free/t_udpmessageformat.htm)

    Send this message to the PC and see how far you get.

    You might want to use a tool such as wireshark to see if you are recieving UDP messages.

    If you want to write PC code to display your data, look for winsock sockets in whatever language you are programming your PC.

    Is is a service that is part of Windows. There are examples on the NET to see how you can manage UDP messages from the PC side.

    For the baud rate: you could use all rates that are available on the network.

    Be aware that the PC aslo needs to be able to follow the data troughput.

    Best Regards,

    Johi.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    --- Quote Start ---

    I don't follow your calculation. You need 48.3Mbits/s. The FT2232, I believe, will give you ~30Mbits/s (I don't know what 3Mbaud/s means, or where it came from). You don't seem to have enough bandwidth with the FT2232.

    --- Quote End ---

    You are right actually 3Mbaud/s means 300Kbytes/s and what I need is 6Mbytes/s (48.3/8). So it wont really work for all sensor.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    --- Quote Start ---

    Hello ctzof,

    I do not totally agree that USB is the simplest solution to your problem.

    I have studied USB PC side and FPGA side, at this time it seems rather complex to me.

    There is however a bare metal solution to your problem that might be interesting:

    - UDP messages are really simple in structure, there is no handshake as with TCP it is fire and forget.

    Therefore it is possible to create a valid UDP message using simple VHDL/VERLOG code.

    (http://www.tcpipguide.com/free/t_udpmessageformat.htm)

    Send this message to the PC and see how far you get.

    You might want to use a tool such as wireshark to see if you are recieving UDP messages.

    If you want to write PC code to display your data, look for winsock sockets in whatever language you are programming your PC.

    Is is a service that is part of Windows. There are examples on the NET to see how you can manage UDP messages from the PC side.

    For the baud rate: you could use all rates that are available on the network.

    Be aware that the PC aslo needs to be able to follow the data troughput.

    Best Regards,

    Johi.

    --- Quote End ---

    It seems that more and more people vote for Ethernet with UDP messages. The problem with Ethernet is that on this particular board the controller is connected to the ARM A9 processor. Since I am not really a software developer I want to keep my hands away from it as possible. I am more familiar with NIOS II, but for that I would need an ethernet controller IP either from opencores or Triple speed ethernet (that costs about 450$). From your post though I understand that I could really perform the UDP transmission without any ethernet controller, is that right?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    I decided to go with Ethernet using Nios and an external module like W5300, cause it seems to be the easiest solution for me at the moment. As protocol I am thinking of using TCP/IP cause is really important not to miss any packet coming from FPGA. Using the internal ethernet controller of ARM seems to be the best solution but its not so straightforward for to start with. Theoretically the W5300 has a bandwidth of 50Mbits/s which is more than enough for my application.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    9 years ago

    Hello Ctzof,

    Your solution is realistic, there is no reason why it should not work, be sure however to choose because of the right reasons;

    You are right that with UDP, you need to implement retries on the user layer, this means you have to program retries yourselves if a message is lost (implement some sort of handshake or message counter). TCP/IP has this implemented in the protocol layer itself, this is a major advantage for TCP/IP.

    On the other hand, TCP/IP is stream oriented, this means that there is a continuous stream of bytes between the 2 communication partners where your program has to determine where a message starts and where it ends. It is like a water pipe, on the one side you pour bytes in, on the other they come out. Once you are 1 byte off on the reciever side, you are lost. UPD has the concept of sending data telegram by telegram, this makes synchronizing client and server much easier and adds to the reliability of the solution in the long term.

    Best regards,

    Johi