Jump to content
  • 0

ethernet communication with pc


sachin

Question

22 answers to this question

Recommended Posts

3 hours ago, wtf said:

send your own code for receiving and transmitting data using UDP protocol using ethernet in spartan6 fpga.

Wow, this is a pretty specific question. For the record I rarely use UDP or any other standard packet type, except for the few that are required like ARP to do FPGA Ethernet. I almost exclusively use custom packets for data transfer. I also don't try and implement a whole TCP/IP stack in HDL. It's just not necessary for anything that I want to do... and I do use that Ethernet PHY for a lot of projects. They just aren't going to connect to a LAN or the internet. I don't think that doing so would be a good idea. I also haven't seen a reason to deal with a lot of the  issues that can happen to packets like being received out of order or collisions and the like... not necessary for what I've wanted to do. It is a particular intention of mine that my FPGA Ethernet is not compatible with all of that in fact. When I want PC connectivity to my FPGA platform I avoid using normal OS Ethernet connectivity, though I do use raw Ethernet in my PC applications.

3 hours ago, wtf said:

Why don't you give the link to your code if you are so much experienced

I'm just going to wing it an providing an answer, and at the moment I don't have a lot of time... because I'm still working on all of that experience.

Answers that come to mind without much contemplation (in no particular order):

  • I'm not a resource for easy solutions to everyone's immediate problems.
  • I'm not a source for free code. What I do publish takes a lot of time and effort to prepare. Source code that I do publish is always free for re-use by anyone as long as they don't turn around and charge someone else for it.
  • Not eeveryone who uses published code does it for 'learning purposes'.
  • I don't want to cheat people out of the satisfaction of figuring out how to do things on there own. Along those lines it seems to me that people should have developed a certain level of skill before trying to take on various problems. I recognize that this is a topic worthy of debate.

Now if you read enough of my postings you will notice that sometimes I provide complete answers to questions. Usually, I believe that it's better for everyone if I suggest a path for people to figure out how to find answers on their own. I do a lot of reading between the lines and often my answers take a longer view of what the question implies about what exactly the 'problem' really is. I don't always get this right but this is more of a philosophical perspective beyond the scope of this particular answer.

I do appreciate your question though.

On the matter of using a Ethernet PHY in FPGA designs, I have published code in Digilent's Project Vault. If you bother to do some research on Ethernet you will see hints that are valuable trail markers. If you can't be bothered with doing any research then the links provided by @PhDevmight be what you are looking for. I haven't looked at them. BTW, parsing packets is not advanced HDL design though I suppose that you could use rarely used structures like records to do it.

Ethernet is a topic that I specifically believe that posting easy code solutions to is a bad idea.  It is one that I strongly believe that only those who are knowledgeable enough to understand the implications of what they are trying to do with it should be using Ethernet for their projects  You can figure it out. I view the effort and time getting to where I am as worth more than the destination.

3 hours ago, wtf said:

You are  telling something that disrespects others solutions.

I have to admit that I have no idea what it is that you are intending to say. But I'm an old fart and my concept of respect or the more gansta rap concept of disrespect is not in line with popular opinion. I certainly don't intend to offend or belittle anyone. Today I know more about effectively using the ubiquitous Ethernet hardware layer than I did 10 years ago. That fact neither raises nor lowers my opinion of my former self. It's just the result of a journey that I embarked on and am happy that I did.

Link to comment
Share on other sites

@zygotWhy don't you give the link to your code if you are so much experienced?. In this world there are more tellers than doers. You are  telling something that disrespects others solutions. So just don't do it. Some of your answers are good. In some cases we need to be happy for getting the answer, but you are not. Your are not encouraging the beginners. This attitude not good. SO ENCOURAGE THE BEGINNERS. 

 

If you have the capability, then send your own code for receiving and transmitting data using UDP protocol using ethernet in spartan6 fpga

Link to comment
Share on other sites

On 2/18/2019 at 11:35 AM, D@n said:

wikipedia does a decent job describing most of what you'll need for the various protocols,

