프리실리콘 소프트웨어 개발 최적화

오늘날과 같이 빠르게 변화하는 기술 시대에 시장의 요구 사항을 처리하기 위한 가장 일반적인 접근 방식은 SoC(System-on-Chip)입니다. SoC는 기본적으로 기능 가속기와 이것이 지원하는 관련 주변 장치에 대한 많은 I/O로 둘러싸인 프로세서입니다. 2002년 모바일 데이터 혁명 이후 스마트폰을 정의하는 주요 기능을 용이하게 하기 위해 SoC를 사용하는 것이 전제 조건이 되었습니다. 같은 방식으로 SoC는 이후 TV, 자동차 및 계속 확장되는 사물 인터넷(IoT) 시장과 같은 "스마트" 소비자 제품을 만들기 위한 필수 장치가 되었습니다.

SoC에 대한 수요 증가는 경쟁이 치열한 시장을 창출했습니다. 이 때문에 SoC는 점점 더 복잡해지고 SoC의 주변 장치는 지속적으로 진화하며 시장 출시 시간은 단축되고 있습니다. SoC 개발의 복잡성을 충족시키는 중요한 구성 요소는 소프트웨어의 가용성입니다. 실수할 여지가 거의 없으며 소프트웨어는 가능한 한 빨리 준비되어야 합니다. 이 문제를 해결하려면 SoC 부품이 출시되기 전에 소프트웨어 개발을 시작해야 합니다.

SoC 소프트웨어 개발

전통적으로 소프트웨어 개발은 ​​제조 공정에서 첫 번째 실리콘 샘플이 도착한 후 시작되었습니다. SoC 샘플이 도착하면 소프트웨어 및 검증 팀이 개발 활동을 시작하고 대규모 SoC 도입 노력이 시작됩니다. SoC 작업을 하는 팀은 SoC 도입을 지원하기 위해 제한된 시간 동안 전 세계에서 수렴하여 한 지붕 아래에 있게 됩니다.

소프트웨어 개발은 ​​일반적으로 첫 번째 샘플이 도착한 후 프로덕션 준비가 되기까지 몇 달이 걸렸습니다. 한편, 실리콘 검증이 완료되어 관련 제품의 대량 생산을 시작할 수 있는 제한된 확신을 갖게 됩니다.

그러나 SoC 설계의 복잡성이 증가함에 따라 일반적으로 소프트웨어 개발에 몇 달이 걸리던 작업이 이제 소프트웨어를 생산할 준비가 되기까지 몇 년으로 늘어날 수 있습니다. 지원되는 주변 장치의 수가 증가하고 이러한 주변 장치가 발전함에 따라 해당 주제에 대한 전문성에도 격차가 생겼습니다. 소프트웨어 팀은 해당 영역(오디오, 비디오, USB, 이더넷 등)에 대한 전문 지식을 갖춘 새로운 개발자에게 리소스를 제공하여 이러한 특정 격차를 메워야 합니다.

프로젝트 초기에 생산 준비가 된 소프트웨어를 제공할 수 있도록 소프트웨어 개발은 ​​실리콘의 첫 번째 샘플을 사용할 수 있을 때까지 기다릴 수 없습니다. 소프트웨어 개발이 가능한 한 빨리 시작되고 더 나아가 SoC 하드웨어 설계가 시작되는 동시에 시작되는 좌회전 접근 방식을 취해야 합니다. 사전 실리콘 소프트웨어 개발은 ​​SoC 구현 버그를 식별하고 잠재적으로 금속 수정 또는 전체 마스크 테이프아웃 비용을 줄이는 데 도움이 될 수 있습니다. 이러한 요구 사항을 충족하기 위해 여러 방법론이 고려됩니다.

사전 실리콘 개발 접근 방식

