RTL simulation의 다음 병목은 CPU front end다: ARMOR node compression이 2.7배를 만든 조건

🆓 무료 글 · 누구나 무료로 읽을 수 있는 글입니다

결론부터 말하면, 대형 RTL compiled simulation의 다음 병목은 RTL 연산량만이 아니라 host CPU가 거대한 simulator binary의 instruction을 제때 공급하는 능력이다. 2026년 8월 9일 공개된 ARMOR는 반복되는 narrow node를 CPU word의 서로 다른 bit slice에 묶으면서 full unrolling을 유지했고, 논문은 Repcut 대비 AI accelerator 평균 2.69배, CPU 평균 1.63배의 simulation speedup을 보고했다.

그러나 이 숫자는 보편 순위가 아니다. 효과는 module·subgraph reuse, node-width distribution, activity, host ISA와 instruction-cache 상태가 맞을 때 커지며, 공개 저장소는 핵심 source code를 MICRO 2026 이후 내놓겠다고 적어 현재 독립 재현이 닫혀 있다.

이 글의 첫 독자 job은 verification·simulation lead가 “simulator가 느리다”를 graph, activity, build, host 네 층으로 분해하는 일이다. 둘째 job은 accelerator·CPU architecture lead가 model 크기를 키우기 전에 어떤 RTL regularity와 host counter를 수집할지 정하는 일이다.

두 결정도 분명하다. 첫째는 ARMOR형 packing, event-driven 최적화, compact kernel/data representation 중 어디에 engineering time을 넣을지다. 둘째는 benchmark의 단일 × 숫자를 받아들일지, correctness·compile cost·memory·host 조건까지 포함한 사내 acceptance run을 요구할지다.

컨센서스와 VLSI Korea의 정확한 불일치

컨센서스는 compiled RTL simulator의 성능을 “더 적은 node를 평가하고 더 좋은 C++를 생성하는 문제”로 본다. event-driven 방식은 signal activity가 낮을 때 불필요한 evaluation을 피하고, cycle-based 방식은 full graph를 straight-line code로 펼쳐 branch와 scheduler overhead를 낮춘다.

VLSI Korea의 견해는 한 단계 더 내려간다. 생성된 C++가 충분히 커지면 RTL optimization이 host microarchitecture problem으로 전환되고, simulator IR의 목표 함수도 node count 하나에서 useful RTL work per fetched instruction byte로 바뀐다.

정확한 불일치는 full unrolling을 버려야 하느냐가 아니다. ARMOR의 주장은 full unrolling의 compiler optimization 이점을 유지하면서 반복되는 narrow computation을 word slice에 압축해 instruction footprint와 bit underutilization을 동시에 줄일 수 있다는 것이다.

왜 지금인가. ARMOR, GSIM, RTeAAL Sim이 2025~2026년에 서로 다른 표현—packed nodes, supernodes, sparse tensor algebra—으로 같은 host-CPU 병목을 겨냥했다. 한 논문의 신기한 speedup보다 세 접근이 RTL simulation을 instruction locality와 representation density의 문제로 재정의한다는 점이 더 중요하다.

병목은 RTL graph에서 CPU front end로 이동한다

Verilator는 Verilog/SystemVerilog를 C++ 또는 SystemC model로 바꾸고 single-threaded 또는 multithreaded executable을 만든다. CIRCT의 Arcilator도 Arc IR을 LLVM을 통해 object code로 내리며 hierarchy를 flatten하고 state-transfer function으로 실행한다.

이 계열의 장점은 compiler가 constant propagation, inlining, scheduling을 공격적으로 적용할 수 있다는 데 있다. 단점은 design이 커질수록 한 cycle을 평가하는 instruction working set도 커지고, 자주 재사용되는 data보다 거대한 code stream을 host front end가 계속 공급해야 한다는 데 있다.

