UVM003 - UART_Tx, fork

이전

https://hdnua.tistory.com/254

UVM002 - UART_Tx, task

.

.

이전 문서에서 다음과 같이 주석을 달았던 적이 있다.

// -----------------------------------------------------------------------------
// Insight: 왜 UART testbench는 fork 없이는 말이 안 되는가
// -----------------------------------------------------------------------------
//
// UART는 서로 다른 장치 간 비동기 직렬 통신이다.
// 실제 시스템에서 TX 장치와 RX 장치는 물리적으로 동시에 동작한다.
// TX가 비트를 쏘는 동안, RX는 그 선을 듣고 있다.
//
// testbench에서 이를 모델링하려면 driver와 monitor가 동시에 실행되어야 한다.
//
// 그러나 순차 실행에서는:
//
//   send_byte('H')  → valid 올리고 즉시 반환
//   send_byte('e')  → w_TxReady 기다리는 중(블로킹)
//                     ← 이 동안 recv_byte 는 실행 못 함
//                     ← 'H' 프레임은 지금 지나가고 있음
//   send_byte('e')  → 완료
//   recv_byte()     → 이제 실행 — 근데 'H' 프레임은 이미 지나감
//
// driver가 블로킹되는 동안 monitor가 동시에 들을 수 없기 때문에,
// 순차 실행으로는 UART의 본질 자체를 표현할 수 없다.
//
// fork는 단순한 편의 기능이 아니라,
// "동시에 동작하는 두 장치"를 시뮬레이션하기 위한 필수 구조다.
// =============================================================================

.

.

fork 의 존재 이유에 대해서는 잘 설명이 된 거 같고. 다음은 TB다.

https://github.com/HDNua/hw001_uvm_study/blob/main/260329_uart/m1_uart_tx/m03_fork/tb/tb_top_v3.sv

// =============================================================================
// m03_fork : fork/join 병렬 실행
//
// m02_task 대비 변화:
//   - 다음 바이트를 보내기 전에 o_TxReady 복귀를 기다린다.
//   - fork/join으로 driver와 monitor를 병렬 실행한다.
//   - payload를 "Hello" 5바이트로 확장한다.
//
// 한계:
//   - driver와 monitor가 payload를 직접 공유한다.
//   - pass/fail 판정이 monitor task 내부에 섞여 있다.
//     → 비교 로직을 분리한 scoreboard가 필요한 이유.
// =============================================================================

.

.

waveform

.

.

두 프로젝트의 차이.

.

.

.

.