SoPC를 위한 최상의 ASIC 설계 흐름을 찾아라
기재: 2001년 04월 29일

By Robert Kaye
Market Development Manager

John Wilson
Business Development Manager

Mentor Graphics Corp.

SoPC(System-on-programmable-chip) 기술은 보드 설계와 ASIC기반의 '시스템 온 칩' 설계 특성을 모두 갖고 있다. 즉각적으로 눈길을 끄는 SoPC의 장점은 마치 만능기판(breadboard)처럼 재빨리 디자인을 구현하여 동작시킬 수 있게 해준다는 것이다. 디버거와 연결할 수 있고, 수분 내로 디자인 코드를 실행시킬 수 있다. 게다가 설계 오류가 발생할 때 SoPC를 재프로그래밍 하는 것도 가능하다. 이 모든 것들은 SoPC를 마치 빵판 기술의 절정인 것처럼 느껴지게 만든다.

그렇지만 ASIC 설계 공정의 속성들이 많이 남아 있으므로 어떤 설계 기법과 툴이 SoPC용으로 적합한지 알아보는 것도 의미가 있을 것이다. SoPC가 제공하는 신속한 신제품 출시 능력은 기존의 SoC ASIC의 설계 흐름을 대체해버릴 것인가 아니면 디자이너에게 최대의 가치를 제공하기 위하여 통합되는 보조 기술이 될 것인가?

새로운 세대의 프로그래머블 로직 디바이스들은 SoPC가 SoC ASIC 설계에서와 같은 레벨의 복잡성을 갖게 만든다. 여기에 프로세서 코어를 도입하게 되면 설계 공정은 더욱 복잡해지며, 설계 공정의 일부로서 소프트웨어/하드웨어의 디자인 및 소프트웨어/하드웨어 인터페이스를 고려해야 할 필요가 생긴다. 이러한 복잡성을 다루기 위한 방법들이 SoC의 경합 과정에서 발전되어 왔으며, 현재는 SoPC 디자이너들에게 중요한 일이 되었다.

넓은 의미에서 SoC 디자인은 계속해서 치밀하게 다듬어 가는 공정이라고 할 수 있다. SoC 디자인은 동작 HDL이나 시스템의 기능들을 기술하는 C 모델들의 집합에서부터 시작된다. 디자이너는 이 단계에서 전체 RTL을 기술하기 전에 고성능 시뮬레이션 모델들과 디자인의 특성을 먼저 조사한다.

각 블록이나 기능이 완성됨에 따라 디자인은 각 행동 모델에 해당하는 RTL로 대체되는 공정을 거치면서 진전된다. 완성된 디자인이 합성 가능한 RTL 네트리스트에 기재되었을 때에야 비로소 SoPC 로의 매핑 공정이 시작될 수 있다.

SoPC 류의 프로그래머블 로직을 대상으로 한 것처럼 복잡한 디자인에서 100 퍼센트 RTL에 도달하는 것은 몇 달이나 걸리는 장기적인 공정이 될 수도 있다. 내장형 시스템에서는 코드 개발과 디버그 작업이 전체 설계 작업의 75 퍼센트 내지 80 퍼센트를 차지한다. 코드를 실행시키고 검증하기 전에 하드웨어 디자인이 완성될 때까지 기다리면 하드웨어와 소프트웨어 디버그 작업을 순차적으로 할 수 있다. 이러한 순차적 작업은 SoPC의 주요 이점 하나를 유명무실하게 만든다. 만드는 시간보다 더 많은 시간을 시제품 검증에 소비한다면, 시제품을 빨리 만들어도 소용이 없는 것이다.

HDL 시뮬레이터와 하드웨어/소프트웨어 공동 검증 툴을 사용하면 세부적인 디자인을 개발하고 있는 동안에도 코드를 실행시키고, 디버깅하며, 하드웨어와 제대로 상호작용하고 있는지 확인할 수 있다. 공동 검증 작업을 하는 SoC 디자이너들은 소프트웨어와 하드웨어 개발을 한꺼번에 진행함으로써 설계 일정을 앞당길 수 있었다고 매달 반복적으로 보고하고 있다. 그리고 시제품이 이용 가능해 진 후 소프트웨어와 하드웨어를 통합하는데 걸리는 시간이 줄어들고, 제조에 들어간 후 오류를 찾아내게 되는 위험이 없어졌다고 한다.

