Wiznet makers

Lihan__

Published May 21, 2026 ©

67 UCC

8 WCC

3 VAR

0 Contests

0 Followers

0 Following

Original Link

Research and implementation of architecture optimization for the HEPS fast orbit feedback system

This paper proposes a star-ring FOFB architecture using BDTs for HEPS , reducing latency by 4.83 µs and enhancing system stability.

COMPONENTS
PROJECT DESCRIPTION

Inside the 6 GeV Beast — How W5500 Quietly Runs Diagnostics in China's High Energy Photon Source

#ParticleAccelerator #Synchrotron #HEPS #FOFB #BeamDiagnostics #W5500 #TOE #FPGA #BigScience #IndustrialDeployment

📚 Context: Peer-reviewed paper from Institute of High Energy Physics, Chinese Academy of Sciences (IHEP), published in High Power Laser and Particle Beams, Vol. 38 No. 10, Oct. 2026. Verified deployment: The proposed Star-Ring architecture with BDT (BPM Data Transceiver) has been validated in a 12-hour continuous test, and the predecessor Ring-Star-Ring FOFB system has been running stably for over two months at HEPS, supporting multiple operational beamlines.


01 — What is this project?

The High Energy Photon Source (HEPS) is China's first 4th-generation synchrotron light source, operating at 6 GeV with an ultra-low beam emittance of ~35 pm·rad and a brightness of 1×10²² phs·s⁻¹·mm⁻²·mrad⁻²·(0.1% bw)⁻¹. The storage ring hosts more than 90 high-performance beamlines for cutting-edge research in materials, life sciences, and environmental science.

Achieving sub-micrometer beam orbit stability requires a Fast Orbit Feedback (FOFB) system: 576 Beam Position Monitors (BPMs), 384 Fast Correctors, and 16 Fast Orbit Controllers (FOCs) cooperate at 22.037 kHz, with a hard end-to-end latency budget of 160 μs to maintain a 500+ Hz effective feedback bandwidth.

The original architecture — Ring–Star–Ring — strings 12 BPMs together in a serial ring within each station, exposing the system to single-point cascade failures, eating ~3.5 μs of avoidable propagation latency, and pushing the FOFB controller's FPGA close to LUT and BUFG resource exhaustion (80.65% and 93.75% utilization respectively).

This work introduces a new node called the BPM Data Transceiver (BDT) and rewires the topology into a Star–Ring structure: within each station, 12 BPMs connect point-to-point to one BDT; 48 BDTs across the ring then feed 16 FOCs forming a high-speed serial ring. The result is a leaner, more deterministic, and dramatically more scalable data transport fabric — without touching the existing FOFB control algorithm or BPM/FOC firmware.

🎯 Headline outcome: BPM data transmission latency drops by 4.83 μs, single-node failures no longer cascade, FPGA resource pressure on the FOC is relieved, and the door opens for XBPM and other detectors to join the feedback loop.


02 — Why a new data transmission architecture?

🔷 The serial-ring trap

In the legacy Ring-Star-Ring topology, the 12 BPMs in each station are daisy-chained. Every BPM has to wait for its upstream neighbor to forward data through it. Any single BPM dying takes the entire station's data path with it. And the cumulative per-hop latency adds up to ~3.5 μs of pure propagation overhead before the data even reaches the FOC.

🔷 FPGA resource saturation on the FOC

The FOC's Kintex UltraScale FPGA was running close to its limits — LUT at 80.65%, BUFG at 93.75%. Adding new detector classes (such as XBPMs for photon-beam position measurement) into the same FOC pipeline simply wasn't viable.

🔷 The aggregation-first answer

By inserting a per-station aggregation layer (the BDT), the system gets:

  1. No serial BPM ring → no cascading failures, no per-hop latency stack-up
  2. Local pre-processing of 12 BPMs into a single tidy stream → FOC sees fewer high-speed channels and spends fewer LUTs on data plumbing
  3. Extra GTH lanes freed up → XBPMs and future detectors can plug in
  4. Multiple BPM data classes accessible simultaneously — FA (Fast Acquisition), TBT (Turn-by-Turn), and raw 4-electrode signals all become available, not just the 22.037 kHz FA stream

