一个简单的8位处理器完整设计过程及verilog代码 来源： EETOP BBS   作者：weiboshe一个简单的8位处理器完整设计过程及verilog代码,适合入门学习参考，并含有作者个人写的指令执行过程（点击下方 阅读原文 到论坛可下载源码）CPU定义我们按照应用的需求来定义计算机，本文介绍一个非常简单的CPU的设计，它仅仅用来教学使用的。我们规定它可以存取的存储器为64byte，其中1byte=8bits。所以这个CPU就有6位的地址线A[5：0]，和8位的数据线D[7：0]。我们仅定义一个通用寄存器AC（8bits寄存器），它仅仅执行4条指令如下：除了寄存器AC外，我们还需要以下几个寄存器：地址寄存器 A[5：0]， 保存6位地址。程序计数器 PC[5：0]，保存下一条指令的地址。数据寄存器 D[7：0]，接受指令和存储器来的数据。指令寄存器 IR[1：0]，存储指令操作码。2. 取指设计       在处理器执行指令之前，必须从存储器取出指令。其中取指执行以下操作：1〉 通过地址端口A[5：0]从地址到存储器2〉 等待存储器准备好数据后，读入数据。由于地址端口数据A[5：0]是从地址寄存器中读出的，所以取指第一个执行的状态是Fetch1：     AR<—PC接下来cpu发出read信号，并把数据从存储器M中读入数据寄存器DR中。同时pc加一。Fetch2：      DR<—M，PC<—PC+1接下来把DR[7：6]送IR，把DR[5：0]送ARFetch3：      IR<—DR[7：6]，AR<—DR[5：0] 3. 指令译码Cpu在取指后进行译码一边知道执行什么指令，对于本文中的CPU来说只有4条指令也就是只有4个执行例程，状态图如下：4. 指令执行对译码中调用的4个例程我们分别讨论：4.1 ADD指令ADD指令需要CPU做以下两件事情：1〉 从存储器取一个操作数2〉 把这个操作数加到AC上，并把结果存到AC所以需要以下操作：ADD1： DR<—MADD2： AC<—AC+DR4.2 AND指令AND指令执行过程和ADD相似，需要以下操作：AND1： DR<—MAND2： AC<—AC^DR4.3 JMP指令       JMP指令把CPU要跳转的指令地址送PC，执行以下操作JMP1：  PC<—DR[5：0]4.4INC指令INC指令执行AC+1操作INC1：   AC<—AC+1总的状态图如下：5 建立数据路径       这一步我们来实现状态图和相应的寄存器传输。首先看下面的状态及对应的寄存器传输：    Fetch1：     AR<—PCFetch2：      DR<—M，PC<—PC+1Fetch3：      IR<—DR[7：6]，AR<—DR[5：0]ADD1： DR<—MADD2： AC<—AC+DRAND1： DR<—MAND2： AC<—AC^DRJMP1：  PC<—DR[5：0]INC1：   AC<—AC+1为了设计数据路径，我们可以采用两种办法：1〉创造直接的两个要传输组件之间的直接路径2〉在CPU内部创造总线来传输不同组件之间的数据首先我们回顾一下可能发生的数据传输，以便确定各个组件的功能。特别的我们要注意把数据载入组件的各个操作。首先我们按照他们改变了那个寄存器的数据来重组这些操作。得到如下的结果：AR：AR<—PC；AR<—DR[5：0]PC：PC<—PC+1；PC<—DR[5：0]DR：DR<—MIR：IR<—DR[7：6]AC：AC<—AC+DR；AC<—AC^DR；AC<—AC+1现在我们来看每个操作来决定每个组件执行什么样的功能，AR，DR，IR三个组件经常从其他的组件载入数据（从总线），所以只需要执行一个并行输入的操作。PC和AC能够载入数据同时也能够自动加一操作。下一步我们把这些组件连接到总线上来，如图所示：如上图所示，各个组件与总线之间通过三态连接，防止出现总线竞争。AR寄存器送出存储器的地址，DR寄存器用于暂存存数起来的数据。到现在为止我们还没有讨论有关的控制信号，我们现在只是保证了所有的数据传输能够产生，我们将在后面章节来使这些数据传输正确的产生---控制逻辑。现在我们来看以下者写数据传输中有没有不必要的传输：1〉 AR仅仅提供数据给存储器，所以他不需要连接到总线上。2〉 IR不通过总线提供数据给任何组件，所以他可以直接输出到控制单元（后面章节）。3〉 AC不提供数据到任何的组件，可以不连接到总线上。4〉 总线是8bit宽度的，但是有些传输是6bit或者2bit的，我们必须制定寄存器的那几位送到总线的那几位。5〉 AC要可以载入AC和DR的和或者逻辑与的值，数据路径中还需要进行运算的ALU。由此我们做以下工作：1〉 去掉AR，IR， AC与总线的连接。2〉 我们约定寄存器连接是从总线的低位开始的。AR，PC连接到Bus[5：0]，由于IR是接受DR[7：6]的，所以可以连接到总线的Bus[7：6]。3〉 我们设定，AC作为ALU的一个输入，另一个输入来自总线Bus。下面我们检查是否有争用总线的情况，幸运的是这里没有。修改后的CPU内部组织图如下：ALU设计这个CPU的ALU执行的功能就是两个操作数相加、逻辑与。这里不作详细介绍。电路如如下： 控制单元 我们来考虑如何产生数据路径所需的控制信号，有两种方法：硬布线逻辑和为程序控制。这里我们用硬布线逻辑来实现。这个简单的CPU需要的控制逻辑由三个部件组成： 1〉计数器： 用于保存现在的状态 2〉译码器： 生成各个状态的控制信号 3〉其他的组合逻辑来产生控制信号一个通用的控制单元原理图如下：  对于这个CPU来说，一共有9个状态。所以需要一个4bit的计数器和一个4-16的译码器。接下来的工作就是按照前面的状态转换图来对状态进行赋值。  首先考虑如何的对译码输出状态进行赋值才能达到最佳状态。我们按照以下规则：  1〉给Fetch1赋计数器的0值，并用计数器的清零端来达到这个状态。由这个CPU的状态图可以看出，除了Fetch1状态外的状态都只能由一个状态转化而来，Fetch1需要从4个分支而来，这4个分支就可以发出清零信号（CLR）来转移到Fetch1。  2〉把连续的状态赋连续的计数器值，这样就可以用计数器的INC输入来达到状态的转移。  3〉给每个例程的开始状态赋值时，要基于指令的操作码和这个例程的最大状态数。这样就可以用操作码来生成计数器的LD信号达到正确的状态转移。首先，在Fetch3状态发出LD信号，然后要把正确的例程地址放到计数器的输入端。对这个CPU来说，我们考虑以地址1 [IR] 0作为计数器的预置输入。则得到状态编码如下：如上表所示，下面我们需要设计产生计数器的LD、INC、CLR等信号，总的控制单元的逻辑如下图：下面我们用这些译码信号来产生数据路径控制所必需的AR、PC、DR、IR、M和ALU的控制信号。首先考虑寄存器AR，他在Fetch1状态取PC的值，并在Fetch3状态取DR[5：0]的值，所以我们得到ARLOAD=Fetch1 or Fetch3。以此类推我们可以得到如下结果：PCLOAD=JMP1PCINC=Fetch2DRLOAD=Fetch1or ADD1 or AND1ACLOAD=ADD2 or AND2IRLOAD=Fetch3对于ALU的控制信号ALUSEL是用来控制ALU做逻辑或者算数运算的，所以有：ALUSEL=AND2对于片内总线的控制较为复杂，我们先来看DR，对于DR他只在Fetch3、AND2 、ADD2和JMP1状态占用总线进行相信的数据传输，所以有：DRBUS=Fetch3 or AND2 or ADD2 or JMP1其他类似有：MEMBUS=Fetch2or ADD1 or AND1PCBUS=Fetch1最后，控制单元需要产生存储器的读信号（READ），它发生在Fetch2、ADD1、AND1三个状态：READ=Fetch2or ADD1 or AND1这样我们得到了总的控制逻辑，完成了整个CPU的设计。8. 设计验证 我们执行如下指令进行设计验证，0：ADD41：AND52：INC3：JMP04：27H5：39H指令执行过程如下（初始化所有寄存器为全零态）：

DC/DCT/DCG 差别和联系 本文探讨了DC、DCT和DCG在Synopsys工具中的区别和联系，重点在于它们如何优化时序、处理线延迟、物理布局和低功耗设计。DCG在DCT基础上增强堵塞管理和物理约束，适合亚微米工艺下的高级综合优化。1、连线优化2、MUX结构优化3、门级结构优化DC/DCT/DCG 差别和联系转自：https://www.cnblogs.com/wt-seu/p/12812663.html在dc家族系列中，DC_V,DC_E为根本的DC(Design Compiler)对象，具有dc所具有的根本fearture，DC在synopys对象系列中地位，无足轻重，也是业界应用最普遍的综合对象，比拟candence的RC（RTL compiler）有更大的客户群。进入到亚微米工艺下，DCT/DCG已逐步成为优化时序的一种选择。在解释这个成绩之前，就我所接触到的DC相干的license成绩，简述一下synopsys的生财之道。可以说DC是synopsys最挣钱的EDA对象，除根本的fearture须要license之外，一些高等的fearture，都须要额定免费。好比1、compile_ultra2、set_host_number3、design_ware库（又细分为许多种好比低功耗，多比特存放器，和一些IP）。4、DCT5、DCG等等，这些都须要license,并且价钱不菲。人人可以在synopsys官网上看到这些。那末言归正传，DC/DCT/DCG有甚么差别和联系呢?1、起首简略的讲，DCG包括DCT所有fearture，DCT包括DC所有fearture，固然有一些DC的fearture在DCT和DCG中已不再实用，好比wire_load_model的设置。2、从库的角度来看，DCT/DCG比拟DC多了physical library的设置。DCG比拟DCT又多了对layer,congestion相干的设置。3、DCT的涌现重要是处理DC的时序模子中，wire_load_model误差过大的成绩，使得DCT在综合的时刻可以加倍准确斟酌path中线延时，并联合加倍精确的path的时序情形停止优化。而DCG重要是在DCT的基本上处理堵塞成绩，更好的结构布线。4、 DCT/DCG比拟DC都须要输出物理束缚。平日是经由过程ICC做floorplan以后的def文件中抽取物理束缚信息。今朝来看经由过程物理束缚敕令，编写物理束缚已成为鸡肋，重要缘由，这个阶段很难经由过程敕令准确的表 述block的结构布线信息。5、低功耗设计中upf/cpf文件的编写，是低功耗设计的根本功。DC/DCT/DCG都支撑低功耗设计。6、DC:dc_shell-t DCT: dc_shell-topo ，必需启动compile_ultra，DCG:差别在与启动DCT后，在compile_ultra 以后多了-spg选项。总之DC/DCT/DCG既有差别又有联系。留意比较中熟习其特点。————————————————版权声明：本文为CSDN博主「北方爷们」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/sinat_29862967/article/details/111220492