Intel의 Top-Down Microarchitecture Analysis에서 front-end bound는 pipeline slot이 instruction fetch·decode 문제로 채워지지 못한 비율이다. latency는 I-cache miss, ITLB miss, branch resteer처럼 공급이 멈춘 경우이고 bandwidth는 fetch·decode 폭을 충분히 쓰지 못한 경우다.

ARMOR 논문은 특정 Verilator example에서 unoccupied slot의 70% 이상이 front end와 연결되고, cycle당 working set이 수백 KB에서 수천 KB에 이르러 실험 host의 32 KB L1 instruction cache보다 크다고 보고한다. 이 수치는 모든 Verilator run에 적용되지 않지만, “RTL node를 더 빨리 계산하자”만으로는 부족하다는 진단을 뒷받침한다.

RTeAAL Sim은 반대 방향의 대조군이다. 거대한 statically generated code 대신 circuit을 sparse tensor와 compact loop kernel로 표현해 binary size와 behavior를 분리한다. ARMOR가 unrolled code의 density를 높인다면 RTeAAL은 code를 compact하게 유지하고 circuit structure를 data로 옮긴다.

ARMOR의 mechanism: node를 없애지 않고 한 word에 병렬 배치한다

ARMOR의 출발점은 isomorphic narrow node다. operation과 dependency pattern이 같고 width가 작은 node들을 찾아 각 node의 value를 machine word 안의 고정 slice에 배치하면, 한 번의 bitwise operation으로 여러 RTL node를 동시에 평가할 수 있다.

첫 단계는 module-aware subgraph discovery다. 같은 module instance 안에서 반복되는 graph를 찾으면 structural comparison 범위를 줄일 수 있고, 하드웨어 generator가 만든 규칙성이 압축 후보가 된다.

둘째는 alignment다. 단순히 width가 같다고 묶으면 안 된다. operand position, predecessor mapping, operation semantics가 맞아야 slice 간 간섭 없이 같은 instruction을 공유할 수 있다.

셋째는 packing과 data rearrangement다. 여러 node의 bit를 word slice에 넣고 다음 연산이 요구하는 layout으로 옮겨야 한다. 논문은 평균 57%의 node가 압축됐지만 data rearrangement overhead 22.7%를 반영한 net RTL graph reduction은 34.51%라고 보고한다.

넷째는 host instruction 선택이다. 공개 README는 x86-64 BMI2, Clang 12, -mbmi2를 요구한다. 즉 speedup은 simulator algorithm만의 속성이 아니라 PEXT/PDEP류 bit manipulation을 포함한 host ISA·compiler 계약의 결과다.

압축의 원재료는 규모보다 구조적 재사용이다

ARMOR benchmark의 node 수는 2만에서 286만까지 넓지만 module reuse가 항상 규모와 비례하지는 않는다. GEMM-16×16과 Conv2D-16×16은 99%, Gemmini-32×32는 97%인 반면 BOOM-2C는 58%, BOOM-8C는 83%였다.

이 차이는 project triage에 중요하다. “큰 design이라 ARMOR가 유리하다”가 아니라 generator가 동일한 tile·lane·queue·pipeline structure를 얼마나 반복하고, 그 내부 node width가 얼마나 좁고 정렬 가능한지를 먼저 봐야 한다.

AI accelerator가 평균적으로 더 큰 이득을 보인 이유도 이 가설과 맞는다. systolic array와 replicated PE는 높은 activity와 regular structure를 만들 수 있고, cycle-based evaluation의 고정비를 많은 유효 연산으로 상쇄한다.

CPU core는 control path, variable-width compare, cache·TLB·predictor state처럼 irregular structure가 많고 workload activity가 낮을 수 있다. 이때 event-driven simulator가 inactive region을 건너뛰는 이점과 packing의 instruction-density 이점을 같은 workload에서 비교해야 한다.

2.69배를 읽는 법: denominator와 측정층을 섞지 않는다

