How to Build a Unified UDP, TCP Client, and TCP Server with W5500 on FPGA?

Summary

This project implements a configurable Ethernet endpoint in pure FPGA logic using a WIZnet W5500. A single Verilog control framework selects UDP, TCP client, or TCP server behavior through a mode input, while the W5500 provides the underlying hardwired TCP/IP processing and eight independent hardware sockets. The FPGA communicates with the W5500 through SPI and exposes received network payloads to application logic through a FIFO-style interface. This architecture is useful for distributed embedded systems that need Ethernet connectivity without introducing a processor-based software TCP/IP stack.

What the Project Does

The project builds an FPGA-side Ethernet controller around the W5500 rather than placing a soft-core CPU and networking software inside the FPGA.

The main architectural path is:

FPGA application logic → Verilog network controller → SPI → W5500 hardware socket → Ethernet

For received data, the direction is reversed:

Ethernet → W5500 socket → SPI → RX FIFO/interface → FPGA application logic

The CSDN implementation combines three operating modes in one logic framework:

• UDP
• TCP client
• TCP server

A two-bit top-level mode input determines which socket behavior the FPGA selects. The article describes the internal controller as a state machine that starts from common socket initialization and then branches according to the required transport mode.

Conceptually, the control flow is:

Reset → Network Configuration → Socket Initialization → Mode Selection

From there:

UDP:
OPEN → SOCK_UDP → Send/Receive

TCP Client:
OPEN → SOCK_INIT → CONNECT → SOCK_ESTABLISHED → Send/Receive

TCP Server:
OPEN → SOCK_INIT → LISTEN → SOCK_LISTEN → Accept Connection → SOCK_ESTABLISHED → Send/Receive

These differences matter because W5500 handles TCP client and server connections differently. For both roles, the socket is first opened in TCP mode. A server then issues LISTEN and waits for an incoming connection, while a client actively initiates a connection to a destination address and port. WIZnet documents these as passive-open and active-open TCP operation respectively.

UDP does not establish a TCP-style connection. The FPGA configures a W5500 socket for UDP, assigns the source port, issues OPEN, and then verifies that the socket status reaches SOCK_UDP.

This makes the unified design suitable for distributed embedded systems where different nodes may have different networking responsibilities. For example, one FPGA endpoint could transmit sensor data through UDP, another could connect as a TCP client to a central collection server, while a maintenance interface could operate as a TCP server.

The article also states that the design can make use of all eight W5500 hardware sockets rather than being restricted to a single network channel. The W5500 itself officially supports eight independent sockets that can operate simultaneously.

Where WIZnet Fits

The exact WIZnet device is the W5500 Hardwired TCP/IP Ethernet Controller.

Its job is to separate the FPGA's application logic from the implementation of TCP/IP.

The W5500 provides hardwired support for TCP, UDP, IPv4, ICMP, ARP, IGMP, and PPPoE, together with an integrated 10/100 Ethernet MAC and PHY. It provides eight independent hardware sockets and 32 KB of internal memory allocated to socket TX and RX buffers. The host FPGA accesses these resources through SPI.

The architectural division is therefore:

FPGA

• Mode selection
• W5500 register control
• Socket-state supervision
• Application data generation
• Application data consumption
• Retry and reconnect policy

W5500

• TCP state and packet processing
• UDP/IP processing
• ARP
• Ethernet MAC
• Ethernet PHY
• Socket TX/RX buffering

This distinction is particularly important when interpreting the original article. The source includes an example macro that appears to construct or inspect protocol-header fields in FPGA logic. However, normal W5500 TCP or UDP socket operation does not require the FPGA to generate Ethernet, IPv4, UDP, or TCP headers manually. Those protocol functions are implemented by the W5500's hardwired stack.

For a W5500-based implementation, the cleaner interface is therefore:

application payload → W5500 socket TX buffer

rather than:

application payload → FPGA TCP/IP packet builder → W5500

The article does not provide enough surrounding RTL to establish why its header-related macros are present, so they should not be treated as a required part of normal W5500 socket control.

Why SPI works well for this FPGA architecture

The source drives the W5500 SPI interface directly from FPGA logic and reports operation at an 80 MHz SPI clock. The W5500 officially supports an SPI host interface up to 80 MHz, using SPI Mode 0 or Mode 3.

