저장·복구 기능 통해 디버깅으로 스마트한 '하드웨어 에뮬레이션'

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

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

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

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

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

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

[그림 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) 테스트벤치에 의해 구동될 경우에는 문제가 발생한다.

ICE 모드에서, DUT를 구동하는 물리적 테스트 환경은 본질적으로 비반복적이거나 비결정론적이다. 따라서 버그가 연속되는 두 개의 에뮬레이션 실행 전반에 걸쳐 상이한 시점에 나타나거나 심지어 한 에뮬레이션에는 나타나고 다른 에뮬레이션에는 나타나지 않을 수도 있다. 멘토의 벨로체(Veloce) 에뮬레이션 플랫폼에서는 벨로체 결정적(Deterministic) ICE 애플리케이션을 이용해 이런 위험을 경감시킨다. 이는 비결정론적인 ICE 환경에 결정론을 구현한다.

그렇다면 HVL 테스트벤치의 경우는 어떠할까? 이는 행동적(Behavioral) 레벨에서 기술돼 있으며, 이를 상태 기계(State Machine)에 의해 정의되는 RTL(Register Transfer Level) 구성물로 합성할 수 없기 때문에 즉, HVL 테스트벤치는 저장할 수 없다. 따라서 DUT의 체크포인트를 설정해도 테스트벤치의 체크포인트를 설정하지 못한다면 아무런 의미가 없다.
특히 트랜잭션 기반의 테스트벤치에서 이런 합성 불가능한 테스트벤치를 저장하거나 복구하려면 어떻게 해야 할까?

테스트벤치 체크포인트

테스트벤치 가속 시의 테스트벤치 설정은 듀얼 도메인 환경으로 알려져 있으며, 다음 두 부분으로 구성된다:

• RTL보다 높은 추상화 수준에서 작성된 소프트웨어 기반의 도메인 또는 HVL 도메인은 테스트벤치로부터 기대되는 어떠한 검증 활동이라도 구현해내며 워크스테이션에서 실행된다.
• RTL 코드로 작성돼 에뮬레이터 상에 합성된 하드웨어 기반의 도메인 또는 하드웨어 기술 언어(HDL) 도메인은 테스트벤치 I/O 프로토콜을 구현한다. 이것은 다시 말해 상태기기나 버스 기능 모델(BFM)로서 DUT의 I/O 핀 전환을 제어한다.
도메인 간의 통신은 신호 레벨의 전환 대신에 멀티 사이클 트랜잭션(Multi-cycle transaction)들로 구성되며, SCEMI 기반의 DPI(Direct Programming Interface) 들여오기(Import)와 내보내기(Export) 기능과 태스크(Task)는 물론 SCEMI 파이프 세만틱(Pipe semantics)을 이용해 구현된다[그림 2].

[그림 2] 스플릿 트랜잭터는 테스트벤치로부터 오는 트랜잭션을 DUT가 요구하는 특정 프로토콜용의 신호 레벨 시퀀스로 변환하며, 그 반대로도 변환한다.

HVL 도메인은 행동적이고 시한적이지 않은(Untimed) 모델이다. 이는 소프트웨어 디버거, 중단점, 순수성(Purify), 수량화(Quantify)와 같은 건전성 검증기(Sanity Checker)에 익숙한 소프트웨어 개발자들의 영역이다. HDL 도메인은 오늘날의 합성 기술이 갖는 한계에서 자유롭지 못하다. 즉, 행동적인 구성물은 일반적으로 지원되지 않는다(주 [1]). 이 도메인은 파형, 트리거(Ttrigger), 모니터를 이용하며 레지스터와 메모리 내의 값도 조작하는 ASIC 디자이너들의 ‘안락 지대’다.

◈ 주 [1] 멘토는 시스템베리로그(SystemVerilog) RTL의 상위집합인 eXtended RTL을 위한 XRTL을 개발함으로써 버스 기능 모델(BFM) 작성 능력을 향상시켰다. 여기에는 내재 상태기계, 행동적인 클락과 리셋 생성 같은 다양한 구성물과 에뮬레이터 상에 합성할 수 있는 DPI 기능과 태스크들이 포함돼 있다.

이 두 도메인은 두 세트의 툴을 필요로 하는데, 그 각각에는 일반적으로 서로 다른 파일들이 입력되며 요구사항도 서로 다르다. 따라서 DUT 체크포인트를 설정할 수 있게 해주는 스냅샷 접근방법은 배제된다. 유일한 해결책은 테스트벤치의 활동 전체를 ‘0’ 시점부터 캡쳐하는 것이다. 여기에는 테스트벤치와 DUT 간에 교환되는 모든 트랜섹션들이 포함된다.

다시 말해, HDL DUT를 HVL 테스트벤치와 트랜잭터로부터 분리시키고 이들을 서로 다르게 취급해야 하며, 분할 정복하는 접근방법을 채택해야 한다. 따라서 DUT의 경우와는 달리, 주기적으로 테스트벤치의 스냅샷을 찍을 수 없다. 그 대신 테스트벤치와 DUT 간에 교환되는 모든 트래픽을 캡처해 저장하고, 디버깅을 위해서는 이 트래픽을 다시 재생해서 원하는 DUT 체크포인트에 도달해야 한다.

백업과 재생 기능을 이용한 디버깅

전통적인 디버깅 시에는 문제에 도달할 때까지 검증 엔지니어가 에뮬레이터를 실행한다. 엔지니어는 신속하게 분석을 수행한 뒤에 문제를 추적하기 위한 해당 시간대를 추정해 데이터 추적 기능을 활성화 하고 에뮬레이터를 재실행해 파형을 캡처한다. 이는 파형 캡처 없이 실행한 경우보다 훨씬 더 오래 걸린다. 모니터와 트랙커(Tracker) 같은 디버깅 툴을 사용할 경우에는 실행 시간은 더욱 느려진다.

