Google Cloud로 칩 설계 시간을 단축하여 지연 없이 제공
Mark Mims
Solutions Architect
Sashi Obilisetty
Chief Architect, Silicon Solutions
* 본 아티클의 원문은 2021년 5월 28일 Google Cloud 블로그(영문)에 게재되었습니다.
클라우드는 엔드 투 엔드 칩 설계 흐름의 속도를 높이는 입증된 방법을 제공합니다. 이전 블로그에서는 클라우드에 내재된 탄력성을 살펴보면서 더 많은 컴퓨팅 리소스에 액세스하여 어떻게 프론트엔드 시뮬레이션 워크로드를 확장할 수 있는지 확인했습니다. 클라우드의 또 다른 이점은 강력한 최신 글로벌 인프라에 액세스할 수 있다는 점입니다. 온프레미스 환경이 지속적인 수요를 충족하는 역할을 충실하게 수행하기는 하지만, 전자 설계 자동화(EDA) 도구의 업그레이드 빈도(6~9개월에 한 번)는 일반적인 온프레미스 데이터 센터 인프라의 업그레이드 빈도(3~5년에 한 번)에 비해 훨씬 더 높습니다.
즉, EDA 도구가 적절한 인프라에 액세스할 수 있다면 훨씬 더 우수한 성능을 제공할 수 있는 것입니다. 이는 특히 설계 프로세스의 특정 단계에서 유용합니다.
물리적 확인 워크로드를 예로 들어 보겠습니다. 물리적 확인은 일반적으로 칩 설계 프로세스의 마지막 단계에 해당합니다. 간단히 설명하면 이 프로세스는 파운드리가 제공한 프로세스 설계 키트(PDK)를 기준으로 한 설계 규칙 확인(DRC)으로 구성됩니다. 이 프로세스는 물리적 합성 프로세스에서 생산된 레이아웃이 제조를 위해 파운드리(내부 또는 기타)에 전달할 준비가 되었는지를 확인합니다. 물리적 확인 워크로드에는 고급 노드를 위해 메모리 용량이 큰(1TB 이상) 머신이 필요한 경우가 많습니다. 이러한 컴퓨팅 리소스에 액세스할 수 있게 되면 더 많은 물리적 확인을 동시에 실행하고, 테이프 아웃(즉, 제조를 위해 전달)되는 설계에 대해 안심할 수 있습니다.
물리적 확인과 대비되는 또 다른 워크로드로, 기능 확인 워크로드가 있습니다. 앞서 설명한 물리적 확인 프로세스와 달리 기능 확인은 일반적으로 설계의 초기 단계에서 수행되며 머신에 필요한 메모리 용량도 훨씬 더 적습니다. 또한 기능 확인(특히 동적 확인)은 설계 주기에서 가장 많은 시간을 차지합니다(컴퓨팅 가용성으로 직결됨). 대부분의 설계팀에서 추구하는 확인 시간의 단축이라는 목표는 적절한 규모의 컴퓨팅 리소스의 가용성에 따라 좌우되는 경우가 많습니다.
확인(기능 확인과 물리적 확인 모두 해당)을 위한 간헐적이고 다양한 인프라 요구사항은 온프레미스 데이터 센터를 운영하는 조직에 문제가 될 수 있습니다. 온프레미스 데이터 센터는 사용률을 극대화하기 위해 최적화되는데, 이것이 최고의 도구 성능을 제공하기 위해 적절한 크기의 컴퓨팅에 액세스하는 문제를 직접적으로 해결하지는 않습니다. IT 및 컴퓨터 이용 설계(CAD) 부서에서 적절한 하드웨어를 추가로 프로비저닝하기로 결정하더라도, 온프레미스에서 새 하드웨어를 프로비저닝하고 획득하고 설정하는 프로세스는 가장 현대화된 조직에서도 보통 몇 개월이 걸립니다. 대부분의 시간에는 온프레미스 클러스터를 사용하도록 허용하되 필요에 따라 클라우드 리소스에 대한 원활한 액세스를 제공하는 '하이브리드' 흐름이 이상적입니다.
하이브리드 칩 설계의 작동 체계
향상된 컴퓨팅에 대한 즉각적인 액세스를 제공하는 하이브리드 환경을 활용하는 것만으로도 일반적인 확인 워크플로를 개선할 수 있습니다. 설명을 위해 프론트엔드 시뮬레이션 워크플로를 선택하여 온프레미스 및 클라우드 클러스터를 복제하는 환경을 설계했습니다. 또한 몇 가지 요소를 추가로 조정해서 환경을 간소화했습니다(아래에서 설명). 간소화된 설정은 GitHub 저장소에서 제공되므로 직접 사용해볼 수 있습니다.
모든 하이브리드 칩 설계 흐름에서 몇 가지 중요한 고려사항이 있습니다.
- 온프레미스 인프라와 클라우드 간의 연결: 클라우드로의 연결 설정은 이 흐름에서 가장 기본적인 측면 중 하나입니다. 또한 지난 몇 년간 이 분야에 대한 이해도가 크게 높아졌으며 대부분의 설정에서 안전한 고가용성 연결이 실제로 사용되고 있습니다.
이 튜토리얼에서는 온프레미스 클러스터와 클라우드 클러스터를 클라우드의 서로 다른 네트워크 두 개로 나타내며 이 클라우드에서 모든 트래픽은 두 네트워크 간에 전달될 수 있습니다. 실제 환경의 네트워크 구성은 아니지만 기본적인 연결 모델을 설명하는 데는 충분합니다. - 라이선스 서버 연결: 대부분의 칩 설계 흐름에서는 EDA 공급업체의 도구를 활용합니다. 일반적으로 이러한 도구에는 라이선스가 적용되므로 도구를 사용하려면 유효한 라이선스가 부여된 라이선스 서버가 필요합니다. 라이선스 서버에 연결할 때 발생하는 지연 시간이 허용 가능한 수준이라면 하이브리드 흐름에서 라이선스 서버를 계속 온프렘에 둘 수 있습니다. 지연 시간을 단축하기 위해 클라우드의 Compute Engine VM(특히 단독 테넌트 노드)에 라이선스 서버를 설치할 수도 있습니다. 라이선스 서비스를 클라우드에 재호스팅할 수 있는지 여부는 EDA 공급업체에 문의하세요.
이 튜토리얼에서는 오픈소스 도구(Icarus Verilog Simulator)를 사용하므로 라이선스 서버가 필요하지 않습니다. - 데이터 소스 식별 및 데이터 동기화: EDA 작업 실행에서 세 가지 중요한 측면은 EDA 도구 자체, 도구가 실행되는 인프라, 도구 실행을 위한 데이터 소스입니다. 도구는 크게 변화하지 않으며 클라우드 인프라에 설치할 수 있습니다. 반면 데이터 소스는 주로 온프레미스에서 생성되며 정기적으로 업데이트됩니다. 설계를 설명하는 SystemVerilog 파일, 테스트벤치 또는 레이아웃 파일 등이 여기에 해당합니다. 온프레미스과 클라우드 간에 데이터를 동기화하여 패리티를 유지하는 것이 중요합니다. 또한 프로덕션 환경에서 고성능 동기화 메커니즘을 유지하는 것도 중요합니다.
이 튜토리얼에서는 온프레미스에서 일반적으로 사용되는 것과 비슷한 파일 시스템 계층 구조를 클라우드에 생성합니다. 도구를 호출하기 전에 최신 입력 파일을 전송합니다. - 워크로드 스케줄러 구성 및 작업 제출 투명성: 일괄 작업을 활용하는 대부분의 환경은 작업 스케줄러를 사용하여 컴퓨팅 팜에 액세스합니다. 이상적인 환경에서는 비용과 성능 간에 균형을 맞추고, 시스템에 매개변수를 빌드하여 작업 스케줄러에 대한 예측 및 처방적 래퍼를 실현합니다(아래 그림 참고)
이 튜토리얼에서는 오픈소스 SLURM 작업 스케줄러 및 자동 확장 클러스터를 사용합니다. 편의를 위해 튜토리얼에는 작업 제출 에이전트를 포함하지 않습니다.
Kubernetes와 같은 다른 클라우드 기반 일괄 처리 환경에서는 워크로드 관리를 위한 추가 옵션도 제공할 수 있습니다.
여기서 온프레미스 네트워크의 이름은 ‘onprem’이며 클라우드 클러스터의 이름은 ‘burst’입니다. 온프레미스 및 버스트 클러스터의 특성은 아래에 나와 있습니다.
설정 후 단일 타일 및 2개 타일 구성에 대해 OpenPiton 회귀를 실행했습니다. 아래에서 결과를 볼 수 있습니다.
'burst' 클러스터에서 실행된 회귀가 'onprem'에서 실행된 회귀와 비교해 평균 30% 더 빨랐기 때문에 확인 완료와 물리적 확인에 소요된 시간도 단축되었습니다. 사용한 명령어에 대한 자세한 내용은 저장소에서 찾을 수 있습니다.