SoC 테이프아웃 전에 소프트웨어 개발을 시작하기 위해 개발자는 소프트웨어 프로토타이핑, RTL 테스트벤치, FPGA 보드, 하드웨어 에뮬레이터 등과 같은 몇 가지 접근 방식을 사용할 수 있습니다. 이러한 접근 방식은 일반적으로 개별 모듈에 초점을 맞추기 때문에 이러한 접근 방식 각각은 목표 이후 고유한 과제가 있습니다. 개별 모듈이 아닌 전체 SOC를 육성하기 위한 소프트웨어를 개발하는 것입니다. 문제를 더 작은 모듈로 나누면 드라이버 개발을 시작하기 전에 가장 먼저 필요한 것은 개발 중인 각 프로세서, 가속기 또는 주변 장치에 대한 지식입니다.

시스템 C 모델

SoC의 각 IP에 대해 C 행동 모델을 구축할 수 있으며 이러한 행동 모델에서 독립 실행형 소프트웨어 드라이버를 테스트할 수 있습니다. 그러나 이 접근 방식에는 몇 가지 문제가 있습니다. 첫째, 막대한 소프트웨어 노력이 필요합니다. 즉, 모델 자체의 구현을 지원하기 위해 대규모 소프트웨어 팀이나 전담 모델 팀이 필요합니다. 따라서 모델의 개발은 비용 효율적이지 않을 것입니다. 둘째, 행동 모델의 정확성은 개발자의 해석에 달려 있습니다. IP 설계 소유자와 모델 개발자 사이의 통신 격차로 인해 부정확한 동작이 발생할 수 있습니다. 이로 인해 디자인의 잘못된 해석과 관련된 문제를 수정하는 데 많은 노력이 낭비됩니다.

RTL 테스트벤치

이 부정확성 문제를 해결하기 위해 취할 수 있는 또 다른 접근 방식은 Verilog 테스트 벤치를 사용하는 것입니다. 테스트벤치는 일반적으로 검증을 위해 SoC 설계 팀에서 개발 및 유지 관리합니다. Verilog 테스트벤치는 일부 IP 블록이 아니라 전체 SoC를 나타내는 SoC의 레지스터 전송 언어(RTL) 사양을 기반으로 합니다. 결과적으로 사이클마다 정확합니다. RTL이 발전함에 따라 테스트벤치는 그에 맞춰 움직입니다. 이렇게 하면 개발 중인 SoC를 가장 최신의 정확한 표현으로 유지할 수 있습니다. 소프트웨어 개발 목적으로 Verilog 테스트벤치를 사용하여 소프트웨어 드라이버를 개발할 수도 있습니다.

이 방법을 사용하여 개발된 소프트웨어는 정확하며 제조 프로세스 후에 SoC 샘플이 도착할 때 소프트웨어 불러오기 시간을 줄이는 데 도움이 될 수 있습니다. 그러나 이 접근 방식에는 문제가 있습니다. Verilog 테스트벤치는 주기가 정확하기 때문에 매우 느립니다. 이러한 환경에서 소프트웨어를 개발하는 것은 가능하지만 개발 및 디버그하는 데 매우 느릴 것입니다. 이 방법론으로 드라이버를 개발하는 데 몇 달이 걸릴 수 있습니다. Verilog 테스트벤치는 훨씬 더 일찍 시작하여 사용할 수 있습니다. 본질적으로 솔루션의 느린 속도를 설명하기 위해 사전 실리콘에 필요한 시간을 늘립니다(그러나 테스트벤치의 가용성에 따라 다름). 대안적인 접근 방식에서 다른 소프트웨어 팀은 이 방법론을 사용할 수 있습니다(사전 실리콘 개발에서만 작업). 본질적으로 필요한 리소스 수를 늘리므로 C 행동 모델 방법의 문제와 유사한 이 문제를 제거하지 못합니다.

실제로는 부정확하거나 긴 개발 주기를 수용할 수 없으며, 정상적인 설계 주기 일정을 유지하기 위해 리소스를 복제하거나 늘리는 데 필요한 추가 비용도 수용할 수 없습니다. 결과적으로 우리는 프리실리콘 소프트웨어 개발에 대한 또 다른 접근 방식을 고려해야 합니다. 이 접근 방식은 FPGA(Field-Programmable Gate Array)에서 각 SoC IP 블록의 에뮬레이션을 포함합니다.