🔷 How HEPS compares to peer light sources

The field is converging on aggregator-style topologies, and HEPS now joins that pattern:

  • SSRF (Shanghai): GbE + Reflective Memory — flexible but not deterministic
  • TPS (Taiwan): daisy-chained Libera + GDX expansion modules
  • ALBA (Spain): per-sector copper aggregation, fiber inter-sector
  • NSLS-II / APS-U (USA): dual-ring FPGA serial fabrics, low-tens-of-microseconds full-ring sharing
  • SIRIUS (Brazil): bidirectional ring with backplane-level BPM data
  • HEPS (China) — this work: Star-Ring with dedicated per-station BDT aggregator

03 — System architecture


04 — Why W5500? ⭐ (The most important section)

Let's be direct about W5500's role here, because honesty makes the case stronger.

In the BDT, the main feedback data path travels over SFP+ optical links and Kintex UltraScale FPGA GTH transceivers at multi-gigabit speed — that's the FOFB physics. The W5500 sits next to a 1 GbE PHY (KSZ9031) and handles a fundamentally different, but operationally critical, role:

"KSZ9031RNXIC and W5500 chips are configured as Ethernet interfaces, used for system parameter configuration, operational status monitoring, and non-real-time data transmission, improving system maintainability and debugging convenience." — from the paper, BDT hardware section

So why does it matter that this is W5500 and not just any random Ethernet IC?

🔷 The "boring infrastructure must never fail" axis

A 6 GeV synchrotron does not stop for an Ethernet driver bug. Every BDT's management interface needs to:

  • Come up cleanly through power cycles, beam dumps, and machine studies shutdowns
  • Respond predictably during full-load 22.037 kHz operation, when the host FPGA is saturated
  • Stay reachable when the operator at the control room needs to push a parameter at 03:00 AM

This is exactly where W5500's hardwired TCP/IP stack (TOE — TCP/IP Offload Engine) earns its keep. There's no firmware-based LwIP stack to crash, no MCU cycles consumed by retransmission state machines, no race conditions between application logic and network stack. The chip just is the network.

🔷 Mode selection (inferred)

The paper does not explicitly state W5500's socket mode, but the workload — "system parameter configuration, status monitoring, non-real-time data" — is the textbook fingerprint of a TCP server (TOE) mode (Sn_MR_TCP, 0x01) deployment:

  • Operator console initiates connection to BDT
  • BDT acts as TCP server listening on a fixed port
  • Reliable delivery is required (status data and parameter writes must not be silently dropped)

⚠️ Note: this is an inference from the described use case. The paper does not show source code or explicit socket configuration. If exact mode confirmation is needed for downstream curation, contact IHEP authors.

🔷 Why not just "use the 1 GbE port for everything"?

Smart separation. The KSZ9031 1 GbE path is used to bulk-upload FA-mode position data and TBT data to upper-level systems — it needs throughput, but it's not the operator's lifeline. The W5500 100 Mbps path is isolated, simple, deterministic — exactly what you want for a control-plane channel that has to always work. Splitting bulk data plane from management plane is a textbook scientific-instrumentation pattern, and W5500 is purpose-built for the management side.

🔷 Verified deployment evidence ✅

  • 4th-generation synchrotron at 6 GeV — among the most demanding industrial environments for any embedded component
  • Originally deployed Ring-Star-Ring FOFB has run stably for 2+ months supporting active beamline experiments
  • The Star-Ring proposal with W5500-equipped BDT passed a 12-hour continuous BDT stress test with no data loss, ordering errors, or protocol anomalies under multi-frame overload conditions far exceeding normal duty
  • 48 BDTs are planned across the storage ring

05 — Key components