Unlike an MCU SPI driver, the FPGA can implement the SPI transaction engine directly as synchronous logic.

A W5500 SPI transaction contains:

Address Phase → Control Phase → Data Phase

The address selects a register or TX/RX memory offset. The control phase selects the W5500 block, read/write direction, and SPI transfer mode. The data phase then transfers the register or socket-buffer content.

That makes W5500 socket access suitable for FPGA state machines because SPI transactions can be represented as predictable hardware states rather than software function calls.

Multi-socket control

The same FPGA SPI engine can control any of the W5500's eight sockets.

Each socket has its own configuration and state registers, including protocol mode, local port, destination address, destination port, command register, status register, and TX/RX buffer information.

A practical distributed-system design could therefore assign sockets by responsibility:

Socket 0: TCP connection to central server
Socket 1: Local TCP configuration server
Socket 2: UDP telemetry
Socket 3: UDP discovery or status
Sockets 4–7: Additional endpoints or reserved services

The exact allocation is application-specific. The important point is that UDP, TCP client, and TCP server behavior does not require three separate TCP/IP implementations. They are different socket-control sequences built on the same W5500 hardware.

Implementation Notes

The accessible source is a CSDN article rather than a browsable source repository. The author states that the complete project was uploaded to GitHub, but an actual repository URL and source-file paths are not exposed in the accessible article. The snippets below are therefore quoted from the published article, with the source path listed as unavailable rather than inferred.

Unified mode state machine

Source path: Not published in the accessible article
Function: Selects the socket initialization path according to the requested network mode.

SOCK_INIT:
    if(tcp_mode) next_state = TCP_HANDSHAKE;
    else next_state = UDP_BIND;

DATA_XFER:
    if(need_retry) next_state = RETRY_WAIT;

The article explains that the top-level design uses a two-bit mode configuration to select UDP, TCP client, or TCP server operation. For TCP server operation, the initialization sequence includes a listening state; TCP client operation follows an active connection path instead.

This state machine exists because the physical SPI interface is common to all three operating modes, while the sequence of W5500 socket commands differs.

A robust implementation should base these transitions on W5500's actual socket status register rather than treating TCP handshake details as something generated directly by FPGA logic. For example, a TCP server should verify SOCK_INIT before issuing LISTEN, while UDP initialization should verify SOCK_UDP after OPEN.

FPGA application interface

The article also provides an example of how the controller is instantiated:

Source path: Not published in the accessible article
Function: Selects TCP client mode and exposes received network data to FPGA logic.