FPGA 프로토타입

최신 FPGA는 상당히 빠르며 FPGA는 RTL로 구축되기 때문에 사이클 간 정확합니다. 설계 복잡성이 증가함에 따라 IP 블록에는 몇 년 전보다 훨씬 더 많은 게이트가 있습니다. 몇 년 전 FPGA는 ASIC 게이트의 수로 인해 제한을 받았으므로 더 큰 로직 블록을 단일 FPGA에 맞출 수 없었습니다. 이제 각 블록에 대해 FPGA를 구축하고 빠르고 정확한 드라이버를 개발할 수 있습니다.

이 방법론은 더 빠르며 소프트웨어 팀이 일찍 시간을 할애할 필요가 없습니다. 전체 통합 SoC 설계가 아니라 각각의 개별 IP 블록과 함께 작동하기 때문에 이 접근 방식은 소프트웨어가 전체 SoC 수준 개발을 수행하는 것을 제한합니다. 다양한 IP 블록이 함께 작동하는 방식에 대한 통합 세부 정보는 생략합니다. 따라서 이 방법이 도입 노력을 줄이더라도 관련 SoC 통합 세부 정보를 놓치기 때문에 격차가 여전히 존재합니다. 이 방법은 제한된 수의 변경 사항이 있지만 SoC 소프트웨어 개발에 필요한 전체 범위를 원하지 않는 파생 SoC에 대해 수용 가능한 접근 방식일 수 있습니다.

더 큰 이미지를 보려면 클릭하세요.

그림. 프리실리콘 소프트웨어 개발 솔루션 개요. (출처:Nitin Garg)

SoC 에뮬레이터

정확도, 속도 및 적용 범위 문제를 해결하기 위해 SoC 에뮬레이터를 사용하는 보다 강력한 접근 방식을 취할 수 있습니다. 매우 크고 복잡한 SoC를 에뮬레이트할 수 있는 상용 SoC 에뮬레이터가 많이 있습니다. SoC 에뮬레이터는 RTL을 기반으로 하기 때문에 정확하고 Verilog 테스트벤치보다 100배 빠르기 때문에 소프트웨어 개발에 훨씬 유리합니다. 상당히 빠르기 때문에 전체 OS 이식 및 드라이버 개발을 합리적인 시간 내에 수행할 수 있습니다. SoC 에뮬레이터는 전체 SoC를 확장할 수 있으므로 소프트웨어 개발이 최종 생산 SoC에 더 잘 적응합니다.

실리콘 이전 소프트웨어 개발 및 설계에 SoC 에뮬레이터를 사용하면 전반적인 개발 격차를 제거하거나 줄일 수 있으므로 소프트웨어 시작 시간과 노력을 줄일 수 있습니다. SoC 에뮬레이터에서 표준 JTAG 도구를 사용하여 소프트웨어를 디버깅할 수도 있습니다. 에뮬레이터는 ROM 개발 및 검증, 펌웨어 및 OS 개발, IP 또는 SoC 수준 검증과 같은 여러 작업에 사용할 수 있습니다. SoC 에뮬레이터의 또 다른 흥미로운 기능은 개발 보드에 있는 것과 같은 실제 구성 요소에 SoC를 인터페이스할 수 있다는 것입니다. 예를 들어 실제 또는 가상 NAND 장치를 에뮬레이터에서 SoC에 연결하고 ROM, OS 드라이버 등을 개발할 수 있습니다.

SoC 에뮬레이터는 다른 소프트웨어 개발 접근 방식보다 훨씬 더 많은 가능성을 제공합니다. 에뮬레이터는 SoC를 UART, I2C, 다양한 디스플레이, 저장 장치, PCIe 장치, 이더넷 및 Wi-Fi와 같은 연결 장치 및 카메라 및 센서와 같은 캡처 장치에 동시에 인터페이스할 수 있습니다. 즉, SoC 에뮬레이터는 실제 개발 보드를 나타낼 수 있으므로 Android와 같은 완전한 프레임워크를 불러올 수 있고 SoC를 테이프로 만들기 전에 완전한 사용 사례를 실행할 수 있습니다. 예를 들어 Android를 부팅하고 SOC 에뮬레이터에서 몇 프레임의 비디오를 디코딩하는 데 몇 시간이 걸릴 수 있지만 SOC 성능을 분석하는 데 매우 유용할 수 있습니다.

