하드웨어와 소프트웨어 간의 까다로운 상호작용 문제는 설계 단계의 훨씬 초기에 하드웨어의 추상 모델에 대해, 그리고 나중에는 클럭 주기가 정확한 하드웨어의 RTL 모델에 대해 이미 해결되어 있게 된다.
이는 일단 물리적 프로토타입이 제공되었을 때 소프트웨어 개발에 필요한 시간을 극적으로 단축시켜줄 수 있다.
글/러셀 클라인(Russell Klein), 멘토 그래픽스
이제 SoC를 인도한다는 것은 단순히 실리콘을 배치하는 일이 아니다. 오늘날의 디바이스들은 소프트웨어 스택, 미들웨어, 부트 코드 및 드라이버를 포함하여 상당량의 소프트웨어와 함께 인도된다. 실리콘이 인도될때까지 기다렸다가 보드에 탑재하여 소프트웨어 개발을 시작할 수도 있지만, 경쟁사가 그 때까지 기다려 줄리만무하므로 이는 문제가 될 수 있다. 일정에 대한 압박이 증가하는 추세이므로, 실리콘이 완성되기 전에 소프트웨어 개발에 착수한다면 상당한 경쟁상의 이점을 누릴 수 있다. 그러나 이를 위해서는 에뮬레이션을 이용한 소프트웨어 개발을 가능케 해줄 일련의 툴들이 필요하다. 여기에는 실리콘이나 개발 보드가 제공되기 훨씬 전에 소프트웨어를 실행할 수 있을 정도로 빠르게 동작하는 RTL 디자인을 가능케 해주는 에뮬레이션 시스템과 에뮬레이터를 워크스테이션 기반의 소프트웨어 디버깅 툴에 연결시켜주는 고속의 트랜잭션 기반 통합 모델링 채널 그리고 소프트웨어 개발자들이 요구하는 기능들을 자랑하는 소프트웨어 디버깅 환경이 포함된다.
해당 코드를 실행할 수 있는 환경
아직 존재하지 않는 어떤 것을 위한 소프트웨어를 개발할 때 제일 먼저 필요한 것은 해당 코드를 실행할 수 있는 환경이다. 기본적으로 주어지는 옵션은 두 가지로서, 물리적으로 진행하거나 가상으로 진행하는 것이다. 대부분의 프로젝트는 기존의 디자인을 기반으로 한다. 다시 말해서, 가장 최근 버전의 디자인에 특징들을 추가하여 보다 크고 빠르며 우수하게 만드는 것이다. 이 같은 경우라면 아마도가장 최근의 프로젝트에서 만든 보드가 귀하의 책상 위에 놓여 있을 것이며, 이 보드용의 소프트웨어를 작성하기 위한 소프트웨어 환경과 이와 함께 사용할 디버깅 환경도 갖춰져 있을 것이다. 가장 손쉬운 길은 이 보드를 계속 사용하는 것이다. 뭔가 완전히 새로운 것을 개발 중이라면 개발보드를 입수할 수 있다. 아마도 현재 제작 중인 것에 가까운 뭔가를 발견할 수 있을 것이다. 이에 대한 대안은 QEMU와 같은 가상 보드 상에서 실행하는 것이다. QEMU는 다양한 ARM 보드들을 손쉽게 모델링 해주는 오픈소스 시스템 에뮬레이터이다. ARM도 Foundation Model (ARM의 웹사이트에서 무상 제공된다)이라고 하는 가상 플랫폼을 가지고 있는데, 이것은 QEMU와 비슷하며 ARM코드를 실행한다. 둘 다 디버거 도입 기능을 갖추고 있다.
일단 코드를 실행 및 디버깅할 수 있는 바탕이 마련되고 나면 프로그래밍에 착수할 수 있다. 어떤 시점에 이르면 아직 제공되고 있지 않은 모종의 새로운 주변장치를 액세스해야 할 필요가 생긴다. 모델을 생성하는 것도 이러한 문제를 다루기 위한 방법 중 하나이다. 그야말로 간단한 예제, 즉 새로운 주변 장치의 ID 레지스터를 읽는 일로 시작해 보자. 많은 주변 장치들이 ID 레지스터를 갖고 있는데 이것은 판독 전용 레지스터로서, 이를 판독할 경우 이미 알려져 있는 정해진 값을 돌려준다. 이는 드라이버가 올바른 장치와 얘기하고 있음을 어느 정도 확신할 수 있게 해준다. 드라이버 초기화의 아주 초기에 이 레지스터를 판독하여 기대값과 비교하는 것이 합리적이다.
ARM pl011 시리얼 드라이버에서 그 같은 예를 살펴보면 그림 2와 같다.
드라이버 코드는 매크로 명령 readl과 writel을 이용하여 레지스터를 판독 및 기록한다. 이들은 리눅스 커널에서 하드웨어 액세스 방법으로서 정의된다. 그러나 새로운 드라이버를 시작한다면 이를 로컬로 재정의함으로써 필요한 응답을 얻을 수 있다. 그림 3은 그러한 예 중 하나이다. 실제 하드웨어를 액세스하는 것은 아니지만 개발작업을 진행할 수 있는 것이다. 물론 극단적인 경우에는 이 접근 방법을 이용해 주변 장치 전체를 모델화할 수 있다. 그러나 가장 단순한 주변 장치라면 몰라도 이런 방법은 곧 실패로 끝날 수 밖에 없다. 일단 기본적인 핸드쉐이킹과 간단한 작동이 이루어지고 나면 아마도 수확체감점 (point of diminishing returns)에 이르게 될 것이다.
QEMU나 AFM
QEMU나 AFM(ARM Fast Model: Foundation Model의 유료 버전)과 같은 가상 환경에 있다면 보다 정교한 모델들을 도입할 수 있다. AFM은 System-C에 대한 연결 기능을 갖추고 있는데, 이것은 하드웨어 동작을 모델화 하는 데 있어서 스텁 코드(stub code)로 얻을 수 있는 것보다 적합한 환경이다. QEMU도 모델을 이용해 확장할 수 있지만 이는 경험이 적거나 급한 과제 담당자들에게는 권하고 싶지 않은 경험이다. 많은 오픈소스 프로젝트들이 그렇듯이, 코드는 그 자체가 문서이다. 귀하가 QEMU를 사용하고 있으며 일이 어떻게 돌아가고 있는지 알아내기 위해 장황한 C 코드를 붙잡고 고군분투할 생각이 없다면, 그리고 스텁 코드 단계를 벗어나고자 한다면 이 단계를 건너뛰고 싶을 것이다.
스텁 코드나 심지어는 귀하의 소프트웨어를 실행하기 위해 작성하는 보다 정교한 System-C 모델을 이용해서도 검증할 수 없는 것들이 많다. 예를 들어, 하드웨어 팀과 소프트웨어 팀이 디바이스에 동일한 레지스터 맵을 사용하고 있는지는 알 수가 없다. 레지스터에서 비트 하나를 설정한 것이 예상치 않은 방식으로 반응하지 않을 것임도 입증할 수 없다. 주변 장치의 드라이버와 상응하는 모델을 둘 다 작성한다면 해당 디바이스에 대한 자신의 이해 정도를 입증할 수 있을 뿐이다.
멘토 그래픽스의 VistaTM와 같은 가상 프로토타이핑시스템을 이용함으로써 실행하고자 하는 새로운 하드웨어의 보다 정교한 모델들을 생성할 수 있다. 이들은 일반적으로 소프트웨어가 수월하게 실행될 수 있을 정도로 빠르다. 가상 프로토타입을 위한 모델들이 하드웨어 팀에 의해 작성되었다면 그 위에서 소프트웨어를 실행함으로써 해당 디자인에 대한 소프트웨어 팀의 시각이 하드웨어팀의 시각과 일치함을 검증할 수 있다. 대개는 양쪽의 시각 사이에 어느 정도의 차이가 있게 마련이다. 이러한 차이점을 초기에 발견하면 설계 주기 후반에 겪을 수 있는 수많은 고통과 괴로움을 피할 수 있다. 하드웨어와 소프트웨어를 둘 다 손쉽게 디버깅할 수 있는 툴에서 이러한 차이점을 찾아낸다면 일이 거의 쉬워지다시피 할 것이다.
가상 프로토타입
가상 프로토타입은 하드웨어 개발의 목적인 주변 장치의 완전한 기능 모델을 갖게 된다. 소프트웨어도 최종목표 시스템을 위해서 동일한 방식으로 구축할 수 있게 된다. 주변 장치의 레지스터들을 마치 실제 하드웨어 상에서 실행하고 있는 것처럼 액세스할 수 있다. 금상첨화로, 가상 프로토타입은 이러한 주변 장치 레지스터들을 비침입적으로 직접 들여다볼 수 있도록 해주므로 디버깅이 보다 쉬워진다. 드라이버를 완전히 작성한 뒤 이것이 기능적으로 올바른지 확인할 수 있게 되는 것이다. 심지어는 총 타이밍 문제까지도 해결할 수 있다. 그러나 세부적인 타이밍 검증을 위해서는 하드웨어에 보다 긴밀하게 일치되는 뭔가를 기다려야만 할 것이다.
가상 프로토타입은 실제 하드웨어가 아니라 모델에 불과할 뿐임을 잊지 말자. 즉, 인간이 작성한 모델(프로그램의 형태를 갖는)인 것이다. 유감스럽게도 인간이 작성한 프로그램들은 가끔씩 버그를 갖고 있다. 또 하나 염두에 둬야 할 사항은 하드웨어가 매우 추상적인 레벨에서 모델화되고 있기 때문에 실제 하드웨어와는 미묘하면서도 커다란 차이점들을 가져올 수 있다는 점이다. 따라서 드라이버를 자신의 가상 프로토타입에 대해 완전히 점검했다 해도 일이 끝난 것은 아니다. 아직도 보다 세부적인 하드웨어 기술 내용에 대해 인증을 거쳐야 한다.
하드웨어 팀은 정상적인 개발 주기의 일환으로서 이미 해당 하드웨어의 실행 가능한 모델을 작성하고 있다. 이들은 해당 디자인을 RTL(register transfer level)에서 하드웨어 기술 언어(HDL)로 기술하고 있다. 궁극적으로, 해당 디자인에 대한 이 HDL 기술 내용은 일련의 컴파일러와 분석기를 거쳐 실리콘 제조용의 마스크 세트를 생성하게 된다. 이 HDL은 시뮬레이터에서 실행할 수 있으며, 생산될 하드웨어의 거동을 클럭 주기 정확도로 제공하게 된다. 유일한 문제는 HDL로 묘사되는 실제 디자인의 시뮬레이션 대부분이 두 자리 수나 세 자리 수의 헤르쯔 단위로만 실행된다는 것이다. 메가헤르쯔도 아니고 심지어는 킬로헤르쯔도 아닌 그냥 헤르쯔인 것이다. 이는 너무 느리기 때문에 소프트웨어 팀에게는 별로 도움이 되질 못한다. 이 HDL을 FPGA나 혹은 멘토 그래픽스의 Veloceⓡ와 같은 에뮬레이션 시스템을 프로그램하는 데도 사용할 수 있다. FPGA와 에뮬레이션 시스템은 HDL시뮬레이션과 동일한 거동을 구현하지만 이들은 메가헤르쯔 범위의 속도로 실행된다. 이는 소프트웨어 팀에서 보기에는 느리겠지만 그래도 쓸만하다.
RTL에 대한 인증
?
일단 스텁 코드와 가상 프로토타입(사용 가능했다면)의 유용성이 바닥을 드러내고 나면 그 다음 단계는 자신의 코드를 하드웨어의 보다 정확한 모델, 구체적으로는 RTL에 대해 인증하는 것이다. 이를 시작하기 위한 최선의 방법은 가상 머신(QEMU나 AFM)을 하드웨어의 RTL모델과 결합시켜 시뮬레이션이나 에뮬레이션으로 실행시키는 것이다. 멘토 그래픽스는 이를 가능하게 해주는 Application Review Warpcore라는 제품을 갖고 있다. 이 제품은 가상 머신을 RTL 실행 환경과 결합시켜 준다. 이것은 RTL이 액세스되고 있을 때만 RTL 시뮬레이터나 에뮬레이터를 진행시킨다. 가상 머신을 시뮬레이션과 결합하여 수백 헤르쯔의 단위로 실행시킨다는 것은 비현실적으로 들릴 수도 있겠지만, 하드웨어를 많이 움직이지만 않는다면 가능한 일이다.
하드웨어가 메가헤르쯔 단위 정도로만 실행된다면 꽤 잘 동작하는 것이다. 시뮬레이터는 대개 설정하고 액세스하며 디버깅 하기가 보다 쉽다. 하드웨어 쪽에서 메가헤르쯔 단위 이상으로 동작시켜야 할 필요가 생기면 에뮬레이션 시스템으로 옮겨가야 괜찮은 성능을 달성할 수 있다. 가상 머신과 에뮬레이션을 결합시켜 실행하면(어떤 벤더들은 이를 하이브리드 에뮬레이션이라고 부른다) 소프트웨어를 클럭 주기가 정확한 하드웨어 모델에 대해 신속하고도 손쉽게 실행시킬 수 있다.
이러한 구성의 전형적인 성능은 100MHz 정도이다. 이것은 실시간은 아니지만 소프트웨어 스택 전체를 실행 및 디버깅하기에는 충분한 속도이다.
통합 모델 호스트
일부 간단한 테스트를 주변 장치에 대해서만 실행할 수 있다. 그러나 드라이버를 완전히 인증하기 위해서는 주변 장치가 루프백(loop-back) 이상의 어떤 것을 해주기를 바랄 것이다. 이는 주변 장치를 에뮬레이터 상의 일부 I/O 케이블을 통해서 외부 세계에 연결시키거나 혹은 에뮬레이터가 연결되어 있는 컴퓨터 상의 모델이나 호스트 인터페이스에 가상으로 연결시켜야 함을 뜻한다. 멘토그래픽스의 에뮬레이션 시스템에서는 이를 통합 모델 호스트라고 부른다. 에뮬레이션 통합 모델 호스트와 에뮬레이터 간에 신속하고도 효율적인 링크를 갖추는 것은 높은 성능 수준을 유지하는 데 있어서 필수적이다.
이 구성에서는 전체 디자인이 RTL로 되어 있지 않다는 점에 유의하자. 이는 시스템이 올바르게 기능하겠지만 최종 제품과 동일한 성능 특성을 보여주지는 않을 것임을 뜻한다. 성능 중에 이 구성에서 관찰할 수 있는 측면이 몇 가지 있는데, 특정 부품들 간에 오가는 트래픽 양 같은 것이 그런 것이다. 그러나 상세한 성능 분석을 위해서는 시스템을 보다 정확하게 표현할 수 있어야 한다.
전체 디자인이 RTL로 표현될 경우에는 전체 시스템에 대해 클럭 주기가 정확한 모델을 얻게 된다. 이를 이용해 세부적인 타이밍 분석을 수행하고 처리 속도, 대기 시간 및 응답 시간에 대해 확실한 결론을 내릴 수 있다. 시스템을 효과적으로 실행하기 위해서는 이를 에뮬레이션 시스템이나 FPGA 프로토타입 상에 놓아야 한다. 사실적인 소프트웨어 부하를 포함한 전체 시스템은 사실상 소프트웨어 기반의 시뮬레이션을 이용해서 모델화 할 수 없다. 에뮬레이션 모드에서조차도 한 자리 수 메가헤르쯔의 단위로 실행된다는 점을 기억하자. 이는 소프트웨어 기반의 시뮬레이션보다는 훨씬 빠르지만 실시간보다는 훨씬 느린 속도이다.
디자인을 에뮬레이션 모드에서 실행하면서 임베디드 프로세서에서 실행되는 소프트웨어를 디버깅할 수 있어야 한다. 전통적으로 이는 JTAG와 같이 시스템에서 제공하는 하드웨어 인터페이스를 이용해 이들을 연결시켜 검토 하드웨어를 디버깅함으로써 이루어져왔다. 그러나 여기에는 문제가 있다. JTAG은 기능 문제를 디버깅하기에는 훌륭하지만 성능과 타이밍 문제의 디버깅에 사용하기는 매우 어렵다.‘ 하이브리드’가상 머신과 에뮬레이션을 이용해 얻게 되는 성능이 너무도 높기 때문에 모든 기능 문제들을 이를 통해 디버깅하고 싶을 것이다. 그렇다면 유일하게 남아 있는 문제는 타이밍 관련 버그와 성능 문제들뿐이다.
JTAG와 유사 디버깅 기법들은 프로세서를 디버깅 모드에 놓은 뒤 다양한 기법들을 이용해 프로세서와 주변메모리로부터 데이터를 검색한다. 최선의 경우에 조차도 이러한 동작에는 적어도 수십만 클럭, 대개는 수백만 클럭이 소요된다. 게다가 디버깅 클럭은 대개 프로세서 클럭의 몇분의 일의 속도로 실행된다. 디버깅할 무렵에 디버깅 툴이 프로세서의 동작에 수백만 클럭의 지연을 야기하게 되면 성능이나 타이밍 문제를 디버깅하기가 엄청나게 힘들어진다. 개발자들은 이러한 지연을 피하기 위해 프로세서 동작 추적 기능을 이용한 디버깅으로 되돌아가는 경우가 많다. 그러나 프로세서 동작 추적의 수집 조차도 관찰하려는 시스템의 동작에 영향을 미칠 수 있다.
Codelink
멘토 그래픽스는 Codelinkⓡ라는 제품을 갖고 있는데, 이것은 에뮬레이션 모드에서 실행되고 있는 디자인의 동작 추적를 수집한 뒤 이를 이용하여 전통적인 소프트웨어 디버거를 구동할 수 있도록 해준다. 본질적으로, 귀하는 코드를 단계적으로 밟아나가기, 중단점 설정, 메모리와 변수 살펴보기와 같은 전통적인 소프트웨어 디버거의 모든 기능들을 얻게 된다. 이는 침입적 부작용 없이 이루어지므로 시스템 에뮬레이션이 갖는 클럭 주기 정확성이라는 성격이 유지된다. 또한 완전한 동시병행적 멀티코어 가시성과 역실행 및 역스테핑 기능도 얻게 된다. 그러나 성능 문제는 소스 레벨에서 디버깅하기가 어렵기 때문에 디자인 내 프로세서들의 활동을 타임라인에서 하드웨어 활동과 나란히 살펴봐야 할 때가 많다. Codelink에 의해 수집되는 이 동작 추적은 멘토 그래픽스의 시스템 분석툴로 주입될 수 있으며, 해당 성능 데이터는 이 툴에 의해 하드웨어 데이터와 함께 나란히 표시될 수 있다. 이는 아마도 이 개발 단계에서 귀하가 진단하고자 하는 성능 및 타이밍 문제들을 시각화하기 위한 최상의 방법일 것이다.
FPGA 프로토타입은 대개 에뮬레이션보다 다소 빠르게 실행되므로 보다 긴 소프트웨어를 실행할 수 있다. 따라서 디자인에서 보다 많은 문제들을 찾아낼 가능성이 있다. 소프웨어 측면에서 디버깅은 대개 JTAG이나 다른 유사한 기법들에 의해 이루어지는데, 이는 위에서 설명된 문제점들을 가지고 있다. FPGA는 전통적으로 하드웨어에 대한 디버깅 가시성이 매우 제한적이라는 단점을 가지고 있었다. FPGA 벤더들이 제공하는 임베디드 로직 분석기는 동작 추적 폭이 제한되고 동작 추적 깊이가 얕을 뿐만아니라 해당 장비를 다시 수행해야 하는 경우가 빈번하기 때문에 오랫동안 (종종 밤새도록) 재컴파일(합성 및 P&R)해야 하는 결과를 초래한다. 이는 디자인을 FPGA로 디버깅하기가 고통스럽고 지루하게 만든다. 다행히도, 최근 출시되고 있는 신기술들은 수천 개의 신호들에 대한 가시성과 칩 및 시스템 레벨의 활동에 대한 깊이 있는 동작 추적 능력을 제공할 뿐만 아니라, 전례 없는 사용의 용이성과 강력한 런타임 구성 능력도 제공함으로써 대부분의 해당 장비의 재가동과‘밤샘’반복 작업에 대한 필요성을 없애 디버깅 생산성을 크게 향상시켜 주고 있다. 개선된 디버깅 능력은 FPGA 프로토타입을 사용하는 경험과 생산성에 긍정적인 영향을 미친다.
요약
간단한 스텁 코드로 시작해서 잇달아 점점 더 세부적이고 완전한 일련의 하드웨어 모델들로 진전해 나아감으로써 물리적인 실리콘을 손에 넣기 전에 소프트웨어를 인증할 수 있다. 최고의 성능을 제공하며 디버깅하기가 가장 쉬운 환경에 가능하면 오래 남아 있으면서 필요할 경우에는 보다 세부적인 모델들을 이용함으로써 달리 커버되지 않는 시스템 측면들을 인증하고 싶을 것이다. 구축하고 실행하며 디버깅하기 위한, 즉 하나의 환경에서 다른 환경으로 매끄럽게 핸드오프 하기 위한 공동의 환경이 필요할 것이다. 그리고 이는 최종 실리콘에까지 이어져야 한다. 최종 생산 디바이스에 대해 최종적인 시험을 수행해야 하기 때문이다. 이는 일단 물리적인 프로토타입을 손에 넣은 뒤에는 모든 것이 제대로 돌아가고 있는지 최종 점검만 하게 될 뿐임을 뜻한다. 하드웨어와 소프트웨어 간의 까다로운 상호작용 문제는 설계 단계의 훨씬 초기에 하드웨어의 추상 모델에 대해, 그리고 나중에는 클럭 주기가 정확한 하드웨어의 RTL 모델에 대해 이미 해결되어 있게 된다. 이는 일단 물리적 프로토타입이 제공되었을 때 소프트웨어 개발에 필요한 시간을 극적으로 단축시켜줄 수 있다.
<반도체네트워크>
※ 출처 : EngNews (산업포탈 여기에) - 프리 실리콘 단계의 소프트웨어 검증