Jump to content

Ethernet/IPV4/UDP Basys3

Recommended Posts

In an effort to learn how to move network data to/from an FPGA I have taken the https://www.fpga4fun.com/10BASE-T.html ethernet project, rewrote it in VHDL and ported it to a Basys3.  I also added a LOT of comments in the code to help explain the header information required for the packets, and I changed the way the IPV4 checksum was calculated in an attempt to make it more obvious with out it works.  I used clock wizard IP to gen the 20MHz clock required for the project.  This was all in Vivado 2019.1 but that only matters if you want to use the clock wizard IP that I attached.  If you just generate your own clock IP, the vivado version you use will not matter. I learned a large amount (yet just scratched the surface) about ethernet, IPV4, and UDP to allow me to rewrite this project.

fpga4fun.com is a fantastic site, even after it appears to have been abandoned years ago. Thank you so much Jean P. Nicolle for leaving your fantastic site online for us.

UDP_Tx.vhd Basys3_Master.xdc clk_wiz_0.xcix

Link to comment
Share on other sites

I just noticed I wrote an incorrect comment in the XDC file I uploaded. The notes on what pins I am using are not correct.  I chose these two pins because the FPGA chip has these two as a dedicated differential pair.  You can see this when you open synthesis and view the Package Pins window. H1 is the P pin and J1 is the N pin of a pair. At the slow 10BASE-t speeds this detail might not matter but why not use pins that are placed inside the FPGA specifically with the option of acting as a differential pair? So thats what I did.

#Sch name = JA7
set_property PACKAGE_PIN H1 [get_ports Ethernet_TDp]
set_property IOSTANDARD LVCMOS33 [get_ports Ethernet_TDp]
#Sch name = JA1
set_property PACKAGE_PIN J1 [get_ports Ethernet_TDm]
set_property IOSTANDARD LVCMOS33 [get_ports Ethernet_TDm]

Link to comment
Share on other sites

I've always thought of the Project Vault as a place where completed projects with sources are posted, but I guess that there's no one enforcing that.

I love the idea of doing projects just for the sheer self-guided educational enjoyment as I do this myself. The idea of flying blind has a certain romantic cachet to it but if you have at least one working eye if might preferable to use it.  So, I have a few reactions to the post:

  • For FPGA projects the place to start for all work is with the FPGA device vendors datasheets and user manuals. You can't use a device properly if you don't understand how it works. As the tools are closely coupled with the device capabilities you should at least speed read though that material as well.
  • For Ethernet projects the place to start is with the official documentation. It's freely available and has a description of all of the layers.
  • 10BASE-T, 100BASE-T, Gigabit, and multi-gigabit Ethernet physical layer implementations are very different things. The differences are important.
  • If your intent is to propagate knowledge then don't just throw out some 'code' but add a description of how the code can be used for a particular purpose. Partially completed code snippets can be very misleading to those who don't know enough to ask the right questions about concepts.
On 4/29/2021 at 9:46 AM, FlyingBlindOnARocketCycle said:

why not use pins that are placed inside the FPGA specifically with the option of acting as a differential pair?

The answer to this question can be found in the Series7 SelectIO Reference Manual and the Basys3 schematic. Don't assume. Don't do experiments without first doing your prep work. Even for 'just for home entertainment' projects the same level of discipline that one might employ on a 'work' project is more productive.

I briefly read through your transmitter code. If you use a common, or even a related derived clock source for Tx and Rx, you will be fooling yourself about how well your design works.

Personally, I have a problem with offering code examples that suggest a broader usefulness or state of completeness than it provides, so perhaps my reactions seem a bit harsh.


Link to comment
Share on other sites


Personally, I have a problem with offering code examples that suggest a broader usefulness or state of completeness than it provides

Would your objection be alleviated if the project had been titled "Ethernet/IPV4/UDP Tx from a Basys3" ?  The code I posted is complete and operates for Tx. I also have a link to the source project on fpga4fun.com  The VHDL I posted along with its comments are documenting much of what I learned while converting the original Verilog project to VHDL. As I doubt there are any Basys3 owners who haven't looked through the Digilent forum for education and inspiration, I feel this project, even in its Tx only state, is completely appropriate here. It's not as if I am trying to sell this as IP. I'm just leaving some bread crumbs along my journey to help any others who stumble upon my path.