백업과 재생 방법론은 이와 비슷하면서도 다르다. 백업 캡처는 ‘0’ 시점부터 활성화되며 신속한 턴어라운드가 가능할 정도로 짧은 시간 간격으로 설정되지만, 그렇다고 체크포인트가 과도해질 정도로 짧게 설정되지는 않는다. 문제에 부딪힐 경우, 엔지니어는 디버깅에 필요한 가장 근접한 시점을 파악한 뒤 HVL 테스트벤치의 사용 없이 그 시점 이전의 가장 근접한 체크포인트로부터 실행을 재생한다. 재생 시에는 DUT로부터 HVL 테스트벤치로 전달된 어떠한 메시지도 실행되지 않는다. 단, 몇몇 시스템 태스크와 어썰션(Assertion) 위배사항들은 예외다[그림 3].

[그림 3] 테스트벤치와 DUT 간의 트래픽을 캡처해 저장하고, 이 트래픽을 재생해 필요한 DUT 체크포인트에 도달한다.

백업과 재생 접근방법은 디버깅 사이클의 효율성을 향상시킨다. 엔지니어는 필요한 시간대로 점프함으로써 제로 시점으로부터 재생 시작을 위해 설정된 시점까지 경과되는 시간을 절약할 수 있다. 재생 시에는 실행할 HVL 테스트벤치가 없으므로 처리속도가 더 빨라진다. 프로세싱은 저장된 테스트벤치와 DUT 활동 간의 통신 채널로만 국한되기 때문이다. 이는 테스트벤치 측의 추적 활동과 테스트 데이터 생성을 감소시킨다.

이런 접근방법은 디버깅의 효과도 향상시킨다. 이를 비결정론적인 테스트벤치에 적용하면 커스텀 모니터와 트랙커, 그리고 디스플레이 시의 ‘$display’와 같은 디버깅 정보를 더 많이 얻을 수 있다.

에뮬레이터와 테스트벤치를 처리하는 호스트 워크스테이션 간의 통신 채널은 높은 처리 속도를 달성하기 위해 대역폭이 넓고 대기 시간은 짧아야 한다. 어떤 에뮬레이션 플랫폼에서는 최대 64개의 통합 모델링 채널을 통해 넓은 대역폭을 보장한다. 그러나 백업과 재생 방식에는 한계가 있다는 것을 유의해야 한다. 이는 테스트벤치의 가속에만 사용할 수 있고, ICE 타깃이 존재할 경우에는 사용할 수 없기 때문이다.

디버깅 테스트 케이스

400kHz 속도로 에뮬레이트 되는 50M 게이트 디자인을 실시간으로 16ms 동안 디버깅한다고 가정하자. 테스트벤치는 1M 패킷들을 생성하며 백업 데이터베이스의 크기는 119MB이다.
이는 다음의 단계들을 밟게 된다.

① 백업 기능을 활성화 한 상태에서 실제 시간 20분의 백업 간격으로 에뮬레이션을 실행한다.
• 테스트벤치는 각 간격의 말미에서 DUT에 체크포인트를 설정한다.
• 백업 데이터베이스에는 간격당 20MB의 추가 공간이 필요하다.
• 간격당 20초의 추가 시간이 필요하다.

② 세 번째 간격(실제 시간으로 약 40분)부터 재생한다.
• 테스트벤치는 체크포인트가 설정된 DUT를 자동적으로 복구한다.
• 복구하는 데는 대략 20초가 걸린다.
• 파형을 업로드하고 디버깅한다.
보다 상세한 내용은 [표 1]과 [그림 4]에서 확인할 수 있다.

[표 1] 이 표는 전통적인 런타임/디버깅과 백업/복구 방법론을 비교했으며, 이를 통해 런타임 효율성의 향상을 수치적으로 확인할 수 있다.

[그림 4] 전통적인 런타임/디버깅과 새로운 백업/복구 방법론을 비교했다. 이를 통해 런타임 효율성의 향상을 그래픽으로 확인할 수 있다.

결론

주기적인 체크포인트 기반의 저장과 복구는 게이트 레벨, HDL 시뮬레이션에서 오랫동안 실행돼 왔다. 이 방법이 지금까지 에뮬레이션에 채택되지 않았던 이유는 물리적 디바이스의 비결정론적인 성격으로 인해 ICE 모드에 사용할 수 없었기 때문이다. 또 HVL 테스트벤치의 합성 불가능한 특성으로 인해 테스트벤치 가속 모드에도 사용할 수 없었다. 그러나 이제는 분할정복 접근방법을 통해 저장과 복구 방법을 테스트벤치 가속에서의 에뮬레이션으로 확장할 수 있게 됐고, 이런 방법론을 수많은 사용자들이 성공적으로 이용하고 있다.

결과적으로 백업/재생은 필요한 저장 공간을 줄이고 프로세스 속도를 올림으로써 디버깅의 효율성을 높여준다. 또한 첨단 디버깅 기능을 이용함으로써 디버깅 효과를 향상시키고 에뮬레이션 자원의 활용을 최적화한다.

글: 라우로 리자티(Lauro Rizzatti) 하드웨어 에뮬레이션 분야 박사,
비제이 쵸비사(Vijay Chobisa) 멘토 지멘스 비즈니스 에뮬레이션 사업부의 제품 마케팅 매니저
자료제공: 멘토 지멘스 비즈니스

회원가입 후 이용바랍니다.