최민영 Choi Minyoung
설계와 검증에서
온디바이스 AI로
확장하는 엔지니어

ToF 센서(VL53L1X)로 앞차와의 거리를, 로터리 엔코더(AS5600)로 속도를 측정하고, PID 제어로 DC 모터 출력을 조절해 목표 거리(30cm ± 5cm)를 유지하는 ACC 시스템을 DE10-Standard(Cyclone V SoC) 보드로 구현한 4인 팀 프로젝트.

앞차와의 거리를 자동으로 유지하며 속도를 조절하는 Adaptive Cruise Control(ACC)을, 실제 차량이 아닌 RC카 + FPGA 조합으로 구현한 4인 팀 프로젝트입니다. DE10-Standard 보드(Cyclone V SoC)의 HPS(ARM 리눅스)와 FPGA 로직을 함께 활용해, 센서 처리는 HPS가, 실시간 PWM 제어는 FPGA가 담당하는 역할 분리 구조로 설계했습니다. HPS와 FPGA라는 이질적인 두 영역을 I2C와 AXI라는 서로 다른 버스로 엮어낸 것이 이 프로젝트의 핵심입니다.

정량적 목표

• 선행 차량과의 목표 거리 30cm ± 허용 오차 5cm 유지
• 센서 측정 주기 최소 50Hz 이상
• 모터 제어 주기 10ms 단위 제어 루프 구현
• PID 제어 응답 시간: 목표 거리 도달까지 2초 이내 안정화
• 실내 평탄한 환경 기준 1분 이상 안정적 주행 유지

기능적 목표

• VL53L1X ToF 센서 기반 실시간 거리 측정, AS5600 엔코더 기반 속도 측정, PID 제어로 목표 거리 유지 및 부드러운 속도 변화 구현
• 기존 GHRD 예제에 HPS I2C2 인터페이스를 추가 구성하고, HPS-FPGA 간 Lightweight AXI Bridge를 활성화해 센서 데이터를 실시간 전달
• FPGA 내부에 센서 처리 FSM 및 모터 제어 FSM 설계, 7-Segment로 거리 실시간 출력, LED로 에러 상태 표시
• RC카 플랫폼에 통합 적용 후 실제 주행 환경에서 ACC 기능 및 Fail-safe 동작 검증

ToF 센서(VL53L1X)가 측정한 거리와 로터리 엔코더(AS5600)가 측정한 속도는 HPS의 I2C2 인터페이스를 통해 HPS로 전달되고, HPS는 이 값을 AXI(Advanced eXtensible Interface) 기반 Lightweight AXI Bridge를 통해 FPGA 내부 레지스터에 write합니다. 즉 센서 쪽은 I2C, HPS-FPGA 경계는 AXI로 나뉘는 2단 버스 구조입니다. FPGA 내부에서는 Sensor Interface FSM → PID Controller FSM → PWM Generator 순서로 데이터가 흘러가며, 최종 PWM 신호가 모터드라이버(DRV8833)를 거쳐 DC 모터 속도를 제어하는 피드백 루프를 구성합니다. 제어 주기는 10ms입니다.

DE10-Standard(Cyclone V SoC)가 기본 제공하는 GHRD(Golden Hardware Reference Design)는 단순 입출력 테스트 수준이라 센서 제어나 실시간 제어 로직이 전혀 없었습니다. 이를 기반으로 Platform Designer에서 HPS I2C2 인터페이스를 추가 구성하고, Lightweight AXI Bridge를 활성화해 센서 데이터를 HPS→FPGA로 실시간 전달할 수 있는 경로를 새로 만들었습니다. 여기에 FPGA 내부 FSM 3종(Sensor Interface / PID Controller / PWM Generator)을 신규 설계해, 단순 데모 수준이던 GHRD를 실제 센서 기반 실시간 제어 시스템으로 확장했습니다.

개발 중 I2C로 연결된 VL53L1X 센서가 VL53L1_ERROR_CONTROL_INTERFACE, VL53L1_ERROR_TIME_OUT 같은 오류를 내며 거리값이 0으로 고정되는 문제를 겪었습니다. 브레드보드 접촉 불량이 원인 중 하나였고, 근본적으로는 소프트웨어 차원의 복구 로직이 없었던 게 문제였습니다. 이를 해결하기 위해 오류 감지 시 센서를 PlatformDeInit → 200ms 대기 → PlatformInit 순서로 재초기화하는 루틴을 넣어, 사용자 개입 없이도 약 200ms 이내에 자동 복구되도록 만들었습니다.

거리값과 에러코드를 32비트 하나에 패킹해서(상위 16비트 에러코드, 하위 16비트 거리) /dev/mem 기반 mmap으로, Lightweight AXI Bridge가 매핑한 FPGA 주소 공간(0x00040000)에 직접 write하는 방식을 택했습니다. FPGA 쪽에서는 이 32비트 값을 다시 상/하위로 분리해 거리는 7-Segment에 표시하고, 에러코드는 LED 상태 표시나 에러 핸들링에 사용하도록 구성했습니다.

