프로세서의 설계, 검증 및 구현은 일부 회사의 핵심 역량이지만 다른 회사는 가능한 한 빠르고 저렴하게 소형 프로세서를 구현하기를 원합니다. 어떤 도구와 옵션이 있습니까?

프로세서는 제품에 깊이 내장된 매우 작고 단순한 코어부터 데이터 센터에서 가능한 최고 클럭 속도 및 처리량으로 작동하는 코어에 이르기까지 다양합니다. 경우에 따라 동일한 기능을 사용할 수 있습니다. 명령어 세트 아키텍처 (ISA), 마이크로 아키텍처만 차별화했습니다. 다른 경우에는 프로세서 아키텍처가 단일 애플리케이션에 대해 고도로 조정되거나 매우 특정한 조건에 최적화됩니다. 가능한 프로세서의 수는 무한하지만 이를 설계하고 구현하는 방법은 몇 가지뿐입니다.

"임의의 애플리케이션을 매우 빠른 속도로 실행해야 하는 서버는 휴대용 SoC와는 다른 게임입니다."라고 ASIP 도구의 수석 이사인 Gert Goossens가 말했습니다. Synopsys. “유사한 ISA가 있을 수 있지만 구현은 감당할 수 있는 프로세스 기술과 달성하려는 클록 주파수에 따라 크게 달라집니다. 이러한 요소는 제품 또는 디자인에 의해 주도되며 이러한 요소는 원하는 마이크로 아키텍처 구현을 결정합니다. 문제는 트레이드오프 분석을 수행하여 애플리케이션 도메인에 가장 적합한 것이 무엇인지 파악하는 것입니다.”

획일적인 디자인은 일반적인 디자인 함정입니다. Ampere의 최고 제품 책임자인 Jeff Wittich는 "예를 들어 클라이언트 워크로드로 구동되는 코어를 생성하여 클라우드 네이티브 워크로드에 적합하게 작동하거나 HPC에 중점을 둔 코어를 클라우드 네이티브 워크로드에 사용할 수 있다고 기대할 수는 없습니다. “또 하나는 성능 및 효율성 리더십을 제공하는 데 필요한 핵심 아키텍처의 미세 ​​조정의 양을 과소평가하고 있습니다. 실리콘 전 단계와 후 단계에서 의도한 용도에 대해 완전히 검증된 세계적 수준의 프로세서를 만들려면 매우 숙련되고 경험 많은 설계 팀이 필요합니다.”

다른 응용 프로그램의 경우 기성품으로 충분할 수 있습니다. Tensilica Xtensa 프로세서 IP 제품 마케팅 이사인 George Wall은 "기존 IP 블록이 PPA 및 성능 목표를 충족하는 경우 위험이 가장 적은 경로입니다."라고 말합니다. 운율. “기성품이 요구 사항을 충족하지 못하는 그 이상을 넘어서면 고객은 프로세서를 사용자 정의하는 방법을 찾기 시작합니다. 기준에는 성능 요구 사항, 데이터 처리량 요구 사항 및 프로세서에서 실행할 알고리즘 종류가 포함됩니다. RTOS 및 이와 유사한 기타 구성 요소와 같이 프로세서에서 실행되는 다른 소프트웨어는 무엇입니까? 그리고 나 자신의 개발 목적과 최종 사용자의 개발 목적 모두를 위해 어떤 도구 지원이 필요합니까? 이는 매핑해야 하는 요구 사항을 제공하고 다양한 구현을 얼마나 빨리 탐색할 수 있는지의 문제입니다. 파이프라인 깊이를 변경하는 것이 얼마나 쉬운가요? 곱하기, 나누기 또는 부동 소수점 연산과 같은 일반적인 명령어를 선택하거나 선택 해제하는 것이 얼마나 쉬운가요? 그리고 명령어, 레지스터 또는 인터페이스 여부와 상관없이 프로세서에 리소스를 추가하는 것이 얼마나 쉬운 일입니까? 얼마나 빨리 이를 수행할 수 있으며 그렇게 하면 내 소프트웨어에 어떤 영향을 미치나요?”

아키텍처 및 마이크로아키텍처
일반적으로 병렬화 또는 전문화를 통해 성능을 얻을 수 있습니다. 주로 아키텍처에서 전문화를 얻고 주로 마이크로 아키텍처에서 병렬화를 얻습니다. 그렇다면 이 둘의 균형을 어떻게 맞추는가? 사람들이 아키텍처 또는 마이크로 아키텍처를 먼저 변경해야 합니까?

전문화는 오랫동안 논쟁의 대상이었습니다. "80년대 초에 RISC 대 CISC 토론이 있었습니다."라고 아르테리스 IP. “당시 Dave Patterson이 RISC의 편에 섰고 업계가 그 뒤를 따랐습니다. 클럭 속도를 높이면 상황이 더 어려워졌고 메모리 벽에 부딪히기 시작했습니다. 오늘날에는 단일 명령으로 더 많은 작업을 프로세서 코어에 수행할 수 있기 때문에 CISC의 장점이 다시 나타납니다.”