Thank you for your input.

Link to comment
Share on other sites

1 hour ago, FlyingBlindOnARocketCycle said:

Would your objection be alleviated if the project had been titled "Ethernet/IPV4/UDP Tx from a Basys3" ?  The code I posted is complete and operates for Tx.

Not really. I think that projects posted here should be confirmed as working on hardware before being posted.

When you say that your code is complete, what do you mean by that? Have you connected the output pins to an old PC with a 10BASE-T Ethernet card? Have you even  gotten around to receiving packets on something attached to the output pins? What external hardware sits between your Basys3 output pins and the receiving hardware? You've posted in two different places in the Digilent Forums about this project and you seem to prefer that they be taken as referring to different projects. The other post references Ethernet Rx hardware. I think that I've addressed the concept that simply referencing a link to a related project or even one that is the basis for your work isn't very meaningful.

It doesn't take much effort to write up a short description of how you verified that your code works on hardware, how you tested it, and how users can replicate your results. Perhaps all of this is missing because you haven't 'closed the loop' by implementing a receiver yet?

There's nothing wrong with posting 'code projects in progress', I suppose.. if you are honest and careful in advertising it for what it is. I'd just rather see it posted somewhere else. This is just my personal opinion. I'm not the Digilent Project Vault Overseer.

My personal preference would be that people submit projects to Digilent for posting here. Digilent staff would replicate and vet the projects and post those that are good along with editorial commentary and corrections as needed. That isn't going to happen so we're left to post and comment as desired.

If someone experiments on their own hardware and ruins it but doesn't post about it then blowing up a board is the worst that can happen. If they post about it then they can induce people who know even less than they do to ruin their hardware and that's not a very nice thing to do.  Posting project code that is incomplete, ignores pertinent details, and involves connecting FPGA pins to external hardware is more apt to cause real harm to those who might not know enough to be selective about what to try out for themselves. That's my thinking...

Mostly, I'd have preferred if you chose other statements in my earlier post to react to as they are relevant to the project material.


Link to comment
Share on other sites

I have a PC running UDP receiving software that is always listening.  The Basys3 project I posted is wired to one pair of Tx pins on a short piece of CAT5 and plugs into a LAN switch on my home network.  I can see on my PC the UDP packets I'm receiving from the FPGA and the data is correct. 

All of this is explained in great detail at the link I provided in my first post https://www.fpga4fun.com/10BASE-T0.html

It seemed silly to retype all of the information that is found at the link. I clearly stated that my project was a VHDL version of that project and ported to Basys3.


I have taken the https://www.fpga4fun.com/10BASE-T.html ethernet project, rewrote it in VHDL and ported it to a Basys3. 

I wonder how much of this post you have really examined before providing an opinion on its lack of merit?

Link to comment
Share on other sites

Ok, I have bad eyesight but even I can see that the link to your project in your first post is different than it is in your last post. In the link in your last post states:

"We are using a Pluto board here with an external 20MHz oscillator."

Also, there's this: "Also even if that works in practice, we are not compliant to the Ethernet electrical requirements by just connecting the FPGA to a cable (we would need a filter and a transformer). So let's just consider that a "lab" experiment."

I don't know what kid of a switch you are using but in my experience Ethernet switches require periodic ARP packet handshaking to determine what node addresses are active, or they don't pass along incoming packets.

I assume that you are using the software described in your last post.

When I tried looking at the link you provided in your original post I saw a static page and none of the information in the link provided most recently. Neither shows a Basys3 connected to your home network switch. But at least the link in your last post provides some of the information that should be there.

What do you suppose is the effect on the FPGA pins driving a "short" Cat5 cable into the magnetics of a switch Ethernet receiver? What if you used a 30' or 100' Ethernet cable?

3 hours ago, FlyingBlindOnARocketCycle said:

it seemed silly to retype all of the information that is found at the link.