처음엔 흔히 쓰이는 L298N을 사용했지만, BJT 기반이라 전압 강하가 커서 채널당 최대 피크 전류를 안정적으로 보장하기 어려웠습니다. RC카 구동에 필요한 전류(정격 700~900mA, 급가속 시 최대 2.3A)를 계산해보니 L298N으로는 부족할 수 있다고 판단해, MOSFET 기반이라 전력 손실이 적고 채널당 2.4A까지 지원하는 DRV8833로 교체했습니다.

senser 제어 소프트웨어를 매번 수동 실행하지 않도록 systemd 서비스로 등록해, 보드 전원이 켜지면 센서 측정 프로그램이 자동으로 실행되고 곧바로 FPGA로 데이터가 흘러가도록 구성했습니다.

• 목표: 선행 차량과의 거리 30cm ± 5cm 유지, 센서 측정 주기 50Hz 이상, 모터 제어 주기 10ms
• HPS-FPGA 연동, 센서 자동 복구, PID 제어, 부팅 자동화까지 포함한 통합 임베디드 시스템 설계 경험

FPGA(Basys-3) 한 대로 완결되는 셀프 네컷사진 부스입니다. OV7670 카메라로 촬영한 영상을 보드 내부에서 실시간으로 필터링·마커 인식·스티커/드로잉 편집까지 처리하고, 완성된 사진을 UART로 PC에 전송해 Python UI에서 QR코드로 다운로드할 수 있게 만들었습니다. 7명 팀 프로젝트이며, 저는 Edit Engine(편집 엔진)을 권동오 님과 함께 설계·구현했습니다.

버튼·스위치 입력을 동기화해 System Controller로 전달하고, System Controller가 상태에 따라 각 모듈의 동작을 제어합니다. OV7670의 픽셀 데이터는 Camera Interface로 수신된 뒤 Down Scaler와 Filter를 거쳐 Capture&Filter 블록에 저장되고, Marker 좌표를 기반으로 편집한 결과를 VGA Monitor에 실시간 출력하는 동시에 UART로 Python UI에 전송합니다.

카메라로 촬영 → 보드에서 실시간 필터 적용 및 편집 → 완성된 4컷 사진까지 이어지는 전체 플로우입니다. Python UI는 촬영 가이드부터 필터/스티커 선택, 최종 사진 확인, QR코드 다운로드까지의 흐름을 담당합니다.

Edit Engine은 VGA Controller가 생성하는 좌표(VGA Cntl)와 Capture&Filter에서 넘어온 촬영 이미지(Memory), Marker Detection이 넘겨주는 마커 좌표(Marker Overlay)를 하나로 합쳐 최종 픽셀 데이터를 만들고, 이를 Monitor와 UART(Python 전송용) 양쪽으로 동시에 출력하는 블록입니다. Down Scaler로 축소한 프리뷰 영상과 Capture로 저장된 원본 이미지를 pixel mux로 전환하고, Memory Address Generator가 계산한 주소로 Memory에서 픽셀을 읽어 Marker Overlay에서 스티커·드로잉·컬러피커 결과를 덮어씌운 뒤 MEM Writer로 다시 저장합니다.

Marker Overlay 픽셀 선택 로직

Memory Writer 동작 흐름

Sticker는 Marker 좌표 근처에 저장된 스티커 이미지를 그대로 덮어쓰고, Drawing은 Marker 궤적을 따라 지정 색상을 기록하며, Color Picker는 Marker 좌표의 Memory 값을 읽어와(Memory Read) 해당 색상을 UI에 반영합니다. 이 세 경로 모두 최종적으로 Memory Write 단계로 모여 하나의 프레임 버퍼에 반영됩니다. VGA 좌표와 Marker 좌표를 비교해 겹치는 위치인지 판단한 뒤, 겹치면 Control Signal에 따라 오버레이 색상으로 덮어쓰고 겹치지 않으면 메모리 원본 값을 그대로 출력합니다.

System Controller의 전송 요청을 받으면 (0,0)부터 (639,479)까지 좌표를 순차 생성하며 Memory Read → UART 전달(valid/ready 핸드셰이크)을 반복하고, 전체 프레임 전송이 끝나면 System Controller에 완료 신호를 보냅니다.

OPEN(시작 대기) → SHOOT(프리뷰·필터 선택) → CAPTURE(4장 순차 촬영) → STICKER(스티커 편집) → DRAW(그리기·모자이크) → FINAL_EXPORT(이미지·UART 전송 완료 대기) → RESULT(결과 표시) 순서로 전이하며, 이미지 송신 완료 후 20초 경과 또는 외부 버튼 입력 시 자동으로 OPEN 상태로 복귀합니다. 현재 상태와 설정값을 32bit Status Data로 구성해 UART로 Python UI에 함께 전달합니다.