논문은 dual-socket Intel Xeon Platinum 8338 host에서 Clang++ 12 -O2를 사용했다. 각 core의 L1I는 32 KB, L1D는 48 KB, L2는 1.25 MB이고 socket당 L3는 48 MB였으며 baseline에는 Verilator 5.036, Arcilator, Khronos, Repcut, RTeAAL, Dedup, ESSENT가 포함됐다.

Repcut 대비 평균 speedup은 AI accelerator 2.69배, CPU 1.63배였고 peak는 Gemmini-32×32 3.84배, BOOM-8C 1.95배였다. ARMOR의 평균 IPC는 각각 2.32와 1.75였으며 Verilator는 1.11과 0.83이었다.

bit utilization은 single-node 25.57%에서 multi-node 45.61%로 늘었다. 계산하면 45.61 ÷ 25.57 = 1.78배지만 이는 end-to-end speedup이 아니다. packing density의 한 구성요소다.

front-end bound는 ARMOR 47.6%, Verilator 76.1%로 보고됐다. 이 역시 두 simulator가 소비한 전체 cycle이 다르므로 percentage-point 차이를 곧바로 절약한 wall time으로 바꾸면 안 된다.

VLSI Korea의 해석은 세 층이다. graph reduction은 generated work를, IPC·front-end bound는 host delivery를, end-to-end speedup은 compile된 simulator 전체를 본다. 세 층이 같은 방향으로 움직여야 mechanism과 결과가 연결된다.

Front-End Compression Fit: 도입 전 세 축을 측정한다

VLSI Korea의 분석 framework는 Front-End Compression Fit이다. 첫 축 R은 repeated/isomorphic structure ratio, 둘째 W는 packable narrow-width share, 셋째 F는 baseline host의 front-end pressure다.

R×W가 낮으면 압축 후보가 적고, F가 낮으면 instruction footprint를 줄여도 wall time이 줄지 않는다. 반대로 세 값이 높아도 rearrangement, equality handling, compile time이 이득을 먹을 수 있으므로 곱은 순위식이 아니라 실험 우선순위다.

실무에서는 synthesis 전후 graph 통계를 모두 보지 않아도 된다. FIRRTL/IR 단계에서 operation별 width histogram, module instance reuse, isomorphic subgraph coverage를 뽑고 baseline executable에서 IPC, frontend bound, I-cache MPKI, branch miss를 측정하면 첫 triage가 가능하다.

activity는 별도 축이다. 동일 design에서도 Linux boot, CoreMark, random test, directed accelerator kernel은 switching과 hot path가 다르다. simulator를 비교할 때 trace·seed·cycle count·waveform setting을 고정하지 않으면 representation 이점과 workload 차이가 섞인다.

도입 경제성은 (baseline wall time − new wall time) × daily regression count에서 compile·preprocess time, peak memory, integration effort, debug observability cost를 뺀다. 한 번의 긴 run보다 nightly regression 전체와 engineer wait time을 보아야 한다.

hard part와 failure mode: equality, wide nodes, rearrangement, correctness

logical operation은 slice 독립적이라 packing과 잘 맞는다. 하지만 equality는 여러 bit를 함께 비교하고 결과가 1 bit로 줄어 slice 경계를 넘기 쉽다. ARMOR는 width 4 이하의 equality에 packing을 적용하고 CPU equality에는 제한된 lookup-table 방식을 쓴다.

wide arithmetic, variable shift, cross-slice carry, irregular fan-in이 많으면 packable share가 내려간다. 압축 전후 layout을 자주 바꾸면 data rearrangement instruction과 register pressure가 늘어 front end를 줄이는 대신 backend·data path를 키울 수 있다.

host portability도 failure mode다. 공개 workflow는 BMI2를 전제로 하므로 ARM, BMI2가 없는 x86, 다른 compiler version에서 동일한 code generation과 speedup을 가정할 수 없다. target fleet이 heterogeneous라면 architecture별 baseline을 따로 둬야 한다.

