FIFO 질문

작성자 없음

0 asked

0

안녕하세요, 답변 남겨드립니다.

질문 주신 부분은 FIFO를 단순히 “데이터가 들어가고 나온다” 수준으로 보는 것이 아니라, 실제 통신에서 producer와 consumer의 속도가 다를 때 FIFO가 어떻게 버퍼 역할을 하는지 보려고 만든 시뮬레이션 패턴입니다. 25번 강의는 overflow와 underflow를 피하기 위한 FIFO 설계를 다루는 파트라서, push와 pop을 둘 다 계속 1로 두기보다는 FIFO 내부에 데이터가 쌓였다가 빠지는 상황을 파형에서 보이도록 구성했습니다.

제가 push를 길게 1로 둔 것은 데이터를 보내는 쪽이 매 clock마다 계속 write를 시도하는 상황을 만들기 위해서입니다. 이때 push_rate = 1 word/cycle이 됩니다. 반대로 pop까지 계속 1로 두면 읽는 쪽도 매 clock마다 데이터를 가져가므로 read_rate = 1 word/cycle이 되고, FIFO 내부 count가 크게 변하지 않습니다. 그러면 full 근처로 가는 상황이나 empty 이후 underflow를 막는 조건을 파형으로 보기 어렵습니다. pop을 1, 0, 1, 0처럼 반복시키면 평균 read_rate가 0.5 word/cycle이 되기 때문에, push가 계속 1인 동안 FIFO 내부에는 평균적으로 0.5 word/cycle씩 데이터가 쌓입니다. 예를 들어 depth가 8인 FIFO라면, reset 이후 empty에서 시작했을 때 대략 16 cycle 안팎에서 full 조건에 가까워지는 흐름을 관찰할 수 있습니다.

실무적으로는 이 상황이 꽤 중요합니다. SoC 안에서 어떤 IP는 매 cycle 데이터를 만들 수 있지만, 그 데이터를 받는 쪽 IP는 arbitration, bus stall, ready deassertion, 내부 연산 지연 때문에 매 cycle 받지 못할 수 있습니다. AXI 계열로 보면 source는 valid를 계속 올리고 있는데 destination의 ready가 1 cycle마다 한 번씩만 올라오는 상황과 비슷합니다. 이때 FIFO가 없거나 depth가 부족하면 overflow가 발생하고, 반대로 읽는 쪽이 empty 상태에서도 읽어버리면 underflow가 발생합니다. 그래서 강의에서는 pop을 계속 1로 둔 이상적인 소비자보다, 읽었다 멈췄다 하는 소비자 패턴을 보여주는 쪽이 FIFO의 의미를 설명하기에 더 적합했습니다.

말씀하신 “pop이랑 clk이 잘못해서 겹치지 않는 경우”는 아주 좋은 관찰입니다. 다만 synchronous FIFO에서는 pop이 clk과 파형상 겹치는지가 핵심이라기보다는, posedge clk에서 pop 값이 안정적으로 1로 잡히는지가 중요합니다. 즉 read 동작은 보통 posedge clk에서 if (pop && !empty) 조건이 참일 때 발생합니다. pop 신호가 posedge 바로 근처에서 바뀌면 setup/hold 관점에서 좋지 않고, testbench에서도 race처럼 보일 수 있습니다. 그래서 깔끔한 testbench에서는 pop을 posedge에 딱 맞춰 바꾸기보다 negedge clk에서 바꿔 다음 posedge까지 약 반 주기 정도 여유를 주는 방식을 많이 씁니다. clk period가 10ns라면 negedge에서 pop을 바꿨을 때 다음 posedge까지 약 5ns의 setup 여유가 생기는 셈입니다.

pop을 쭉 1로 두는 테스트도 틀린 것은 아닙니다. 오히려 FIFO RTL이 잘 설계되어 있다면 pop이 계속 1이어도 empty 상태에서는 read pointer가 증가하면 안 됩니다. 안전한 설계라면 write는 push && !full일 때만, read는 pop && !empty일 때만 일어나야 합니다. 그래서 검증을 제대로 하려면 pop을 계속 1로 두는 case, pop을 토글링하는 case, push만 빠른 case, pop만 빠른 case, full 직전에서 push가 들어오는 case, empty 직전에서 pop이 들어오는 case까지 나눠서 보는 게 좋습니다. 강의에서 pop을 토글링한 것은 그중에서 producer가 더 빠르고 consumer가 간헐적으로 받는 상황을 직관적으로 보여주기 위한 대표 테스트라고 이해하시면 됩니다.

정리해서 말하면, pop을 토글링한 이유는 clock과 억지로 맞추기 위해서가 아니라 FIFO 내부 occupancy 변화를 만들고 overflow, underflow 방지 로직을 파형에서 확인하기 위해서입니다. clk과 pop의 관계는 “겹치느냐”보다 “posedge clk에서 안정적으로 샘플되느냐”가 핵심이고, 실제 설계에서는 pop && !empty 조건으로 read pointer를 보호하는 구조가 반드시 들어가야 합니다. 이 관점으로 파형을 다시 보면 push는 데이터를 계속 밀어 넣는 쪽, pop은 받는 쪽의 처리 속도가 낮거나 불규칙한 쪽을 모델링한 것이라고 보시면 됩니다.

0

안녕하세요, 인프런 AI 인턴입니다. 815aldo님.

FIFO(First-In-First-Out)에서 pop 신호를 1에서 0으로 반복해서 토글링하는 방식에 대해 궁금해 하시는군요. 이 방식은 일반적으로 FIFO의 동작이 제대로 수행되는지를 확인하기 위한 시뮬레이션 기법 중 하나입니다.

pop 신호를 항상 1로 유지하지 않고 토글링하는 몇 가지 이유는 다음과 같습니다:

1. 읽기 동작 확인: FIFO에서 데이터를 읽어가는 경우 pop 신호가 1로 설정될 때마다 데이터를 읽어오는 동작을 수행하게 됩니다. 그러나, pop을 계속 1로 유지하면 FIFO가 비어있을 때 억지로 데이터를 읽어오려 하거나 오류가 발생할 수도 있습니다. 따라서 pop 신호를 반복적으로 토글시켜서 정상적인 작동을 확인합니다.

2. 제어 신호 타이밍: pop 신호가 클록 신호와 적절하게 동기화되어 동작해야 합니다. pop과 클록이 정확히 맞물리지 않으면 올바르지 않은 시점에서 데이터를 읽게 되어 오류가 발생할 수 있습니다. 이를 예방하기 위해 pop 신호를 주기적으로 토글링하여 클록과의 타이밍이 잘 맞는지 검토합니다.

3. 상황 재현: 실제 동작 환경에서는 pop 되지 않는 경우도 있기 때문에 이를 모방하여 다양한 상황에서의 동작을 시뮬레이션할 필요가 있습니다. 이로 인해 발생할 수 있는 문제를 조기에 발견하고 해결하는 것이 중요합니다.

이와 관련된 좀 더 구체적인 사례 및 답변은 다음 유사한 질문에서 도움을 받을 수 있습니다:
- I2C SLAVE: 시스템 클럭과 SCL을 동기화하는 이유를 설명합니다.
- cache 코드 관련 질문드립니다!: 코드 타이밍 및 신호 동작에 대한 설명이 포함되어 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.