System Controller Top — 버튼/스위치 동기화 + FSM + Status 생성

32bit Status Data 비트 필드

Cam_IF는 top_setup(I2C 기반 OV7670 레지스터 초기화)과 ov7670_mem_controller(픽셀 카운터 기반 좌표 생성)로 구성됩니다. Marker Detector는 색상 LUT(target_lut) 기반으로 목표 색상을 판별한 뒤, Line 단위가 아닌 Blob(덩어리) 단위 검출을 채택했습니다 — 시뮬레이션 결과 Line 방식이 첫 출력까지 32.2μs로 더 빨랐지만 valid 횟수가 10회로 출력이 불안정했던 반면, Blob 방식은 160.2μs로 약 128μs 느린 대신 valid 1회로 좌표가 안정적이어서, 사용자 체감에 미치는 영향이 적은 응답속도보다 좌표 안정성을 우선해 Blob 방식을 채택했습니다.

Capture_Controller는 IDLE → WAIT_FRAME_START → CAPTURE → CAPTURE_DONE → CAPTURE_WAIT → ALL_DONE 상태를 거치며 프레임 시작 시점(x=0, y=0)부터 마지막 픽셀(x=159, y=119)까지 다운스케일된 이미지를 순차로 Memory에 기록하고, 4장 촬영이 끝나면(cap_count==3) ALL_DONE으로 전이합니다. Filter_top은 Grayscale/Sepia/Softfocus/Filmlook 4개 필터를 병렬로 두고 i_filter_sel로 mux 선택하는 구조이며, 필름룩 필터는 채널별 게인 조정(R×1.12, G×1.043, B×0.88)을 Q8 고정소수점(256배 정수화)으로 구현했습니다.

Capture_top — DownScaler + filter_top + Capture_Controller

Capture_Controller FSM

Send Control이 System Controller의 32bit Status Data와 Edit Engine의 픽셀 데이터를 Byte 단위로 분할해 UART TX로 전달하고, Baud Generator가 1Mbps 기준 타이밍을 생성합니다. UART TX는 8N1 방식으로 IDLE → START → DATA(LSB부터 8bit) → STOP 순서로 직렬 전송하며, PC(Python)에서 수신 데이터를 재조립해 상태 확인 및 최종 이미지를 복원합니다.

UART Interface — Send Control + Baud Generator + UART TX

UART TX ASM Chart

문제 상황 — Critical Path에서 Negative Slack 발생 (WNS -5.156ns)

해결 방안 — 파이프라인 레지스터 2단계 삽입 (WNS +0.463ns)

Edit Engine을 대상으로 NONE passthrough, STICKER(하트 4×4 아이콘 투명/채움 경계), DRAW(3×3 박스 그리기 및 영역 밖 미변경), Color Picker(5×5 블록 코너·중심 픽셀) 4가지 시나리오를 SystemVerilog Testbench로 검증했으며, 총 16개 항목 모두 PASS(ALL TESTS PASSED)를 확인했습니다. UART 경로에서는 32bit Status Data(0x12345678 → 78→56→34→12 LSB Byte First 순서)와 RGB444 Pixel(0xABC → BC→0A) 분할 전송이 설계한 순서대로 정상 동작함을 시뮬레이션으로 확인했습니다.

• FPGA Board: Digilent Basys-3
• Camera: OV7670 (I2C 설정, 320×240)
• Tool: Vivado / Vivado Simulator
• Language: SystemVerilog
• Display: VGA (640×480)
• PC 통신: UART (1Mbps, 8N1) + Python

AXI4-Lite와 APB 프로토콜의 UVM VIP(Verification IP)를 재사용 가능한 구조로 직접 설계하고, 이를 이용해 RV32I 5단 파이프라인 CPU와 AXI-APB 프로토콜 변환 브리지까지 검증한 개인 프로젝트입니다. 팹리스 SoC 설계/검증 직무 포트폴리오로 진행했으며, VIP 설계(Phase 1) → CPU 설계·검증(Phase 2) → 프로토콜 변환 브리지 검증(Phase 3) 순서로 난이도를 확장해 나갔습니다.

재사용 가능한 AXI4-Lite UVM VIP(interface, transaction, sequence, sequencer, driver, monitor, agent, scoreboard, coverage)를 직접 설계하고, 예제 AXI4-Lite 레지스터 슬레이브 DUT를 대상으로 write-read 데이터 무결성을 검증했습니다.

Coverage 항목: write/read 여부(cp_rw), 레지스터별 접근(cp_addr), 데이터 패턴(cp_data: zero/all_one/others), 레지스터×R/W cross coverage(cx_addr_rw).