SoC에서 주변 장치의 가용성이 증가함에 따라 SoC 에뮬레이션은 성능 벤치마킹에도 매우 유용하며 테이프아웃 전에 설계의 약점을 강조할 수 있습니다. 이 기능은 SoC에서 식별되지 않은 성능 단점과 관련된 위험이나 후속 테이프아웃을 줄일 수 있습니다. 또한 SoC 에뮬레이터를 사용하면 타사 IP에 필요한 경우 SoC를 타사 FPGA 또는 소프트 모델에 인터페이스할 수 있습니다.

SoC 샘플이 도착한 후 문제를 디버깅하는 것은 실제 하드웨어와 동일한 OS, 드라이버 및 프레임워크를 실행한다는 사실을 감안할 때 에뮬레이터에서도 유용합니다. 신호 수준에서 조사할 수 있도록 실리콘에서 관찰된 문제를 에뮬레이터에 복제해야 하는 경우가 종종 있습니다. 에뮬레이터와 실리콘 간에 동일한 소프트웨어를 사용하면 문제를 더 빠르고 정확하게 재현할 수 있어 칩 내부의 세부 정보에 완전히 액세스할 수 있습니다.

다양한 SoC 소프트웨어 개발 접근 방식을 비교할 때 SoC 에뮬레이터를 사용하는 것이 실리콘 이전 개발과 실리콘 이후 디버그 관점에서 더 나은 선택입니다. 소프트웨어 팀이 SoC 에뮬레이터를 실행하는 데 드는 비용은 비싸 보일 수 있습니다. 그러나 SoC 에뮬레이터가 생산 소프트웨어를 더 빨리 제공하고 위험과 비용을 줄임으로써 제공하는 기여는 시장 출시 목표에 미치는 영향을 고려할 때 매우 중요할 수 있습니다. 다른 소프트웨어 개발 접근 방식에는 동일한 적용 범위가 없으므로 위험하고 더 큰 소프트웨어 팀 리소스가 필요할 수 있습니다. SoC 에뮬레이터 이외의 소프트웨어 개발 접근 방식을 사용하는 모든 요소를 ​​고려하면 비교 시 훨씬 더 많은 비용이 소요될 수 있습니다.

그림 2. 솔루션별 실행 속도 비교. (출처:Nitin Garg)

무어의 법칙에 따라 IC의 기능 향상으로 인해 집적 회로(IC)에서 트랜지스터 수가 2년마다 두 배로 늘어납니다. 오늘날 대부분의 ARM 기반 64비트 SoC에는 1억-3억 개의 논리 게이트가 있습니다. 현재 SoC 소프트웨어 개발 접근 방식 중에서 SoC 에뮬레이터는 오늘날의 경쟁 시장에서 SoC의 복잡성 증가와 관련된 문제에 직면한 소프트웨어 개발 팀의 요구를 확장하고 지원하는 것으로 입증되었습니다.

참조

1. Trimberger, Stephen M. “FPGA의 세 가지 시대.” IEEE Xplore 전체 텍스트 PDF: 2015, ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7086413.
2. 브루네, 장마리. "현대 SoC 설계가 에뮬레이션을 수용하는 이유." 임베디드 컴퓨팅 디자인 , 2018년 9월 5일, Embedded-computing.com/embedded-computing-design/why-modern-soc-designs-embrace-emulation.
3. "Soc 에뮬레이션." 사회 에뮬레이션 , 2019년, www.aldec.com/en/solutions/hardware_emulation_solutions/co-emulation–soc-emulation.
4. "집적 회로에 더 많은 구성 요소를 집어넣음." http://www.cs.utexas.edu/ , 2006년, cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf.