Ethernet board development!!!

[Siwastaja]

I second the solution for using a Wiznet chip. The easiest solution by far and nowadays they also have IPv6 versions available.

Yeah. I have to add though that even this isn't completely problem free solution, though it bypasses a large part of peter-h's complaints, but not everything. The chip implements ARP, TCP and IP on-chip, but not only you have to interface with this chip, you also need DHCP and DNS software implementations, and the code supplied by Wiznet is broken (e.g., overindexing memory) so you need to either fix it or find working implementations which still need integration work. But sure, DNS and DHCP are both very simple protocols. And if you need TLS, integration work for something like mbedTLS is needed too.

But sure, bypassing monstrosity like lwip helps, and time-to-market with Wiznet is probably faster. One extra word of caution: this chip comes with weird compatibility issues with some routers, on the lowest physical level, which require workarounds like forcing the link to 10Mbit mode. This is well documented by many once you Google it ("wiznet" "tp-link"). Just something to watch out for.

[radiolistener]

You can use some FPGA chip wih about 6k LE to implement UDP stack connect to PHY chip with GMII or MII.
In many cases there is even no need for MCU, you can do all things in hardware on FPGA.
In case of needs you can even implement your own MCU core on FPGA...

[nctnico]

I second the solution for using a Wiznet chip. The easiest solution by far and nowadays they also have IPv6 versions available.

Yeah. I have to add though that even this isn't completely problem free solution, though it bypasses a large part of peter-h's complaints, but not everything. The chip implements ARP, TCP and IP on-chip, but not only you have to interface with this chip, you also need DHCP and DNS software implementations, and the code supplied by Wiznet is broken (e.g., overindexing memory) so you need to either fix it or find working implementations which still need integration work. But sure, DNS and DHCP are both very simple protocols. And if you need TLS, integration work for something like mbedTLS is needed too.

But sure, bypassing monstrosity like lwip helps, and time-to-market with Wiznet is probably faster. One extra word of caution: this chip comes with weird compatibility issues with some routers, on the lowest physical level, which require workarounds like forcing the link to 10Mbit mode. This is well documented by many once you Google it ("wiznet" "tp-link"). Just something to watch out for.

Interesting but by the looks of it all these problems are caused by hardware or software errors made by the people trying to integrate it into their design, not the chip itself. If the Wiznet chips where that bad, they would have fixed them by now.

[Siwastaja]

Interesting but by the looks of it all these problems are caused by hardware or software errors made by the people trying to integrate it into their design, not the chip itself. If the Wiznet chips where that bad, they would have fixed them by now.

The TP-LINK issue is widely documented using Wiznet's own modules, too, so I don't think it's a signal integrity problem - in other words, my own PCB design which works perfectly with 99% of the routers fail with exact same routers others have problems with, too, using Wiznet's own PCB designs. The minimum code to reproduce the problem is absolutely trivial, because the problem appears by the chip not being able to bring the PHY up at all; I have not scoped it to see if it's in autonegotiation logic or something else, but I'm 99% sure it's the "chip itself". I'm not surprised they haven't fixed it. World is full of products and semiconductors with problems that are not getting fixed, especially when there is at least some kind of workaround available (see all STM32 microcontrollers, for example - nothing gets fixed). In fact, I would be surprised if this kind of complex product was flawless.

[Scrts]

You can use some FPGA chip wih about 6k LE to implement UDP stack connect to PHY chip with GMII or MII.
In many cases there is even no need for MCU, you can do all things in hardware on FPGA.
In case of needs you can even implement your own MCU core on FPGA...

Only for very niche solutions with fixed IP addresses. Otherwise, you want ICMP ping to work, DHCP to pick up address, resolve IP to MAC address using ARP, etc. You will also need a hardware muxer, which would redirect all UDP traffic to FPGA logic and all ARP/ICMP/TCP traffic to softcore.

Ask me how I know... 

[radiolistener]

Only for very niche solutions with fixed IP addresses. Otherwise, you want ICMP ping to work, DHCP to pick up address, resolve IP to MAC address using ARP, etc.