싱글사이클 RV32I CPU 설계를 기반으로 IF-ID-EX-MEM-WB 5단 파이프라인 CPU를 새로 설계하고, Forwarding/Hazard 처리와 Golden Model(싱글사이클 CPU 재사용) 기반 Scoreboard로 명령어 실행 결과를 검증했습니다.

AXI4-Lite VIP와 구조는 같지만 프로토콜은 더 단순한(SETUP→ACCESS 2단계, 단일 채널) APB UVM VIP를 새로 만들고, AXI4-Lite ↔ APB 프로토콜 변환 브리지를 설계해서 Phase 1의 AXI4 VIP로 브리지 너머의 APB 슬레이브까지 End-to-End로 검증했습니다.

APB VIP를 Phase 1 AXI4 VIP와 동일한 구조(Driver/Monitor/Agent/Sequence/Scoreboard/Coverage)로 구축해 예제 APB 슬레이브로 단독 검증한 뒤, AXI4-Lite ↔ APB 변환 브리지를 별도 RTL로 설계했습니다(AXI4-Lite 슬레이브 포트로 AW/W를 캡처해 APB 마스터 포트의 SETUP→ACCESS 시퀀스로 변환하는 FSM 구조). 최종적으로는 Phase 1의 AXI4 VIP·Sequence·Scoreboard를 그대로 재사용해 "AXI4 VIP → 브리지 → 실제 APB 슬레이브"까지 한 번에 검증했습니다 — 이 단계에서는 APB VIP(Driver/Monitor)를 쓰지 않고 브리지 자체가 APB 마스터 역할을 합니다.

• Synopsys VCS (시뮬레이션)
• Synopsys Verdi (파형 디버깅)
• UVM 1.1d

NVIDIA Jetson Orin Nano 위에서 Webcam 3대 입력을 실시간으로 처리해, 운전자 졸음, 차량 내 잔류 아동/반려동물, 차량 주변 비인가 접근을 하나의 On-Device AI 파이프라인으로 감지하는 3인 팀 프로젝트입니다. 모든 추론과 위험 판단을 외부 서버 없이 Jetson 내부에서 수행하고, 최종 상태와 이벤트 정보만 Web UI/Telegram으로 전달합니다. 저는 이 중 운전자 졸음 감지(System1)를 전담 설계·구현했고, 잔류 탑승자 감지(System2)의 Jetson 전력 소비 측정 및 분석을 함께 담당했습니다.

3대의 Webcam(운전자·뒷좌석·차량 주변)이 Jetson Orin Nano에 각각 연결되고, Jetson 내부에서 3개 서브시스템이 각자의 AI 파이프라인으로 실시간 추론을 수행합니다. 최종 상태와 이벤트 정보만 Web UI와 Telegram Bot으로 전달되어, 영상 데이터 자체는 외부로 나가지 않습니다.

운전자의 눈 감김(Eye), 하품(Yawn), 고개 자세(Head Pose)를 하나의 Multi-task 모델로 동시에 추론하고, 단일 Frame이 아닌 시간에 따른 상태 변화를 누적해 졸음 위험도(Risk Score)를 실시간으로 판단합니다. ResNet18 / MobileNetV2 / MobileViT-XXS 3종 Backbone을 직접 학습·비교하고, Jetson Orin Nano 실측 성능과 Grad-CAM 분석까지 거쳐 최종 모델을 선정했습니다.

Shared Backbone에서 추출한 특징을 Eye Head(2-class), Yawn Head(2-class), Pose Head(3축 회귀)로 분기하는 구조이며, Eye/Yawn/Head Pose 데이터셋마다 라벨이 달라 Batch마다 해당 Task의 Loss만 계산하되 Shared Backbone은 항상 업데이트하는 Partial-label Multi-task Learning으로 학습했습니다. 최근 3초 구간의 Eye Closed Ratio, 60초 구간의 Yawn Score, 3초 구간의 Head-down Ratio를 가중합해 Risk Score를 산출합니다.

단일 Task 기준으로는 ResNet18이 가장 높은 정확도(96.83%)를 보였지만, Multi-task 학습 결과에서는 가장 가벼운 MobileViT-XXS가 Eye Accuracy(97.31%)·Pose MAE(10.44°) 모두에서 가장 우수했습니다. Latency는 7.13ms로 세 모델 중 가장 길었지만, 30FPS 영상의 Frame당 처리 제한시간(약 33.3ms) 대비 충분히 짧아 실시간 처리에 문제가 없다고 판단했습니다.

Accuracy vs Latency Trade-off

모델 종합 효율성 비교 (Radar Chart)