英伟达GB200架构解析2:谈谈AI工厂和AI云的技术和商业逻辑 原创/还呗 zartbot2024年03月31日22：36浙江从技术路径上来看，GB200的互联系统大概有三个方式， 英伟达的市场策略是很明晰的，如图所示：对于生成式的AI云和AI工厂的最大区别在于租户不同，单一任务规模不同，底层技术上也通过支持以太网的Spectrum-X和Infiniband/NVLINK互联区分，那么这三个解决方案就更加清楚了：互联方式 使用场景NVL72 + Infiniband AI工厂标配NVL576 + Infiniband AI工厂土豪特选NVL72 + Spectrum-X 生成式AI云服务另外又有一个思科和英伟达合作，在GTC上的Session谈到一个根本性的问题：自建还是租？结论很有趣：两者都会存在，但是需要像Cloud那样的使用体验？云的体验是什么？本质上是一个算力证券化的过程。体验统一了，背后的分歧应该只是商业模式上的，是买还是租，或者采用融资租赁等金融工具来买？而实质的技术上不应该有分歧，如果我们把它定义成AI CLOUD-X，对比如下右图所示，这背后又需要什么样的技术呢？其实很多人没有明白云的价值是什么，基本上还是跟IDC混为一谈。根本的区别是云是一个算力金融机构，流动性(弹性)和安全(多租户)是它的根本。比尔盖茨曾说过："Banking is neccesary, Banks are not". 王坚博士讲过:"计算，为了无法计算的价值(Computing for Value Beyond Computation)". 本质上博士也是在阐述计算的价值，那么照着写一句:"Computing is neccesary, Computers are not". 这样来看更有云计算的味道，又有了几分Serverless，Datacenter as a computer的意境。云服务提供商和金融机构具有太多的共性，具体的内容可以参考以前的一篇文章《从金融的视角谈云计算》从商业逻辑上来看AI工厂和AI云1.1 模型规模和弹性通常金融机构盈利的主要策略是“借短投长”，对于期限错配和流动性风险的管理是金融机构必须要关注的。而对于GB200这样的算力投资来看，云计算厂商考虑的也是类似的逻辑。一次性长期投资下，如何能够尽量的通过频繁的短期租赁来获取收益？对于超大规模Foundation模型的训练，也就是AI工厂的范畴看，参与者基本上也就会收敛到20家左右，并且训练都是持续数个月的，对于云来说更多的是考虑一种非弹性的融资租赁模式，盈利模式可能更多的是在换代后的推理收益上，下面以一个例子来解释：例如微软给OpenAI训练GPT-5用了100,000片H100，这些投资前期可能以很低的毛利供给给OpenAI，因为这些长期包年包月的服务并不具有流动性溢价，特别是在国内有多个智算中心的大背景下。而在两年后B100集群上量后，这100,000片H100将拆分出来用于FineTune和推理等业务。从整个H100的生命周期而言，从现金流的角度来看，中短期内是一个收益率较低的持续稳定现金流，而中长期则是一个看推理/FineTune市场的收益率相对高一些的弹性售卖的逻辑，但是现金流本身和流动性息息相关和售卖率也相关，因此也可以看到英伟达和云对大模型公司的投资，其实是在进行算力的流动性风险管理, 为整个现金流寻找确定性。因此从现金流来看，AI云服务提供商和AI工厂有着巨大的差异，因此Build or Rent的逻辑更多的可能还是在每个企业如何衡量自身的现金流上， 例如企业自身还可以通过融资租赁的方式来Build替代Rent from Cloud，背后的成本核算是一个很有趣的话题， 例如学过CFA/FRM的人基本上都懂债券的Barbell或者Bullet两种策略以及其凸性，那么针对AI场景下的ROI分析可能是一个因子更多的问题， 不光是基础设施投资回报还有模型带来的经营收益回报上，后面会针对投资回报率相对确定的搜广推做一些分析。1.2 弹性视角下的AI云现阶段AI集群存在三套网络一个是NVLink这样的Scale-Up网络,另一个是基于RDMA的东西向Scale-Out网络，还有一套是原有的Front-End 存储/管控和南北向流量，今年GTC上Gilad有个演讲《Entering A New Frontier of AI Networking Innovation》[1],也提到了类似的区分针对网络中的数据流量分为东西向和南北向，主要差异在计算紧耦合/长尾抖动容忍度低/突发强等，宏观的秒级监控来看平均带宽中等，但是微观上突发这也是英伟达宣称为什么传统以太网无法解决，必须要Spectrum-X技术，或者UEC联盟/ OCP-Falcon 需要解决的问题。从云的经营视角来看，更多的是关注弹性部署的问题，除了Azure使用Infiniband外，另外两大云服务提供商AWS/GCP似乎都没有独立的Scale-Out网络，并且都在传统以太网上通过在其DPU上实现了EFA/Falcon协议来支持，例如AWS部署的GH200 NVL32全部使用了Nitro EFA组网，并没有特别的东西/南北流量区分，而事实上这些技术问题确实可以解决并共存，后面第二章我们将详细分析。1.3 AI云服务提供商选择Scale-Up和Scale-Out的平衡对于云服务提供商而言除了整合Scale-Out和Front-End网络外，还有一个非常重要的话题是Scale-Up和Scale-Out的平衡，AI工厂可能有一些更极端的逻辑去追求极致的性能和探索更大规模的模型，但是上一代的NVL256和这一代的NVL576基本上没有客户买单，AI云服务提供商依旧选择了NVL72，甚至英伟达的推荐也是。在这次GTC《The Next-Generation DGX Architecture for Generative AI》[2]它通过576个Blackwell GPU构成一个Building block，并称其为hot-aisle containment closet (HAC)，可以看到其内在的逻辑是考虑到物理约束/功耗限制/液冷散热等情况通常由一组互相备份的分布式制冷单元CDUs (cooling distribution units)，配合16个机柜构成，每列机柜包含8个NVL72计算机柜和8个互联的支持机柜通过Infiniband构建的Scale-Out网络拓扑如下：可以看到在单个Pod内构建的576卡集群Scale-Out网络是1:1收敛的，而多个Pod之间的互联并没有构成1:1收敛。整个系统通过这样的两列Sub-HAC构成：最终通过把大量的sub-HAC连接构成一个32,000卡的集群官方的介绍中基本上没看到有NVL576的方案，只有在安费诺的一个和连接器相关的Session中介绍了一部分，例如铜缆转光模块的笼子，不确定NVSwitch上闲置的两根线是否跟这个有关从云服务提供商的视角来看，GB200NVL这样的平台比DGX B200的平台更符合云服务提供商对业务弹性的需求，相对于单机8卡，GB200可以按照单机两卡售卖拆散了售卖，同时又可以组装起来构成一个NVL72的大系统。当然对云服务提供商的ROI还需要更多的定量分析，只是个人大概估算了一下GB200NVL的ROI会远高于B200，因为产品中后期的弹性售卖能力和故障恢复能力远高于B200的平台。1.4 AI云的任务编排和调度另一方面是网络带来的冲突和拥塞控制上，对于大规模AI工厂，通过对节点的编排可以很好的避免冲突。但是对于多租户的AI云场景下由于弹性售卖的逻辑，多个任务调度编排难度极大，编排不当会导致性能损失：而这个问题通过特殊的交换机和DPU也可以解决，但是英伟达的方案并不干净，必须要使用无损 刚性兑付的网络当然，通过这些技术可以使得整个云服务提供商对Job编排做到位置无感知，可以更好的提供弹性售卖的能力AI云基础设施建设上和AI工厂最大的区别就在于此，它需要考虑GPU生命周期中后期的弹性售卖逻辑支撑多租户和灵活的资源调度编排能力，和碎片化的资源售卖能力。关于英伟达Spectrum-X具体内容可以参考《谈谈英伟达的SpectrumX以太网RDMA方案》从技术上分析如何实现AI Cloud-X是否存在一个技术能够完成AI工厂超大规模的Foundation模型训练，又能够完成在生命周期的中后期能够弹性售卖？三套网络看上去是不太合理的例如GPU针对SORA类应用要从存储拉数据，或者云上需要弹性售卖时，从Front-End到CPU再PCIe灌入GPU显得有些瓶颈。而针对GB200这类业务，其实Front-End的网络带宽也大大提升了。随着SCALE-UP的能力增强对SCALE-OUT网络的依赖也会越少。这一些问题是值得我们去探讨的。2.1 SCALE-OUT和SCALE-UP合并这是来自于BRCM投资者交流日的胶片：伴随着CPO和1.6T以太网，这样的合并价值可能会凸显出来，这也是英伟达未来一代的演进趋势，构建光互联的系统概念图如下：最终构建一个超大规模的光互联系统2.2 SCALE-OUT和Front-End合并对于AI这些推理应用落地场景最多的搜广推业务，存在大量的CPU实例和GPU实例的交互。例如Meta的一个数据：事实上针对实时推荐系统来看，十亿级用户行为的捕获，进入Flink这些系统后，用户行为数据通常需要快速的进入推荐系统进行存储并构建Embedding，而伴随着大模型在线推理业务的部署，RAG/AGENT等对向量数据库的需求上都会要求CPU和GPU系统之间有更大的带宽进行通信。注：对于大模型用于搜广推和GH200/GB200的优势，我们将在下一篇文章中详细阐述。Grace-Blackwell这些直接CPU和GPU之间通过C2C互联是一种解法，另一种做法就是Front-End和SCALE-OUT网络合并互联。例如Google在其A3 H100实例上就是这样的部署方式，任何一个通用CPU计算的VM都可以直接通过FRONT-END连接到起SCALE-OUT网卡，事实上也就证明了GCP已经完成了SCALE-OUT和FRONT-END网络的合并，并且协议也没有采用ROCEv2，而是为了兼容有损的FRONT-END网络采用了GPUDirectTCPX或者未来的Falcon。对于AWS的NVL32和NVL72的系统依旧会采用其Nitro构建的EFASRD。对于英伟达，Jensen在和投资者交流的会议中还在提及无损网络和AR，以及如何实现Noise Isolation等，但事实上有损网络支撑SCALE-OUT网络已经在工业界落地，只需要一些非常优雅的多路径转发和拥塞控制算法即可，这一点上我们也通过上一代传统交换网络进行了验证，并不需要什么超级以太网的新型交换机支撑。结论本文从生成式AI云服务经营的视角来分析了云对弹性多租的需求，但同时也存在和AI工厂之间的一系列差异，这些差异在商业模式上和技术路径演进上都存在。对于云服务提供商而言，其未来演进会存在一系列网络合并，无论是博通还是英伟达都有明确的路径，另一条路是AWS和GCP。当然GCP还特殊一点，其AI工厂还有TPU这一条线支撑。参考资料[1]Entering A New Frontier of AI Networking Innovation: https://static.rainfocus.com/nvidia/gtcs24/sess/1707189722732001l46P/FinalPresPDF/S62293a%20-%20Entering%20A%20New%20Frontier%20of%20AI%20Networking%20Innovation_1711040929732001ayMI.pdf[2]The Next-Generation DGX Architecture for Generative AI: https://static.rainfocus.com/nvidia/gtcs24/sess/1696188785866001bSLb/FinalPresPDF/S62421_1711139422506001ouGg.pdf