But what you've posted here doesn't match the information on any of the links that you provide. That's why writing up a short description of exactly what you've done isn't at all silly.. but necessary.

As a purely learning exercise I suppose that porting someone's Verilog code into VHDL is worthwhile. But how many people want to do 1-way UDP over 10BASE-T? Using a switch implies that multiple Ethernet sources (Basys3 boards) can communicate with your PC application. What's going to happen when collisions occur or you decide to send longer packets and they get fragmented by the switch? 

I suggest that trying to receive packets on your Basys3 will be pretty hard to accomplish. Your documentation should address these questions to avoid confusion from your readers.

To be clear, I haven't stated an opinion on the merit of your post; I've just presented my reaction to reading it and the links that you've provided along with your other post that you haven't replied to. I'm just trying to figure out what it is that you are presenting and what you think that it could be used to do. But yes, I have been following along as best I can given what you've presented. That silly project description write-up might have saved us both a lot of typing.

All of this would be easier using the PMODNIC100 and using a PHY instead of limiting yourself to 10BASE-T and Tx only communication ( and possible abuse of your Basys3 FPGA pins ) . Since Digilent doesn't actually provide any FPGA support for that product you might have a larger audience. You've already got the basic packet structure down. In fact I was contemplating using the ENC424J600 as the basis for a Project Vault project before I realized that they already had such a product. It wouldn't be too hard to modify your project to demonstrate a simple true 2-way point to point 10 Mbps Ethernet project using that PMOD and avoid the hardware issues at the same time.

BTW, if you look around, this isn't the first or only UDP project posted to the Digilent Project Vault...

Link to comment
Share on other sites

16 hours ago, zygot said:

As a purely learning exercise I suppose that porting someone's Verilog code into VHDL is worthwhile.

You could have saved time by just adding commentary to the original Verilog and instantiating the Verilog module as a component in a VHDL entity, if that's your preferred HDL. Still, the exercise has been valuable to you. The biggest issue that I have with the post is the hardware interface. I'm not interested in selling PMODs for Digilent but that solution is cheap, has an RJ-45 Ethernet connector, will do 100 Mbps and will work with any FPGA board having PMOD connectors that aren't the low speed variety... they might even work with those, I haven't tried. I think that this would be useful and of interest to a lot of people using the Digilent forums. I suggest concentrating on a limited Ethernet capability, especially for UDP as there's no guarantee that packets are delivered in the order in which they are sent.

Link to comment
Share on other sites

Last thought, for now. Sending the same packet contents repeatedly might not be a good exercise for a UDP demo. It doesn't address potential real-world behavior. I realize that the idea is to improve what you've read in the material that your links point to, but there's still work to do before you have a useful application.

If all of these comments seem hyper-critical or dismissive, I can assure you that they aren't. I'm a big fan of MAC-free, vendor IP-free, Ethernet physical layer FPGA HDL point-point communication. It's my way of urging you on...

Link to comment
Share on other sites

As @FlyingBlindOnARocketCycleseems to have lost interest in interacting with a discussion of his post I should make it clear that his source might be useful to someone trying to learn about Ethernet and FPGA HDL implementations. It's just not complete enough to use in anyone's application. Look around this site and you will find other projects that might be a better starting point.

The idea of connecting FPGA pins directly to Ethernet cables or equipment, however is a very bad idea. So is finding hardware interfaces on the internet and deciding that it's worth trying out without understanding how it works, or more importantly, if it's compatible. If you are willing to read and understand the vendor reference material for your FPGA device and are up to the task of designing suitable interface hardware then that's another matter.

Digilent makes a few good low-cost platforms with a 10/100 Ethernet PHY that are quite suitable for learning and experimenting with implementing rudimentary Ethernet connectivity without resorting to MAC IP, soft-processors like MicroBlaze, or any other vendor IP. When done intelligently, I'm all for this kind of endeavor and encourage it. Ethernet is complex and has a lot of moving parts to understand so be prepared to put in some research effort and don't rely on a couple of posts. Just because something appears to 'work' doesn't mean that that it does reliably or safely.

Link to comment
Share on other sites


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

  • Create New...