수치 비교만으로 설명하기 어려운 정확도 차이를 보완하기 위해, Eye Task의 OPEN/CLOSED 판단 근거를 Grad-CAM으로 시각화했습니다. CLOSED 샘플은 세 모델 모두 정확히 분류했으나, OPEN 샘플에서는 MobileViT-XXS가 8/10으로 가장 우수했습니다. Heatmap 비교 결과 MobileNetV2는 눈 전체와 주변까지 넓게 활성화된 반면, MobileViT-XXS는 동공·눈꺼풀 중심의 좁은 영역에 집중되어 Eye 상태 판단과 직접 관련된 특징에 더 집중하는 경향을 확인했습니다.

CLOSED 샘플 Grad-CAM (10/10 정확)

OPEN 샘플 Grad-CAM (MobileViT-XXS 8/10)

졸음 판단의 핵심 지표인 Eye Accuracy, 가장 작은 모델 크기(Jetson에서 여러 모델을 동시 실행해야 하는 메모리 제약), Grad-CAM으로 확인한 판단 근거의 타당성을 종합해 MobileViT-XXS를 System1의 최종 모델로 선정했습니다.

System2는 YOLO11(Person/Cat/Dog 검출) + MiVOLO V2(연령 추정)의 2-Stage Pipeline으로 7세 이하 아동·반려동물 잔류를 감지하고, 잔류 지속시간에 따라 Stage 0~3 단계별로 경고합니다. 저는 이 중 YOLO11n/s/m의 Jetson 실측 전력 소비(Average Power, Energy/Frame) 측정 및 분석을 담당했습니다.

측정 초기에는 1회 단발 측정으로 인해 YOLO11s가 YOLO11m보다 전력이 높게 나오는 비정상적인 결과가 나왔는데, 모델당 30초씩 3회 반복 실행 + 실행 사이 5초 대기시간을 Shell Script로 자동화하고 평균·표준편차를 계산해 YOLO11n < YOLO11s < YOLO11m의 정상 경향을 재현성 있게 확인했습니다(다만 차이는 약 67mW로 미미). 또한 MiVOLO V2가 측정 시점에 ONNX CPU Provider로 실행되어 최종 시스템(TorchScript GPU)과 조건이 달랐던 것을 발견해 GPU 실행으로 통일 후 재측정했습니다.

팀원이 구현한 서브시스템으로, YuNet(얼굴 검출) → MiniFASNetV2(Anti-Spoofing) → SFace(얼굴 인식) 3-Stage Pipeline으로 OWNER/GUEST/UNKNOWN/SPOOF를 판정합니다. UNKNOWN/SPOOF를 단일 Frame에서 즉시 경고하지 않고, Capture Timer와 Presence Timer를 분리 운영해 순간적 오검출과 실제 장시간 비인가 접근을 구분하는 지속시간 기반 보안 정책이 특징입니다.

• Hardware: NVIDIA Jetson Orin Nano Developer Kit, USB Webcam × 3
• OS / SDK: JetPack 6.2.2 (Jetson Linux), CUDA 12.6
• Language: Python
• AI Framework: PyTorch, timm, TensorRT FP16, TorchScript
• Model Training: Google Colab (Tesla T4 GPU)
• User Interface: Web UI (FastAPI / Flask), Telegram Bot Alert

HAL 없이 레지스터를 직접 제어하는 방식으로 4x4 키패드 인증, I2C LCD, 8x8 도트매트릭스, 서보 PWM을 통합한 상태 머신 기반 도어락 시스템.

STM32F411RE(Cortex-M4) 위에서 HAL 라이브러리를 쓰지 않고 레지스터를 직접 제어하는 방식으로 만든 도어락 시스템입니다. 4x4 키패드로 비밀번호를 입력받아 I2C LCD에 표시하고, 인증에 성공하면 서보모터로 잠금을 해제, 실패가 누적되면 일정 시간 입력을 막는 Lockout 상태로 전환됩니다. HAL 없이 직접 레지스터를 건드린 이유는 각 페리퍼럴이 실제로 어떻게 동작하는지 이해하고 싶었기 때문입니다.

IDLE → INPUT → CHECK → UNLOCK/LOCKOUT의 4단계 상태 머신으로 인증 로직을 설계했습니다. 비밀번호가 일치하면 UNLOCK 상태로 전환되어 서보모터가 문을 열고, 불일치 시 다시 IDLE로 돌아가되 실패 횟수를 누적합니다. 3회 연속 오답 시 10초간 LOCKOUT 상태로 전환되어 입력 자체를 막는 방식으로 무차별 대입 시도를 방지했습니다.

LCD 통신에 쓰인 I2C1 페리퍼럴을 HAL 없이 START/ACK/STOP 시퀀스부터 직접 구현했습니다. 레지스터를 직접 다루다 보니 타이밍 이슈나 ACK 누락 같은 문제를 초반에 자주 만났고, 이 과정에서 I2C 프로토콜의 신호 레벨 동작을 훨씬 깊이 이해하게 됐습니다.

