[Verilog HDL Q/A. 020] Testbench 에서의 input 신호 handling. # 10, @(posedge clk) 에 따른 DUT 결과의 다름. (Verilog Race Condition)

Q

안녕하세요. 이번에 테스트벤치 작성하면서 궁금한 것이 있어서 질문드립니다.

먼저 i_run신호를 강사님께서 작성하신대로

이렇게 작성하고 시뮬레이션을 돌리면

다음과 같이 나옵니다.

근데 위의 코드를

이렇게 바꾸면

이렇게 나옵니다. 저 두개의 코드는 같은 의미가 아니였나요?

왜 이렇게 나오는지 궁금합니다. 또, 두개의 테스트 벤치중에서 어떤게 맞는 건지 궁금합니다.

 

A

안녕하세요 :)

이런 응용을?! 이럴 수 있겠다 생각이 드네요.

결론부터 말씀드리면,

 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) 

 

즐공하세요 :)