w5500_driver u_driver(
    .clk_80m(sys_clk),
    .mode(2'b01),
    .target_ip(32'hC0_A8_01_64),
    .local_port(16'h1F90)
);

The example selects TCP client mode, configures the target as 192.168.1.100, and assigns port 8080.

The article then describes received data as being exposed through an RX data interface:

always @(posedge data_ready) begin
    recv_data <= rx_data;
    recv_valid <= 1'b1;
end

This interface is important because it isolates the user logic from W5500 register-level operation.

Ideally, FPGA application modules should see a streaming abstraction such as:

rx_data + rx_valid + rx_ready

and:

tx_data + tx_valid + tx_ready

while a lower-level controller handles W5500 socket registers, SPI transfers, TX/RX pointers, socket commands, and connection recovery.

This provides a cleaner boundary for distributed embedded applications because sensor acquisition, DSP, control logic, or FPGA accelerators do not need to understand W5500 register transactions.

Practical Tips / Pitfalls

• Use the W5500 socket-status register as the authoritative connection state. TCP client, TCP server, and UDP each transition through different Sn_SR states. FPGA logic should wait for the expected hardware state before moving to the next operation. 
• Do not duplicate the W5500 TCP/IP engine in RTL unless raw networking is intentionally required. In TCP and UDP socket modes, the FPGA normally transfers application payloads while the W5500 handles TCP, UDP, IPv4, ARP, MAC, and PHY functions. 
• Treat 80 MHz SPI as a board-level timing target, not an automatic guarantee. The article reports successful 80 MHz operation and W5500 supports SPI up to that rate, but FPGA timing closure, output delay, PCB routing, CS timing, and signal integrity still determine whether a particular board can operate reliably. 
• Implement TCP reconnection as an explicit state-machine path. A distributed node must recover from server restart, cable removal, switch reboot, timeout, or remote disconnect without requiring an FPGA reset.
• Allocate the 32 KB W5500 socket memory according to channel traffic. A high-rate TCP data channel may deserve more TX/RX memory than a low-rate configuration socket. Equal allocation across all eight sockets is not mandatory. 
• Use a real FIFO handshake between the W5500 controller and application logic. Triggering application logic directly from an asynchronous or pulse-like data_ready event can complicate timing. A synchronous FIFO or valid/ready interface provides better isolation between SPI transfers and internal FPGA processing.
• Verify the Ethernet PHY link separately from socket state. A socket retry loop cannot repair a missing physical link. Link detection, network configuration, socket initialization, and application reconnect logic should be separate parts of the controller.

FAQ

Q: Why use W5500 instead of implementing Ethernet networking entirely inside the FPGA?

W5500 removes most TCP/IP protocol processing from FPGA logic. It provides hardwired TCP, UDP, IPv4, ARP, eight sockets, 32 KB of network buffer memory, and an integrated 10/100 Ethernet MAC/PHY. The FPGA mainly controls socket state and transfers application payloads through SPI, leaving LUTs, RAM blocks, and development effort available for the actual application.

Q: How does W5500 connect to the FPGA?

The FPGA controls W5500 through SPI using SCLK, MOSI, MISO, and chip-select, with reset and optionally interrupt signals added by the board design. W5500 supports SPI Mode 0 and Mode 3 at up to 80 MHz. Each access consists of an address phase, control phase, and data phase, so the FPGA can implement the interface as a synchronous SPI transaction state machine.

Q: What role does W5500 play in this unified UDP/TCP architecture?

W5500 provides the actual hardware network sockets. FPGA logic selects a socket's mode and commands: UDP sockets are opened for connectionless datagrams, TCP clients actively connect to a remote endpoint, and TCP servers enter a listening state and wait for incoming connections. The same FPGA SPI controller can manage all three behaviors by changing the W5500 socket-control sequence.

Q: Can beginners implement this FPGA W5500 architecture?

It is more suitable for developers who already understand basic Verilog state machines and SPI. The W5500 significantly reduces the networking complexity because the developer does not need to implement TCP itself, but the FPGA still needs reliable SPI timing, register sequencing, TX/RX buffer control, socket-state monitoring, and reconnect handling. Starting with a single UDP socket before adding TCP client, TCP server, and multiple simultaneous sockets is the easier development path.

Q: How does FPGA + W5500 compare with an FPGA soft-core CPU running LwIP?

A soft-core + LwIP architecture executes the TCP/IP stack as software on a processor implemented inside the FPGA. LwIP is specifically designed as a compact embedded TCP/IP stack and supports raw, sequential, and BSD-style socket APIs, but it requires processor execution time, code storage, RAM for protocol state and packet buffers, and usually an Ethernet MAC/PHY integration layer.

With W5500, TCP/IP, Ethernet MAC, PHY, and socket buffering are moved into a dedicated external controller. FPGA logic instead implements SPI control and application-facing data paths. A soft-core + LwIP design offers greater flexibility when custom protocols, IPv6, deep stack modification, or extensive software networking services are required. W5500 is simpler when the requirement is conventional IPv4 TCP/UDP connectivity and FPGA resources are better reserved for deterministic data processing or hardware acceleration.

Source

Original Project Article: FPGA W5500 Three-in-One Driver for UDP, TCP Client, and TCP Server

The article was published on February 26, 2026 and describes a pure-Verilog W5500 controller supporting UDP, TCP client, and TCP server modes, an 80 MHz SPI interface, configurable mode selection, multi-socket operation, retry handling, and an FPGA-facing receive-data interface. The accessible article does not expose the claimed GitHub repository URL or individual RTL file paths.

License: CC BY-SA 4.0. The CSDN article explicitly identifies itself as original content published under the Creative Commons Attribution-ShareAlike 4.0 license.

W5500 Technical Reference: WIZnet official documentation confirms eight independent sockets, 32 KB internal TX/RX memory, hardwired TCP/UDP/IPv4 processing, integrated 10/100 Ethernet MAC/PHY, and an SPI host interface supporting up to 80 MHz.

LwIP Comparison Reference: The official LwIP documentation describes LwIP as an embedded TCP/IP stack designed to minimize RAM requirements while retaining full TCP functionality and provides raw, sequential, and BSD-style socket APIs.

Tags

#W5500 #FPGA #Verilog #UDP #TCPClient #TCPServer #Ethernet #HardwareTCPIP #DistributedSystems #EmbeddedSystems #SPI

FPGA에서 W5500으로 UDP, TCP Client, TCP Server 통합 구조를 구현하는 방법은?

요약

이 프로젝트는 WIZnet W5500을 이용하여 FPGA에서 UDP, TCP Client, TCP Server를 하나의 Verilog 제어 구조로 구현합니다. 상위 로직의 Mode 입력에 따라 필요한 네트워크 동작을 선택하며, 실제 TCP/IP 처리는 W5500의 Hardwired TCP/IP Engine이 담당합니다. FPGA는 SPI를 통해 W5500의 Register와 Hardware Socket을 제어하고, 수신된 Network Payload는 FIFO 형태의 인터페이스를 통해 애플리케이션 로직으로 전달됩니다. 별도의 Soft-Core Processor와 Software TCP/IP Stack을 사용하지 않고도 FPGA에 여러 종류의 Ethernet 연결을 추가할 수 있어 분산 임베디드 시스템의 Network Endpoint 구성에 적합한 구조입니다.

프로젝트가 하는 일

이 프로젝트는 FPGA 내부에 Soft-Core CPU와 Network Software Stack을 구현하는 대신 W5500을 외부 Ethernet Controller로 사용하는 구조입니다.

기본 데이터 경로는 다음과 같습니다.

FPGA Application Logic → Verilog Network Controller → SPI → W5500 Hardware Socket → Ethernet

수신 방향은 반대입니다.

Ethernet → W5500 Hardware Socket → SPI → RX FIFO / Interface → FPGA Application Logic

CSDN의 원본 구현은 다음 세 가지 네트워크 동작을 하나의 Logic Framework에서 처리합니다.

UDP

TCP Client

TCP Server

상위 모듈의 2-bit mode 신호에 따라 FPGA가 사용할 Socket 동작을 결정합니다.

전체적인 State Machine은 공통 Network 및 Socket 초기화를 수행한 후 선택된 Protocol Mode에 따라 각기 다른 Socket 제어 흐름으로 분기합니다.

개념적으로 다음과 같이 구성할 수 있습니다.

Reset → Network Configuration → Socket Initialization → Mode Selection

이후 Protocol별 흐름은 다음과 같습니다.

UDP

OPEN → SOCK_UDP → Send / Receive

TCP Client

OPEN → SOCK_INIT → CONNECT → SOCK_ESTABLISHED → Send / Receive

TCP Server

OPEN → SOCK_INIT → LISTEN → SOCK_LISTEN → Client Connection → SOCK_ESTABLISHED → Send / Receive

이 차이가 중요한 이유는 W5500에서 TCP Client와 TCP Server가 서로 다른 Socket Command Sequence를 사용하기 때문입니다.

TCP Client와 Server 모두 먼저 Socket을 TCP Mode로 열지만, Server는 LISTEN Command를 실행하고 외부 Client의 Connection을 기다립니다.

반대로 TCP Client는 목적지 IP와 Port를 설정한 뒤 CONNECT를 사용해 원격 Server에 능동적으로 연결합니다.

UDP는 TCP와 같은 Connection Establishment 과정이 없습니다.

FPGA는 W5500 Socket을 UDP Mode로 설정하고 Local Port를 구성한 후 OPEN을 실행합니다. 이후 Socket Status가 SOCK_UDP 상태인지 확인한 뒤 데이터를 송수신할 수 있습니다.

따라서 하나의 FPGA Network Controller를 이용해 분산 시스템 내에서 서로 다른 역할을 갖는 Node를 구성할 수 있습니다.

예를 들어 센서 Node는 UDP를 통해 데이터를 지속적으로 전송할 수 있고, 데이터 수집 Node는 중앙 Server에 TCP Client로 연결할 수 있습니다. 동시에 별도의 Socket을 TCP Server로 운영하여 설정이나 유지보수용 Interface를 제공할 수도 있습니다.

원본 프로젝트에서는 W5500이 제공하는 8개의 Hardware Socket을 활용할 수 있도록 설계되었습니다.

즉 하나의 Network Channel에 제한되지 않고 여러 TCP 및 UDP 연결을 동시에 구성할 수 있습니다.

WIZnet은 어디에 사용되는가

이 프로젝트에서 사용되는 WIZnet 제품은 W5500 Hardwired TCP/IP Ethernet Controller입니다.

W5500의 핵심 역할은 FPGA Application Logic과 TCP/IP Protocol 처리를 분리하는 것입니다.

W5500은 다음 기능을 하드웨어로 제공합니다.

TCP

UDP

IPv4

ARP

ICMP

IGMP

PPPoE

Ethernet MAC

10/100 Ethernet PHY

8개의 Hardware Socket

총 32 KB의 TX/RX Socket Buffer Memory

FPGA는 SPI를 이용해 W5500의 Register 및 Socket Buffer에 접근합니다.

따라서 기능을 다음과 같이 분리할 수 있습니다.

FPGA가 담당하는 부분

UDP / TCP Client / TCP Server Mode 선택

W5500 Register 제어

Socket State Monitoring

Application Payload 생성

수신 데이터 처리

Retry 및 Reconnection 정책

W5500이 담당하는 부분

TCP Connection State 처리

TCP Packet 처리

UDP/IP 처리

ARP 처리

Ethernet MAC

Ethernet PHY

Socket TX/RX Buffer 관리

이 역할 분리를 명확히 이해하는 것이 중요합니다.

원본 글에는 FPGA에서 Ethernet, IP, TCP 또는 UDP Header와 관련된 데이터를 직접 구성하거나 분석하는 것으로 보이는 RTL Macro가 일부 제시되어 있습니다.

하지만 W5500의 일반적인 TCP 또는 UDP Hardware Socket Mode에서는 FPGA가 Ethernet, IPv4, TCP, UDP Header를 직접 생성할 필요가 없습니다.

이러한 Protocol Processing은 W5500 내부의 Hardwired TCP/IP Stack이 담당합니다.

따라서 W5500을 사용하는 기본적인 데이터 흐름은 다음과 같이 구성하는 것이 더 자연스럽습니다.

Application Payload → W5500 Socket TX Buffer

다음과 같은 구조가 필수적인 것은 아닙니다.

Application Payload → FPGA TCP/IP Packet Builder → W5500

접근 가능한 원본 자료만으로는 해당 Header 관련 RTL이 어떤 별도의 목적으로 포함되었는지 확인할 수 없으므로, 일반적인 W5500 Socket 제어에 필요한 기능으로 해석해서는 안 됩니다.

FPGA에서 SPI Interface를 사용하는 이유

원본 프로젝트는 FPGA에서 W5500 SPI Interface를 직접 구동합니다.

작성자는 80 MHz SPI Clock으로 동작한다고 설명하며, 이는 W5500이 지원하는 최대 SPI Clock 범위와 일치합니다.

MCU에서는 SPI Driver가 Software Function 형태로 구현되는 경우가 많지만 FPGA에서는 SPI Protocol 자체를 Synchronous State Machine으로 구현할 수 있습니다.

일반적인 W5500 SPI Transaction은 다음 단계로 구성됩니다.

Address Phase → Control Phase → Data Phase

Address Phase에서는 접근할 Register 또는 TX/RX Buffer Address를 지정합니다.

Control Phase에서는 다음 항목을 지정합니다.

접근할 W5500 Block

Read / Write 방향

SPI Transfer Mode

마지막 Data Phase에서 실제 Register 또는 Socket Buffer 데이터를 송수신합니다.

이 구조는 FPGA Logic에 적합합니다.

각 SPI Transaction을 명확한 State로 구분하여 Hardware State Machine으로 구현할 수 있기 때문입니다.

여러 Socket을 하나의 Controller에서 관리하기

FPGA의 동일한 SPI Engine을 이용해 W5500의 8개 Hardware Socket을 모두 제어할 수 있습니다.

각 Socket은 독립적인 설정과 상태를 갖습니다.

대표적인 Socket 관련 정보에는 다음이 포함됩니다.

Protocol Mode

Local Port

Destination IP Address

Destination Port

Socket Command

Socket Status

TX Buffer Information

RX Buffer Information

분산 임베디드 시스템에서는 다음과 같이 Socket별 역할을 정할 수도 있습니다.

Socket 0: 중앙 Server 연결용 TCP Client
Socket 1: 설정용 Local TCP Server
Socket 2: Telemetry UDP Channel
Socket 3: Discovery 또는 Status UDP Channel
Socket 4–7: 추가 서비스 또는 향후 확장용

실제 Socket 배치는 애플리케이션 요구에 따라 달라집니다.

중요한 점은 UDP, TCP Client, TCP Server를 위해 각각 별도의 TCP/IP Engine을 FPGA에 구현할 필요가 없다는 것입니다.

모두 동일한 W5500 Hardware Socket을 사용하며, FPGA에서 Socket Command Sequence만 다르게 제어하면 됩니다.

구현 참고 사항

접근 가능한 원본은 CSDN 기술 글이며 전체 Source Repository를 직접 확인할 수 있는 형태는 아닙니다.

글에서는 전체 프로젝트가 GitHub에 업로드되었다고 설명하지만, 현재 확인 가능한 본문에서는 실제 Repository URL과 개별 RTL File Path를 확인할 수 없습니다.

따라서 다음 코드는 게시된 기술 글에서 확인되는 예제이며 실제 파일 경로를 임의로 지정하지 않습니다.

통합 Mode State Machine

Source Path: 접근 가능한 원본 자료에서 확인되지 않음
기능: 선택된 Network Mode에 따라 Socket 초기화 및 동작 경로를 결정

SOCK_INIT:
    if(tcp_mode) next_state = TCP_HANDSHAKE;
    else next_state = UDP_BIND;

DATA_XFER:
    if(need_retry) next_state = RETRY_WAIT;

원본 프로젝트는 상위의 2-bit mode 설정을 이용해 UDP, TCP Client, TCP Server를 선택합니다.

실제 세 Mode가 공유하는 부분은 W5500 SPI Interface와 기본 Socket Register Access이며, 차이는 Socket Command Sequence에서 발생합니다.

TCP Server에서는 LISTEN 과정이 필요하고, TCP Client에서는 Active Connection 과정이 필요합니다.

UDP에서는 Connection Handshake 없이 Socket을 열고 바로 Datagram 송수신 상태로 이동합니다.

실제 구현에서는 추상적인 TCP_HANDSHAKE 상태만을 기준으로 하기보다 W5500의 Sn_SR Socket Status Register를 확인하면서 상태를 전환하는 것이 중요합니다.

예를 들어 TCP Server에서는 OPEN 이후 SOCK_INIT 상태가 확인된 뒤 LISTEN을 실행해야 합니다.

UDP에서는 OPEN 이후 SOCK_UDP 상태인지 확인해야 합니다.

FPGA Application Interface

원본 자료에서는 다음과 같은 Controller Instantiation 예제를 제공합니다.

Source Path: 접근 가능한 원본 자료에서 확인되지 않음
기능: TCP Client Mode를 선택하고 Network Parameter를 전달

w5500_driver u_driver(
    .clk_80m(sys_clk),
    .mode(2'b01),
    .target_ip(32'hC0_A8_01_64),
    .local_port(16'h1F90)
);

이 예에서는 TCP Client Mode를 선택하고 IP 192.168.1.100과 Port 8080을 설정합니다.

수신 데이터는 다음과 같이 FPGA Application Logic으로 전달하는 형태도 제시됩니다.

always @(posedge data_ready) begin
    recv_data <= rx_data;
    recv_valid <= 1'b1;
end

이와 같은 Interface가 중요한 이유는 FPGA Application Logic을 W5500 Register-Level Control과 분리할 수 있기 때문입니다.

실제 설계에서는 Application Module이 다음과 같은 Streaming Interface만 바라보도록 구성하는 것이 관리하기 쉽습니다.

RX

rx_data + rx_valid + rx_ready

TX

tx_data + tx_valid + tx_ready

하위 W5500 Controller에서는 다음 기능을 담당합니다.

SPI Transfer

W5500 Register Access

Socket Command

TX/RX Buffer Pointer 관리

Connection State Monitoring

Reconnection

상위 Application Logic은 다음과 같은 실제 시스템 기능에 집중할 수 있습니다.

Sensor Data Acquisition

DSP

Control Logic

FPGA Accelerator

Data Formatting

이러한 계층 분리는 여러 FPGA Node가 네트워크로 연결되는 분산 임베디드 시스템에서 특히 유용합니다.

실용적인 팁과 주의사항

W5500의 Socket Status Register를 실제 Connection State의 기준으로 사용하는 것이 좋습니다. UDP, TCP Client, TCP Server는 각각 서로 다른 Sn_SR 상태를 사용합니다. FPGA State Machine은 Command 실행 후 예상되는 Hardware State를 확인한 뒤 다음 단계로 진행해야 합니다.

특별한 목적이 없다면 W5500이 이미 처리하는 TCP/IP 기능을 RTL에서 다시 구현할 필요가 없습니다. 일반적인 TCP/UDP Socket Mode에서는 FPGA가 Application Payload를 전달하면 W5500이 TCP, UDP, IPv4, ARP, MAC 및 PHY 기능을 담당합니다.

80 MHz SPI를 모든 보드에서 자동으로 보장되는 값으로 생각해서는 안 됩니다. W5500이 최대 80 MHz SPI를 지원하고 원본 프로젝트도 해당 속도를 사용한다고 설명하지만, 실제 안정성은 FPGA Timing Closure, PCB Routing, Output Delay, CS Timing 및 Signal Integrity에 따라 달라집니다.

TCP Reconnection을 별도의 State Machine 경로로 구현해야 합니다. 중앙 Server 재시작, Ethernet Cable 분리, Network Switch 재부팅, Timeout 또는 Remote Disconnect가 발생하더라도 FPGA 전체를 Reset하지 않고 Socket을 복구할 수 있어야 합니다.

W5500의 32 KB Socket Memory는 Channel 특성에 따라 배분해야 합니다. 고속 TCP Data Channel에는 더 많은 TX/RX Buffer를 할당하고, 낮은 대역폭의 Configuration Channel에는 작은 Buffer를 할당할 수 있습니다. 모든 Socket에 동일한 크기를 할당할 필요는 없습니다.

W5500 Controller와 Application Logic 사이에는 동기식 FIFO 또는 Valid/Ready Handshake를 사용하는 것이 좋습니다. 단순히 비동기적인 data_ready Edge에 의존하면 Timing Analysis와 Clock Domain 처리가 복잡해질 수 있습니다.

Ethernet PHY Link 상태와 Socket State를 분리해서 관리해야 합니다. Physical Link가 끊어진 상태에서는 Socket Retry만 반복해도 Connection이 복구되지 않습니다. Link Detection, Network Configuration, Socket Initialization, Application Reconnection을 별도의 단계로 설계하는 것이 좋습니다.

FAQ

Q: FPGA 내부에서 Ethernet Network Stack을 직접 구현하지 않고 W5500을 사용하는 이유는 무엇인가요?

W5500은 TCP, UDP, IPv4, ARP 등 대부분의 일반적인 Network Protocol Processing을 전용 Hardware에서 처리합니다. 또한 8개의 Hardware Socket, 총 32 KB의 Network Buffer Memory, 10/100 Ethernet MAC 및 PHY를 제공합니다. FPGA에서는 SPI와 Socket Control Logic만 구현하면 되므로 LUT, Block RAM 및 개발 시간을 실제 데이터 처리나 Hardware Acceleration에 사용할 수 있습니다.

Q: W5500은 FPGA와 어떻게 연결되나요?

W5500은 SPI를 이용해 FPGA와 연결합니다. 기본 신호는 SCLK, MOSI, MISO, Chip Select이며, 보드 설계에 따라 Reset 및 Interrupt 신호도 함께 사용할 수 있습니다. FPGA는 Address Phase, Control Phase, Data Phase로 구성되는 W5500 SPI Transaction을 State Machine으로 구현할 수 있습니다.

Q: 이 통합 UDP/TCP 구조에서 W5500은 정확히 어떤 역할을 하나요?

W5500은 실제 Network Hardware Socket을 제공합니다. UDP Mode에서는 Connectionless Datagram을 송수신하고, TCP Client Mode에서는 FPGA의 제어에 따라 원격 Server로 Connection을 시작하며, TCP Server Mode에서는 LISTEN 상태에서 외부 Client 연결을 기다립니다. FPGA는 각 Mode에 필요한 Socket Command Sequence를 선택하고, 실제 TCP/IP Packet Processing은 W5500이 담당합니다.

Q: 초보자도 FPGA + W5500 구조를 구현할 수 있나요?

기본적인 Verilog State Machine과 SPI에 대한 경험이 있다면 접근할 수 있지만, 완전한 구현은 중급 수준의 FPGA 개발에 가깝습니다. TCP 자체를 RTL로 구현할 필요는 없지만 W5500 Register Sequence, Socket Status, TX/RX Buffer Control, SPI Timing 및 Reconnection 처리를 이해해야 합니다. 처음에는 하나의 UDP Socket부터 구현하고 이후 TCP Client, TCP Server, Multi-Socket 구조로 확장하는 것이 현실적인 접근 방법입니다.

Q: FPGA + W5500 구조는 Soft-Core CPU에서 LwIP를 실행하는 방식과 어떻게 다른가요?

Soft-Core + LwIP 방식에서는 FPGA 내부에 Processor를 구현하고 그 위에서 Software TCP/IP Stack을 실행합니다. 따라서 Network Protocol 처리에 CPU 실행 시간, Program Memory, RAM 및 Packet Buffer가 필요하며 Ethernet MAC과 PHY를 연결하기 위한 별도의 Integration도 필요합니다.

반면 W5500을 사용하면 TCP/IP, Socket Buffer, Ethernet MAC 및 PHY 기능을 외부 전용 Controller에 분리할 수 있습니다. FPGA는 SPI Controller와 Application Data Path 구현에 집중하면 됩니다.

Soft-Core + LwIP는 Network Stack을 직접 수정하거나 복잡한 Software Service를 추가하거나 더 높은 Protocol Flexibility가 필요한 경우 유리합니다.

W5500은 일반적인 IPv4 기반 TCP/UDP 통신이 목적이고 FPGA Resource를 Signal Processing, Control 또는 Hardware Acceleration에 더 많이 사용하려는 시스템에서 구조가 단순합니다.

Trade-off는 외부 W5500 IC가 추가되고 FPGA와 W5500 사이의 SPI Throughput을 고려해야 한다는 점입니다.

출처

Original Project Article:
CSDN — FPGA W5500 Three-in-One Driver for UDP, TCP Client, and TCP Server

원본 주소:
https://blog.csdn.net/NBhhbYyOljP/article/details/158423092

원본 기술 글은 Pure-Verilog 기반 W5500 Controller에서 UDP, TCP Client, TCP Server Mode를 통합하고, 80 MHz SPI Interface, Mode Selection, Multi-Socket Operation, Retry 처리 및 FPGA Application 측 Receive Data Interface를 구현하는 구조를 설명합니다.

접근 가능한 글에서는 전체 프로젝트가 GitHub에 업로드되었다고 설명하지만 실제 Repository URL과 개별 RTL Source File Path는 확인되지 않습니다.

W5500 Technical Reference:
WIZnet W5500 Official Documentation

WIZnet 공식 자료에서는 8개의 Hardware Socket, 총 32 KB의 TX/RX Memory, Hardwired TCP/UDP/IPv4 Processing, 10/100 Ethernet MAC/PHY 및 최대 80 MHz SPI Host Interface를 확인할 수 있습니다.

LwIP Comparison Reference:
Official LwIP Documentation

LwIP는 Embedded System을 위한 Lightweight TCP/IP Software Stack으로, RAM 사용량을 줄이면서 TCP 기능을 제공하도록 설계되어 있으며 Raw API, Sequential API 및 BSD-style Socket API를 지원합니다.

License: CC BY-SA 4.0

원본 CSDN 글은 작성자가 Original Content로 표시했으며 Creative Commons Attribution-ShareAlike 4.0 License를 명시하고 있습니다.

태그

#W5500 #FPGA #Verilog #UDP #TCPClient #TCPServer #Ethernet #HardwareTCPIP #DistributedSystems #EmbeddedSystems #SPI