작성
·
674
2
답변 1
0
안녕하세요 :)
이런 응용을?! 이럴 수 있겠다 생각이 드네요.
결론부터 말씀드리면,
Testbench 에서의 현재 수정하신 (#10 i_run) "i_run 신호는 Clock 에 동기화 되지 않았다" 입니다.
저 두개의 코드는 같은 의미가 아니였나요?
#10 과 posedge clk 는 현재 simulation 상에서 같은 time 을 바라보고 있는 것은 맞습니다.
하지만 전혀 다른 i_run 신호입니다. :)
위와같이 확인하신 현상은 Verilog Race Condition 이라고 부릅니다.. (출처)
A Verilog race condition occurs when two or more statements that are scheduled to execute in the same simulation time-step, would give different results when the order of statement execution is changed, as permitted by the IEEE Verilog Standard.
1. "#10 i_run" 신호는 clk 에 동기화되지 않았습니다.
- #10 i_run 으로 하게되면 clk 와 아무런 동기화가 없는, 아무상관없는 i_run 이 됩니다. 이는 simulation 에 따라서 다른 결과를 만들 수 있습니다. 또한 이런 상황은 HW 관점에서 Race condition 이 됩니다. (비추천)
SW 하시는 분들은 이해하기 힘든... 안배우는 내용이죠.
HW 의 Race Condition 을 공부하시면 이해에 도움이 되실 것 같아요.
- posedge clk 이후에 i_run 을 하게 되면, clk 의 상승엣지의 동기화에 맞춘 i_run 이 됩니다.
즉 posedge clk 를 사용하는 것이 맞습니다.
2. 난 꼭!! #10 i_run 을 사용하고 싶다. (다시 말씀드리지만 추천 드리지 않습니다.)
이러려면 blocking assignments (=) 대신, nonblocking assignment (<=) 를 사용하시면 됩니다.
임시적인 방법일 뿐, 정상동작을 보장하긴 힘듭니다. 또한 다른 시뮬레이션 툴에서는 오작동을 할 가능성이 있습니다. (맛비도 정확하게 설명을 못하겠습니다.) 참고로 보여드리려고 작성드립니다. 궁금해하실까봐.
<blocking 사용시>
<non-blocking 사용시>
결론은 i_run 신호는 Clock 에 동기화해서 동작시켜야 정상적인 동작을 볼 수 있습니다.
Clock 동기화가 되지 않은 서로 다른 신호는 race condition 을 유발하게 됩니다.
posedge clk 로 Clock 동기화를 명시하여, i_run 신호를 handling 해주시면 되겠습니다.
또, 두개의 테스트 벤치중에서 어떤게 맞는 건지 궁금합니다.
제 의도는 기존 코드의 동작이 맞아요. :)
c_state 기준으로 0 -> 1 -> 2 -> 0 으로 돌면됩니다. (Idle -> run -> done -> idle)
즐공하세요 :)
덕분에 궁금한 것이 말끔하게 해결됐습니다! 즐거운 설에 이런 귀중한 답변 해주셔서 정말 감사드립니다! 늦었지만 새해복 많이 받으시고 행복한 하루 되셨으면 좋겠습니다!