FPGA 및 시스템 디자인의 출시, ASIC 입증된 분석 툴로 앞당긴다

  • 2020-01-07
  • 글 / 크리스 자일스(CHRIS GILES), CDC 및 RDC 툴 제품 마케팅 매니저 멘토, 지멘스 비즈니스




디지털 시스템에는 클럭이 필요하다. 오늘날의 디자인은 과거 어느 때보다도 클럭킹 방식으로부터 보다 많은 것이 요구되고 있으며, 이러한 추세는 앞으로도 계속될 것으로 보인다.

전력 제약사항이 증가함에 따라 디자인은 클럭을 비활성화하거나 보다 극단적일 경우 전원을 완전히 차단할 수 있는 기능 영역으로 세분화되고 있다. 시스템은 상황에 맞는 클럭 관리를 통해 스위칭 전력을 최소화 할 수 있어야 한다.

성능과 면적의 제약으로 인해 보수적인 설계 관행을 버리고 보다 공격적인 디자인을 선호하는 추세이다. 기능 영역이나 클럭 영역들 사이에서 버퍼 역할을 하는 메모리 주변의 레지스터 뱅크를 없애는 것이 그러한 예 중 하나이다. 이처럼 복잡성이 증가하는 가운데, 비용 및 타임투마켓의 압력으로 인해 업계나 애플리케이션을 막론하고 시스템이나 SoC 또는 FPGA 디자인을 출시하기 전에 더욱 엄격한 검증 작업이 요구되고 있다.

이러한 추세를 감안할 때, 연구소로 가거나 보다 중요한 시장에 출시되는 FPGA 및 시스템 제품에서는 클럭킹 문제가 과거 어느 때보다도 만연하고 있다. 윌슨 리서치 그룹(Wilson Research Group)의 2018년도 기능 검증 연구내용에 따르면, 클럭킹 결함은 FPGA 부문에서 생산 문제를 일으키고 있는 두 번째 주요 원인으로서 최근 6년간 20% 가까이 증가했으며, 그림 1에서 보듯이 FPGA 생산 문제의 주요 원인이 되는 것도 시간 문제라고 한다.



이 연구내용은 그림 2에서 보듯이 2018년에 FPGA 디자인의 84%가 중대한 버그를 가진 채로 생산에 들어갔으며, 이러한 비율은 2년 만에 6퍼센트나 증가했음을 보여주고 있다. 따라서 FPGA 분야에서 검증 방법론의 채택 수준과 성숙도를 개선해야 할 필요성이 절실한 상황이다.



하지만 FPGA 및 시스템 디자이너들에게 희소식이 있다. 이러한 클럭킹 문제를 해결해줄 툴이 ASIC 커뮤니티에 의해 이미 개발 및 입증되어 있으며, 이를 FPGA 및 시스템 설계 분야에도 쉽게 적용할 수 있다는 것이다.

클럭 도메인 크로싱 문제

클럭킹 문제는 FPGA 개발 커뮤니티의 중요 관심사이다. 하지만 클럭킹 문제가 클럭 자체의 무결성에 관한 것으로 오해되는 경우가 많다. 클럭킹 문제는 그보다는 CDC(clock domain crossing)로 알려져 있는, 두 비동기 클럭 도메인 간의 경계를 가로질러 발생하는 데이터 손상이나 신호 손실과 관련 있는 경우가 많다. 데이터나 제어 신호가 한 클럭 도메인으로부터 다른 클럭 도메인으로 건너갈 때, 이러한 신호들은 소싱 클럭 도메인과 관련된 타이밍 특성을 갖는다.

이러한 신호들은 궁극적으로 수신 도메인에서 플립플롭과 같은 클럭킹 된 요소에 의해 샘플링 된다. 데이터가 클럭 에지에 너무 가깝게 변경되는 플립플롭은 지속시간이 확률적인 과도기적이고 불확실한 상태가 되고 만다. 이를 준안정적(metastable) 상태라고 한다. 이러한 준안정 상태가 발생하더라도 제어 또는 데이터 신호가 정확히 전송되도록 보장하기 위한 수많은 클럭 경계 동기화 방식이 존재한다. 이러한 메커니즘이 없다면 부정확한 데이터나 제어 신호 값이 샘플링 되어 잘못된 동작이 발생하게 된다.