I forgot to mention that unlike some interfaces you can download copies of the Ethernet standards which provide (almost, they won't provide code to implement a robust PHY interface in HDL for you FPGA board for instance) all of the information that you need to implement a workable application. Well you can get the standards for others if you pay to become a member of the organization that maintains them. I have nothing against using wikipedia, I do so frequently, but it's not always the best, or most reliable, source for information. Really, parsing the packet structures for Ethernet is  not a big deal or close to the being a significant part of the work involved in creating a usable application.

Link to comment
Share on other sites

@PhDev

Perhaps you'd be willing to provide a simple application to the Project Vault demonstrating your positive experience with these cores that come in the form of pre-compiled netlists. It's been my experience that becoming invested in such IP with very limited documentation is, in the long run, not very productive. There are, obviously, quite a few people out there who just need a quick and dirty solution to solve a problem and don't have long term interest in developing standard Ethernet based projects.

Link to comment
Share on other sites

@D@n Yes I think they work great. Very easy to use.

I have mostly been using FC1002 with TCP. I have also used FC1003 in a project where UDP (broadcast) was a better choice. I hope they release a FC1004 with RMII: (Both UDP and TCP)

DHCP or fix IP works as expected.

The remote programmer also works very good. I think it is faster and easier than using XIlinx programming tools.

The logic analyzer is also very useful for debugging the system without using the jtag. Only bad thing is that I sometimes need larger sample buffers. I also miss some documentation, however I think I have figured it out most of it now.   

I really like the AXI-stream. Xilinx has very good components supporting this like clock domain crossing, FIFO, Filters etc.

 

Link to comment
Share on other sites

The following argument is just a philosophical perspective. I understand that there are people who want to do stuff but not necessarily spend the time to learn stuff. That's fine but I'd suggest to those people that they should find another platform to do their stuff. Raspberry Pi is a very useful platform. There are no doubt alternatives for it than a full blown OS to make projects easier. There are a lot of Rpi or simple micro-controller based alternatives out there. There are also people who need to do stuff and have a very fixed time frame to do it in that precludes the normal preparatory learning. That's also fine. But they also should find a less complex way to do their stuff to ensure making that deadline. I know that FPGA vendors would like to maintain the illusion that FPGA development is just like programming a computer, just  more capable and flexible. It isn't. It won't be for a very long time. Yes you can replicate a particular demo easily ( sometimes if the project source isn't a tcl script ) but try and make it do new tricks and you will find youself stuck, or at least stuck having to go and learn everything that you didn't want to learn when you started. If you just have to use and FPGA and can't learn Ethernet basics then perhaps you can bootstrap someone else's project to fit your needs if you're lucky.

If you only need to do 1 thing and then move one to other endeavors find the simplest way to do it and move on. There are products that almost trivialize the basic Ethernet communication. Making a workable application might not be so easy. If you choose to do your stuff using an FPGA then I suggest that you are choosing to learn all of the little details and minutiae that software libraries or full blown programs like MATLAB do for you in the background. Taking the time to learn about every subject that you're working with is a given with FPGAs. It's really not a good tool for the casual developer. FPGAs just aren't the best solution for every problem; even for people who are really proficient at using them.

I've had involvement with companies who's products used Ethernet for control and data transfer and once timing, responsiveness or throughput requirements start driving the design it's not easy for them to meet customer needs even with an Ethernet expert in house.

Link to comment
Share on other sites

"Don't let Zygot discourage you". I certainly agree with that!

I won't walkback on my advice though. You need to do some preparation and though the information you need is there to be found it's not going to be neatly packaged into a form that can be trivially added to your project and make it work. By the time that your application is useful you will have the basic understanding.

Just writing a Windows or Linux application to talk to your FPGA requires some knowledge. Once you've written your first HDL to detect and extract packet headers and data it gets a whole lot less mysterious but that first one can be difficult for those learning the subject. Also you need to have a basic understanding of the physical layer; 10/100 isn't the same animal as gigabit. You need to understand the hardware platform that you are working with. Supporting triplespeed MACs in your HDL involves some digital design techniques that are beyond the beginner's stage.

I'd never want to discourage anyone from completing a project goal but I certainly think that it's fair to point out the scope of the work involved. I'm not the type of person who pushes an adult who can't swim into the pool as I call out "Don't worry, you'll figure if out". (Evidently in some parts of the world they do this to newborn babies and it all work out...)

As I've mentioned in other posts the FPGA vendors don't want to make it easy for users ( especially casual ones ) to use Ethernet without being tied to their own IP. At least Digilent configures their Ethernet PHYs is a usable state out of reset making things less painful. 

The lowly UART is fairly simple in comparison to Ethernet. Even still, trying to implement a multipoint network network using HDL Uarts is a significant undertaking.

 

Link to comment
Share on other sites

@Aamirnagra,

You can find my own RMII interface work here.  There's also a simple-ping program to drive it here.