대부분의 사람들에게 아키텍처를 변경하는 것은 명령어 세트를 변경하는 것을 의미합니다. "이것은 대부분의 사람들에게 훨씬 더 쉽습니다."라고 의 최고 마케팅 책임자인 Rupert Baines는 말합니다. 코드. “대단한 가속을 얻을 수 있기 때문에 대부분의 이점을 얻을 수 있습니다. 그리고 확인하기가 훨씬 쉽습니다. 마이크로 아키텍처로 들어가기 시작하면 이를 검증하는 방법을 고려해야 합니다. ISA 변경 사항을 고수한다면 새로운 명령을 이해하는 시뮬레이터를 갖게 됩니다. 도구 내에서 설계되었으므로 변형, 해당 명령에 대한 UVM 등을 생성할 수 있습니다.”

마이크로 아키텍처 변경은 지저분할 수 있습니다. Cadence's Wall은 "기본 마이크로 아키텍처를 변경하면 잠재적으로 위험할 수 있습니다."라고 말합니다. “이러한 마이크로 아키텍처 변경이 디버거와 같은 소프트웨어 도구와 운영 체제와 같은 상위 수준 소프트웨어를 통해 어떻게 파급되는지에 대한 완전한 이해가 없으면 원하는 작업이 아닙니다. 애플리케이션과 코어 사이의 모든 임베디드 프로세서 위에 있는 기본 배관 소프트웨어는 운영 체제, 컴파일러 및 디버거와 마찬가지로 마이크로 아키텍처에 매우 민감합니다. 이는 고객이 마이크로 아키텍처를 변경하려는 경우 그 영향을 이해해야 하는 일종의 절충안입니다.”

이러한 검증 위험을 억제하기 위해 일부 산업 그룹은 인터페이스를 통해 액세스할 수 있는 기본 프로세서와 가속기 사용을 고려하고 있습니다. Synopsys의 Goossens는 다음과 같이 말합니다. “일반적으로 VLIW 아키텍처의 방향으로 이동하지만 기본적으로 전체 RISC-V 아키텍처인 VLIW에 스칼라 슬롯이 있을 수 있습니다. 그런 다음 더 많은 병렬 작업으로 이동하는 추가 병렬 문제 슬롯이 있습니다. 많은 RISC-V 에코시스템을 계속 사용할 수 있지만 고성능 애플리케이션의 경우 옆에 만든 병렬 확장을 통해 성능이 향상됩니다.”

맞춤화 정도
미리 설계된 IP를 선택하는 것부터 완전한 맞춤형 디자인에 이르기까지 다양한 수준의 사용자 정의가 있습니다. 그 중:

• 기존 IP 블록
• 일정량의 사용자 정의를 허용하는 IP 블록
• 템플릿 기반 도구 기반 구성 및 사용자 정의 기반
• 아키텍처 및 마이크로아키텍처 수준 모두에서 임의의 프로세서를 설명할 수 있는 도구
• 전체 사용자 정의 디자인.

이러한 각 범주 내에는 다양한 유형이 존재하며 여러 회사와 도구에서 지원합니다.

"고성능 프로세서 코어를 설계하려면 수동 설계와 합성 도구를 모두 사용해야 합니다."라고 Ampere의 Wittich는 말합니다. “자동 생성 프로세서가 고유한 특성과 대기 시간 및 처리량에 대한 엄격한 요구 사항을 가진 클라우드 네이티브 워크로드의 요구 사항을 충족할 가능성은 거의 없습니다. 그렇게 하면 항상 성능과 효율성이 테이블 위에 남게 됩니다. TLB의 크기나 분기 예측 알고리즘과 같은 코어의 모든 측면은 실제 워크로드 성능에 큰 영향을 미칠 수 있으며 특정 제품 사용에 맞게 신중하게 최적화해야 합니다."

고성능 프로세서는 최적화를 위해 가능한 모든 수단을 사용하는 경향이 있으며 IP 블록으로 제공될 수 있습니다. 수석 CPU 설계자이자 펠로우인 Fred Piry는 "추측 실행과 같은 기술을 가능하게 하는 기본 기능은 성능 목표에 따라 구현이 상당히 다릅니다. 이러한 구조는 영원히 확장되지 않고 크기에 따라 다른 형식이 필요하기 때문입니다. 팔. “투기적 실행을 예로 들겠습니다. 20가지 문제 CPU에 대해 600주기의 비순차적 창을 처리하려면 XNUMX개 이상의 명령에 대해 추측적으로 실행할 수 있는 CPU와 완전히 다른 마이크로 아키텍처가 필요합니다. 가능한 모든 성능 포인트를 처리하기 위해 구성 가능한 단일 CPU는 지속 가능하지 않으며 이것이 Arm이 여러 요구 사항을 충족하는 다양한 마이크로 아키텍처를 구축하는 이유입니다.”

어떤 기술을 사용할 수 있는지에는 한계가 있습니다. Arteris IP의 엔지니어링 담당 부사장인 Hunglin Hsu는 "투자 수익이 감소하고 있습니다. “아키텍처 레지스터가 몇 개뿐이므로 결국 레지스터 종속성으로 인해 디스패치만큼 많은 명령어를 폐기하지 못하게 됩니다. 더 크고 더 큰 프런트 엔드 디스패치 머신을 구축함에 따라 클럭 주파수가 떨어지기 시작합니다. 나는 거대하고 넓은 슈퍼스칼라 코어를 구축하는 것보다 멀티 코어로 가는 것을 선호합니다. 그리고 멀티 코어에 관해서는 두 가지가 가장 중요합니다. 하나는 OS의 스레드 일정입니다. CPU 선호도를 알아야 합니다. 메모리에 가까운 코어에 스레드를 할당해야 합니다. 또 다른 중요한 것은 일관된 원단입니다.”

이 최적화 수준에서는 많은 것들이 서로 연결됩니다. Arm's Piry는 "추측 실행이나 여러 문제와 같은 기능은 모두 함께 연결되어 있으며 각 성능 포인트에 대해 단일 설계 선택이 없습니다."라고 말합니다. “예를 들어, CPU가 추론적으로 명령을 실행할 수 있는 용량을 늘리지 않고 실행 병렬성을 높이는 것은 역효과를 낳을 것입니다. 파이프라인 단계의 수는 CPU가 도달할 최대 클록 주파수를 나타내며 주파수는 성능에 직접적인 영향을 미칩니다. 파이프라인 단계의 수는 분기 오예측으로 인한 성능 손실에 직접적인 영향을 미칩니다. 파이프라인이 길수록 잘못된 예측 비용이 높아집니다. 따라서 CPU 설계자는 설계의 가능한 타이밍 중요 구조를 이해한 다음 주파수, 면적 및 전력 사이에서 최상의 절충안을 찾아야 합니다. 따라서 파이프라인 단계를 미리 정의해야 합니다. 그렇지 않으면 구성 가능성이 복잡해집니다.”

기반에서 구축
소개 RISC-V ISA는 프로세서 설계와 관련하여 중간 지점에 대한 관심을 불러일으켰습니다. "RISC-V는 공통 명령어 세트 기반을 갖고 공통 아키텍처를 정의하는 등 많은 이점이 있습니다."라고 Wall은 말합니다. “IP 벤더와 대학생이 바퀴를 재발명할 필요가 없도록 하는 특정 기본 규칙 세트를 정의합니다. 그들은 명령 세트를 만들거나 메모리 관리 모델 또는 RISC-V 세계에 있는 다른 훌륭한 것들을 만들 필요가 없습니다. 그러나 프로세서의 모양을 보면 실제로는 작은 XNUMX단계 마이크로컨트롤러나 거대한 고성능 코어만큼 간단할 수 있습니다. RISC-V ISA는 둘 중 하나에서 사용할 수 있습니다. 이러한 확장성을 염두에 두고 설계되었습니다.”

많은 경우에 프로세서 생성기는 기본 프로세서 설계의 사용자 지정 사용자 지정을 기반으로 프로세서의 기능적 구현을 ​​자동 생성합니다. 생성기 공급업체는 여러 기본 마이크로 아키텍처를 설계했으며 고객은 파이프라인 단계 수 또는 캐시 크기와 같은 제한된 사용자 지정 옵션 집합에서 선택할 수 있습니다.

Wittich는 "이 접근 방식은 사용 가능한 기본 모델이 대상 애플리케이션의 일반적으로 보통이거나 낮은 성능 및 전력 효율성 요구 사항을 충족할 수 있을 때 잘 작동합니다."라고 말합니다. "또한 개발 비용과 전문화된 프로세서 설계 전문 지식의 부족이 주요 제약 조건인 경우, 즉 사용자가 진정으로 최적화된 프로세서를 구축할 수 있는 전문 지식, 시간 또는 예산이 없는 경우에도 매력적입니다."

많은 경우 이러한 기본 모델은 특정 응용 프로그램 공간을 대상으로 합니다. Codasip의 Baines는 "합리적인 것, 합리적으로 일반적인 것에서 시작하지만 사용자 지정을 통해 매우 다른 방향으로 나아갈 수 있습니다."라고 말합니다. “새 지침을 추가할 수 있으며 이러한 새 지침은 완전히 고유합니다. 다른 누구도 이전에 그런 일을 하지 않았을 것입니다. 마이크로 아키텍처를 변경할 수 있고 아주 기본적인 방식으로 변경할 수 있습니다. 하지만 출발점이 된 가이드 레일 안에 머물러야 합니다.”

이러한 도구를 사용하면 탐색이 가능합니다. "이를 통해 프로세서에서 실제 애플리케이션 코드를 컴파일하고 시뮬레이터에서 생성된 코드를 실행하고 프로파일링할 수 있는 트레이드오프 분석을 수행할 수 있습니다."라고 Goossens는 말합니다. “응용 프로그램의 장단점을 실제로 볼 수 있습니다. 이러한 도구를 사용하면 자동으로 컴파일 및 프로파일링이 생성되므로 단순한 추측이 아니라 실제 데이터를 기반으로 하는 분석을 수행할 수 있습니다. 이것이 우리가 프로세서 설계 도구의 사용을 강력히 지지하는 이유입니다.”

각 도구는 다른 언어를 기반으로 하지만 그림 1과 같이 모두 유사한 흐름을 공유합니다.

그림 1: 생성 도구를 사용하는 프로세서의 설계 및 검증 흐름. 출처: 시놉시스

일부 도구는 목록에서 기능만 선택하도록 허용할 수 있지만 다른 도구에는 더 넓은 범위의 프로세서를 개발할 수 있는 보다 일반적인 프로세서 설명 언어가 있습니다. 예를 들어 nML 언어에는 그림 2와 같이 다양한 최적화 가능성이 있습니다.

그림 2: nML 언어 내에서 액세스할 수 있는 기능. 출처: 시놉시스

이 도구 체인의 중요한 부분은 컴파일러의 생성입니다. Arteris의 Frank는 "ISA는 동일하지만 구현이 다른 두 개의 프로세서가 있는 경우 이론상 두 프로세서 모두에 대해 동일한 컴파일러를 사용할 수 있습니다. “AMD와 Intel의 전쟁을 생각해 보십시오. Intel 컴파일러를 사용하여 컴파일된 프로그램은 AMD 시스템보다 해당 시스템에서 훨씬 더 잘 실행됩니다. 이는 주로 컴파일러가 특정 프로세서에 맞게 조정되었기 때문입니다. 때때로 파이프라인을 모르기 때문에 다른 프로세서에 나쁜 일을 할 것입니다. 타고난 지식이 있으면 분명히 유리합니다.”

프로세서 언어에는 아키텍처 및 마이크로 아키텍처 정보가 모두 포함되어 있으며 이는 효율적인 컴파일러를 생성하는 데 사용할 수 있습니다. "우리 도구는 LLVM으로 시작합니다."라고 Baines는 말합니다. “이는 LLVM의 사용자 정의 버전을 생성하며 사실상 컴파일러의 컴파일입니다. 변형을 작성하면 컴파일러, 디버거, 프로파일러가 생성됩니다. 그들은 모두 자동으로 출력되며 변경 사항을 이해합니다. 우리가 그렇게 할 수 있는 이유는 우리가 가지고 있는 언어가 프로세서 전용이기 때문입니다. 새로운 RTL이 아닙니다. 범용 언어가 아닙니다.”

이것은 고급 합성 더 일반적입니다. Wittich는 "고수준 합성은 프로세서를 설계하는 데 훨씬 더 노력이 많이 드는 접근 방식입니다. "여기서 사용자는 C 또는 C++와 같은 고급 언어로 대상 알고리즘이나 기능을 지정할 수 있는 깊은 전문 지식이 필요합니다. 그러면 합성 도구가 기능적 구현을 ​​생성할 수 있습니다. 통찰력과 전문 지식이 필요한 것 외에도 현재 HLS 기능은 제한된 범위와 범위의 알고리즘(예: 신호, 이미지 및 비디오 처리)의 합성만 지원합니다. 그리고 생성된 구현은 기능적으로 정확하고 빠르게 생성되지만 일반적으로 최적의 성능, 전력 및 면적에 대해 잘 조정되지 않습니다. 이 접근 방식은 아직 고성능 프로세서에서 성공적으로 시연되지 않았습니다.”

결론
프로세서 생성은 노력하지 않는 것(기성 IP를 구매하는 것)에서 종종 IP로 끝나는 완전한 맞춤형 설계까지 다양할 수 있습니다. 자신의 요구에 더 잘 맞는 것을 필요로 하는 사람들을 위해 일련의 제한 사항과 규칙을 준수하는 한 프로세스를 통해 사용자를 안내할 수 있는 프로세서 생성 도구가 있습니다. 이는 최적화 수준, 감당할 수 있는 시간과 노력의 양, 그리고 이것이 제품에 추가되는 이점 사이의 절충점입니다. 다음 프로세서 설계에 가장 적합한 도구는 경계를 얼마나 넓히고 싶은지에 따라 다릅니다.