준안정성은 비동기식 클럭이 있는 시스템에서 발생한다. 준안전성이 디자인 자체의 기능적인 부분에 노출될 경우 발생하게 되는 문제는 테스트에서 디버깅하기 어려우며, 생산 단계나 현장으로 들어가게 되면 디버깅하기가 한층 더 어려워진다. 플립플롭 값의 불확정적이고 확률적인 특성은 환경 조건의 영향을 받는다. 특정한 환경 특성은 준안정성 자체의 조건을 악화시킬 수도 있다. 확률론적인 성격은 비결정론적 거동으로도 나타난다.

즉, 주어진 일련의 상황 및 조건이 동일한데도 때로는 고장이 발생하고 때로는 발생하지 않기도 하는 것이다. CDC를 경시한 채 설계할 경우, 설계 팀은 실험실에서 디버깅에 상당한 시간을 허비하게 될 수 있으며, 경우에 따라서는 현장에서 고객과 품질 문제로 시간을 허비하거나, 또는 까다로운 근본 원인 분석 작업이나 비용이 많이 드는 재작업을 수행해야 할 수도 있다.

클럭이 한두 개 있는 간단한 디자인의 경우에는 많은 클럭킹 문제를 디자인 출시 전에 잡아낼 수 있다. 규율에 따른 기본적인 린트(lint) 클럭 점검 방법과 제한된 동기화 방식, CDC에 대한 상세한 검토 및 최종 시스템 구현을 나타내는 시뮬레이션에서의 클럭 변화를 조합함으로써 문제를 발견할 수 있다. 이러한 분석은 다루기 쉽고 검토 가능하다. 클럭 도메인 순열의 수가 두 개에 불과하기 때문이다.



하지만 그림 3에서 볼 수 있듯이, 현재 FPGA 디자인의 대다수는 적어도 세 개의 클럭을 갖고 있다. 클럭이 세 개 이상인 디자인의 수는 2014년~2016년 기간에 소폭 감소하긴 했지만 최근 6년간 6%나 증가했다. 클럭이 두 개를 넘는 FPGA 디자인의 수는 2018년에 73%로 늘어났다.

검증이 필요한 CDC의 수는 도메인 수에 따라 선형적으로 증가하는 것이 아니라 도메인 크로싱의 순열에 따라 증가하므로, 클럭 도메인이 네 개인 디자인에서는 최악의 경우 12개의 상이한 순열을 점검해야 한다. 여기에다 클럭 관리, 전원 관리, 성능 및 지연 시간이라는 복잡성까지 추가로 고려하면 단순한 디자인에 적합했던 기법과 솔루션으로는 감당이 안 된다. 수작업에 의한 검토와 엄격한 방법론만으로는 충분치가 않은 것이다.

시뮬레이션의 한계

이 때문에 많은 팀들이 기능적 시뮬레이션으로 CDC를 검증한다. 이러한 시뮬레이션의 목표는 CDC 전반에 걸쳐 언제 데이터 손상이나 신호 손실이 발생하는 지 파악하는 것이다. 이것은 숭고한 목표이긴 하지만, 설계 팀이 문제를 놓치게 만들 수 있는 해결과제 몇 가지가 있다.

첫째는 디지털 시뮬레이션이 정의상 비 디지털적인 거동은 잘 다루지 못한다는 것이다. 따라서 플립플롭이나 기타 스토리지 요소의 준안정적인 거동은 전통적인 디지털 시뮬레이션에서 모델링 되지 않는다. 이 때문에 준안정적 거동에 대해서는 정확한 동기화를 확인하기가 어렵다.

