인프런 커뮤니티 질문&답변
작성한 질문수
FSM은 밀리머신인가 무어머신인가
작성
·
1.7K
2
안녕하세요 맛비님.
다음과 같은 코드를 보면
always문 안에는 *(asterisk) 로 combination circuit 즉, clock에 의존하지 않습니다.
제가 알기로 무어(MOORE) 머신은 output이 현재 state 에만 의존한다. 클럭 엣지에 의해서만 output이 바뀐다.로 이해하였고,
밀리(MEALY) 머신은 output이 현재 state와 input에 의존한다. 클럭의 한 사이클을 기다리지 않고 같은 사이클에서 입력을 바로 출력에 반영한다. 라고 알고 있습니다.
그럼 위 코드는
clock에 의존하지않고,
1. 현재 상태 = S_IDLE 일 때 현재 입력이 i_run=1이면 clock에 관계없이 바로 output, 즉 다음 상태가 S_RUN으로 되고,
2.현재 상태 = S_RUN 일 때 현재 입력이 is_done=1이면 clock에 관계없이 바로 output, 즉 다음 상태가 S_DONE으로 되고,
3.현재 상태 = S_DONE일 때 현재 입력에 상관없지만 clock에 관계없이 바로 output, 즉 다음 상태가 S_IDLE로 됩니다.
c_state는 clock에 의존하여 변하지만,
"밀리(MEALY) 머신은 output이 현재 state와 input에 의존한다. 클럭의 한 사이클을 기다리지 않고 같은 사이클에서 입력을 바로 출력에 반영한다. 라고 알고 있습니다." 에서
n_state는 같은 사이클에서 입력을 바로 출력에 반영한다. 라고 보이므로, MEALY 머신이 아닌가요?
인터넷에서는 FSM이 MOORE 머신이라고 나와서 질문드립니다!
답변 1
1
안녕하세요 :)
제가 알기로 무어(MOORE) 머신은 output이 현재 state 에만 의존한다. 클럭 엣지에 의해서만 output이 바뀐다.로 이해하였고,
밀리(MEALY) 머신은 output이 현재 state와 input에 의존한다. 클럭의 한 사이클을 기다리지 않고 같은 사이클에서 입력을 바로 출력에 반영한다. 라고 알고 있습니다.
그런가요? Clock 의 사이클과 밀리 무어가 상관이 있는지는 처음 들었습니다. (출력 State 가 현재 input state 에 영향이 있는지 없는지의 차이라고 알고 있어요. 다시말씀드리지만, Cycle 과 무관합니다.)
여기 다음 링크의 생각이 제 생각과 같고요.
읽어보시고 다시 질문 남겨주시면 좋을 것 같아요. (답변을 수정하기에, 너무 기네요..ㅠㅠ)
참고로 제가 사용한 실습코드는 moore 입니다. (무어를 많이 사용해요. 밀리는.. 로직을 최소화 하는 장점외에는.. 별로 이점이 없네요. 줄이는게 전체 시스템에 0.00...0001 % 도움이 될 것 같긴한데..;; 가독성이나, 글리치 이슈가 더 크리티컬하여... 아직 필요성은 못느껴봤습니다.)
즐공하세요 :)
안녕하세요 :)
한 clock 이후에 출력값이 나오게 함으로써 글리치 이슈가 적어지거나 발생하지 않는 이유가 뭔가요?
-> Combinational 로직이 관여하지 않은 sync edge 기반의 출력이기 때문입니다. Digital logic 설계 내에서 가장 안전한 출력이죠.
플립플롭을 거침으로써 noise가 사라지는 건가요?
-> 노이즈의 종류 중 외부 요인이 있기때문에, noise 가 사라지진 않습니다. 글리치는 실생활에서 항상 존재합니다.
관련 내용은 석사 수업에서 배우고요. 잘 나와있는 사이트는... 저도 잘... ㅎㅎ 구글링 해서 종합해보시면 좋을 것 같아요. 찾아보시고 공유 해주시면 감사하겠습니다.
즐공하세요 :)
답변 감사합니다.
그러면 1 clock 이후에 출력값이 나오게 하는 것과
3 clock 이후에 출력값이 나오게 하는 것은 글리치 이슈에 대해서
똑같은 영향력을 지니나요?
(ex. 출력이 나오게 되는 clock을 더 늘림으로써 글리치 이슈가 더 적어지거나 할 수는 없나요?)
정확한 답변은 어렵겠지만, (경우의 수가 많은지라)
일반적으로 답변을 하자면.
1 clock 이후 출력, 3 clock 이후 출력은 글리티 이슈에서 같은 영향력을 지니지 않습니다.
고속 clock 설계에서는 멀티 cycle 을 사용하기도 하죠.
즐공하세요 :)
맛비님. n_state와 c_state로, c_state는 sync_logic, n_state는 comb_logic의 두가지 상태로 나누는 이유를 알 수 있을까요?
n_state만 써도 어떤 block 이든 설계가 가능하지 않을까 싶은데
이렇게 n_state와 c_state로 나누는 이유가 있을까요?
나누는 이유라...
나누는 이유는 설계하기 쉬워서 입니다.
FSM 은 상태 기반이죠. 즉 현재 상태, 다음 상태가 필요합니다.
이정도면.. 이유는 충분한데요.. 안쓰고 설계하시는게 편하시다면 그렇게 하셔도 됩니다.
결론 정답은 없다. (하지만 맛비의 방식을 추천한다. 직접 설계해보다 보면.. 자연스럽게 아시게 되지 않을까..요?)
음.. 저도 사실 맛비님 방식대로 설계를 하지 않을 때보다 방식대로 설계할 때 하고자 하는 동작을 구현하기 더 쉬웠습니다.
그런데.. 만약 팀끼리 프로젝트를 하다가, 왜 현재 상태와 다음 상태로 굳이 나누었어? 라고 물어보면
현재 상태에서 할 수 있는 동작과 다음 상태에서 할 수 있는 동작을 코드로 구현하기 쉽다라고 말할 것 같은데 뭔가 말이 깔끔하지 않달까.. 싶습니다.
코드를 줄일 수 있어? 왜? F/F만 늘어나는거 아냐? 라고 물어보면 뭐라고 대답하는게 좋을까요?
알려주신
"현재 상태에서 할 수 있는 동작과 다음 상태에서 할 수 있는 동작을 코드로 구현하기 쉽다"
이 답변이 수긍이 되신다면 이렇게 대답을 해야겠네요. (제 답글의 의도를 잘 정리해주셨...)
그런데.. 만약 팀끼리 프로젝트를 하다가, 왜 현재 상태와 다음 상태로 굳이 나누었어? 라고 물어보면
이런 질문을 현업에서 들어본적은 없는데, 혹여나 누군가 한다면 위에 적어주신 대로 답변할께요 :)
===================
이건 이렇게 하고.. 말보다는
직접 구현해보시면 자연스럽게 해결될 일 같아보여요. (어떤코드와 제 코드를 비교해야 이런 질문이 나오는지 모르겠는데...;;;)
저라면 친구에게 이렇게 이야기하겠습니다.
코드를 줄일 수 있어?
"바꿀려고 하는 코딩스타일이 뭐길래...? 생각하는 코드를 구현해보고 비교해볼래?" 라고 답을 할 것 같고요.
"왜? F/F만 늘어나는거 아냐?"
"정말 그럴까? 생각하는 코드를 구현해보고 합성해서 비교해 볼래?" 라고 답을 할 것 같습니다.
그리고... "우리 같이 코드와 합성 결과를 보자 :) "
F/F util 사용량 확인 방법은 보드가 없더라도 다음 영상으로 충분히 커버가 되실꺼에요.
https://www.youtube.com/watch?v=8aBeMae2TqQ&t=1011s
방법은 알려드린 것 같아요. 나머지는 궁금증을 해결하고자하는 의지의 차이같습니다.
"본인"이 하실 수 있다면 직접 답을 찾아보시는 건 어떨까요? :)
안녕하세요 맛비님.
한 clock 이후에 출력값이 나오게 함으로써 글리치 이슈가 적어지거나 발생하지 않는 이유가 뭔가요?
플립플롭을 거침으로써 noise가 사라지는 건가요?
그리고 글리치에 대해 설명이 잘 나와있는 사이트 추천해주실 수 있을까요?