Chapter 16 FSM 관련 질문

投稿した質問数 2

0

안녕하세요. 맛비입니다.

질문자님이 짚으신 이유가 핵심입니다. 코드가 복잡해졌을 때 디버깅과 추적성이 급격히 떨어지는 것이 가장 큰 이유입니다.

추가로 실무에서 이 방식을 쓰지 않는 대표적인 이유를 정리해 드립니다.

• FSM 3-Step 분리 이유 (1-Always 구조를 피하는 이유)

  
  

  • 설계 명확성: State 업데이트(Sequential)와 Next State 계산(Combinational), Output 제어를 분리해야 HW 구조가 한눈에 들어옵니다.

    
    

  • 의도치 않은 Latency 방지: always @(posedge clk) 안에서 조합논리 조건까지 한 번에 처리하면, 원하는 시점보다 1 클락 늦게 동작하거나 의도치 않은 F/F이 생기기 쉽습니다.

    
    

• localparam과 연산자(+1) 미사용 이유

  
  

  • 가독성과 디버깅: Waveform 분석 시 숫자(0, 1)보다 S_IDLE, S_RUN 같은 이름이 직관적입니다.

    
    

  • FSM 확장성 및 최적화: 상태는 순차적으로만 넘어가지 않고 분기(Branching)하는 경우가 많습니다. c_state + 1 구조는 예외처리가 어렵고, 합성 툴(Synthesis Tool)이 One-hot 같은 FSM 최적화를 수행하는 데 걸림돌이 됩니다.

    
    

간단한 예제에서는 직관적으로 보일 수 있지만, 확장성과 유지보수를 위해 강의에서 다룬 표준 3-Step 방식과 localparam 사용을 권장합니다.

즐공하세요.

0

안녕하세요, 인프런 AI 인턴입니다. 백승민님.

Verilog 코드를 작성하면서 FSM(Finite State Machine) 설계를 최적화하는 방법에 대한 질문을 주셨군요. FSM의 설계 방식은 실제 코딩 스타일과 설계자의 편의에 따라 달라질 수 있지만, 기본적인 원칙들은 여전히 유지됩니다. 여기서 주신 두 가지 방법에 대해 설명 드리겠습니다.

1. Step1 과 2를 합치는 방식:

   • 두 단계를 합쳐서 사용하는 방식도 가능합니다. 그러나 이 경우에도 상태 전환을 명확하게 정의하고 코드의 가독성을 유지하는 것이 중요합니다. 코드를 분석하거나 디버깅할 때 각 스텝이 분리되어 있으면, 문제를 개별적으로 파악하기가 더 쉬울 수 있습니다.
     

2. Localparam 없이 상태 정의:

   • Localparam을 사용하지 않고 상태를 직접적으로 정의하는 것도 가능합니다. 이러한 방식은 코드를 간결하게 만들 수 있지만, 명확한 식별자 없이 숫자로 상태를 정의할 때 코드를 읽고 이해하는 데 시간이 더 걸릴 수 있습니다. 특히 모듈이나 코드가 복잡해질수록 가독성 면에서 불리할 수 있습니다. 따라서, 대규모 프로젝트에서는 state를 정의하는 데 있어 가독성을 고려해 Localparam을 사용하는 것이 권장됩니다.
     

   관련되는 질문의 FSM case문 default 와 latch 관련 질문이 있습니다. 이 질문에서 case문의 default 사용과 latch 방지에 대해 설명되어 있습니다.

FSM 설계는 설계자의 스타일과 프로젝트의 요구사항에 따라 달라질 수 있습니다. 각자의 스타일에 맞게 효율적이고 가독성 높은 코드를 작성하는 것이 중요합니다.

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