설계 팀이 이 문제를 성공적으로 해결한다 해도, 그 다음에는 클럭의 제약사항들이 반도체 상의 실제 클럭의 시나리오를 정확하게 반영하도록 해야 한다. 그래야만 시뮬레이션이 클럭 도메인 크로싱을 제대로 생성해 테스트하는 데 필요한 시나리오를 찾아낼 수 있다. 이는 복잡한 디자인의 경우 철저하게 수행하기가 쉽지 않다.

그 다음 해결과제는 직관에 어긋나는 것처럼 보일지도 모르지만, 모든 클럭을 올바르게 제약하는 것만으로는 불충분하다는 것이다. 동기화 문제는 클럭이 타이밍 문제를 야기할 정도로 가까운 주기에 데이터나 제어 신호가 클럭 도메인 크로싱을 통과하는 경우에만 발생한다. 이러한 경우에는 기능 커버리지를 추가하여 시뮬레이션에서 발생하도록 할 수 있지만, 이는 알려진 크로싱만을 커버할 뿐 우연히 발생하는 크로싱은 검증하지 못한다.

최종적인 해결과제는 테스트 합격의 정의와 관련이 있다. 데이터 손상이나 신호 손실이 클럭 도메인 크로싱 전반에 발생하더라도 기능 테스트에는 사실상 합격할 수도 있다. 테스트를 문제의 경로에 대해 어떤 방식으로든 민감하게 만들어야 하며, 모든 테스트가 모든 경로에 집중하지 않도록 해야 한다.

요컨대 기능적 시뮬레이션에 의존하는 것은 운이 좋으면 매우 까다로운 작업이 예상되는 정도에 그치겠지만, 최악의 경우에는 오류가 발생하기 쉽고 설계 팀이 시스템에 존재하게 될 주요 CDC를 놓치게 만든다. 시뮬레이션만으로는 충분치 못함을 분명히 알 수 있는 것이다. 따라서 클럭 네트워크와 CDC에 대한 철저한 비시뮬레이션 기반의 검증이 필요하다.

ASIC 분야의 CDC 기법 차용

FPGA 및 시스템 디자이너들에게는 다행스럽게도, 다중 클럭 도메인 디자인 문제는 일반적으로 FPGA 및 시스템 디자인보다 ASIC 시스템온칩(SoC) 분야에서 먼저 직면한 문제이다. 이 때문에 ASIC SoC 업계는 혁신적이고 성숙한 CDC 검증 기법을 개발하였으며, 그 결과 강력하고도 폭 넓은 CDC 솔루션 군을 거의 지난 20년간 성공적으로 사용해 왔다. 이러한 기능들을 FPGA 및 시스템 설계 분야에도 손쉽게 적용할 수 있다.

ASIC CDC 검증 노력의 성공은 CDC의 사용이 일반적인 ASIC 커뮤니티와 그보다는 덜 일반적인 FPGA 커뮤니티 간의 결과 차이에서 확인할 수 있다. 그림 4에서 보듯이, 윌슨 리서치 그룹의 차이2018년도 서베이 결과에 따르면 클럭킹 문제가 ASIC의 기능적 결함을 일으키는 근본 원인인 경우는 26퍼센트에 불과한 반면, FPGA 디자인의 경우에는 43퍼센트에 달했다.



클럭킹 문제는 ASIC의 경우 세 번째로 큰 고장 원인으로서, 이러한 추세는 2016년 이래로 계속되어 왔다(그림 5). 이에 비해 FPGA의 경우에는 두 번째로 큰 고장 원인이다(그림 1 참조). 2018년의 조사에 따르면, ASIC이 FPGA보다 평균적으로 23퍼센트 더 많은 클럭 도메인을 갖고 있음에도 불구하고(2016년에는 95퍼센트 더 많았다!) 이러한 차이가 존재한다는 점에서 그 의미는 더욱 크다.
그림 3과 그림 6을 비교해보면 FPGA의 클럭 수 대비 고장률이 더 높다는 것을 분명하게 알 수 있다.