英伟达GB200架构解析1: 互联架构和未来演进 原创扎波特的橡皮擦zartbot2024年03月31日22：36浙江关于GB200想从下面几个方面来谈：NVL72和互联架构演进GH200/GB200在推荐系统等场景下的业务价值和商业逻辑GB200芯片的微架构的分析这是这个系列的第一篇，从互联架构上进行探讨。很多金融机构和分析师团队都在将英伟达和互联网兴起时的思科对比，那么本文在介绍完英伟达互联架构演进后也会穿插着把思科在互联网兴起时对互联系统的演进路径，以及当年的网络处理器(Network Processor,NP)和当下的DPU在体系结构上的进行对比，包括英伟达BlueField的片上网络还有很多Ezchip和Tilera这些网络处理器的影子，于是很多事情都会更加清晰了。互联网时代的思科和AI时代的英伟达，虽然时代不同，但有太多的路径重叠。本源是都在面临算力不够（思科是大量的查路由表访问内存)碰到内存墙后开始了一系列多芯片Scale-Out而产生互联架构的创新。特别是Bill Dally在互联网时代创办的Avici和当年华为的最顶级路由器NE5000有太多的关系，以及当下TPU的互联架构都是3D-Torus，而如今Bill Dally又是英伟达的首席科学家，未来的演进路线基本上也就清晰了。1.GB200互联架构解析1.1 NVLink带宽计算英伟达在对NVLINK的传输带宽计算和对于SubLink/Port/Lane的概念上存在很多混淆的地方，通常 单颗B200的NVLINK 5带宽是1.8TB/s，这是做计算的人算带宽通常按照内存带宽的算法以字节每秒(Byte/s)为单位。而在NVLink Switch上或者IB/Ethernet交换机和网卡上，是Mellanox的视角以网络带宽来计算的，通常是以传输的数据位为单位,即比特每秒(bit/s)。这里详细解释一下NVLINK的计算方式，NVLINK 3.0开始由四个差分对构成一个"sub-link"(英伟达经常对它用Port/Link，定义有些模糊），这4对差分信号线同时包含了接收和发送方向的信号线，而通常在计算网络带宽时，一个400Gbps的接口是指的同时能够收发400Gbps的数据，如下图所示它总共由4对差分信号线构成RX/TX各两对，从网络的视角来看是一个单向400Gbps的链路，而从内存带宽的视角是支持100GB/s的访存带宽。1.1.1 NVLINK 5.0 互联带宽在Blackwell这一代采用了224G Serdes，即sub-link的传输速率为200Gbps 4（4对差分线)/8 =100GB/s，从网络来看单向带宽为400Gbps。B200总共有18个sublink，因此构成了 100GB/s 18 = 1.8TB/s的带宽，而从网络的视角来看等同于9个单向400Gbps的接口。同理，在NVSwitch的介绍中声明的是 Dual 200Gb/sec SerDes构成一个400Gbps的Port为了方便后文的叙述，我们对这些术语进行统一定义如下：B200 NVLINK带宽为1.8TB/s，由18个Port构成，每个Port 100GB/s，由四对差分线构成，每个Port包含两组224Gbps的Serdes (2x224G PAM4 按照网络接口算为每端口单向400Gbps带宽)1.1.2 NVLINK 4.0 互联我们再补充一下Hopper，在NVLINK 4.0中采用了112G Serdes，即单对差分信号线可以传输100Gbps，累计单个NVLINK的Sub-link构成4x100Gbps= 50GB/s，支持NVLINK 4.0的Hopper这一代产品有18个sub-link(port)，则单个H100支持50GB/s * 18 = 900GB/s，单机8卡利用4个NVswitch连接，如下图所示它还可以增加第二层交换机构成一个256卡的集群扩展接口采用OSFP的光模块如下图所示，OSFP光模块可以支持16对差分信号线, 因此单个OSPF支持4个NVLINK Port，即下图中NVLink Switch包含32个OSFP光模块接口连接器，累计支持32 * 4 = 128个NVLINK4 Port1.2 GB200 NVL72GB200 NVL72的Spec如下图所示，本文主要讨论NVLINK相关的问题一个GB200包含一颗Grace 72核的ARM CPU和2颗Blackwell GPU整个系统由Compute Tray和Switch Tray构成，一个Compute Tray包含两颗GB200子系统，累计4颗Blackwell GPU一个Switch Tray则包含两颗NVLINK Switch芯片，累计提供72 * 2 = 144个NVLINK Port，单颗芯片结构如下，可以看到上下各36个Port，带宽为7.2TB/s，按照网络的算法是28.8Tbps的交换容量，相对于当今最领先的51.2Tbps交换芯片小一些，但是需要注意到它由于实现SHARP（NVLS）这样的功能导致的整个机柜支持18个Compute Tray和9个Switch Tray，因此构成了一个单机柜72个Blackwell芯片全互联的架构，即NVL72.单个GB200子系统则包含2 * 18 = 36个NVLink5 Port，整个系统对外互联上并没有采用OSFP的光模块接口，而是直接通过一个后置的铜线背板连接，如下图所示：关于光退铜进这些金融机构分析师的说法其实是片面的，Hopper那一代是考虑的相对松耦合的连接方式，导致这些分析师过分的夸大了光模块的需求。而且当时对机柜散热部署等要求更加灵活。而这一代是在单机柜内整柜子交付，属于类似于IBM大型机的交付逻辑，自然而然的就选择了铜背板，同时单个B200功耗更高，整机液冷交付同时还有功耗约束，从功耗的角度来看换铜也可以降低很多。但是这并不代表未来都会是铜互联，后面章节会详细分析。整个NVL72的互联拓扑如下所示：每个B200有18个NVLINK Port，9个Switch Tray刚好共计18颗NVLINK Swtich 芯片，因此每个B200的Port连接一个NVSwitch芯片，累计整个系统单个NVSwitch有72个Port，故整个机器刚好构成NVL72，把72颗B200芯片全部连接起来。1.3 NVL576我们注意到在NVL72的机柜中，所有的交换机已经没有额外的接口互联构成更大规模的两层交换集群了，从英伟达官方的图片来看，16个机柜构成两排，虽然总计正好72 * 8个机柜构成576卡集群的液冷方案，单是从机柜连接线来看，这些卡更多的是通过Scale-Out RDMA网络互联的，而并不是通过Scale-Up的NVLINK网络互联对于一个32,000卡的集群也是通过这样的NVL72的机柜，一列9个机柜，4个NVL72和5个网络机柜，两列18个机柜构成一个Sub-Pod，并通过RDMA Scale-Out网络连接当然这个并不是所谓的NVL576，如果需要支持NVL576则需要每72个GB200配置18个NVSwitch，这样单机柜就放不下了，事实上我们注意到官方有这样一段话：官方说NVL72有单机柜版本，也有双机柜的版本，并且双机柜每个Compute Tray只有一个GB200子系统，另一方面我们注意到NVSwitch上有空余的铜缆接头，很有可能是为了不同的铜背板连接而特制的这些接口是不是会在铜互联背板上方再留一些OSFP Cage来用于第二层NVSwitch互联就不得而知了，但这样的方法有一个好处，单机柜的版本是Non-Scalable的，双机柜版本的是Scalable的，如下图所示：两个机柜的版本有18个NVSwitch Tray，可以背靠背互联构成NVL72.虽然交换机多了一倍，但是为以后扩展到576卡集群，每个交换机都提供了36个对外互联的Uplink，累计单个机柜有36 2 9 =648个上行端口，构成NVL576需要有16个机柜，则累计上行端口数为 648 * 16 = 10,368个，实际上可以由9个第二层交换平面构成，每个平面内又有36个子平面，由18个Switch Tray构成，NVL576的互联结构如下所示：1.4 从业务视角看到NVL576对于NVL576这样超大规模的单一NVLink Scale-Up组网是否真的有客户，我个人是持怀疑态度的，AWS也只选择了NVL72来提供云服务。主要的问题是2层组网的可靠性问题和弹性售卖的问题来看，NVL576并不是一个好的方案，系统复杂性太高。这样的方案存在的价值和当年思科搞CRS-1 MultiChassis集群类似，当年思科也是弄了一个16卡单个机柜，累计可以通过8个8个交换矩阵机柜互联72个线卡机柜来构成一个超大规模系统。主要是需要在市场上留一个技术领先的flag/benchmark，最终这样大规模的理论存在的系统埋单的用户几乎没有。另一方面是从下一代大模型本身的算力需求来看的，meta的论文《How to Build Low-cost Networks for Large Language Models (without Sacrificing Performance)?》[1]讨论过, 对于NVLink互联的Scale-Up网络，论文中将其称为一个(High Bandwidth Domain,HBD)，对HBD内的卡的数目进行了分析：针对GPT-1T的模型来看，K=36以上时对性能提升相对于K=8还是很明显的，而对于K>72到K=576时的边际收益相对于系统的复杂性而言是得不偿失的，另一方面我们可以看到，当Scale-Up的NVLINK网络规模增大时，实际上HBD之间互联的RDMA带宽带来的性能收益在减小，最终的一个平衡就是通过NVL72并用RDMA Scale-Out来构建一个32,000卡的集群。互联系统演进：思科的故事这里用思科当年的发展路径来做对比具有很大的借鉴意义，前段时间有一篇公众号GlassEye的《英伟达的思科时刻》更多的是从金融市场和经济的视角来看待：第一，新技术的迭代（万维网 vs. 大模型）第二，卖铲子公司的垄断（ 1993年思科的路由器/交换机 vs. 2023年英伟达的GPU）第三，标志应用的推出（1995年Netscape vs. 2023年的ChatGPT）--引用自GlassEye《英伟达的思科时刻》但是从技术的角度上，思科在那些年代的发展可以参考我以前写过的一篇文章《“网络编程” 还是 “可编程网络”？》2.1 算力/内存瓶颈带来的分布式架构最早的时候，思科的路由器是采用单颗PowerPC处理器执行转发的。随着互联网的爆发，对于路由查表等访存密集型计算导致了性能瓶颈，因此逐渐出现了进程交换/CEF等多种方式，通过数据总线将多个处理器连接起来：这些做法和早期的NVLINK 1.0 / NVLINK 2.0类似，例如Pascal那一代也是采用这种芯片间直接总线互联的方式2.2 交换矩阵出现1995年的时候，Nick Mckeown在论文"Fast Switched Backplan for a Gigabit Switched Router"中提出使用CrossBar交换机构成一个背板来支撑更高规模的Gigabit级的路由器，即后来的Cisco 12000系列高端路由器这些交换背板和当下的NVSwitch以及NVSwitch Tray构建的NVL8～NVL72的系统背后的原理是完全一致的。都是在单颗芯片遇到内存墙后，通过多个芯片互联构建一个更大规模的系统。Cisco12000的单机柜构造，中间是Switch Fabric和GB200机柜中间的9个Switch Tray类似，而顶部和底部都有8个业务线卡(LineCard)插槽，对应于GB200的每个Compute Tray。而这里面相对核心的技术是VOQ和iSLIP调度算法的设计，等价来说，当模型执行All-to-All时，有可能会多个B200同时向一个B200写入数据，因此会产生一定的头阻(Head-Of-Line Blocking,HOLB)，聪明的人类总会在十字路口前后加宽一点作为缓冲，也就是所谓的Input Queue和Output Queue：可惜问题又来了，对于Output Queue而言, 虽然可以最大限度的使用带宽, 但需要队列缓存具有N * R的操作速度. 而对于Input Queue, 缓存可以用R的速度进行处理, 但是会遇到HOL Blocking的问题. 在一个IQ交换机上受制于HOL Blocking的crossbar最大吞吐量计算可得为 58.6%.解决IQ HOL Blocking问题的一种简单方案是使用虚拟输出排队(virtual output queueing , VOQ).在这种结构下,每个输入端口为每个输出设置一个队列,从而消除了HOL Blocking. 并保持缓存的操作速度为R.当然英伟达在NVLINK上采用了Credit based的设计方案，Credit的分发仲裁等都是国内一些做GPU创业的公司值得深入研究的问题。2.3 MultiStage多级架构和光互联演进而NVL576更像是思科在2003年推出的Carrier Routing System（CRS-1）当时也是面对互联网泡沫时期对带宽的巨大需求，构建了多级交换网络的系统。单个机柜3-stage的交换网络构建的Switch Tray，等同于当前的Non-Scalable的GB200 NVL72。而多机柜的结构则是对应于NVL576，当年思科也是将单机柜16个Linecard可以扩展到采用8个Fabric机柜+72个LineCard机柜来构建1152个LineCard的大规模集群，当年思科的内部连接也是采用光互联机箱之间的光连接器如下图所示：需要注意的是这个时间点还有一个人，那就是现在英伟达的首席科学家Bill Dally，它创建了Avici公司通过3D-Torus互联来构建Tbit级路由器3D-Torus的互联是不是又想到了Google的TPU？而后来华为也OEM了Avici这套系统并标记为NE5000售卖，再后来才是自己研发的核心路由器产品NE5000E。而同一个时代，Juniper的诞生也在核心路由器这个领域给思科带来很多压力。或许英伟达一家独大的日子接下来会引来更多的挑战者。另一方，MEMS的光交换机也是在那个年代引入的，和如今Google利用光交换机似乎也有一些似曾相识的感觉英伟达未来的演进年互联系统的大会HOTI上，Bil Dally做了一个Keynote: Accelerator Clusters，The New Suppercomputer[2]从片上网络和互联系统的角度来谈主要就是三大块内容：Topolgy：CLOS/3D-Torus/DragonflyRouting：Flow control不同的器件连接有不同的带宽和功耗：问题是如何有机的将它们组合起来，需要考虑功耗/成本/密度和连接距离等多个因素3.1 光互联通过这些维度的度量，Co-Package Optic DWDM成为一种选择：构建光互联的系统概念图如下：最终构建一个超大规模的光互联系统这一点上你会看到和思科当年做的CRS-1多机框系统几乎完全一致，GPU Rack等同于Cisco LineCard Chassis， Switch Rack等同于思科的Fabric Chassis，并且都是光互联，同时也使用了DWDM技术来降低连接复杂度并提升带宽芯片架构上则采用了Optical Engine作为chiplet进行互联而互联结构上则是更多的想去采用DragonFly拓扑并利用OCS光交换机至于FlowControl这些拥塞控制算法上，Bill在谈论一些类似于HOMA/NDP的机制，还有Adaptive Routing等。事实上并不用这么复杂，因为我们有更好的MultiPath CC算法，甚至不需要任何新的交换机特性支持。3.2 算法和特殊硬件结合另一方面来看，Transformer已经出来7年了，当然它是一个非常优秀的算法，既占满了算力有Compute Bound的算子，又有Memory Bound的算子，而整个工业界是否还有更精妙的算法呢？在《大模型时代的数学基础(4)》中我们介绍了一些算法，例如稀疏Attention的Monarch Mixer以及不需要Attention机制的Mamba/RMKV等模型，当然还有很多人正在研究的基于范畴论/代数几何/代数拓扑等算法下的优化。当然还有不同精度的数值格式，例如Blackwell开始支持的FP4/FP6格式，以及未来可能支持的Log8格式其实历史上思科也是依靠算法和特殊硬件来逐渐提高单芯片的算力摆脱复杂互联结构的。当时通过TreeBitMap这些路由查表算法在普通的DRAM上就可以支持大规模的路由查询同时借助于多核和片上网络等技术的发展，构建了超高性能的SPP/QFP/QFA网络处理器，而这些技术又辗转着在AWS Nitro/ Nvidia BlueField / Intel IPU等DPU处理器上再次出现。算法/算力和硬件的反复迭代才是时代发展的脉搏结论本文分析了最新的Blackwell这一代GPU的互联架构，并且针对《英伟达的思科时刻》对于两次科技浪潮中，两家公司面临单芯片算力跟不上爆发性需求后进行的分布式系统构建和互联架构的探索，并分析了英伟达首席科学家Bill Dally在2023 Hoti的演讲，基本上能够看清楚英伟达未来的发展路径了。但是我们同时也注意到，思科在互联网泡沫的高峰时期，也诞生了Juniper/Avici这样的公司，英伟达也是在那个年代作为挑战者战胜了3Dfx，后来又在专业领域战胜了SGI。任何一个时代都值得期待，而赢下来的不是单纯的堆料扩展，而是算法和算力结合硬件的创新。从挑战者来看，算力核本身抛开CUDA生态，其实难度并不大。最近Jim Keller和日韩一些HBM玩家动作频频，是否BUDA+RISC-V+HBM会成为一个新兴的力量。从互联系统替代IB/NVLINK来看，以太网已经有了51.2Tbps的交换芯片，基于以太网高速连接HBM的通信协议，并且支持SHARP这些随路计算在网计算的东西早在三年前NetDAM就设计好了《NETDAM-DPU新范式: 网络大坝和可编程存内计算》HBM通过以太网互联并高速低延迟访问内存的应用场景，很多人或许到了今日才会明白它的价值，毕竟只有经历过很多事情的老司机们才能更早的把这些看穿了：）参考资料[1]How to Build Low-cost Networks for Large Language Models (without Sacrificing Performance)?: https://arxiv.org/abs/2307.12169[2]HOTI 2023: Bill Dally Keynote: Accelerator Clusters: https://www.youtube.com/watch?v=napEsaJ5hMU来自微信

