검증

예전에 후배가 한 세미나 자료에서 그림을 많이 발췌합니다. 항상 검증을 언제 끝낼 것인가 하는 문제는 어렵습니다. 그래서, 검증할 때 coverage를 측정하여 검증을 언제 마칠것이냐 하는 것을 참고하게 됩니다. Functional verification때 고려하는 coverage로는 code coverage와 function coverage라는 것이 있는데, code coverage는 RTL 코드에 대한 분석을 기반으로 해당 문장이나 표현, 가능한 데이터 흐름이 현재 사용하고 있는 test program(혹은 stimulus) 에 의하여 어느 정도 수행되었는지 측정하는 것입니다.

검증 작업을 시작했다는 포스팅을 얼마전에 했었습니다. 뭐, 일단 검증 시나리오 짜고, function coverage 전략 세우고.. 이런것 부터 시작했습니다만.. verilog로 약간 검증 마인드로 이런 저런 것을 작성하다보니, synthesizable subset의 틀이 얼마나 옭죄고 있었나라는 생각이 심각히 들더군요.. verilog 표준에서 정의된 동작에 대해서 어느정도는 알고 있다고 자부하고 있었는데, 좀더 깊이 알게 되는 기회가 되고 있는 것 같습니다. 얼마전 gil님께서 class와 비슷한 verilog를 말씀하신 이유도 납득이 가구요..

Transaction Level Modeling(이후 TLM)이라는 것이 한 2-3년전부터 SoC설계 분야에서 논문/책/툴을 쏟아내고 있습니다. 그만큼 이제 시장 상황이 익어간다는 것이겠지요. 하지만 설계라는 분야에서 RTL에서 TLM 수준으로 추상화 수준이 이동할 것이라고 믿었던 사람들도 이제는 거의 TLM 수준에서 설계가 이루어질 것이라 믿고 있지 않습니다. 그 이유는 무엇일까요?

개인적으로 SoC에서 가장 재미있게 생각하는 부분이 검증/디버깅입니다. 처음부터 버그없는 넘을 만들면 좋겠지만, 그럴수 없다면 효과적인 검증과 디버깅은 “비용을 소모하는 부수적인 일”이 아니라 이미 필수적인 일인 것입니다. 간혹 몇몇 경영자분들께서 “자신이 실수를 하고 자신이 디버깅하는데 시간과 돈을 소모하는 건 전적으로 엔지니어의 부주의다.”라고 말씀하시곤 하는데, 50%는 납득하지만, 50%는 절대 납득할 수 없습니다.