TIM2/TIM3/TIM4/TIM5 네 개의 타이머를 각각 서보 PWM 제어, LCD 화면 갱신, Lockout 카운트다운, 범용 딜레이 용도로 나눠 배치했습니다. 하나의 타이머를 여러 용도로 겸용하면 인터럽트 우선순위 충돌이나 타이밍 꼬임이 생기기 쉬워서, 기능별로 완전히 분리하는 쪽을 택했습니다.

개발 중 배선 불량, 접촉 불량 같은 하드웨어 문제와 실제 로직 버그가 뒤섞여 원인 파악이 어려운 경우가 많았습니다. 이를 해결하기 위해 각 페리퍼럴 상태를 실시간으로 출력하는 진단용 펌웨어를 별도로 만들어, 문제가 하드웨어 쪽인지 소프트웨어 쪽인지 먼저 구분한 뒤 접근하는 방식으로 디버깅 시간을 줄였습니다.

MicroBlaze를 AXI Master로 사용하고, 직접 설계한 Custom AXI I2C Master IP를 포함한 GPIO/Timer Peripheral을 AXI4-Lite로 통합한 SoC. LCD/FND/LED/Button 기반 반응속도 측정(Reaction Test) 앱을 HW/SW Co-Design으로 구현하고 UVM으로 검증.

Button → Custom AXI GPIO → MicroBlaze Application → Reaction Test FSM → Timer(1ms Tick) → FND/LED → Custom AXI I2C Master → PCF8574 LCD 순서로 데이터가 흐릅니다.

유지형 Control Bit(intr_en)와 Pulse형 Command(cmd_start/stop/write/read)를 분리 설계했습니다. Command bit는 1클럭 펄스 후 하드웨어가 자동 클리어되며, done은 SR을 읽으면 자동 클리어(rc_r)되어 intr_en과 AND되어 인터럽트를 발생시킵니다.

IDLE → WAIT(랜덤 2~5s) → GO → RESULT → IDLE 상태로 구성되며, WAIT 상태에서 너무 빨리 버튼을 누르면(Too Early) 결과를 9999로 처리합니다. Timer Interrupt 기반 1ms Tick과 FND Multiplexing으로 반응시간을 논블로킹으로 측정하도록 설계했습니다.

Custom AXI GPIO IP에 대해 Write/Readback/WSTRB/Corner Pattern 등 5개 UVM 테스트를 수행해 Functional Coverage 29/29 Bin, 100%를 달성했습니다. AXI Simulation, I2C FSM 신호, Logic Analyzer 실측까지 전부 정상 확인했습니다.

SPI와 I2C Master/Slave RTL을 각각 설계하고, UVM(sequence → driver → monitor → scoreboard/coverage) 기반 검증 환경으로 기능 검증. Verdi 시뮬레이션·Functional Coverage뿐 아니라 Logic Analyzer로 FPGA 실측 파형까지 확인해 simulation과 hardware의 정합성을 검증한 개인 프로젝트.

sequence → agent(sequencer/driver/monitor) → scoreboard/coverage 구조이며, Interface를 경계로 위쪽은 Software(UVM), 아래쪽은 Hardware(DUT)로 분리했습니다.

Master 보드(button_debounce + Master Controller + Master + 7-seg)와 Slave 보드(Slave + Slave Controller + 7-seg)로 나눈 실제 FPGA 2-Board 구성입니다.

I2C Master/Slave Board 구조

SPI Master/Slave Board 구조

START/STOP 조건과 ACK/NACK 응답이 I2C 프로토콜의 핵심입니다. 실제 파형으로 두 상황을 비교 분석했습니다.

I2C START/STOP 조건 파형

ACK vs NACK 응답 비교

단순 데이터 비교가 아니라 I2C 프로토콜 규칙 자체를 판정 로직에 반영했습니다. 트랜잭션 완료 여부(타임아웃), NACK 테스트인지 ACK 테스트인지, 그리고 실제 데이터 일치 여부를 순서대로 검사해서 각각 다른 사유로 PASS/FAIL을 기록합니다. 의도적으로 잘못된 주소를 보내 NACK을 유도하는 테스트에서는 NACK이 오는 것이 오히려 정상 동작이므로, sequence item에 expect_nack 필드를 추가하고 uvm_config_db로 scoreboard까지 전달해 정상/의도된 NACK 시나리오를 모두 정확히 판정하도록 만들었습니다.

I2C Master/Slave 상태 정렬 Waveform

Functional Coverage 100% 달성

RV32I 명령어 서브셋을 지원하는 Single Cycle CPU를 SystemVerilog로 설계하고, R/I/IL/S/B/U/J 각 명령어 타입별 datapath·control path를 시뮬레이션으로 검증. C 코드 기반 누적합(sum)·버블 정렬 프로그램 실행까지 검증.