가장 중요한 것은 correctness다. waveform 한 구간이 같다는 것으로 충분하지 않다. reset, X/unknown handling, multi-clock boundary, DPI/PLI, random seed, architectural state, long boot의 checkpoint를 포함해야 한다.

또 하나의 현실적 제약은 source availability다. ARMOR 저장소는 MIT license이지만 현재 README와 build 설명이 중심이고 core source는 MICRO 2026 이후 공개 예정이라고 적혀 있다. 따라서 오늘의 결론은 “즉시 교체”가 아니라 “재현 가능한 evaluation queue의 1순위 후보”다.

가장 강한 반론: 새로운 표현이 더 나은 답일 수 있다

가장 강한 반론은 unrolled code를 더 잘 압축하는 대신 circuit behavior를 compact data structure로 옮겨야 한다는 것이다. RTeAAL Sim은 sparse tensor algebra, GSIM은 supernode·node·bit-level optimization으로 다른 지점을 공격한다.

이 반론이 맞는 조건은 binary size와 compile memory가 이미 운영 한계를 넘고, workload activity가 낮거나 irregular하며, host front end 외의 data access·branch·scheduler cost를 compact kernel이 더 잘 제어할 때다.

ARMOR의 thesis가 맞는 조건은 full unrolling이 주는 compiler optimization을 포기하기 어렵고, regular narrow node가 많으며, baseline profile이 실제로 instruction delivery에 묶여 있을 때다. 결국 경쟁 단위는 simulator 이름이 아니라 workload별 representation portfolio다.

Korean Lens: 국내 팀은 simulator 선택보다 측정 contract를 먼저 만든다

한국의 AI accelerator·RISC-V 팀은 generator 기반 RTL, FPGA emulation, commercial simulation, Verilator를 혼합하는 경우가 많다. 이 환경에서는 외부 논문의 peak speedup보다 tape-out 전 regression queue에서 어떤 job이 몇 engineer-hour를 막는지가 가치 단위다.

첫 선택은 IR telemetry다. Chisel/FIRRTL 또는 사내 IR에서 width histogram, repeated module coverage, top subgraph를 nightly artifact로 남기면 ARMOR형 packing뿐 아니라 partitioning·incremental compile 투자에도 재사용할 수 있다.

둘째는 host 표준화다. CPU model, microcode, compiler, flags, NUMA binding, core pinning, cache setting을 benchmark manifest에 고정해야 simulator 결과가 procurement와 capacity planning에 연결된다.

셋째는 bilingual vendor question이다. “몇 배 빠른가” 대신 동일 design·trace에서 compile time, peak memory, frontend bound, IPC, waveform correctness, unsupported feature를 요구해야 한다. 이 contract는 국내 design service, IP vendor, university open-source project가 같은 기준으로 결과를 교환하게 한다.

실무 체크리스트와 thesis breaker

1. 동일 RTL revision, elaboration parameter, trace, seed, simulated cycle을 고정한다. 2. waveform 또는 architectural checkpoint로 semantic equivalence를 먼저 닫는다.

3. compile·preprocess wall time과 peak memory를 simulation time과 분리한다. 4. CPU ISA, BMI2, compiler, optimization flag, core pinning, NUMA를 기록한다.

5. IPC, frontend bound, I-cache MPKI, branch miss, backend bound를 함께 수집한다. 6. nightly regression throughput, energy, license 또는 cloud cost, engineer wait time으로 번역한다.

첫 thesis breaker는 core source 공개 후 독립 팀이 correctness를 유지한 채 논문의 평균 이득을 의미 있게 재현하지 못하는 경우다. 둘째는 wide·irregular graph에서 packable share와 net graph reduction이 낮아 rearrangement overhead가 이득을 없애는 경우다.