날카로운 지적은 아니지만 의미 있는 사실은 소프트웨어와 하드웨어 개발을 한꺼번에 진행시키는 것이 최종 설계 품질을 향상시킨다는 것이다. 소프트웨어와 하드웨어 팀은 제품을 개발하는 동안 단일한 참조용 설계 모델을 사용하여 공동으로 작업한다. 검증 툴을 사용하면 디자인의 문제점을 알아낼 수 있다. 이러한 문제점들은 실제의 버그나 인터페이스 문제일 수 있지만, 종종 비효율적인 설계에 기인한 것이어서 디자인이 동작은 하지만 최선의 기능을 발휘할 수 없게 만들 수 있다. 이 단계에서는 하드웨어와 소프트웨어가 모두 유동적이고 둘 중 한가지 또는 모두를 쉽게 변경할 수 있으며, 검증을 위해 신속하게 시뮬레이션 할 수 있다. 하드웨어와 소프트웨어를 다듬을 수 있다는 것은 고품질의 설계를 가능케 하는 것이다.

검증 작업은 일찌감치 자주 이루어져야 하며, SoPC 플랫폼을 목표로 한 네트리스트와 더불어 연속적인 다듬기 과정의 끝인 설계의 한 주기를 통해 계속 이루어져야 한다. 유사한 "불완전한 RTL" 논쟁은 디자인에 상업적 IP가 포함되어 있다면 적절한 것이 될 수 있다. 합성 가능한 IP 모델의 완전 접속은 상업적 사용 면허 관련 협정이 타결되기 이전에는 가능하지 않다. 설계 탐색 단계에서 설계 내에 원하는 IP를 작동할 수 있도록 하는 내용이 비준되기 전까지는 이 협정에 서명하지 않는 것이 좋다.

IP 회사는 보안대책으로 HDL 시뮬레이터에서만 사용하기 위하여 이미 컴파일된 소스 없는 모델을 제공할 예정이다. 이것은 디자이너로 하여금 전형적인 소프트웨어 디자인과 검증 툴을 사용하여 하드웨어/소프트웨어의 초기 공동 검증 작업을 시뮬레이션하고 완성시키도록 압박한다.

SoPC의 빠른 시제품 제작에 또 하나의 제약 사항은 시제품을 빨리 만들어 내는 능력에 있다. 하나의 디바이스에 완성된 디자인이 다 들어갈 수 있다면, 이는 매우 그럴싸한 접근방법이 될 수 있을 것이다. 그렇지만 많은 디자인은 추가적인 보조 회로(주로 아날로그/RF)를 필요로 하며, 기능의 완성과 디바이스의 테스트를 쉽게 해주는 적절한 연결을 허용해 준다.

이러한 경우 시제품을 신속하게 제작하는 것이 얼마나 유용한가 하는 것은 SoPC 자체를 제외한 디자인의 나머지 부분을 제조하는 데 걸리는 시간과 디자인에 적용되는 적절한 테스트 패턴 수행의 용이함과 같은 요소에 달려 있다. 이는 SoC와 SoPC 사이의 구분을 없애고 프로그래머블 디자인으로 SoC 스타일 설계를 바꿀 필요성을 더욱 부각시킨다.

현대의 32비트 프로세서는 매우 복잡한 버스 프로토콜, 인터럽트 처리와 다른 소프트웨어/하드웨어 인터페이스를 제공한다. 현대의 32 비트 프로세서는 최종 사용자에게 몇 가지 흥미 있는 해결 과제들을 제기한다. 그 중 하나는 프로토콜에 맞는 주변장치의 개발과 검증이다. 효과적인 로우 레벨 코드는 하드웨어/소프트웨어의 상호작용에 달려 있다. 따로 개발된 코드는 종종 시제품에서 작동은 되지만 최적화되지 않는 경우가 있다.

어떻게 하드웨어와 소프트웨어 동작 모두를 동작의 미세 조절이 가능하고, 완전한 디버그 시설을 갖춘 유동적인 단일 환경에서 한눈에 알아볼 수 있게 만들 수 있을 것인가? 한가지 방안은 공동 검증이며, 이것은 어디에서 "검증"이 끝나고 "설계"가 시작되는지 그 경계를 불분명하게 한다.

예를 들어 Mentor Graphics社는 최근 소프트웨어 예외 처리기가 각각의 예외마다 한 번 이상 들어가는 상황을 경험했다. 독립적으로 테스트 한 하드웨어와 소프트웨어는 모두 정상적으로 예외 처리장치가 종료되고 반환되었다. 테스트에서 하드웨어는 제대로 작동했다. 그렇지만, 필요로 하는 것보다 더 많은 주기를 소모하는 다중 진입 및 예외는 다중 예외가 일어날 경우, 문제를 야기시킬 수가 있다. 하드웨어(로직 시뮬레이터)와 소프트웨어(디버거)를 보면서 이러한 글리치의 원인을 파악하고 이를 수정할 수 있다.