Program Counter → Instruction Memory → Control Unit(opcode/funct3/funct7 decode) → Register File(rs1/rs2 read) → Immediate Generator → ALU → Data Memory → Write-back MUX → Register File(write-back) 순서로 데이터가 흐르며, branch/jump 여부에 따라 next PC가 결정됩니다.

R-type은 rf_we=1, alusrc_sel=0으로 rs1/rs2가 ALU를 거쳐 곧바로 write-back되고, I/IL-type은 alusrc_sel=1로 immediate를 ALU 입력으로 사용합니다. 같은 immediate 기반 연산이라도 I-type은 ALU 결과를, IL-type(Load)은 Data Memory 출력을 write-back한다는 점이 구분 포인트였습니다. B-type은 Register File write 없이 branch 조건만으로 PC를 갱신하고, JAL/JALR은 PC+4를 link register(rd)에 저장합니다.

R-type부터 J-type까지 7개 타입 모두 opcode decode → control signal → datapath 연산 → write-back까지 단계별로 검증했습니다. 여기서 그치지 않고, 누적합(loop, function call, stack frame 포함)과 버블 정렬(배열 접근, swap, branch) C 프로그램을 instruction memory에 올려 실제 프로그램 흐름 레벨까지 검증했습니다.

• R/I/IL/S/B/U/J 7개 타입 전부 예상값과 일치 확인
• C 누적합 프로그램: 1~10 합산 loop + function call → data_ram[58]=55 확인
• C 버블 정렬 프로그램: 배열 정렬 후 1,3,5,7,9 순서 확인

UART RX/TX, FIFO, ASCII Decoder를 하나의 DUT로 통합하고, SystemVerilog 기반 class-based testbench(Generator → Driver → Monitor → Scoreboard)로 End-to-End 기능 검증을 수행한 개인 프로젝트입니다. Directed test와 Constraint Random test를 함께 적용해 각 블록 단위 검증과 통합 경로 검증을 모두 수행했습니다.

• Class 기반 Testbench: Transaction class로 자극(stimulus)을 정의하고 Generator/Driver/Monitor/Scoreboard를 독립 class로 분리해 재사용성 확보
• Directed + Constraint Random 혼합 검증: 기본 동작은 Directed test로, 경계·조합 케이스는 Constraint Random으로 커버
• UART End-to-End 경로 검증: TX → RX loopback 및 RX → FIFO → ASCII Decoder까지 이어지는 전체 데이터 흐름을 하나의 Scoreboard로 판정
• FIFO 동시 Push/Pop 검증: 실제 DUT의 조합/순차 로직 특성을 반영한 reference model로 정확한 비교 수행
• fork~join 기반 병렬 검증: Driver/Monitor를 병렬 thread로 구동해 실시간 검증 환경 구성

UART RX → FIFO → ASCII Decoder 전체 경로를 하나의 top 모듈로 통합했습니다. Generator가 transaction을 생성하면 Driver가 interface를 통해 DUT에 입력하고, Monitor가 출력을 관찰해 Scoreboard로 전달, Scoreboard가 내부 reference queue와 비교해 PASS/FAIL을 판정하는 구조입니다.

UART 검증 환경

FIFO 검증 환경

Testbench 아키텍처 설계(Generator/Driver/Monitor/Scoreboard), Interface 정의, Directed/Constraint Random 시나리오 작성, 통합 경로 Scoreboard 판정 로직 구현까지 전 과정을 직접 담당했습니다.

FPGA(Basys-3) 기반 UART 통신 + FIFO 버퍼링 + SR04/DHT11 센서 + Stopwatch/Watch를 하나의 시스템으로 통합한 프로젝트입니다. 물리 버튼과 UART 명령을 공통 제어 경로로 통합하고, 시간 데이터·센서 데이터를 FND와 UART 양쪽에 동시에 출력하도록 설계했습니다. 4인 팀 프로젝트.

• UART 명령 제어: R/L/U/D/M/S 문자 명령을 ASCII Decoder가 버튼 입력과 동일한 제어 신호로 변환 → 보드 버튼 없이도 원격 제어 가능
• UART 상태 송신: 현재 모드(Watch/Stopwatch/SR04/DHT11)의 데이터를 ASCII Sender가 문자열로 변환해 UART TX로 송신, PC에서 실시간 확인 가능
• FIFO 버퍼링: RX/TX 각각 독립 FIFO(Circular Buffer)로 송수신 타이밍 차이에 의한 데이터 손실 방지
• Stopwatch/Watch: RUN/STOP/CLEAR/Up-Down Count + 시각 자동 증가 및 시/분/초 설정
• SR04 초음파 센서: Trig pulse 생성 → Echo pulse width 측정(1us tick) → 거리 환산(distance = width/58)
• DHT11 온습도 센서: tri-state(inout) 제어 + synchronizer로 안정화, 40bit 프레임 수신 후 checksum 검증
• 공용 FND 출력: 시간 데이터(Main FND)와 센서 데이터(Sensor FND)를 스위치 선택에 따라 하나의 FND 자원에서 Multiplexing 출력
• Button Debounce: Shift Register + Edge Detection으로 채터링 제거, UART 입력과 동일한 제어 경로 공유