셋째 breaker는 host profile이 front-end bound가 아니라 memory/backend bound로 나타나는 경우다. 이때 ARMOR mechanism은 진짜 병목을 건드리지 않는다.

앞으로 6~12개월에 볼 날짜

2026-09-30까지: 공개 저장소의 commit·issue·build artifact가 README 수준을 넘어 reproducible core로 확장되는지 본다. MICRO 2026 종료 후 30일: 약속된 source release, exact commit, benchmark scripts, golden outputs가 실제로 올라오는지 확인한다.

2026-12-31까지: ARMOR 결과가 다른 x86 host와 compiler에서 재현되는지, BMI2 dependency와 compile cost가 정량화되는지 본다. 2027-03-31까지: multi-clock, waveform, DPI/PLI, long software workload 지원 범위와 CPU/accelerator 밖 design에서의 결과를 확인한다.

2027-06-30까지: node compression이 Verilator·CIRCT 계열의 독립 pass 또는 production-quality toolchain에 통합되는지 본다. 이 다섯 관찰점 중 source·correctness·portability가 닫히지 않으면 채택 시나리오를 낮춘다.

최종 판단

ARMOR의 가장 중요한 기여는 3.84배 peak가 아니다. RTL simulation의 code-generation 전략을 host CPU의 instruction-delivery budget과 함께 설계해야 한다는 점, 그리고 hardware generator의 규칙성을 simulator word-level parallelism으로 다시 이용할 수 있다는 점이다.

현재 판단은 “유망하지만 조건부”다. regular narrow nodes와 높은 activity, front-end-bound host가 만나는 accelerator regression에서는 강한 후보지만, low-activity CPU workload, wide/irregular logic, non-BMI2 host, 공개 source 미완료 상태에서는 대안 표현과 나란히 평가해야 한다.

Sources

• ARMOR: Accelerating RTL Simulation via Multi-Node Compression, primary paper, 2026-08-09.
• ARMOR public repository, MIT license, requirements and release status.
• Verilator official repository, generated C++/SystemC model workflow.
• CIRCT Arc dialect documentation, Arcilator compilation model.
• GSIM, primary paper and CC BY 4.0 source for Figure 6.
• RTeAAL Sim, primary paper and CC BY 4.0 source for Figure 7.
• Intel Top-Down Microarchitecture Analysis Method.
• Gemmini official repository and BOOM official repository, benchmark design context.

AI assistance note: AI tools assisted source discovery, arithmetic checks, translation consistency, and visual layout. VLSI Korea verified the cited claims against the linked primary sources; no human expert review, private customer information, or first-person test experience is claimed.

자주 묻는 질문

ARMOR가 보고한 시뮬레이션 속도 향상은 얼마인가요?

Repcut 대비 AI 가속기 평균 2.69배, CPU 평균 1.63배입니다. 2026년 8월 9일 공개된 논문의 수치이며, 모듈 재사용과 노드 폭 분포, 호스트 조건이 맞을 때 효과가 커집니다.

대형 RTL 시뮬레이션의 병목은 어디로 이동했나요?

호스트 CPU의 프론트엔드입니다. 논문은 특정 Verilator 사례에서 비어 있는 슬롯의 70% 이상이 프론트엔드와 연결됐고, 사이클당 작업 집합이 실험 호스트의 32KB L1 명령어 캐시보다 컸다고 보고했습니다.

ARMOR의 압축 방식은 어떻게 동작하나요?

반복되는 좁은 노드를 CPU 워드의 서로 다른 비트 슬라이스에 묶는 방식입니다. full unrolling을 유지하면서 한 번의 연산으로 여러 RTL 노드를 동시에 평가합니다.

ARMOR 결과를 지금 독립적으로 재현할 수 있나요?

어렵습니다. 공개 저장소는 핵심 소스 코드를 MICRO 2026 이후 내놓겠다고 적어 현재 독립 재현이 닫혀 있습니다.