🌐 WIZnet W5500 — TCP Server / TOE (inferred)

  • 10/100 Mbps Ethernet with hardwired TCP/IP stack — no firmware burden on the FPGA
  • Role: BDT management interface for parameter configuration and status monitoring
  • Why W5500 specifically: deterministic, fire-and-forget Ethernet endpoint that runs forever; the FPGA can devote 100% of its logic to BPM data aggregation instead of network stack housekeeping

🧠 Xilinx Kintex UltraScale FPGA (XCKU060FFVA1156-2i)

  • 725,550 logic cells, 38 Mb block RAM, 2,760 DSP slices, 20 pairs of GTH transceivers
  • Heart of the BDT — performs parallel reception, timestamp alignment, frame classification, and serial output of 12 BPM streams at 22.037 kHz

🔌 16× SFP+ optical interfaces (driven by GTH)

  • 16.3 Gb/s per lane maximum
  • 12 lanes for BPMs, 2 for FOC uplinks, 2 reserved for XBPM (the architecture's growth headroom)

📡 KSZ9031RNXIC — 1 GbE PHY

  • High-throughput uplink for bulk FA / TBT / raw-electrode data to the higher-level control system
  • Complementary to W5500: bulk plane vs. management plane

💾 4× MT40A512M16LY-062E DDR4 (32 Gb total)

  • Rolling buffer of raw BPM data for offline post-mortem diagnosis after beam-loss events

⏱️ LMK1D1208P + 119 MHz OCXO

  • Reference clock distribution for FPGA core and GTx transceivers

06 — Application scenarios

01. Sub-micrometer beam orbit stability for 90+ beamlines

The headline use case. Every science experiment downstream depends on FOFB working reliably at 22.037 kHz, and W5500 keeps the management plane of 48 BDTs reachable while it does.

02. Long-term post-mortem diagnostics

With DDR4 ring-buffering tens of seconds of raw BPM data, operators can investigate beam-loss events offline. W5500 + management Ethernet is how parameters get tuned and how status flows to the control room during these investigations.

03. Multi-detector expansion (XBPM, future detectors)

The Star-Ring architecture explicitly reserves GTH headroom for XBPMs and other high-bandwidth detectors. Each new detector class will need management connectivity — and the W5500 footprint scales without burdening the FPGA.

04. Reference architecture for next-generation light sources

The paper positions this as a reusable template for upcoming high-performance synchrotron light sources globally. Any future facility adopting the Star-Ring + per-station aggregator pattern can drop in W5500 for the same management-plane role.


Conclusion

A 6 GeV particle accelerator does not tolerate flaky infrastructure. The W5500's hardwired TCP/IP stack quietly makes itself part of how China's flagship 4th-generation synchrotron stays maintainable, observable, and operable — 22,037 times every second, around the clock.

  • 6 GeV, 4th-generation synchrotron — among the most demanding environments on Earth
  • 48 BDT deployments planned across the HEPS storage ring
  • 12-hour continuous stress test passed with zero anomalies
  • End-to-end FOFB latency: 149.33 μs (within the 160 μs design budget)
  • 4.83 μs latency reduction vs. legacy Ring-Star-Ring architecture
  • TCP/IP offload engine isolates the network stack from FPGA logic — predictable, deterministic, maintenance-friendly
  • Management plane / data plane separation by design — bulk uplink on KSZ9031 1 GbE, control on W5500
  • Peer-reviewed publication in High Power Laser and Particle Beams
  • Architectural reference for future high-performance light sources worldwide

Q&A

Q1. Why W5500 (100 Mbps) when there's already a 1 GbE port via KSZ9031? A. Different jobs. KSZ9031 handles bulk uplink of FA/TBT data — high throughput matters. W5500 handles the management plane — predictability matters. Mixing them on one PHY would couple control-plane reliability to data-plane congestion, which is exactly what you don't want in a 6 GeV synchrotron. The hardwired TCP/IP stack in W5500 also means the FPGA never spends a cycle on network bookkeeping.

Q2. Which W5500 socket mode is used? A. Not stated in the paper. Inferred to be TCP server mode (Sn_MR_TCP, TOE) based on the described workload of parameter configuration and status monitoring — classic management-channel pattern. Confirmation from IHEP authors would be needed for absolute certainty.

Q3. Does the BDT introduction require firmware changes to BPM or FOC devices? A. No. The paper explicitly notes that BDT deployment requires only fiber cabling — existing BPM and FOC firmware is untouched. The Star-Ring architecture slides in seamlessly under the existing FOFB control mechanism.

Q4. Is HEPS already running on the new architecture? A. As of the paper's writing, the legacy Ring-Star-Ring FOFB has been running stably for 2+ months supporting beamline experiments. The Star-Ring with BDT has been validated via single-board 12-hour stress test, and 48-unit ring-wide deployment is the engineering plan. Current rollout status should be verified directly with IHEP for up-to-date information.

Q5. Could this architecture be reused at other facilities? A. Yes — the paper explicitly positions it as a reference solution for large-scale orbit feedback systems at high-performance synchrotron light sources. The W5500 + KSZ9031 management/data plane split is portable to any per-station aggregator design.



🇰🇷 한글 버전

6 GeV 거대 가속기 속 — 중국 고에너지광자광원의 진단 인프라를 묵묵히 떠받치는 W5500

#입자가속기 #싱크로트론 #HEPS #FOFB #빔진단 #W5500 #TOE #FPGA #BigScience #산업배포

📚 컨텍스트: 중국과학원 고에너지물리연구소(IHEP) 소속 연구진이 强激光与粒子束(High Power Laser and Particle Beams) 학술지에 발표한 peer-reviewed 논문 (2026년 38권 10호). 검증된 배포: BDT(BPM Data Transceiver) 기반 Star-Ring 아키텍처는 12시간 연속 스트레스 테스트로 검증되었고, 이전 세대인 Ring-Star-Ring FOFB 시스템은 HEPS에서 2개월 이상 안정 운영되며 다수 빔라인 실험을 실제로 지원하고 있음.


01 — 이 프로젝트는 무엇인가?

고에너지광자광원(HEPS, High Energy Photon Source) 은 중국 최초의 4세대 동기가속기 광원이다. 6 GeV 전자빔, ~35 pm·rad의 초저 발사도, 1×10²² phs·s⁻¹·mm⁻²·mrad⁻²·(0.1% bw)⁻¹의 휘도를 자랑하며, 저장환에 90개 이상의 고성능 빔라인을 수용해 재료·생명·환경과학 등 최첨단 연구를 지원한다.

서브 마이크로미터 수준의 빔 궤도 안정성을 달성하려면 고속 궤도 피드백(FOFB, Fast Orbit Feedback) 시스템이 필수다. 576개 BPM(빔 위치 검출기), 384개 Fast Corrector, 16개 FOC(Fast Orbit Controller)가 22.037 kHz로 협조 작동하며, 500 Hz 이상의 유효 피드백 대역폭을 유지하려면 전체 링크 지연을 160 μs 이내로 묶어둬야 한다.

기존 아키텍처인 Ring-Star-Ring 구조는 한 자(station) 안의 BPM 12대를 직렬 환로로 연결하는 방식이라, 단일 노드 장애가 전체 자(station) 데이터 경로를 끊을 수 있고, 환로 전송에서만 약 3.5 μs의 회피 가능한 지연이 누적되며, FOC의 FPGA가 LUT 80.65%·BUFG 93.75% 점유율로 자원 한계에 다다른 상태였다.

본 연구는 BPM Data Transceiver(BDT) 라는 신규 노드를 도입해 토폴로지를 Star-Ring 형태로 재설계한다. 각 자(station)마다 12대 BPM이 한 대의 BDT에 점-대-점으로 연결되고, 링 전체에 걸쳐 48대의 BDT가 16대 FOC를 환형 네트워크로 잇는다. 기존 FOFB 제어 알고리즘이나 BPM/FOC 펌웨어에는 손을 대지 않으면서, 더 가볍고 더 결정적이며 훨씬 확장성 높은 데이터 수송망을 얻는다.

🎯 핵심 성과: BPM 데이터 전송 지연 4.83 μs 감소, 단일 노드 장애가 더 이상 전파되지 않음, FOC FPGA 자원 압박 완화, XBPM 등 신규 검출기 통합 여지 확보.


02 — 왜 새로운 데이터 전송 아키텍처가 필요했나?

🔷 직렬 환로의 함정

기존 Ring-Star-Ring 토폴로지에서는 한 자(station)의 BPM 12대가 데이지체인으로 묶여 있다. 각 BPM은 상류 BPM이 데이터를 전달해줘야 자기 데이터를 끼워 보낼 수 있고, 어느 하나가 죽으면 자(station) 전체의 데이터 경로가 끊긴다. 게다가 hop마다 누적되는 전송 지연이 ~3.5 μs에 달한다 — FOC에 도달하기도 전에 소모되는 순수 오버헤드다.

🔷 FOC FPGA의 자원 포화

FOC의 Kintex UltraScale FPGA는 한계에 근접해 있었다 — LUT 80.65%, BUFG 93.75% 점유율. XBPM 같은 신규 검출기 클래스를 동일 FOC 파이프라인에 통합하는 건 사실상 불가능한 상황.

🔷 "선집계(aggregation-first)" 라는 해법

자(station)별 집계 계층(= BDT)을 한 층 끼워 넣으면 다음이 동시에 얻어진다:

  1. BPM 직렬 환로 제거 → 캐스케이드 장애 없음, hop별 지연 누적 없음
  2. 로컬 전처리: 12대 BPM 데이터가 BDT에서 한 줄기 깔끔한 스트림으로 합쳐짐 → FOC가 받는 고속 채널 수가 줄고, 데이터 라우팅용 LUT 소비도 감소
  3. GTH 레인 여유 확보 → XBPM 및 미래 검출기를 위한 고속 데이터 채널 예약 가능
  4. 다양한 BPM 데이터 클래스 동시 접근 — 22.037 kHz의 FA(Fast Acquisition) 데이터뿐 아니라 TBT(Turn-by-Turn) 데이터, 4채널 raw 전극 신호까지 병렬로 활용 가능

🔷 다른 광원들과의 비교 속에서 HEPS의 위치

전 세계 광원들은 점점 집계형 토폴로지로 수렴하고 있고, HEPS도 이 흐름에 합류한다:

  • SSRF (상해): GbE + 반사 메모리(RFM) — 유연하지만 결정성 약함
  • TPS (대만): Libera 데이지체인 + GDX 확장 모듈
  • ALBA (스페인): 섹터 내 동축 + 섹터 간 광섬유 계층 구조
  • NSLS-II / APS-U (미국): 이중 환로 FPGA 직렬망, 수십 마이크로초 단위 전체환 공유
  • SIRIUS (브라질): 양방향 환형 네트워크, 백플레인 레벨 BPM 데이터 전송
  • HEPS (중국) — 본 연구: 자(station)별 BDT 집계기를 갖춘 Star-Ring 구조

03 — 시스템 아키텍처

🛰️ W5500 (STM32F103 ↔ 엣지/서버)

다니는 데이터: 가볍고 주기적인 센서/제어 값

데이터방향크기빈도
MQ-2 연기 ADC 값STM32 → 외부16-bit초당 1~10회
MQ-7 CO 농도STM32 → 외부16-bit초당 1~10회
MQ-135 공기질STM32 → 외부16-bit초당 1~10회
DHT11 온습도STM32 → 외부2×16-bit초당 1회
릴레이 ON/OFF 명령 (가스밸브 차단, 전원 차단)외부 → STM321-bit이벤트 발생 시
부저 ON/OFF (경보음)외부 → STM321-bit이벤트 발생 시

🖥️ 기가비트 이더넷 (Jetson Orin Nano ↔ 클라우드 ↔ 3D 대시보드)

다니는 데이터: 무겁고 실시간 영상 + AI 결과 + 시각화

데이터방향크기빈도
카메라 RAW/RTSP 영상 스트림카메라 → Jetson수 Mbps~수십 Mbps30 fps 연속
YOLOv8 추론 결과 (낙상/사람 감지 메타데이터)Jetson → 클라우드수 KB프레임당 1회
압축된 이벤트 영상 클립 (낙상 발생 시)Jetson → 클라우드수 MB이벤트 시
센서 데이터 통합 (Modbus → MQTT/WebSocket 변환)Jetson → 클라우드작음초당 1~10회
3D 대시보드 실시간 갱신 (WebSocket)클라우드 → 브라우저수 KB초당 10회 정도
알람 푸시 (APP/SMS/전화 트리거)클라우드 → 외부작음이벤트 시

04 — 왜 W5500인가? ⭐ (가장 중요한 섹션)

 

BDT 내에서 주 피드백 데이터 경로는 SFP+ 광섬유 + Kintex UltraScale FPGA의 GTH 트랜시버를 통해 멀티 기가비트 속도로 흐른다 — 이게 FOFB의 물리(physics)다. W5500은 1 GbE PHY(KSZ9031) 옆에 자리잡고 근본적으로 다른 운영상 결정적인 역할을 맡는다:

"보드는 SFP+ 광섬유 인터페이스로 BPM/FOC와 고속 데이터 통신을 수행하며, 동시에 KSZ9031RNXIC와 W5500 칩을 이더넷 인터페이스로 구성하여 시스템 파라미터 설정, 운영 상태 모니터링, 비실시간 데이터 전송에 사용한다. 시스템 유지보수성과 디버깅 편의성을 높이는 역할." — 논문 BDT 하드웨어 섹션에서 인용

그렇다면 왜 그 자리에 굳이 W5500 이어야 하는가? 임의의 이더넷 IC가 아닌?

🔷 "지루한 인프라일수록 절대 죽으면 안 된다" 라는 축

6 GeV 싱크로트론은 이더넷 드라이버 버그 하나로 멈추는 시스템이 아니다. BDT의 관리 인터페이스는 다음을 만족해야 한다:

  • 전원 사이클, 빔 덤프, 머신 스터디 정전 후에도 깔끔하게 재기동
  • 호스트 FPGA가 포화 상태인 22.037 kHz 풀로드 운영 중에도 예측 가능한 응답
  • 새벽 3시에 컨트롤 룸 운영자가 파라미터 하나 푸시할 때도 반드시 reachable

여기서 W5500의 하드와이어드 TCP/IP 스택 (TOE — TCP/IP Offload Engine) 이 가치를 발휘한다. 펌웨어 기반 LwIP 스택이 크래시할 일도, MCU 사이클이 재전송 상태머신에 낭비될 일도, 응용 로직과 네트워크 스택 사이 레이스 컨디션도 없다. 칩 자체가 곧 네트워크다.

🔷 사용 모드 (추론)

논문은 W5500의 소켓 모드를 명시적으로 밝히지 않는다. 다만 워크로드 — "시스템 파라미터 설정, 상태 모니터링, 비실시간 데이터 전송" — 는 TCP 서버 모드 (Sn_MR_TCP, 0x01, TOE) 의 교과서적 패턴이다:

  • 운영자 콘솔이 BDT를 향해 연결을 개시
  • BDT는 고정 포트에서 listen하는 TCP 서버로 동작
  • 신뢰성 있는 전달이 필수 (상태 데이터와 파라미터 쓰기가 무성으로 드롭되면 안 됨)

⚠️ 주의: 이는 워크로드 설명에 기반한 추론이며, 논문은 소스 코드나 명시적 소켓 설정을 보여주지 않는다. 정확한 모드 확인이 필요하다면 IHEP 저자에게 문의가 필요함.

🔷 그냥 1 GbE 한 채널로 다 처리하면 안 됐나?

영리한 분리다. KSZ9031 1 GbE 경로는 FA 모드 위치 데이터와 TBT 데이터를 상위 시스템에 대량 업로드하는 용도다 — 처리량이 중요하지만, 운영자의 생명선은 아니다. W5500 100 Mbps 경로는 격리되어 있고 단순하며 결정적이다 — 항상 작동해야 하는 컨트롤 플레인 채널에 정확히 맞는 특성. 대량 데이터 플레인과 관리 플레인을 분리하는 건 과학 계측 분야의 정석적 패턴이고, W5500은 관리 측에 특화되어 설계된 칩이다.

🔷 검증된 배포 증거 ✅

  • 6 GeV 4세대 싱크로트론 — 임베디드 부품이 마주할 수 있는 가장 가혹한 산업 환경 중 하나
  • 기존 Ring-Star-Ring FOFB는 활성 빔라인 실험을 지원하며 2개월 이상 안정 운영
  • W5500 탑재 BDT를 갖춘 Star-Ring 제안은 12시간 연속 BDT 스트레스 테스트 통과 — 통상 부하를 크게 초과하는 멀티프레임 과부하 조건에서도 데이터 손실/순서 오류/프로토콜 이상 없음
  • 저장환 전체에 BDT 48대 배포 계획

05 — 핵심 컴포넌트

🌐 WIZnet W5500 — TCP 서버 / TOE 모드 (추론)

  • 10/100 Mbps 이더넷 + 하드와이어드 TCP/IP 스택 → FPGA에 펌웨어 부담 없음
  • 역할: BDT의 관리 인터페이스 (파라미터 설정 및 상태 모니터링)
  • 굳이 W5500인 이유: 결정적이고 fire-and-forget으로 영속 동작하는 이더넷 엔드포인트. FPGA 로직을 100% BPM 데이터 집계에 할애할 수 있게 해줌

🧠 Xilinx Kintex UltraScale FPGA (XCKU060FFVA1156-2i)

  • 725,550 logic cells, 38 Mb BRAM, 2,760 DSP, GTH 트랜시버 20쌍
  • BDT의 두뇌 — 12대 BPM 스트림을 22.037 kHz로 병렬 수신·시각 정렬·프레임 분류·직렬 출력

🔌 16× SFP+ 광 인터페이스 (GTH 구동)

  • 채널당 최대 16.3 Gb/s
  • 12채널은 BPM, 2채널은 FOC 업링크, 2채널은 XBPM 예약 (아키텍처의 확장 여유)

📡 KSZ9031RNXIC — 1 GbE PHY

  • FA / TBT / 4채널 raw 데이터를 상위 제어 시스템으로 대량 업로드
  • W5500과 상보적 — 대량 플레인 vs 관리 플레인 분리

💾 4× MT40A512M16LY-062E DDR4 (총 32 Gb)

  • 빔 손실 이벤트 후 오프라인 사후 진단을 위한 원시 BPM 데이터 롤링 버퍼

⏱️ LMK1D1208P + 119 MHz OCXO

  • FPGA 코어 및 GTx 트랜시버용 레퍼런스 클럭 분배

06 — 응용 시나리오

01. 90개 이상 빔라인을 위한 서브 마이크로미터 빔 궤도 안정성

가장 대표적인 활용. 하류의 모든 과학 실험이 22.037 kHz로 안정 작동하는 FOFB에 의존하고, 그 동안 W5500은 48대 BDT의 관리 플레인을 reachable하게 유지한다.

02. 장기 사후 진단(post-mortem diagnostics)

DDR4가 수십 초 분량의 원시 BPM 데이터를 링 버퍼링하므로, 운영자는 빔 손실 이벤트를 오프라인으로 조사할 수 있다. W5500 + 관리 이더넷이 그 과정에서 파라미터 튜닝과 컨트롤 룸으로의 상태 전달 통로 역할을 한다.

03. 다중 검출기 확장 (XBPM, 미래 검출기)

Star-Ring 아키텍처는 XBPM과 기타 고대역폭 검출기를 위해 명시적으로 GTH 여유를 확보한다. 새 검출기 클래스가 추가될 때마다 관리 연결성이 필요하고, W5500 풋프린트는 FPGA에 부담 주지 않으며 확장 가능하다.

04. 차세대 광원을 위한 레퍼런스 아키텍처

논문은 이 구조를 전 세계 차세대 고성능 동기가속기 광원용 재사용 가능한 템플릿으로 제시한다. Star-Ring + 자(station)별 집계기 패턴을 도입하는 미래 시설은 동일한 관리 플레인 역할에 W5500을 그대로 가져다 쓸 수 있다.


결론

6 GeV 입자가속기는 불안정한 인프라를 용인하지 않는다. W5500의 하드와이어드 TCP/IP 스택은 중국 대표 4세대 싱크로트론이 유지보수 가능하고, 관측 가능하며, 운영 가능하도록 묵묵히 떠받친다 — 매초 22,037번씩, 24시간 내내.

  • 6 GeV, 4세대 싱크로트론 — 지구상에서 가장 까다로운 환경 중 하나
  • HEPS 저장환 전체에 BDT 48대 배포 계획
  • 12시간 연속 스트레스 테스트, 무결성 100% 통과
  • FOFB 전체 링크 지연: 149.33 μs (160 μs 설계 예산 내)
  • 기존 Ring-Star-Ring 대비 4.83 μs 지연 감소
  • TCP/IP 오프로드 엔진으로 네트워크 스택을 FPGA 로직과 격리 — 예측 가능, 결정적, 유지보수 친화적
  • 데이터 플레인/관리 플레인 분리 설계 — 대량 업링크는 KSZ9031 1 GbE, 제어는 W5500
  • Peer-reviewed 학술지 强激光与粒子束 게재 논문
  • 전 세계 미래 고성능 광원을 위한 아키텍처 레퍼런스

Q&A

Q1. KSZ9031로 이미 1 GbE 포트가 있는데 왜 100 Mbps W5500을 또 두나? A. 일이 다르다. KSZ9031은 FA/TBT 데이터의 대량 업링크 — 처리량이 중요. W5500은 관리 플레인 — 예측 가능성이 중요. 한 PHY에 섞으면 컨트롤 플레인 신뢰성이 데이터 플레인 혼잡과 결합돼버리는데, 이게 바로 6 GeV 싱크로트론에서 가장 원치 않는 상황. W5500의 하드와이어드 TCP/IP 스택은 FPGA가 네트워크 살림에 단 한 사이클도 쓰지 않게 해준다는 추가 장점도.

Q2. W5500은 어느 소켓 모드를 쓰는가? A. 논문에 명시되지 않음. 파라미터 설정 + 상태 모니터링이라는 워크로드 설명에 기반해 TCP 서버 모드 (Sn_MR_TCP, TOE) 로 추론 — 관리 채널의 전형적 패턴. 절대적 확신이 필요하면 IHEP 저자에게 직접 확인 권장.

Q3. BDT 도입에 BPM이나 FOC의 펌웨어 수정이 필요한가? A. 아니다. 논문은 BDT 배포에 광섬유 배선만 추가하면 된다고 명시하고 있고, 기존 BPM과 FOC 펌웨어는 손대지 않는다. Star-Ring 아키텍처는 기존 FOFB 제어 메커니즘 위에 부드럽게 슬라이드인된다.

Q4. HEPS는 이미 새 아키텍처로 운영 중인가? A. 논문 작성 시점 기준으로는 기존 Ring-Star-Ring FOFB가 2개월 이상 안정 운영 중. BDT 탑재 Star-Ring은 단일 보드 12시간 스트레스 테스트로 검증됐고, 48대 링 전체 배포가 엔지니어링 계획. 현재 진행 상황은 IHEP에 직접 확인하는 게 정확.

Q5. 이 아키텍처를 다른 시설에서 재활용할 수 있나? A. 가능. 논문은 이를 고성능 동기가속기 광원용 대규모 궤도 피드백 시스템의 레퍼런스 솔루션으로 명시적으로 포지셔닝한다. W5500 + KSZ9031 관리/데이터 플레인 분리 패턴은 자(station)별 집계기 설계 어디든 이식 가능.

Documents
Comments Write