Yes, I'm done it, I'm using UDP stack with DHCP, ARP and other things on FPGA, ethernet part eats about 3-4 kLE on Cyclone 4. It automatically requests IP from router with DHCP, it responds on pings and streams realtime high speed data (at 100-500 MBps) between PC and my circuit implemented in the same FPGA... And there is no MCU, all is done on FPGA in verilog

[Scrts]

Only for very niche solutions with fixed IP addresses. Otherwise, you want ICMP ping to work, DHCP to pick up address, resolve IP to MAC address using ARP, etc.

Yes, I'm done it, I'm using UDP stack with DHCP, ARP and other things on FPGA, ethernet part eats about 3-4 kLE on Cyclone 4. It automatically requests IP from router with DHCP, it responds on pings and streams realtime high speed data (at 100-500 MBps) between PC and my circuit implemented in the same FPGA... And there is no MCU, all is done on FPGA in verilog

That's cool. I was working on high speed data reception over UDP (video streams), which required a packet type based mux in HW. All non-UDP packets were routed to Nios running LwIP for the data handling. UDP packets were handled in FPGA logic. The whole thing utilizing up to 7 video stream reception took 98% of EP3C55...

[joeqsmith]

And there is no MCU, all is done on FPGA in verilog

Assuming none of that microblaze ... stuff, that's impressive.   

[tellurium]

Yeah. I have to add though that even this isn't completely problem free solution, though it bypasses a large part of peter-h's complaints, but not everything. The chip implements ARP, TCP and IP on-chip, but not only you have to interface with this chip, you also need DHCP and DNS software implementations, and the code supplied by Wiznet is broken (e.g., overindexing memory) so you need to either fix it or find working implementations which still need integration work. But sure, DNS and DHCP are both very simple protocols. And if you need TLS, integration work for something like mbedTLS is needed too.

Second that, and want to add one point:
Wiznet chips implement TCP/IP stack internally and provide socket API via SPI.
But they also provide a so-called "raw socket", meaning it is possible to fully bypass Wiznet TCP/IP implementation, and use W5500 only as a way to send/receive raw Ethernet frames. Of course in that case the MCU must implement the TCP/IP stack.

One might ask - but what's the point. There are two: first, this is a workaround for Wiznet bugs, and second, LWIP is not the only option here. Allow me to mention https://github.com/cesanta/mongoose/ once again - it implements W5500 driver, TCP/IP stack, DNS, ARP, DHCP, HTTP/MQTT/Websocket, and TLS 1.3 - in a single file. As an example, here is a tutorial for SAMD21 + W5500 on Arduino: https://mongoose.ws/documentation/#xiao-m0--w5500-module

[peter-h]

You can use some FPGA chip wih about 6k LE to implement UDP stack connect to PHY chip with GMII or MII.
In many cases there is even no need for MCU, you can do all things in hardware on FPGA.
In case of needs you can even implement your own MCU core on FPGA...

The above is a windup, surely.

How many man-years?

Come on guys, try to help the OP by not suggesting such totally esoteric approaches.

The reality is that this stuff is a lot of work. There is no way around it. I see my name has been referenced in the usual places so yeah the main difference between me and most others is that I

- post questions with a lot of detail so somebody smart can actually help me (most people just post "help me" questions)
- post the solution afterwards (99% of people never do that, sometimes for company policy reasons (leeching is allowed) and mostly because why should they?)

[Red Squirrel]

I'm looking at doing similar stuff as OP and been doing some research myself so this this is NOT expert recommendation, but I found the PIC18F97J60 which looks like an interesting chip.

It's a MCU but also has an ethernet MAC and the PHY built in, which a lot of chips only have one and not the other so you would need extra components but this chip has it all and you only need the magnetics (two small transformers which isolate the ethernet signal).  From my understanding the MAC is basically the software implementation of Ethernet (ex: OSI layer 2) which is often found on MCUs and the PHY is the layer 1 section which drives the actual Ethernet signal, which often is it's own chip.

 You also need transformers (referred to as magnetics) and of course the jack itself.  Some jacks have it built in but it ends up more expensive per unit but if you're only making a few it's a way to go.   If you want to do POE you need a separate chip to control that too.  Make sure you get magnetics that have split transformers as the middle is used for the POE signal.

 Once you have that going you essentially have a device that can talk over an ethernet network at layer 2.  Ex: send ethernet frames.  If you want TCP or UDP you'd have to implement it in your code and that's rather involved.  DHCP, ACK, DNS, etc....  Me personally I will probably just work with raw frames as my device is not technically designed to go on a computer network, I just chose to use ethernet because it can make use of existing infrastructure such as patch panels, jacks, switches etc.