그렇다면 이처럼 성공적인 CDC 검증 기법이란 과연 어떤 모습일까? CDC 솔루션 분야는 정적인 형식 RTL 설계 분석 외에도 동적 시뮬레이션 기반의 솔루션을 포함하고 있는데, 이 솔루션에서는 정적 형식 CDC 툴의 지시 하에 준안정성 모델이 RTL 시뮬레이션에 추가된다. 이는 철저한 형식적 방법에 의해 식별되는 모든 CDC를 민감화 하여 무작위적인 지연을 발생시키며, 커버리지 보고서도 추가된다. 이러한 접근방식은 시뮬레이션에서의 CDC 검증과 관련하여 앞서 살펴본 보다 까다로운 문제들을 다룬다.



넷리스트 중심의 CDC 툴도 도입되고 있는데, 이것은 생산에 들어갈 준비가 된 최종 구현물의 넷리스트를 분석한다. 이러한 툴은 특히 넷리스트 중심의 성능에 맞게 조정되어 있으며, 이전에 RTL에서 실행된 CDC로부터 제약사항을 가져오고, 특히 합성이나 시험 삽입과 같은 구현 도구로 인해 도입되었을 수 있는 새로운 CDC 위배사항을 찾아낸다.

기본적인 정적 CDC 분석 툴의 기능도 시간이 지남에 따라 향상되어서, 코드 분석에 따른 자동 싱크로나이저 방식 추론은 물론, 규격 기반의 설계 의도 흐름, 그리고 형식 및 동적 시뮬레이션 수단을 통한 싱크로나이저 프로토콜 검증 기능도 추가되었다.

마지막으로, FPGA 및 시스템 설계 커뮤니티가 CDC 검증 툴을 채택해야 할 필요성이 증가하고 있음은 분명하지만, 이는 신중을 기하지 않으면 안 되는 일이다. 시판되는 CDC 제품들의 성능은 성숙도, 결과물의 품질 및 분석의 완전성 면에서 상당한 차이를 보인다.

일부는 형식 기반인 반면, 다른 것들은 넷리스트 구문 분석을 통해 문제를 파악한다. 어떤 제품은 다른 제품보다 정확하다. 어떤 것은 성숙하며 ASIC화 된 것도 있는 반면, 어떤 것은 시장에 선보인 지가 비교적 오래되지 않아 결과물의 품질 및 기능 면에서 아직 걸음마 단계에 있는 것도 있다. 따라서 설계 팀이 자신들의 니즈를 파악하여 로드맵과 요건에 따라 확장 가능한 적절한 솔루션을 찾아내는 것이 극히 중요하다.

요컨대, 수 년 전에 ASIC SoC 커뮤니티에서 CDC 툴을 개발하여 성숙시키고 강화하게 만들었던 문제들이 FPGA 및 시스템 디자인에서는 오늘날 초래되고 있는 것이다. 이는 FPGA 및 시스템 설계 커뮤니티에 있어서는 희소식이다. 이제 위험을 크게 줄이고 제품 출시 및 매출 달성을 앞당기는 데 필요한 툴들을 사용할 수 있게 되었기 때문이다.

저자 소개 
크리스 자일스는 멘토, 지멘스 비즈니스의 CDC 및 RDC 툴 제품 마케팅 매니저이다. 다수의 특허권을 보유하고 있으며, 지난 25년간 여러 산업 및 기술 분야에 걸쳐 IP와 SoC의 설계 및 검증 작업을 주도해왔다.

 

<저작권자(c)스마트앤컴퍼니. 무단전재-재배포금지>

본 기사의 전문은 PDF문서로 제공합니다. (로그인필요)
다운로드한 PDF문서를 웹사이트, 카페, 블로그등을 통해 재배포하는 것을 금합니다. (비상업적 용도 포함)
 PDF 원문보기


  • 100자평 쓰기
  • 로그인

태그 검색
본문 검색
TOP