조정 과정의 장애물
공동 검증 툴은 독립형 시뮬레이션 기법과 물리적 시스템 코드를 운영하여 하드웨어와 소프트웨어의 상호작용을 검증하고 분석하는데 상당한 이점이 있다.

이러한 기법들의 최대 값어치는 상호작용이 가장 복잡하게 일어나는 로우 레벨 코드에 있다. 그러나 하드웨어가 중요할 경우에는 하이 레벨 애플리케이션의 동작을 관찰하는 데에까지 제 값어치를 한다.

이 공동 검증 툴의 가치 평가는 제조에 들어가기 전에 하드웨어/소프트웨어 인터페이스를 검증하는 데 주로 초점이 맞춰져 왔다. 그래서 제조에 들어간 후 실험실에서 시제품의 디버깅 작업동안 이 툴들이 얼마나 중요하게 사용되는지를 발견하면 놀랄 사람들도 있을 것이다.

이 설계 단계에서는 시뮬레이션을 하는 동안 발견되지 않았던 이상하거나 비정상적인 특이한 동작이 나타날 수도 있다. 복잡한 프로세서들을 SoC나 '시스템 온 프로그래머블 칩(SoPC)'에 내장시킬 때 생길 수 있는 문제는 특히 소프트웨어 경로가 뒤따라오게 하는 내장형 추적 장치가 제한되어 있을 경우에 이상 동작을 일으키는 내부 회로 조건 (종종 프로세서 주변)을 관찰하기가 어려워진다는 것이다.

실제로 디버그의 수를 눈으로 확인시켜주는 기능은 시제품 구동 운영체제 안에 구성된 모니터링 장치와 하드웨어 디자인 안에 구성된 관측 가능한 로직의 수에 달려있다. 특히 다중 스레드, 실시간 운영체제에서 하드웨어와 소프트웨어 실행 사이의 제어와 조정을 마감하는 것은 매우 어려운 일이 될 수도 있다.

하드웨어/소프트웨어 공동 검증 툴에서 실험실에서의 입력 조건을 맞추고, 코드의 실행을 추적할 수 있기 때문에 디자이너는 문제를 다시 만들어 내고 시제품에서는 가능하지 않았던 방법으로 관측된 동작의 원인을 쉽게 추적할 수 있다.

종종 문제의 근본적 원인을 명확하게 진단하기 이전에 많은 다른 경우들을 조사해보아야 한다. 디자이너는 논리 분석기를 사용하여 시제품 디자인에서 시제품 파형의 트레이스를 추출할 수 있다. 이것은 하드웨어/소프트웨어 공동 검증 툴에 연결된 HDL시뮬레이터에 적절한 포맷으로 트레이스를 조작하는 것을 가능하게 해준다.

복잡한 32 비트 SoPC 디바이스가 빠른 주문형 시제품과 소량의 애플리케이션을 만들기 원하는 SoPC 디자이너들에게 중요하고도 새로운 기회를 제공한다는 것은 의심의 여지가 없다. 모든 디자인의 설계 공정에서 가능한 한 빨리 잠재적인 설계 오류가 제거될 때 이것들이 가장 빠르고 신뢰할 수 있게 사용될 것이다.

디자이너에게 있어 하드웨어/소프트웨어 공동 검증 작업과 다른 ASIC 검증 기법들은 중요한 무기가 될 것이고, 이로 인해 SoPC의 이점을 최대한 활용할 수 있게 될 것이다. EDA 판매업체와 SoPC 공급업체간의 협력은 생산성을 증대시키고, SoPC의 사용을 쉽게 해줄 것이다.

본 기사는 http://www.eetkorea.com/article_content.php3?article_id=8800085240 에 있는 전자 엔지니어 기사에서 인쇄한 것입니다.

본 웹사이트에서 임의의 제품이나 서비스, 또는 간행물에 대해 설명하거나 언급(하이퍼링크를 통한 설명이나 언급을 포함하여)한다고 해서 eMedia Asia Ltd. 사가 그 제품이나 서비스, 또는 간행물을 추천한다는 뜻은 아닙니다. eMedia Asia Ltd. 사는 구체적인 서면 증명을 통한 경우 외에는 본 웹사이트를 통해 제안되는 제품 및 소프트웨어를 보증하지 않으며, 보증하는 경우라 해도 공급자가 그같은 제품이나 소프트웨어와 관련하여 제공하는 서면 인가서나 보증서를 통해서만 보증합니다.