At least that's the jist of what I've figured out so far, someone correct me if I'm off on something. 

[radiolistener]

Assuming none of that microblaze ... stuff, that's impressive.

I don't use soft processor, ARP, DHCP and ICMP protocols are implemented as hardware state machine in plain verilog.

[radiolistener]

You can use some FPGA chip wih about 6k LE to implement UDP stack connect to PHY chip with GMII or MII.
In many cases there is even no need for MCU, you can do all things in hardware on FPGA.
In case of needs you can even implement your own MCU core on FPGA...

The above is a windup, surely.

How many man-years?

using open-source verilog code from github, UDP + ARP can be setup for your FPGA within several hours.
Adding state machine with DHCP and ICMP can take longer time, but you can also find examples on github.

Look at this implementation: https://github.com/alexforencich/verilog-ethernet
It works very stable and supports 10M/100M/1G/10G/25G link.

[mikeselectricstuff]

If you want to do POE you need a separate chip to control that too.  Make sure you get magnetics that have split transformers as the middle is used for the POE signal.

Unless you need the higher-power flavours of PoE (at/bt), the receive side can be very simple and doesn't need a chip to control - all you need is a couple of rectifiers, a resistor (25K if I recall correctly), and a voltage detector+MOSFET so you don't draw any current until the supply comes up to ~48V
 

[nctnico]

If you want to do POE you need a separate chip to control that too.  Make sure you get magnetics that have split transformers as the middle is used for the POE signal.

Unless you need the higher-power flavours of PoE (at/bt), the receive side can be very simple and doesn't need a chip to control - all you need is a couple of rectifiers, a resistor (25K if I recall correctly), and a voltage detector+MOSFET so you don't draw any current until the supply comes up to ~48V

That is it in a nutshell but gettting the softstart to reset in time due to a short interruption is the tricky part. A good idea is to use a power supervisor (reset) chip to take care of that. The softstart is important to prevent large surges to blow up the ethernet chip and/or damage the contacts on the connector. All in all, you'll end up with a bit of circuitry and using a chip made for POE is just easier.

[kripton2035]

https://www.aliexpress.com/item/4001134936204.html

[Red Squirrel]

If you want to do POE you need a separate chip to control that too.  Make sure you get magnetics that have split transformers as the middle is used for the POE signal.

Unless you need the higher-power flavours of PoE (at/bt), the receive side can be very simple and doesn't need a chip to control - all you need is a couple of rectifiers, a resistor (25K if I recall correctly), and a voltage detector+MOSFET so you don't draw any current until the supply comes up to ~48V
 

Hmm that's a good point. I kinda forgot about this while going down the rabbit hole myself. Of course you will want some form of SMPS and transformer if you want to isolate the power out since it will not be isolated. But if you're only using it to power relays or the MCU itself and the power never leaves the device I don't think isolation is needed.

[peter-h]

Ex: send ethernet frames.  If you want TCP or UDP you'd have to implement it in your code and that's rather involved.  DHCP, ACK, DNS, etc....  Me personally I will probably just work with raw frames as my device is not technically designed to go on a computer network, I just chose to use ethernet because it can make use of existing infrastructure such as patch panels, jacks, switches etc.

Sure, but without TCP and the rest like DHCP you do not have a marketable "ethernet" product.

[mikeselectricstuff]

Ex: send ethernet frames.  If you want TCP or UDP you'd have to implement it in your code and that's rather involved.  DHCP, ACK, DNS, etc....  Me personally I will probably just work with raw frames as my device is not technically designed to go on a computer network, I just chose to use ethernet because it can make use of existing infrastructure such as patch panels, jacks, switches etc.

Sure, but without TCP and the rest like DHCP you do not have a marketable "ethernet" product.

That depends on your product. Artnet for example only needs UDP and ARP.