芯片架构设计及其作用

创作时间:

作者:

@小白创作中心

芯片架构设计及其作用

引用

CSDN

https://blog.csdn.net/seasermy/article/details/136708694

芯片架构设计是芯片流片前的重要环节，其质量直接影响芯片产品的市场表现。本文将从市场需求调研、竞品分析到硬件和软件架构设计，再到性能评估与建模，全面介绍芯片架构设计的关键环节和核心要点。

芯片架构设计是芯片流片前很重要的一个环节，俗称pre-silicon，芯片架构设计的好坏，决定了芯片产品的质量，决定了芯片产品是否易用，决定了芯片产品的性能，决定了芯片产品在市场上是否具有持久性。芯片生产是个大工程，芯片硬件和芯片软件具有非常不同的特性，芯片软件在release后可以持续完善和优化，但芯片硬件一经流片就无从更改（重新流片一次要几千万）。

打个形象的比喻，芯片架构设计就像大楼施工前的图纸设计，各种事情（户型，地基，车位，绿化，布线，监控，采暖，上下水，采暖，空调，通风，电梯，安全，材料选取，成本等）都要考虑好，一经施工，无从更改，要么成为精品小区，要么成为烂尾楼。

芯片架构设计概览

在架构设计前，需要进行市场需求调研，同时进行竞品调研，保障芯片在生产出来的时候，能满足市场需求，能有更大竞争力。

市场需求调研
目前大语言模型和多模态模型蓬勃发展，芯片设计前需要进行尽可能多的市场调研，涉及如下方面：
大模型的模型规模和计算类型是什么趋势？算力和带宽需求是什么？
大模型的输入sequence length是否更长？多模态模型和LLM模型的输入sequence length有什么区别？
芯片是面向大模型的推理，还是训练？市场需要的性能目标是什么？
是否需要互联？互联带宽多少？
未来的大模型的技术变化趋势？什么样的attention优化技术是最优的？
芯片的面向客户对各种low precision的接受度和需求度如何？
芯片面向客户的编解码需求是什么样的？性能指标是什么？
客户的部署习惯影响芯片的使用和设计，一定要摸清？客户业务的痛点是什么？
存储需求是什么样的？
芯片需要达到的性价比指标是什么？
客户的软件生态是什么样的？
竞品调研
竞品调研主要考察当前市场上比较top的芯片厂商的软硬件设计情况，同时，预测各厂商的未来技术趋势，目前大模型背景下，市场上比较top的芯片厂商如下：
英伟达
AMD
谷歌
华为

硬件架构设计

top厂商的芯片架构概览

nvidia gpu架构
tpu架构
昇腾架构

硬件架构设计需要考虑的事情
整个的芯片设计的主要部分是SoC的设计，system on chip，SoC是由许许多多的IP组成的（自己设计或者买第三方的），chip designer的任务就是将这些IO装进SoC这个大箱子，装得要多，性能要好。大概需要考虑如下事情：

面积
面积太小，放不下那么多资源，面积太大，同比竞品竞争力差（成本高）
功耗
功耗低，供电不足，处理跟不上，功耗高，费电（大数据中心的电费还是很可观的）
频率
整个芯片有一定的工作频率，每个IP也有自己的工作频率，高频率干活快，低频率干活慢。
颗粒
纳米决定能装多少东西，尺寸有多大，目前美国就是在这方面卡我们脖子。台积电已经能做3纳米了。
存储
用hbm，还是用gddr，这两者存储大小，峰值带宽，价格差距较大，需要根据模型应用需求和性价比考虑。目前芯片其实主要是在卖存储，所以搞存储的闷声发大财（尤其是在当前大模型背景下）。
cpu core
无论是host端cpu core的数量及并行度，还是device端cpu core（例如，华为昇腾架构内的AI cpu core）的数量及并行度，都影响任务的异构并行处理，因为有些是适合device的AI tensor或vector计算任务，有些是适合cpu的非规则计算任务（例如，图和树的遍历与检索）。
host和device间的访问延时与访存开销
需要考虑host与device间的通信一次的latency，因为有可能需要多次互通。
需要考虑host memory与device memory的互访互联及带宽，对大模型和推荐系统（embedding table）有益，可以看看nvidia的grace Hopper+grace cpu架构：
uvm统一虚拟内存，unified virtual memory
可以带来编程与处理的便捷性，可以很灵活的调度存储flow
device memory bandwidth
带宽越大，传输越快，利于memory或IO bound的任务，所以，具体要看你的需求和场景，取决于选多大的带宽合适（既便宜，有满足需求）
多级存储及shared memory(例如，nvidia)
需要考虑要几级memory?要不要dma？每级memory多少存储空间？这个其实和你的任务需求也是有关的，和你调度任务流水的方式也有关。
多级cache(例如，nvidia的L1/L2)
你的cache有多少级？每级cache多大？指令cache和数据cache如何划分？cache的一致性和maintenance如何保障？硬件预取和软件预取是否完善？预取latency是多大？
算力
算力，和带宽一样，其实是一个重要的指标？和场景与客户需求有关。需要什么精度的计算？每种精度的TOPS或TFLOPS是多少（取决于你的任务的TFLOPs或 TOPs）？需要稀疏计算（结构化稀疏，还是非结构化稀疏）吗？
执行与调度模型
你的runtime的调度机制是什么样的？能支持最大outstanding是多少？
采用simd还是simt架构？simt架构的线程数及资源分配如何？simt的多线程调度开销如何？多线程间是否能隐藏指令流开销？
如果你只处理向量或matrix计算，那么，simd可能是最高效的，不需要simt的灵活性。如果你处理标量任务，那么，simt（如，nvidia implicit simd）可能更好。详细的simd与simt的机制最好熟练掌握。
总线宽度
总线宽度和处理数据位宽，其实对调度很有影响取决于你的任务或需求粒度。
互联拓扑和带宽
对大模型训练影响很大。

软件架构设计

芯片设计，讲究一个软硬协同设计，如果不考虑软件或客户的使用方式，不从top down是看架构设计，那么，设计出来的芯片硬件大概率是烂尾楼，兼容性差，迁移性差，软件编程难用，过分注重单一计算或单一模型（性能泛化差），等等一系列问题和痛点。
具体关注哪些？

pytorch等框架或客户框架的eager mode和图模式分别如何执行的？
框架或客户需要什么样的算子或api？
模型的变种如何的？输入输出形状如何变化的？如何做通用支持？不要受限于具体形状或固定pattern。
软件栈如何兼容c++语法？如何用最直接的方式编程？这些映射到硬件需要满足什么需求？例如，cuda
软件的编码方式和生成的code size多大？例如，cuda
模型部署方式？都线程？多进程？多模型并行？
不同计算类型？每种类型的利用率分析？模型内的多分支结构？框架的多operator并行调度？
你是否让用户关注了太多软件细节和调度细节？资源分配细节？这个导致软件不好用，软件可能本身也不是这样用的。
算子的数据流编写方式需要反馈硬件，协同设计。
总之，希望以客户需求和习惯为目标，以技术发展趋势为原则指导芯片设计，坚持top->down，而不是down->top。