Don't forget you'll want an MDIO controller as well!  That one is nearly as trivial as a SPI core--it's pretty easy to write.  You can find my own MDIO controller here.  I also have a software decoder for  the results of that here.  Being able to quickly read and get a status from the MDIO interface can be quite valuable.

1 hour ago, zygot said:

I hope that you don't think that you can do anything useful with the Ethernet interface without having a basic understanding of the layers and protocols involved, especially if you want to communicate with a Linux or Windows computer.

Don't let @zygot discourage you.  Yes, there's a lot to learn about, however wikipedia does a decent job describing most of what you'll need for the various protocols, and the Ethernet data sheet for your device should describe the RMII interaction well enough.  Yeah, there are a couple of gotcha's, and you'll find some surprising things along the way.  For example, I expected the nibble order to be the other way around.  In most cases, you can just debug any problems you run into with wireshark.

1 hour ago, zygot said:

. This is not a trivial undertaking.

At this point, though, I'll agree with @zygot: network interface work is not trivial.  It's a lot of fun though!

Dan

Link to comment
Share on other sites

There are a few projects in the Digilent Project Vault that might interest you... specifically ones by hamster and vonmuller.

I hope that you don't think that you can do anything useful with the Ethernet interface without having a basic understanding of the layers and protocols involved, especially if you want to communicate with a Linux or Windows computer. This is not a trivial undertaking. Opencores has a few projects that might be educational.

Link to comment
Share on other sites

@sachin,

That probably depends upon which IP core you are using.

I know with the IP core I pointed you at, there are a couple steps to sending a message: First, you need to turn the network controls on.  Then, you have to place the message you wish to send into a block RAM memory area.  Finally, you would need to write to the transmit control register and the packet would be away.  A demo program that accomplishes all of this, using an external PC to control the port via a UART interface, is available together with the repository.

This may sound a touch easier than it is, since there's a lot more going on between computers to make network communications possible.

First, the FPGA  needs to have an IP address and an Ethernet MAC address assigned to it.  Every packet the FPGA sends must also include these addresses, together with certain internal checksums.  Format is very important.  Many computers try to acquire the IP address automatically using the DHCP protocol, but ... that's one more protocol you'd need to deal with and if you've never done this before then simplicity is everything.  Then, the FPGA needs to respond to certain network packets, in particular it will need to respond to ARP and ICMP (ping) packets.  Only at this point does the FPGA even exist on a network to the point where other computers on that network will acknowledge its existence.  If you are following or hoping to use the IP I pointed you at earlier, there's a demo program for the ZipCPU (a softcore CPU that can be placed within an FPGA--similar to a MicroBlaze CPU) which does all of this.

The next step sort of depends on what you wish to do, but there are two general approaches you can take next.  The first is to send data from the FPGA to a PC via UDP/IP, and the second via TCP/IP.  From the standpoint of your PC, TCP/IP is simplest.  It acts like a telnet session, and you might even be able to telnet into an FPGA using it.  From the standpoint of the FPGA, TCP/IP is a lot harder: every message you send from the FPGA to the PC needs to be kept in memory on the FPGA until the PC acknowledges it, or resent to the PC should something go wrong.  UDP is simpler from this standpoint.  UDP messages may be sent and lost and ... you'll just need to figure out how to deal with that on your own.  IIRC, the netcat program can be used to receive UDP messages, or you can build your own.

Sound challenging?  It certainly makes the simple task of sending a packet only the beginning of the task.  However, there are a couple of approaches to dealing with this complexity.  For example, there's an IP core on OpenCores that tries to package up the TCP protocol so that all you need to worry about is sending data to it (I've heard of this IP core, but never used it).  Other approaches place a soft core CPU onto the FPGA board to handle the difficulties of a network interface.  You may notice that I was using the ZipCPU for this purpose.  There are also many other soft-core CPUs out there that you might use, to include some bigger named ones such as OpenRISC, and RISC-V.  Some of these (OpenRISC, for example) will even run Linux--hence providing you with a full network stack internal to your FPGA, although their official distribution set tends to do more with Altera parts than Xilinx.  I'm told that the MicroBlaze has a network stack and ethernet IP to go with it that can be used, although I've never used either--you might wish to choose to go that road, although you haven't specified yet which way you wish to go.  From my standpoint, I'm still building the network stack for the ZipCPU, so ... I'm not there yet personally.

I suppose this is a long-winded answer, but ... these are the sorts of things you need to think about when using a network core within an FPGA.

Dan

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...