저장·복구 기능 통해 디버깅으로 스마트한 '하드웨어 에뮬레이션'
상태바
저장·복구 기능 통해 디버깅으로 스마트한 '하드웨어 에뮬레이션'
  • 이나리 기자
  • 승인 2017.10.20 15:36
  • 댓글 0
이 기사를 공유합니다

[CCTV뉴스=이나리 기자] 지금까지 ICE 또는 테스트벤치(Testbench) 가속 시에 사용할 수 없었던 기법을 통해 에뮬레이션 디버깅 속도를 크게 높일 수 있게 됐다.

하드웨어 에뮬레이션은 최근 커다란 진전을 이뤘지만 개선의 여지는 아직도 많이 남아있다. 그 중 디버깅 용도가 좋은 예다. 디버깅은 모든 설계 요소들의 동작이나 파형을 추적할 수 있는 기능에 달려 있으며, 버그를 그 근원까지 추적해서 들어가야 한다.

조금만 계산해 보면, 툴을 그대로 적용할 경우 1MHz 속도로 실행되는 에뮬레이터가 실시간으로 1초간 처리하면 각 게이트 출력으로 1Mbit의 데이터가 생성된다는 것을 알 수 있다. 데이터 압축이나 최적화가 이뤄지지 않는다고 가정할 경우, 이는 대략 클락 주기당 1비트에 해당된다. 따라서 100M-gate 디자인은 실시간으로 1초당 100TB의 데이터를 생성하게 된다.

이런 데이터 용량을 최적화하지 않을 경우, 발생되는 문제는 두 가지로 요약된다. 첫째는 믿지 못할 정도로 엄청난 용량의 저장공간이 필요해진다. 둘째는 포스트 프로세싱과 파형 디스플레이를 위해 데이터를 에뮬레이터로부터 저장매체로 전송함에 있어서 긴 시간이 소요된다는 것이다. 설상가상으로, 에뮬레이션 런타임이 길 경우에 디버깅 데이터를 생성하면, 에뮬레이터 속도는 최대 100배까지 느려진다. 이런 경우 고가의 하드웨어인 에뮬레이터를 제대로 사용한다고 할 수 없다.

다행히 반가운 소식은 멘토 지멘스 비지니스가 이 문제를 해결하고자 노력해왔으며, 다양한 접근 방법들이 사용할 수 있도록 이미 구축했다는 것이다. 예를 들어, 거의 모든 에뮬레이터 벤더들이 데이터 압축과 최적화 기법들을 제공함으로써 필요한 저장공간 용량을 줄여주고 있다.

게이트의 출력 상태가 연속해서 1000클런 주기 동안 변하지 않는다면, 1000비트를 소비해 가면서 동일한 데이터를 반복적으로 저장할 필요가 없다. 역으로 에뮬레이터와 저장매체간에 전송되는 데이터의 양을 제한하기 위해서는 순차적 소자들(예컨대, 레지스터와 메모리)의 데이터만 읽어내면 된다. 순차적 소자들 사이에 끼어있는 조합 소자들의 동작은 에뮬레이터에 연결된 워크스테이션(Workstation)에서 드라이버 역할을 하고 있는 순차적 소자들의 동작으로부터 즉각적으로 재현해낼 수 있다[그림 1].

체크포인트를 통한 저장과 복구

10억 게이트 시대에는 운영체제(OS) 부팅, 소프트웨어 애플리케이션의 실행, 긴 테스트 시퀀스를 필요로 하는 임베디드 디자인을 테스트하는 데 수십억 클럭 주기가 소요될 수 있다. 1MHz 속도로 실행되는 에뮬레이터는 1000초(약 15분) 동안에 10억 사이클을 처리한다. 설계상의 버그가 애플리케이션 프로그램이나 운영체제 부팅 후에 실행되는 소프트웨어 테스트에서 작동될 경우에는 실행 시간이 몇 시간 소요될 수 있다. 디버깅 시에는 일반적으로 실행을 반복해야 하므로, 당연히 이런 시간에 필요한 추가 실행 횟수를 곱해줘야 한다.

이처럼 소요 시간이 급증할 가능성을 통제하기 위해 업계에서 내놓은 아이디어는 여러 기간에 걸쳐 테스트 대상 디자인(DUT)의 상태 공간 전체에 대해 스냅샷을 찍은 뒤, 이 데이터를 외부에 저장하는 방식이다. 우리는 이를 ‘체크포인트’라고 한다.

따라서 DUT는 맨 처음으로 돌아가는 것이 아니라 체크포인트가 설정되던 시점의 상태로 복구될 수 있다. 또 사용자는 체크포인트를 통해 에뮬레이터 실행을 원하는 DUT 상태로 신속하게 이동할 수 있다.

이는 검증 엔지니어에게 유용하다. 설계상의 버그로 인한 오동작은 그것이 동작됐던 시점에 가까운 관찰 시점으로 전파되는 경우가 많기 때문이다. 게다가 동작되는 시점과 오동작이 관찰되는 시점 사이의 간격은 몇 백만 클럭 주기에 불과할 때가 많다. 초기 에뮬레이션 세션에서 몇 백만 사이클마다 체크포인트를 설정할 수 있도록 했다면, 검증 엔지니어는 설계상의 버그로 인한 영향이 나타난 뒤에 실행을 멈추고 가장 근접한 체크포인트로부터 실행을 다시 시작할 수 있다.

버그가 처음 관찰된 지점을 에워싸고 있는 두 개의 체크포인트는 서로의 시간 간격 내에서 버그의 근원까지 추적해 들어갈 수 있을 가능성이 높다. 버그가 이 체크포인트 이전에 작동됐다면, 엔지니어는 그보다 앞서 있지만 해당 체크포인트에는 비교적 가까운 시점부터 실행을 다시 시작할 수 있다. 이 역시 맨 처음까지 되돌아가는 것보다는 낫다.

이런 능력은 DUT와 테스트 환경이 에뮬레이터 내부에 맵핑(Mapping)돼 있다는 과정에 전적으로 달려 있다. 합성 가능한 테스트벤치가 바로 그러한 경우다. 그러나 에뮬레이터가 인서킷 에뮬레이션(ICE) 모드에서 동작하고 있거나 혹은 트랜잭션(Transaction), SCEMI(Standard Co-Emulation Modeling Interface), UVM(Universal Verification Methodology) 접근방법(‘테스트벤치 가속’이나 ‘통합 에뮬레이션’이라고도 한다)을 통해 설계된 하드웨어 검증 언어(HVL) 테스트벤치에 의해 구동될 경우에는 문제가 발생한다.

전체 기사를 보시려면 로그인 필요

로그인 또는 회원가입을 해주세요. (회원만 열람가능)

로그인 회원가입


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
0 / 400
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.