top_uart가 UART 명령을 해석해 내부 제어 신호를 만들고 상태를 ASCII로 되돌려보내는 역할을, top_fnd가 Stopwatch/Watch·SR04·DHT11·FND 출력 등 실제 데이터 생성을 담당합니다. Control Unit FSM이 버튼과 UART 입력을 공통 경로로 받아 스위치 조합(sw[3]/sw[1])에 따라 Watch/Stopwatch/SR04/DHT11 모드를 선택해 각 블록에 제어 신호를 분배하고, FND 출력 선택 로직이 sw[3] 기준으로 Main FND(시간)와 Sensor FND(센서) 중 하나만 최종 출력 포트로 전달합니다.

FPGA(Basys-3) + ComPortMaster 환경에서도 DHT11(temp/humidity:24/51 등)과 SR04(DISTANCE:167 등) 데이터가 FND·UART 양쪽에 정상 반영됨을 확인했습니다.

FPGA(Basys-3) 상에서 UART(Universal Asynchronous Receiver/Transmitter) 송수신 구조를 구현하고, Loopback(수신 데이터를 그대로 재전송) 방식을 통해 송수신 기능의 정확성을 검증한 프로젝트입니다. Tx/Rx를 FSM 기반으로 분리 설계하고, 16배 Oversampling으로 수신 안정성을 확보했습니다.

• UART Transmitter / Receiver: FSM 기반(IDLE → START → DATA → STOP) 상태 제어로 송수신 동작 정의
• Baud Tick Generator: 100MHz 시스템 클럭을 분주해 9600bps 기준 Tick(b_tick) 생성, Tx/Rx가 공통으로 사용
• 16x Oversampling: 비트 중앙(mid-point)에서 샘플링하여 노이즈·타이밍 오차에 대한 수신 안정성 확보
• Loopback 구조: rx_done을 tx_start에 직접 연결해 수신 완료 즉시 동일 데이터를 자동 재전송
• Shift Register 기반 직렬-병렬 변환: LSB-first 방식으로 데이터 조립/분해

UART Receiver(Rx)는 rx 신호의 High→Low 전이로 Start bit를 감지한 뒤 b_tick 기반 카운터로 mid-point에서 샘플링하고, 8bit 수신이 완료되면 rx_done(1-cycle pulse)을 발생시킵니다. UART Transmitter(Tx)는 tx_start 신호로 동작을 시작해 Start bit(0) → 8bit 데이터(LSB-first, shift register) → Stop bit(1) 순서로 출력하며, 전송 중에는 tx_busy가 High를 유지합니다. Baud Tick Generator는 시스템 클럭을 분주하여 Tx/Rx가 공유하는 공통 타이밍 기준(9600bps × 16)을 생성하고, Loopback 구조는 rx_done → tx_start를 직접 연결해 별도 제어 로직 없이 수신 즉시 재전송되도록 합니다.

FPGA(Basys-3) + PC 시리얼 통신(ComPortMaster) 환경에서도 PC에서 입력한 문자열이 동일하게 되돌아오는 것을 확인했으며, 반복 실험에서도 데이터 손실·순서 오류 없이 안정적으로 동작함을 검증했습니다.

UART Tx/Rx FSM 설계, Testbench 작성 및 시뮬레이션 검증, Loopback 구조 System Integration, FPGA Bitstream 생성 및 보드 동작 확인까지 전 과정을 직접 담당했습니다.

FPGA(Basys-3)에서 Stopwatch와 Digital Watch를 하나의 시스템으로 통합 구현. Control Unit(FSM)과 Datapath를 분리한 모듈화 구조, Debounce + Edge Detection 기반 버튼 입력 처리, 계층적 Tick 카운터 구조 적용.

Control Unit(FSM)이 상태 전이와 제어 신호 생성을 담당하고(Stopwatch: STOP→RUN→STOP / STOP→CLEAR / STOP→MODE→STOP, Watch: WATCH→HOUR_SET→MIN_SET→WATCH), Datapath가 그 신호를 받아 실제 시간 데이터를 연산합니다. msec→sec→min→hour로 overflow/underflow(carry/borrow)가 전파되는 계층적 Tick 카운터 구조를 적용했습니다.

2인 팀 프로젝트였고, 저는 Testbench 작성 및 시뮬레이션 검증, 모듈 통합(System Integration), FPGA Implementation을 담당했습니다.