Wiznet makers

상위프로젝트  존재 

상위 프로젝트와의 관계: 이 글이 다루는 daanders03/SCIS_DataConcentrator는 더 큰 SCIS 프로젝트인 HTI-OVGU/FPGA-centric-SCIS(마그데부르크대 HTI 연구실, MIT)의 데이터 컨센트레이터(Data Concentrator) 구현에 특화된 저장소입니다. 

상위 프로젝트는 SCIS를 "관리 감시 유닛(Supervisory Monitoring Unit)"이라는 전체 아키텍처 관점에서 기술하고, 이식성(여러 FPGA로 포팅 가능한 HDL 설계)을 강조합니다. 즉 상위 = 전체 SCIS 아키텍처, 이 글 = 그 안의 데이터 컨센트레이터 상세로 보시면 됩니다. (상위 프로젝트 소개 글: viktor / https://maker.wiznet.io/viktor/projects/fpga-centric-slow-control-interlock-system-scis -  https://github.com/HTI-OVGU/FPGA-centric-SCIS)

프로젝트가 하는 일

SCIS(Slow Control Interlock System) 는 여러 계측 장비에서 오는 측정값을 한곳에 모아, 임계값을 넘으면 즉시 인터록(안전 차단) 신호를 발생시키는 FPGA 기반 안전 감시 시스템입니다. 핵심은 Cologne Chip GateMate M1A1 FPGA 에 구현된 데이터 컨센트레이터(Data Concentrator) 이고, 데이터 입출력은 WIZnet W5500 이더넷이 담당합니다. (물리 실험·가속기·검출기 계열의 "슬로 컨트롤 + 인터록" 용도로 보입니다.)

동작 흐름:

• Metric Provider / DAQ 들이 측정값을 Metric Packet으로 만들어 전송 — 패킷 = 프로토콜 코드(V01) + 장치 식별자 + 측정값(Q22.10 부호 고정소수점)
• 이 패킷이 W5500을 통해 UDP로 GateMate FPGA에 도착
• FPGA의 Data Concentrator가 받아 Threshold Logic Unit(임계값 로직) 으로 판정 → 초과 시 저지연·결정적 인터록 발생
• 상태는 소프트웨어(Prometheus + Grafana)로 모니터링

COMPONENTS

WIZnet이 들어가는 위치

이 프로젝트의 이더넷 플랫폼은 W5500이며, 특징적으로 두 개(듀얼) 를 사용합니다.

• 역할: 계측 장비의 Metric Packet을 UDP로 수신해 FPGA 데이터 컨센트레이터에 공급하고, 경보/텔레메트리를 송신
• 듀얼 구성: 하나는 RX(수신) 전용, 하나는 TX(송신) 전용 — 각각 PMOD 핀에 SPI로 연결해 송·수신 처리량을 분리 확보
• 구현 확인된 것(README "Working"): W5500 컨트롤러(UDP)에서 8개 소켓 라운드로빈, send_first/receive_first 기본 루틴, RX·TX W5500 분리 운용, 40MHz FPGA sys_clk에서 동작
• 테스트 구성: GateMate M1A1 Eval Board V3.2 + W5500 모듈 2개 + 외부 인터록 테스트용 ESP32 1개

즉 W5500은 이 안전 인터록 시스템에서 계측 데이터를 이더넷(UDP)으로 실어 나르는 통신 계층이며, 하드웨어 TCP/IP·8소켓·32KB 버퍼를 활용해 FPGA가 판정 로직에 집중하도록 합니다.

ESP32는 왜 쓰나요? (테스트용 보조 장치)

혼동하기 쉬운데, 이 시스템에서 ESP32는 핵심 부품이 아니라 개발·검증용 보조 장치입니다. README의 테스트 구성에 "외부 인터록 assertion 테스트(external interlock assertion testing)"용으로 명시돼 있습니다.

• SCIS의 안전 기능 중 하나는 "외부에서 인터록 신호가 들어오면 즉시 차단"하는 것입니다(FPGA에 외부 인터록 입력 + 히스테리시스 글리치 필터 존재).
• 이 기능을 개발·시험하려면 인터록 신호를 실제로 만들어 넣어줄 무언가가 필요합니다. 진짜 계측 장비를 붙이기 전에요.
• 그 역할을 ESP32가 대신합니다 — 즉 가짜 외부 인터록 신호를 발생시켜 FPGA가 제대로 차단하는지 확인하는 "신호 자극기(stimulus)" 입니다.

정리하면, 계측 데이터의 본류는 전부 W5500(UDP) 이 담당하고 ESP32는 관여하지 않습니다. ESP32는 운용 필수 요소가 아니라, 동작 검증을 위한 테스트 도구입니다

데이터 컨센트레이터 (FPGA 내부)

• 8-bit AXI-stream 기반 데이터 흐름
• Threshold Logic Unit: 저지연·결정적 인터록 assertion
• 외부 인터록 신호용 히스테리시스 글리치 필터
• 8단계 우선순위(3-bit USER 필드), Priority FIFO에서 최고 우선순위 우선 readout
• Telemetry Sender: 이상 시 "INTERLOCK" / "ALMOSTFULL" 경보 전송
• 새 장치 추가는 threshold_address_generator.py로 Threshold Lookup Memory에 등록

아래 순서로 신호가 흐릅니다.

1. 입력단: 여러 Metric Source(계측 소스 0·1·…·n) 와 Ethernet Interface RX Side(W5500 수신)가 데이터를 올려보냅니다. 별도로 External Interlock Signal Source(외부 인터록 신호원)가 오른쪽 경로로 들어옵니다.
2. Threshold Logic 0~n: 각 계측 소스는 자기 임계값 로직을 거쳐 "한계를 넘었는가?"를 판정합니다. 외부 인터록 신호는 옆의 Glitch Filter(히스테리시스 글리치 필터) 를 거쳐 순간 잡음이 걸러집니다.
3. 첫 번째 Demux: 판정 결과가 우선순위/목적지에 따라 갈라집니다.
4. Round Robin Arbitration & Selection of Priority FIFO: 여러 입력을 라운드로빈으로 공평하게 훑어, 어떤 Priority FIFO에 넣을지 고릅니다.
5. Mux → Priority FIFO 0~n: 선택된 경로가 우선순위별 FIFO(대기열) 에 적재됩니다. 우선순위는 8단계(3-bit)입니다.
6. Priority Scheduling Logic + Demux: 스케줄링 로직이 가장 높은 우선순위부터 꺼내도록 제어합니다.
7. Metric Packet Manager: 위 과정(라운드로빈 수집 → 우선순위 FIFO → 우선순위 스케줄링)을 묶는 관리 블록입니다.
8. Telemetry Sender: 최종적으로 상태·경보(예: "INTERLOCK", "ALMOSTFULL")를 만들어 Ethernet Interface TX Side(W5500 송신)로 내보냅니다.
9. Further Interlock Processing: 외부 인터록 신호원과 글리치 필터를 지난 인터록 경로(그림 오른쪽의 빨간 선)는 별도의 후속 인터록 처리 블록으로 이어져, 계측 데이터 경로와 독립적으로 안전 차단을 담당합니다.

핵심은 두 가지입니다. 첫째, 계측 데이터(왼쪽)와 외부 인터록 신호(오른쪽)가 분리된 경로로 처리되어, 인터록이 데이터 혼잡과 무관하게 결정적으로 동작합니다. 둘째, 입력은 W5500 RX, 출력은 W5500 TX로 나뉘어(듀얼 구성) 수신 계측과 송신 경보가 서로 방해하지 않습니다.

구현 메모

• 툴체인: OSS-CAD-Suite(YosysHQ, Build 21-01-2026 테스트) — 합성·구현·비트스트림 패킹·업로드. 시뮬레이션은 GHDL + GTKwave.
• 빌드: make all(PMOD의 두 W5500용 데이터 컨센트레이터 빌드) · make w5500_all(W5500 기능 테스트) · make sim_spimaster/sim_w5500/sim_dc/sim_all(시뮬레이션)
• 비트스트림: 64Mb SPI 플래시(quad 모드)에 업로드해 빠르게 재구성
• 언어: Verilog ~73% / VHDL ~24% (하드웨어 설계 중심) + Python

알려진 이슈 / 개발 단계

• 버그(README 명시): RX용 W5500이 2KB RX 버퍼를 초과하는 UDP 폭주 시 소켓을 닫는 경우가 있음
• 백로그: TCP 패킷용 W5500 컨트롤러(AXI-stream tdata에서 UDP 헤더 제거) 추가 예정
• 초기 단계(커밋 7, 스타 0, 릴리스 없음). 저장소에 아키텍처 그림(etc/figure/), 재구성 시간 자료(.xlsx), 배치도(placed.svg) 포함.

유사 프로젝트

두 관점으로 나눠 정리했습니다 — (A) 같은 플랫폼(FPGA + W5500) 과 (B) 하는 일이 비슷한 프로젝트(계측 집약·산업 모니터링·안전 제어). 모두 maker.wiznet.io에 실재하는 글입니다.

(A) 같은 플랫폼 — FPGA + W5500

1. FPGA + W5500 Control Unit (mark) — https://maker.wiznet.io/mark/projects/fpga-w5500-control-unit/ Spartan-6 XC6SLX150 + W5500을 중앙 제어로 쓰는 8채널 종합 계측·제어 시스템. 측정 데이터를 기록·해석·저장·전달합니다.
2. EasyDAB v2 (Lihan__) — https://maker.wiznet.io/Lihan__/projects/ethernet-interface-dab-dab-modulator-with-wiznet-w5500--easydab-v2/ Xilinx XC6SLX9 FPGA + W5500 SPI로 HW TCP/IP 오프로드, PicoBlaze6 소프트 CPU + AXI4-Stream 파이프라인(구조가 SCIS와 유사, 용도는 DAB 방송 변조).
3. Firewall on FPGA (irina) — https://maker.wiznet.io/irina/projects/firewall-on-fpga/ FPGA에서 W5500을 SPI로 구동해 네트워크 패킷을 하드웨어로 처리(SCIS는 계측 인터록, 이쪽은 인라인 필터링).
4. TCP/IP stack design based on FPGA and W5500 (WIZnet Makers) — https://maker.wiznet.io/2019/04/26/tcp-ip-stack-design-based-on-fpga-and-embedded-ethernet-w5500/ FPGA가 W5500을 TCP/IP 서버로 구동해 상위 PC와 명령·데이터를 주고받는 기본 예제.

(B) 비슷한 용도 — 계측 집약 · 산업 모니터링 · 안전 제어 (플랫폼 무관)

FPGA/W5500 여부와 무관하게, "여러 계측 데이터를 이더넷으로 모아 → 판정/제어" 라는 SCIS의 목적과 닮은 프로젝트들입니다.

1. How to Design a Super Simple Sensor System for Industrial Monitoring (ssekim) — https://maker.wiznet.io/ssekim/projects/how-to-design-a-super-simple-sensor-system-for-industrial-monitoring-applications/ 산업 모니터링용 모듈형 센서 시스템의 이더넷 서브시스템. 센서 데이터를 이더넷으로 집약하는 부분이 SCIS의 계측 집약과 가장 유사.
2. Securing Industrial PLCs with WIZnet W5500 — Open-Source IoT Gateway (Benjamin) — https://maker.wiznet.io/Benjamin/projects/securing-industrial-plcs-with-wiznet-w5500-an-open-source-iot-gateway-solution/ PLC 데이터를 추출해 W5500 이더넷으로 안전하게 전송하는 산업 IoT 게이트웨이. HW TCP/IP 오프로드로 MCU가 실시간 작업에 집중, 유선으로 안정적 모니터링·제어 — SCIS의 저지연·결정적 처리와 통함.
3. Communication with Siemens PLC using M5Stack W5500 LAN Module (Benjamin) — https://maker.wiznet.io/Benjamin/projects/communication-with-siemens-plc-using-m5stack-w5500-lan-module-m5stacklansiemensplc/ 산업 제어기(Siemens PLC)의 계측/상태 데이터를 이더넷으로 수집·시각화. SCIS의 계측 수집 목적과 유사.
4. TNN Smart Control (anhtn1980) — 2계층 LAN으로 명령을 받아 RS485 릴레이(장비)를 제어하는 시스템. "네트워크로 받은 판단 → 물리 장비 안전 제어"라는 흐름이 SCIS의 인터록(차단)과 유사.

FAQ

Q: 이 프로젝트는 무엇인가요? A: GateMate FPGA에 데이터 컨센트레이터를 구현해, 계측 데이터를 모아 임계값 초과 시 저지연 인터록(안전 차단)을 내는 슬로 컨트롤 시스템입니다.

Q: W5500은 어떻게 쓰이나요? A: 두 개를 써서 하나는 UDP 수신(RX), 하나는 송신(TX) 전용으로 PMOD에 SPI 연결합니다. 계측 Metric Packet을 UDP로 받아 FPGA에 공급합니다.

Q: 왜 W5500을 두 개 쓰나요? A: 수신과 송신을 물리적으로 분리해 처리량과 결정성을 확보하기 위해서입니다(RX 전용·TX 전용).

Q: 완성된 제품인가요? A: 아니요. 개발 초기 단계이며, RX 버퍼 초과 시 소켓이 닫히는 버그와 TCP 컨트롤러 추가가 백로그에 있습니다.

Q: ESP32는 왜 들어가나요? A: 핵심 부품이 아니라 테스트 전용 보조 장치입니다. 외부 인터록 신호를 흉내 내 FPGA가 제대로 차단하는지 검증하는 용도이며, 실제 계측 데이터 전달은 전부 W5500이 담당합니다.

What the Project Does

SCIS (Slow Control Interlock System) is an FPGA-based safety-monitoring system that aggregates measurements from multiple instruments and asserts an interlock (safety cutoff) the moment a threshold is exceeded. Its core is a Data Concentrator on a Cologne Chip GateMate M1A1 FPGA, with the WIZnet W5500 as the Ethernet platform. (It reads like a "slow control + interlock" system for physics experiments / accelerators / detectors.)

Flow:

• Metric Providers / DAQ send measurements as Metric Packets — packet = protocol code (V01) + device identifier + value (Q22.10 signed fixed-point)
• Packets arrive over UDP via the W5500 to the GateMate FPGA
• The FPGA Data Concentrator evaluates them in Threshold Logic Units → on exceedance, a low-latency deterministic interlock fires
• Status is monitored in software (Prometheus + Grafana)

Where WIZnet Fits

The Ethernet platform is the W5500, and notably it uses two of them (dual).

• Role: receive Metric Packets over UDP and feed the FPGA data concentrator; send alerts/telemetry
• Dual setup: one W5500 for RX, one for TX, each connected over SPI on PMOD pins, separating receive/transmit throughput
• Working (per README): W5500 controller (UDP) with round-robin over 8 sockets, send_first/receive_first default routines, separate RX/TX W5500 operation, running at a 40 MHz FPGA sys_clk
• Test rig: GateMate M1A1 Eval Board V3.2 + two W5500 modules + one ESP32 for external interlock-assertion testing

So the W5500 is the transport layer that carries measurement data over Ethernet (UDP), using its hardware TCP/IP, 8 sockets, and 32 KB buffer so the FPGA can focus on the decision logic.

Why an ESP32? (a test-only helper)

It's easy to misread, but the ESP32 here is not a core component — it's a development/verification helper. The README lists it for "external interlock assertion testing."

• One of SCIS's safety features is to assert an interlock the moment an external interlock signal arrives (the FPGA has an external-interlock input plus a hysteresis glitch filter).
• To develop and test that, you need something that actually generates an interlock signal — before wiring up real instruments.
• The ESP32 plays that role: a stimulus that injects a mock external-interlock signal to check that the FPGA cuts off correctly.

In short, all real measurement traffic goes through the W5500 (UDP); the ESP32 isn't involved in it. The ESP32 is a test tool for verification, not a required part of the deployed system.

Data Concentrator (inside the FPGA)

• 8-bit AXI-stream data flow
• Threshold Logic Units: low-latency deterministic interlock assertion
• Hysteresis glitch filter for external interlock signals
• 8 priority levels (3-bit USER field); highest-priority-first readout from Priority FIFOs
• Telemetry Sender: emits "INTERLOCK" / "ALMOSTFULL" alerts
• New devices are added to the Threshold Lookup Memory via threshold_address_generator.py

Data flows from the inputs at the bottom to the outputs at the top.

1. Inputs: several Metric Sources (0, 1, …, n) and the Ethernet Interface RX Side (W5500 receive) feed data upward. Separately, an External Interlock Signal Source enters on the right-hand path.
2. Threshold Logic 0–n: each metric source passes through its own threshold logic to decide "is the limit exceeded?" The external interlock signal passes through the adjacent Glitch Filter (hysteresis) to reject transient noise.
3. First Demux: results are split by priority/destination.
4. Round Robin Arbitration & Selection of Priority FIFO: sweeps the inputs fairly round-robin and chooses which Priority FIFO to write to.
5. Mux → Priority FIFO 0–n: the selected path is queued into a per-priority FIFO (8 levels, 3-bit).
6. Priority Scheduling Logic + Demux: the scheduler controls readout highest-priority first.
7. Metric Packet Manager: the block that bundles the above (round-robin collection → priority FIFOs → priority scheduling).
8. Telemetry Sender: finally builds status/alerts (e.g., "INTERLOCK", "ALMOSTFULL") and sends them out via the Ethernet Interface TX Side (W5500 transmit).
9. Further Interlock Processing: the interlock path (red lines on the right, from the external signal source through the glitch filter) leads to a separate further interlock processing block, handling safety cutoff independently of the measurement-data path.

Two key points: first, measurement data (left) and the external interlock signal (right) are processed on separate paths, so the interlock stays deterministic regardless of data congestion. Second, inputs use the W5500 RX and outputs use the W5500 TX (dual setup), so received measurements and outbound alerts don't interfere.

Implementation Notes

• Toolchain: OSS-CAD-Suite (YosysHQ, tested Build 21-01-2026) for synthesis/implementation/bitstream; GHDL + GTKwave for simulation.
• Build: make all (data concentrator for the two PMOD W5500s), make w5500_all (W5500 functional test), make sim_spimaster/sim_w5500/sim_dc/sim_all (simulations)
• Bitstream: uploaded to a 64 Mb SPI flash (quad mode) for fast reconfiguration
• Languages: Verilog ~73% / VHDL ~24% (hardware-centric) + Python

Known Issues / Project State

• Bug (README): the RX W5500 sometimes closes a socket when bombarded with UDP packets exceeding the 2 KB RX buffer
• Backlog: a TCP-packet W5500 controller (strips the UDP header from AXI-stream tdata) is planned
• Early stage (7 commits, 0 stars, no releases). Repo includes architecture figures (etc/figure/), reconfiguration-time data (.xlsx), and a placement view (placed.svg).

Similar Projects

Grouped two ways — (A) same platform (FPGA + W5500) and (B) similar purpose (measurement aggregation · industrial monitoring · safety control). All are real maker.wiznet.io posts.

(A) Same platform — FPGA + W5500

1. FPGA + W5500 Control Unit (mark) — https://maker.wiznet.io/mark/projects/fpga-w5500-control-unit/ A Spartan-6 XC6SLX150 + W5500 as the central controller of an 8-channel measurement & control system, recording/interpreting/storing/forwarding data.
2. EasyDAB v2 (Lihan__) — https://maker.wiznet.io/Lihan__/projects/ethernet-interface-dab-dab-modulator-with-wiznet-w5500--easydab-v2/ Xilinx XC6SLX9 FPGA with W5500 SPI hardware TCP/IP off-load, a PicoBlaze6 soft CPU and an AXI4-Stream pipeline (structurally similar; application is DAB modulation).
3. Firewall on FPGA (irina) — https://maker.wiznet.io/irina/projects/firewall-on-fpga/ Drives the W5500 over SPI to process network packets in hardware (SCIS does interlocks; this does inline filtering).
4. TCP/IP stack design based on FPGA and W5500 (WIZnet Makers) — https://maker.wiznet.io/2019/04/26/tcp-ip-stack-design-based-on-fpga-and-embedded-ethernet-w5500/ An FPGA drives the W5500 as a TCP/IP server exchanging commands/data with a host PC.

(B) Similar purpose — measurement aggregation · industrial monitoring · safety control (any platform)

Regardless of FPGA/W5500, these match SCIS's goal of "aggregate measurement data over Ethernet → decide/control."

1. How to Design a Super Simple Sensor System for Industrial Monitoring (ssekim) — https://maker.wiznet.io/ssekim/projects/how-to-design-a-super-simple-sensor-system-for-industrial-monitoring-applications/ The Ethernet subsystem of a modular industrial-monitoring sensor system. Aggregating sensor data over Ethernet is closest to SCIS's aggregation.
2. Securing Industrial PLCs with WIZnet W5500 — Open-Source IoT Gateway (Benjamin) — https://maker.wiznet.io/Benjamin/projects/securing-industrial-plcs-with-wiznet-w5500-an-open-source-iot-gateway-solution/ Extracts PLC data and sends it securely over W5500 Ethernet. HW TCP/IP off-load frees the MCU for real-time tasks; reliable wired monitoring/control — matching SCIS's low-latency deterministic processing.
3. Communication with Siemens PLC using M5Stack W5500 LAN Module (Benjamin) — https://maker.wiznet.io/Benjamin/projects/communication-with-siemens-plc-using-m5stack-w5500-lan-module-m5stacklansiemensplc/ Collects and visualizes measurement/status data from a Siemens PLC over Ethernet — similar to SCIS's data collection.
4. TNN Smart Control (anhtn1980) — A two-tier LAN system that receives commands and controls RS485 relays (equipment). Its "networked decision → physical safety control" flow parallels SCIS's interlock (cutoff).

FAQ

Q: What is this project? A: A slow-control system that implements a data concentrator on a GateMate FPGA to aggregate measurements and assert a low-latency interlock (safety cutoff) when thresholds are exceeded.

Q: How is the W5500 used? A: Two are used — one for UDP receive (RX), one for transmit (TX) — connected over SPI on PMOD. They carry measurement Metric Packets over UDP to the FPGA.

Q: Why two W5500s? A: To physically separate receive and transmit for throughput and determinism (dedicated RX and TX).

Q: Is it a finished product? A: No. It's early-stage; a known bug (socket closes on RX-buffer overflow) and a TCP controller are in the backlog.

Q: Why is there an ESP32? A: It's not a core component but a test-only helper — it mimics an external interlock signal to verify the FPGA cuts off correctly. All real measurement data goes through the W5500.