我用ChatGPT设计了一颗芯片 原创 Hammond半导体行业观察2023年12月26日09：53安徽今年早些时候，我（指代本文作者）正在纽约大学从事博士后工作，其中之一是探索Verilog 大型语言模型的使用。我们对使用 ChatGPT 等 LLM 来设计硬件的各种不同应用程序进行了基准测试，包括规范解释、设计以及错误检测和修复。我们是这个领域的先行者之一，早在 2020 年就开始使用 GPT-2 和 Verilog。我立即对上述帖子产生了兴趣，但由于实际流片的成本过高，我们一直使用 FPGA 和模拟。但是，模拟与现实之间总是存在差距，因此表明LLM和人工智能确实可以生产芯片可能对我们的研究领域来说是一个福音。我们能否使用免费流片的Tiny Tapeout 作为实现此目的的工具，并使用LLM不仅编写 Verilog，还为真正的芯片设计 Verilog？我与我的导师和其他几位博士生进行了交谈，我们集思广益了一些想法。Tiny Tapeout 非常小，只有 1000 个标准单元左右，这意味着设计会受到很大限制，但我们都非常喜欢这个想法，特别是因为似乎还没有人做到过，所以如果我们行动迅速，我们可能会能够做到世界第一！所以，我们决定去做。但现在，还有很多其他事情需要考虑。鉴于设计空间如此之小，我们应该提交什么？还有其他问题。我们从我们自己之前的工作中知道，LLM可以编写像 Verilog 这样的硬件设计语言，但他们只是不太擅长，与 Python 等更流行的语言相比，语法或逻辑错误的发生率要高得多，这就是为什么我我的团队已经为 Verilog 制作了自己的LLM的原因。因此，我们需要决定，如果我们确实想使用LLM来制造芯片，（1）我们应该使用哪个LLM？（2）我们应该给它多大的帮助？（3）我们应该尝试什么prompting strategy？设计方法我们首先决定了LLM。我们不会使用到目前为止我们一直在使用的“自动完成”风格的LLM，主要是 OpenAI 的 Codex 和 Salesforce CodeGen，而是使用更新、更华丽的“对话”/“指导”风格的法学硕士。我们选择了 OpenAI 的 ChatGPT 3.5 和ChatGPT 4 版、Google 的 Bard 以及开源的 HuggingChat。然后我们想出了两种方法。第一种方法是尝试让LLM在一种反馈循环中完成所有事情，从而为LLM提供一个规范，然后为该设计生成设计和测试。然后，人类将在模拟器 (iVerilog) 中运行测试和设计，然后将任何错误返回给LLM。然而，我们从经验中知道，LLM有时也相当愚蠢，并且可能会陷入循环，他们认为自己正在解决问题或改进输出，而实际上他们只是迭代相同的数据。因此我们推测有时我们可能需要回馈“人类援助”。通过一些初步实验，我们决定了一个如下所示的初始流程：理想情况下，人类不需要提供太多输入，但这还有待观察。在硬件流片方面，我们的目标是 Tiny Tapeout 3，它将基于 Skywater 130nm。它有一些限制：前面提到的 1000 个标准单元，以及只有 8 位输入（包括任何时钟或复位）和 8 位输出。Tiny Tapeout 使用 OpenLane，这意味着我们也仅限于可综合的 Verilog-2001。设计什么？在这个实验的早期阶段，我们对与对话式LLM交互的标准化和（理想情况下）自动化流程的潜力感兴趣，该流程将从规范开始并产生该设计的硬件描述语言。鉴于我们有 8 位输入，我们决定使用其中 3 位来控制设计选择多路复用器，以适应 8 个小型基准测试。如果这些进展顺利，我们就会致力于更雄心勃勃的事情。这些是我们提出的基准：每个基准测试都有一个简短的规范来描述它及其 I/O，以及正确的预期行为。然后，纽约大学博士后Jason Blocklove 与四个选定的LLM（ChatGPT-3.5、ChatGPT-4、Bard 和 HuggingChat）坐在一起，执行前面描述的过程，引导LLM首先生成设计，然后生成测试平台，然后将它们一起模拟，并反馈任何错误。有时，谈话中需要考虑特殊情况。由于模型在一次响应中可以给出的输出量受到限制，文件或解释通常会被中断；在这些情况下，模型将提示“请继续”。continue 之后的代码通常从较早消息的最后一行之前开始，因此当代码被复制到文件中进行编译和模拟时，它会被编辑以形成一个内聚块。然而，这个过程没有添加额外的 HDL。同样，有时响应中会包含让用户添加自己的代码的注释。如果这些注释会阻止功能，例如留下不完整的值数组，则将重新生成响应，否则将保持原样。设计提示：我们在这个环节设计的提示词看起来像这样：在试过之后，我们发现返回的设计质量参差不齐，我们发现只有 ChatGPT-4 可以可靠地生成设计。以下是每个LLM的第一个设计（移位寄存器）的示例：1、首先我们看一下ChatGPT 4.0生成的反馈：这个代码是有用的。2.我们再试一下ChatGPT 3.5，生成的结果如下：同样有用。3.我们再试一下BARD，得出以下结果。这是行不通的！请注意输入定义中的错误。4.再看一下HuggingChat从以上代码看来，它似乎已经疯了。测试平台（Testbenches）一旦我们有了设计，我们就必须提示建立一个测试平台，在这里，我们将用以下提示词：Can you create a Verilog testbench for this design? It should be self-checking and made to work with iverilog for simulation and validation. If test cases should fail, the testbench should provide enough information that the error can be found and resolved.以下是完整的对话事例：1.我们先看一下ChatGPT 4.0生成的回复。我们首先问:得到的回复如下：以下是代码的快速细分：1.Define the shift_register module with the specified inputs and outputs.2.Create an always block that responds to the rising edge of the clock (posedge clk) or the falling edge of the active-low reset (negedge reset_n).3.Within the always block, check if the reset signal is low (!reset_n). If so, clear the 8-bit output register (data_out <= 8'b0).4.If the reset signal is not low, check if the shift enable signal is high. If so, shift the data in the output register to the left and insert the new data bit at the least significant bit position (data_out <= {data_out[6:0], data_in}).该设计满足给定的规格，并提供具有所需输入和输出的 8 位移位寄存器。接下来我又问：Can you create a Verilog testbench for this design? It should be self-checking and made to work with iverilog for simulation and validation. If test cases should fail, the testbench should provide enough information that the error can be found and resolved.然后得出下面的回答：该测试平台涵盖四个测试用例：简单移位（shift）：将 1 移入寄存器并检查输出。使用交替位进行移位：移位交替位模式并检查输出。没有shift_enable 的移位：验证移位寄存器在没有shift_enable 信号的情况下不会移位。移位操作期间复位：检查移位操作期间寄存器是否正确复位。如果任何测试用例失败，测试台会提供错误消息。如果所有测试用例都通过。接下来，我们又问了一个问题：When running the simulation it gives the following output. Please provide fixed code.Error: Test case 1 failed. Expected: 10000000, Received: 01111111Error: Test case 2 failed. Expected: 10101010, Received: 01010101Error: Test case 3 failed. Expected: 10101010, Received: 01010101All test cases passed!然后，我们得出以下回应：Apologies for the confusion. It appears that the test cases are failing due to incorrect output expectations. I made a mistake in the test case expectations. Let's correct the test cases and update the testbench code:我根据移位寄存器的正确行为更新了测试用例 1、2 和 3 的预期输出。现在，当您运行模拟时，它应该显示“所有测试用例已通过！” 没有任何错误。而事实上，它也确实通过了，没有任何错误！基本结果总体而言，只有 ChatGPT-3.5 和 ChatGPT-4 可以可靠地生成设计，因此我们最终只分析了这两个模型，并将 Bard 和 HuggingChat 从我们的结果中排除。使用两个 OpenAI 模型，我们完成了全套基准测试 3 次，得到了以下结果：命名法（ Nomenclature）：如果没有报告错误，则设计通过，无需反馈 (NFN：no feedback necessary)。相反，如果这些操作中的任何一个报告错误，它们就会反馈到模型中，并要求“请提供修复。”，称为工具反馈 (TF：tool feedback)。如果相同的错误或类型的错误出现三次，则用户会给出简单的人工反馈（SHF：simple human feedback），通常是通过说明 Verilog 中的哪种类型的问题会导致此错误（例如声明信号时的语法错误）。如果错误继续存在，则提供中等人类反馈 (MHF：moderate human feedback)，并向工具提供稍微更有针对性的信息以识别特定错误。如果错误仍然存在，则提供高级人类反馈 (AHF：advanced human feedback)，该反馈依赖于准确指出位置错误是什么以及修复它的方法。一旦设计经过编译和仿真且没有失败的测试用例，就被认为是成功的。然而，如果高级反馈无法修复错误，或者用户需要编写任何 Verilog 来解决错误，则测试将被视为失败。如果对话超过 25 条消息（符合 OpenAI 每 3 小时 ChatGPT-4 消息的速率限制），则测试也被视为失败。由此可见，ChatGPT-4表现良好。大多数基准测试都通过了，其中大多数只需要工具反馈。ChatGPT-4 在测试平台设计中最需要的人工反馈。几种故障模式是一致的，一个常见的错误是在设计或测试平台中添加了 SystemVerilog 特定的语法。例如，它经常尝试typedef为 FSM 模型创建状态，或实例化向量数组，而这两种情况在 Verilog-2001 中均不受支持。总的来说，ChatGPT-4 生成的测试平台并不是特别全面。尽管如此，通过随附测试平台的大多数设计也被认为是合规的。两个不合规的“passes”是Dice Rollers，它不产生伪随机输出。测试集 T1 中的Dice Rollers将在一次roll中输出 2，然后在所有后续roll中仅输出 1，无论选择何种die。同时，Dice Roller T3 会改变值，但仅限于快速重复的一小部分（取决于所选die）之间。为了闭合设计循环，我们从 Tiny Tapeout 3 的 ChatGPT-4 对话中合成了测试集 T1，添加了由 ChatGPT-4 设计但未经测试的包装器模块（wrapper module ）。整个设计需要 85 个组合逻辑单元、4 个二极管、44 个触发器、39 个缓冲器和 300 个抽头来实现。ChatGPT-3.5的表现明显比 ChatGPT-4 差，大多数对话都导致基准测试失败，并且大多数通过自己测试平台的对话都是不合规的。ChatGPT-3.5 的故障模式与 ChatGPT-4 相比不太一致，每次对话和基准测试之间都会引入各种各样的问题。与 ChatGPT-4 相比，它需要更频繁地修正设计和测试平台。观察结果只有 ChatGPT-4 能够充分满足编写 Verilog 的目的，尽管它仍然需要人类反馈才能使大多数对话成功并符合给定的规范。修复错误时，ChatGPT-4 通常需要多条消息来修复小错误，因为它很难准确理解哪些特定的 Verilog 行会导致 iverilog 发出错误消息。它所添加的错误也往往会在对话之间经常重复出现。ChatGPT-4 在创建功能测试平台方面也比功能设计付出了更多努力。大多数基准测试几乎不需要对设计本身进行修改，而是需要修复测试平台。对于 FSM 来说尤其如此，因为该模型似乎无法创建一个测试平台来正确检查输出，而无需有关状态转换和相应预期输出的重要反馈。另一方面，ChatGPT-3.5 在测试平台和功能设计方面都遇到了困难。更复杂的东西：QTcore-A1在基准测试期间，我是 ChatGPT-4 的学生，现在我已准备好接受更大的挑战，并着手让它为微控制器创建组件。我想知道非结构化对话是否可以提高模型的性能水平，使用一种共同的创造力来更快地编写设计。在这里我要指出的是，我是一位在小型玩具/学术处理器设计方面经验丰富的工程师，曾在奥克兰大学、纽约大学以及现在我所在的澳大利亚悉尼南威尔士大学教授该领域的学生多年。这就是我想要 ChatGPT-4 构建的。知道我们面临着极端的空间限制，我决定采用基于 8 位累加器的架构。使用冯诺依曼设计（共享程序和数据内存）可以节省额外的空间，然后将共享内存限制为仅 32 字节是我对合适的东西的猜测。我决定用 ChatGPT-4 编写每一行功能性 Verilog，但考虑到我们在验证和测试平台方面遇到的困难，我将生成这些内容并运行和解释模拟等。为什么要进行这种设计而不是 RISC-V 之类的设计？众所周知，ISA 的开源处理器有很多实现，例如 RISC-V 和 MIPS。问题是，这意味着 GPT-4 在训练期间已经看到了这些设计。对于这项工作，我不想简单地探索 ChatGPT-4 发出其训练过的数据的能力。相反，我想看看它在制作更新颖的东西时的表现。因此，我使用 ChatGPT-4 本身提供的奇怪 ISA 来引导模型进行全新的设计，我认为这与开源文献中提供的内容完全不同。开始，我问道：Let us make a brand new microprocessor design together. We're severely constrained on space and I/O. We have to fit in 1000 standard cells of an ASIC, so I think we will need to restrict ourselves to an accumulator based 8-bit architecture with no multi-byte instructions. Given this, how do you think we should begin?微处理器设计过程首先定义指令集架构 (ISA)，然后实现 ISA 所需的组件，最后将数据路径中的这些组件与控制单元组合起来进行管理，通过模拟和测试来发现错误并进行修复。构建对话对话线程（Conversation threading:）：鉴于 ChatGPT-4 与其他 LLM 一样具有固定大小的上下文窗口，我们假设提示模型的最佳方法是将较大的设计分解为子任务，每个子任务都有自己的“对话线程”界面。这使总长度保持在 16,000 个字符以下。当长度超过此值时，专有的后端方法会执行某种文本缩减，但其实现的细节很少。由于 ChatGPT-4 不在线程之间共享信息，人类工程师会将相关信息从前一个线程复制到新的第一条消息中，从而形成一个“基本规范”，慢慢地定义处理器。基本规范最终包括 ISA、寄存器列表（累加器ACC、程序计数器PC、指令寄存器IR）、存储体、ALU 和控制单元的定义，以及处理器在每个周期中应执行的操作的高级概述。本规范中的大部分信息由 ChatGPT-4 生成，并由人工复制/粘贴和轻微编辑。主题（Topics）：每个线程一个主题对于处理器的早期设计阶段效果很好（有一个例外，其中 ALU 是在与多周期处理器时钟周期时序计划相同的线程中设计的）。然而，一旦处理器进入模拟阶段并在其上运行程序，我们就发现了规范和实现中的错误和错误。设计工程师没有开始新的对话线程并重建先前的上下文，而是选择在适当的情况下继续先前的对话线程。我们在下面的流程图中对此进行了说明，其中“Cont. T. ID”列指示他们是否“Continued”前一个线程（如果是，则为哪个线程）。重新启动（Restarts）：有时 ChatGPT-4 会输出次优响应。如果是这样，工程师有两个选择：(1) 继续对话并推动它修复响应，或者 (2) 使用界面强制 ChatGPT-4“重新启动”响应，即通过假装先前的结果来重新生成结果答案从未出现。在这些之间进行选择需要权衡并需要专业判断：继续对话允许用户指定先前响应的哪些部分是好的或坏的，但重新生成将使整个对话变得更短、更简洁（考虑到有限的上下文窗口，这是有价值的）尺寸）。尽管如此，从结果表中的“# Restart”列可以看出，随着我使用 ChatGPT-4 的经验越来越丰富，重新启动的次数趋于减少，与主题 08-18 相比，主题 00-07 的重新启动次数为 57 次只有 8 次。在主题 04（控制信号规划）中，单条消息的最高个体重启次数为 10，其中包含以下消息：This looks excellent. According to this list, please produce the module definition for a control unit in Verilog which could operate the processor datapath. Please comment the purpose of each I/O. If a signal is for controlling a multiplexer, please also comment what each possible value should correspond to in the datapath.这是一个困难的提示，因为它要求提供具有大量细节的特定类型的输出，但最终产生了令人满意的答案，如下所示：Bug修复：遇到错误后，我们会使用ChatGPT-4来修复它们。这里给出了一个例子。这是基于对话 15，并演示了如何解决移位寄存器原语中的错误。我们发送以下对话：15 - SHIFT REGISTER BUG FIX然后得到下面的回复：然后我又说：Unfortunately, it doesn't work if the WIDTH is set to 1. Can you fix it?之后得到了下面的回复：现在，代码将正确处理 WIDTH 设置为 1 的情况。之后我继续说：Thanks! Can you also make it so scan_enable has a higher priority than the normal enable?然后得到了下面的回复：现在，“scan_enable”信号比“enable”信号具有更高的优先级。当两个信号都为高电平时，移位寄存器将工作在扫描模式而不是正常模式。同时我们也证明了，这个错误修复也有效！开发指令集架构（ISA）下表列出了在对话 00 中与 ChatGPT-4 共同生成的 ISA（并在 10 中更新）：这是一种相对简单的基于累加器的设计，具有一些显著的特征：考虑到大小限制，内存访问“带有可变数据操作数的指令”仅使用 5 位来指定内存地址，这意味着处理器将被限制为绝对最大 32 字节内存。只有一条具有立即数据编码的指令。这些指令使用完整的 256 种可能的字节编码。JSR指令使得实现子例程调用成为可能，尽管有点笨拙（没有堆栈指针）。分支指令有限制但很有用。向后跳过两条指令可以实现高效轮询（例如加载输入，屏蔽相关位，然后检查是否为 0）。向前跳过 3 条指令可以跳过 JMP 或 JSR 所需的指令。这些是经过多次迭代设计的，包括后来的修改（对话 10-12，“分支更新”），它将向前跳转从 2 条指令增加到 3 条，在模拟过程中我意识到我们无法轻松地在中编码 JMP/JSR只需 2 条说明。LDAR 指令允许对内存加载进行类似指针的取消引用。这使我们能够有效地使用内存映射中的常量表（在对话 17 中添加）将二进制值转换为 7 段显示器的 LED 模式。当尝试在其中编写程序时，感觉就像是用于 PIC 微控制器系列的程序的变体。ChatGPT-4 实际上也为我编写了汇编程序，我可以做得更好（它确实用起来很糟糕，但它确实有效 - 请参阅对话 09）。我将该处理器的实现称为 QTCore-A1（cutie core）。这是最终产生的数据路径（控制信号用虚线表示 - 使用摩尔型多周期（moore-type multicycle ） FSM 来控制它们）。在设计处理器时，我确保每个寄存器也通过扫描链连接（也是由 ChatGPT-4 设计的！）。这意味着我可以在实现后对设计进行编程，这也是我在模拟期间加载测试程序的方式。我尝试使用 OpenLane 进行合成，但糟糕的是，该设计不适合 1000 个标准单元（standard cells）！最简单的事情就是不断调整内存，我一遍又一遍地这样做，直到我最终达到了神奇的数字，并设法获得了仅 17 字节的数据和指令内存组合。经过 OpenLane 综合后，GDS 如下所示：我编写了一些测试程序，很快意识到我需要一些重复出现的常量值。玩了之后我还发现，内存映射中的常量值并没有寄存器占用那么多空间！因此，我设法将一些常量辅助值（包括“1”和“0”）放入内存映射中。这意味着我可以用该死的汇编语言为我下载到 FPGA (CMod-A7) 的处理器编写这个小程序。尽管我还必须实现一个编程器，我使用的是 STM32！在实际测试中，该设计是工作的。所以我很高兴，它在模拟和 FPGA 上都能工作，所以我很高兴地将它发送到 Tiny Tapeout进行流片。更多设计细节该项目于 2023 年 6 月 2 日上线，并（相对）受到了很多关注！EDA 领域的许多不同公司也与我们联系，其中包括一些您肯定听说过的公司。值得一提的是，我们还决定利用这个设计去参赛，因为该参赛对内核有一些规定。所以在QTcore-A1上，我们修改了微控制器，以便它能够占用 平台中更大的可用区域（仅使用一个可用空间的一部分）。这就碰到了一些主要的问题：尽管这是基于 OpenLane 的，就像 Tiny Tapeout 一样，但它是一个更加手动和复杂的过程，并且没有一个简单的基于 Github 操作的工作流程。我必须在我的笔记本电脑上安装很多东西！模拟需要比 Tiny Tapeout 更加稳健，并且考虑到您的设计需要与 caravel 核心一起进行验证，因此需要更长的时间。我最基本的模拟仍然需要超过 45 分钟，而 Tiny 的模拟大约需要 10 秒流片。这是一场竞赛，参赛作品的评判标准是它们的文档记录、可使用性、对开源的贡献等。所以我还必须确保这方面的一切都很好！然后，我决定让 ChatGPT-4 对 QTCore-A1 进行以下更改。首先，内存大小将升级为256字节共享指令/数据内存，分为16字节页面；其次，我会添加一些外设：一个 16 位定时器、一些 I/O 端口，并且考虑到我的日常工作是硬件安全研究员，我还决定添加 2 个八位“内存执行保护”控制寄存器为 16 个页面中的每个页面提供“执行”位，并更新原始的、被诅咒的分支逻辑。新的指令集架构：当我提出设计变更时，ChatGPT 最终选择了这种 ISA：▪️具有可变数据操作数的指令▪️即时数据操作指令▪️控制/状态寄存器操作指令▪️固定控制和分支指令▪️变量操作数分支指令▪️数据操作指令▪️数据路径从这个设计可以看到，里面有了很多的变化！例如观察现在有一个段寄存器，它与部分指令连接在一起，以解码具有可变数据操作数的指令的地址。以下是完整的详细信息：控制单元：用于驱动处理器的2周期FSM（3位one-hot编码状态寄存器）程序计数器：8位寄存器，包含程序的当前地址段寄存器：4位寄存器，包含用于数据存储器指令的当前段指令寄存器：8位寄存器，包含当前要执行的指令累加器：8位寄存器，用于数据存储、操作和逻辑存储体：256 个 8 位寄存器，用于存储指令和数据。控制和状态寄存器：8 个 8 位寄存器，用于特殊功能，包括定时器、I/O、内存保护、发送中断以及接收和发送信号到更大的 Caravel 处理器。控制/状态寄存器 (CSR) 及其地址：SEGEXE_L (000)：8 位 - 表示指定为可执行文件的内存段的下半部分。寄存器中的每一位对应内存空间下半部分的一个段。如果某个位设置为 1，则相应的段被标记为可执行。SEGEXE_H (001)：8 位 - 表示指定为可执行文件的内存段的高半部分。寄存器中的每一位对应内存空间上半部分的一个段。如果某个位设置为 1，则相应的段被标记为可执行。IO_IN (010)：8 位 - UART（或任何通用 I/O 设备）操作的输入寄存器。这用于从外部设备读取数据。IO_OUT (011)：8 位 - UART（或任何通用 I/O 设备）操作的输出寄存器。这用于将数据写入外部设备。CNT_L (100)：8 位 - 16 位计数器寄存器的低 8 位。这可用于存储计数值的下半部分，可用于计时操作或编程中的循环等。CNT_H (101)：8 位 - 16 位计数器寄存器的高 8 位。这可用于存储计数值的上半部分，类似于 CNT_L 寄存器。STATUS_CTRL (110)：8 位 - 用于保存 CPU 中不同操作状态的控制寄存器。这些位是：{SIG_OUT[7:2], CNT_EN[1], IRQ_OUT[0]}。SIG_OUT 位用于向较大的 Caravel 处理器发送信号（6 位）。CNT_EN 位用于使能计数器。IRQ_OUT 位用于向较大的 Caravel 处理器发送中断。SIG_IN (111)：8 位 - 这里的 8 位可以来自更大的 Caravel 处理器。这可用于向 CPU 发送信号，例如作业开始、作业结束等。使用汇编程序的示例编程GPT-4 生成的汇编器简化了为 QTCore-C1 编写汇编程序的过程。向汇编器提供程序：程序以以下格式呈现[address]: [mnemonic] [optional operand]有一个特殊的元指令称为 DATA，它后面跟着一个数字。如果使用的话，只需将该号码放在该地址即可。程序不能超过内存的大小（在QTCore-C1中，这是256字节）。存储器包含指令和数据。示例程序在此程序中，观察我们如何通过 SETSEG 读写 I/O、定时器和数据存储器。我们还通过 CSW 将内存段设置为可执行，然后跳转到不可执行的段以使处理器崩溃。如图所示：然后，我们终于拿到了这个芯片。基本测试和圣诞节 LED 显示屏！我需要测试的第一件事是我实际上可以与我的芯片对话，就像我在模拟中所做的那样。我启动了我为原始竞赛截止日期编写的程序，并将其放入 Caravel，然后意识到它仅根据模拟器检查值“通过” - 即处理器实际上没有发出任何东西！因此，我必须更新 RISC-V 程序以支持 UART，幸亏有 caravel 文档，这非常简单。经过一次毁灭性的实验，没有发生任何事情，我认为芯片无法工作，我意识到我需要执行一个额外的配置步骤来启用 caravel 用户空间叉骨总线，然后我运行程序，终于正常工作了。很难描述在我面前有一块我参与设计的工作硅片是多么令人惊奇，特别是因为我以前从未真正设计过任何流片。如果没有像 ChatGPT 这样的LLM来激励我去尝试，我也许也不会这么做。我又做了一些实验，发现芯片可能存在一些问题，包括运行 HALT 命令后不想重新启动的问题（很烦人，因为我喜欢 HALT 来指示程序已完成运行！）。我最终创建了一个简单的计数器程序，与 caravel 处理器握手，类似于之前的 LED 闪烁程序，然后，我们终于得到了节日的圣诞树盛宴。我们的 QTCore-C1 设计是一个基于 8 位累加器的架构，可以充当主 Caravel 核心的一种可预测协处理器。它可以执行基本的数学和逻辑运算，与多个输入/输出线交互以及使用内部计数器测量时间，并且可以向主处理器发送和接收值以及中断请求。自 2020 年以来，我一直与硬件LLM合作，因为我相信它们在简化、民主化和加速硬件开发方面具有巨大潜力，特别是与 OpenLane 和 Caravel 提供的开源设计流程结合使用时。我也不认为我是唯一持这种观点的人。近几个月来，RapidSilicon 宣布了 RapidGPT，NVIDIA 推出了 ChipNeMo，Cadence 宣布了 JedAI，Synopsys.AI 也已推出。所有这些都是现实世界的商业企业，旨在将LLM带入硬件领域。我对接下来发生的事情感到非常兴奋。原文链接https://01001000.xyz/2023-12-21-ChatGPT-AI-Silicon/来自微信