시연에서 확인한 범위
이 사례는 DUJIN KWON이 재공유한 Hugo B.의 제작 영상에서 출발했습니다. 사용자 본인이 제작한 보드로 소개하는 글은 아닙니다.
원문 검토 담당자는 약 6.55초 영상을 재생해 작은 TFT에 DOOM 화면과 하단 HUD가 나타나고 장면이 바뀌는 것을 확인했습니다. 이 글의 편집자는 그 검토 기록과 아래 제작자 문서를 읽었으며, 원영상을 직접 다시 재생하거나 음성을 전사하지는 않았습니다. 영상과 게임 화면은 복제하지 않고 원문으로 연결합니다.
게임이 화면에 표시되는 시연은 시스템을 함께 동작시켰다는 사례입니다. 그 장면만으로 목표 클록, 평균 FPS, 모든 명령어와 예외 처리, 장시간 안정성까지 확인할 수는 없습니다.
CPU에서 화면까지
DOOM 포트 저장소는 Arty S7-50 보드, HOLY CORE, Xilinx AXI-to-SPI IP, ILI9341 컨트롤러를 쓰는 2.8인치 TFT 구성을 설명합니다. i_video.c와 라이브러리의 주변장치 주소가 이 구성에 맞춰져 있어, 다른 보드에서 실행하려면 메모리맵과 화면 초기화부터 맞춰야 합니다.
제작 해설에는 DDR3에 프로그램을 올리고, 처음에는 UART로 프레임을 출력한 뒤 SPI 화면으로 바꾼 과정이 나옵니다. 캐시 개선과 FPGA DSP를 이용한 곱셈도 다룹니다. 여기서 눈여겨볼 점은 하나의 CPU 기능이 아니라, 프로그램 실행과 화면 전송을 함께 맞춘 과정입니다.
클록과 FPS는 같은 조건끼리 비교합니다
| 자료 | 기재된 값 | 해석할 때의 제한 |
|---|---|---|
| LinkedIn 원문 검토 기록 | 35MHz | 검토 담당자가 읽은 게시물의 값입니다. 편집자가 클록을 측정한 결과가 아닙니다. |
| 제작 해설의 보드 예시 | 30MHz | 2026년 6월 23일 업데이트된 글에 나온 조건입니다. |
| 같은 해설의 FPGA 성능표 | 25MHz · 최종 구성 2.5FPS | 제작자가 제시한 해당 구성의 값이며 독립 재현 결과가 아닙니다. |
따라서 이를 합쳐 35MHz에서 2.5FPS를 검증했다고 쓸 수 없습니다. 제작자 성능표를 다시 측정하려면 RTL·소프트웨어 버전, 비트스트림, 캐시 설정, 화면 전송 방식과 측정 구간을 함께 기록해야 합니다.
게임 실행과 기능 검증은 다릅니다
프로젝트 문서에는 RV32I/M·Zicsr, M-mode, CLINT·PLIC·디버그 구성과 RISCOF 실행 안내가 있습니다. 같은 문서는 PLIC에 우선순위 같은 일부 기능이 없고 중첩 트랩을 지원하지 않는다고 설명합니다. 일반적인 RISC-V 주변장치 설명을 이 구현의 기능이나 레지스터 주소로 그대로 대입하면 안 됩니다.
이번 검토에서는 특정 커밋의 RISCOF 실행 결과, RTL 커버리지, 제품 안전성 인증서를 확인하지 않았습니다. 테스트 실행 방법이 적혀 있다고 해서 해당 버전이 시험을 통과한 것은 아닙니다. 화면 출력은 통합 시연으로 소개하되, 명령어 적합성·인터럽트 처리·장시간 안정성은 각각의 시험 결과로 판단하는 것이 맞습니다.
출처와 관련 글
- Hugo B.의 LinkedIn 원문 영상 · 영상 관찰은 원문 검토 담당자의 기록에 근거합니다.
- HOLY_CORE_DOOM 저장소 · 보드·화면 구성과 포트 의존성.
- 제작자의 DOOM 실행 해설 · 구성 변경과 조건별 성능표.
- HOLY CORE 문서 · 기능, 제한과 테스트 실행 안내.
- RISC-V PLIC와 AIA · 일반 구조 설명이며 HOLY CORE의 구현 명세는 아닙니다.
- Hardware bring-up 검증법 · 재현 조건과 측정 기록 정리.