随着数字设计的能力和复杂性不断增长，集成电路（IC）计算机辅助设计（CAD）中的软件组件在整个电子设计自动化流程中都采用了机器学习（ML）。在传统方法试图对每个过程进行形式化建模的情况下，基于ML的方法侧重于识别和利用可推广的高级特征或模式——这意味着ML可以增强甚至取代某些工具。尽管如此，IC CAD中的ML研究往往侧重于后端过程，如逻辑综合、布局、走线和属性估计。在这项工作中，我们探索了将一种新兴类型的ML模型应用于硬件设计过程的早期阶段时的挑战和机遇：硬件描述语言（HDL）本身的编写。

虽然硬件设计是用规范语言（HDL）表示的，但它们实际上是以自然语言提供的规范（例如英语需求文件）开始设计生命周期的。将这些转换为适当的HDL（例如Verilog）的过程必须由硬件工程师完成，这既耗时又容易出错。使用高级综合工具等替代途径可以使开发人员能够用C等高级语言指定功能，但这些方法是以牺牲硬件效率为代价的。这激发了对基于人工智能（AI）或ML的工具的探索，使其作为将规范转换为HDL的替代途径。

这种机器翻译应用程序的候选者来自GitHub Copilot等商业产品推广的大型语言模型（LLM）。LLM声称可以用多种语言生成代码，以用于各种目的。尽管如此，它们还是更加专注于软件，这些模型的基准测试针对Python等语言对它们进行评估，而不是针对硬件领域的需求。因此，硬件设计社区的使用仍然落后于软件领域。尽管“自动完成”风格模型的基准测试步骤已经开始出现在文献中，但最新的LLM，如OpenAI的ChatGPT和谷歌的Bard，为其功能提供了一个不同的“对话式”聊天界面。

因此，我们提出了以下问题：将这些工具集成到HDL开发过程中的潜在优势和障碍是什么（图1）？我们做了两个对话实验。第一个实验涉及预定义的对话流和一系列基准挑战（第三节），而第二个实验涉及开放式的“自由聊天”方法，LLM在更大的项目中担任联合设计师（第四节）。

图1 会话LLM可以用于迭代设计硬件吗？

为了理解这项新兴技术的重要性，进行这样的研究至关重要。ChatGPT在医疗保健、软件和教育等各个领域也在进行类似的研究。我们对会话LLM对硬件设计的影响的调查是很有必要的。

本研究的贡献包括：

• 对会话LLM在硬件设计中的使用进行了首次研究。

• 制定基准以评估LLM在功能硬件开发和验证方面的能力。

• 利用ChatGPT-4对硬件中复杂应用程序的端到端协同设计进行观察性研究。

• 首次使用人工智能为流片编写完整的HDL，实现了一个重要的里程碑。

• 为在硬件相关任务中有效利用LLM提供实用建议。

开源：所有基准测试、流片工具链脚本、生成的Verilog和LLM对话日志都在Zenodo上提供。

大型语言模型（LLM）是用Transformer体系结构构建的。早期的例子包括BERT和GPT-2，但直到GPT-3系列模型，这些模型的相对能力才变得明显。其中包括Codex，它拥有数十亿的学习参数，并在数百万个开源软件存储库上进行了训练。在最先进的技术中，有几十种LLM（包括开源、非开源和商业），可用于通用和特定任务的应用程序。

尽管如此，所有LLM都有一些共同点。它们都充当“可伸缩序列预测模型”，这意味着给定一些“输入提示”，它们将输出该提示的“最有可能”的延续（将其视为“智能自动完成”）。对于此I/O，它们使用令牌，即使用字节对编码指定的常见字符序列。这很有效，因为LLM具有固定的上下文大小，这意味着它们可以提取比通过对字符进行操作更多的文本。对于OpenAI的模型，每个令牌代表大约4个字符，其上下文窗口的大小最多可达8000个令牌（这意味着它们可以支持大约16000个字符的I/O）。

Pearce等人首次探索了在硬件领域使用LLM。他们在综合生成的Verilog片段上微调了GPT-2模型（他们称之为DAVE），并对“本科生级别”任务的模型输出进行了词法评估。然而，由于训练数据有限，该模型无法推广到不熟悉的任务。Thakur等人扩展了这一想法，探索了如何严格评估生成Verilog的模型性能，以及使用不同的策略来训练Verilog编写模型。其他工作探究了这些模型的含义：GitHub Copilot研究了Verilog代码中6种类型硬件错误的发生率，当探讨是否可以使用Codex模型实现自动错误修复时，他们还包括Verilog中的两个硬件CWE。

在这个行业，人们对此的兴趣也越来越强烈：Efabless最近启动了人工智能生成设计大赛，评委来自高通和新思等公司。RapidSilicon等新公司正在推广RapidGPT等即将推出（但尚未发布）的工具，这些工具将在该领域发挥作用。

最近，一种新的训练方法——“基于人类反馈的强化学习（RLHF）”被应用于LLM。通过将其与特定意图的标记数据相结合，可以生成更能遵循用户意图的指令调优模型。如果以前的LLM侧重于“自动完成”，则可以对其进行“遵循说明”的训练。还有一些研究提出的方法不需要人类反馈，然后可以对它们进行微调，以便更好地关注对话式的互动。ChatGPT（包括ChatGPT-3.5和ChatGPT-4版本）、Bard和HuggingChat等模型都使用这些技术进行了训练。它们为硬件领域的工作提供了一个令人兴奋的新的潜在接口。然而，据作者所知，目前还没有人深入探索过这种应用。

从本质上讲，有无数种方法可以与会话模型“聊天”。为了探索使用会话LLM实现“标准化”和“自动化”流程的潜力，我们在一系列基准上定义了一个严格的“脚本化”会话流程。然后，我们使用一致的指标评估一系列LLM，根据通过附带testbench所需的指令水平来确定对话的相对成功或失败。然而，尽管对话流在结构上保持相同，但它在测试运行之间固有地存在一些变化，这是基于评估者需要决定（a）每个步骤中需要什么反馈以及（b）如何标准化人工反馈。

对话流程：图2详细介绍了与LLM进行对话以创建硬件基准的一般流程。图3和图4中详细说明的初始提示首先提供给该工具。然后对输出设计进行视觉评估，以确定其是否符合基本设计规范。如果设计不符合规范，则会以相同的提示重新生成最多五次，之后如果仍然不符合规范则会失败。

图2 简化的LLM对话流程图

图3  8位移位寄存器：设计提示

图4  testbench提示

设计和testbench编写完成后，将使用Icarus Verilog（iverilog）进行编译，如果编译成功，则进行模拟。如果没有报告错误，则设计通过而不需要反馈（NFN）。如果这些操作中的任何一个报告了错误，它们会被反馈到模型中，并被要求“请提供修复”，称为工具反馈（TF）。如果相同的错误或错误类型出现三次，则用户通常会给出简单的人工反馈（SHF），说明Verilog中的哪种类型的问题会导致此错误（例如，声明信号时的语法错误）。如果错误持续存在，则会给出适度的人工反馈（MHF），并向工具提供稍微更有针对性的信息来识别特定错误，如果错误持续，则会提供高级人工反馈（AHF），该反馈依赖于准确指出错误的位置和修复错误的方法。一旦设计在没有失败测试用例的情况下进行编译和模拟，它则被认为是成功的。然而，如果高级反馈无法修复错误，或者用户需要编写任何Verilog来解决错误，则该测试被视为失败。如果会话超过25条消息，与每3小时ChatGPT-4消息的OpenAI速率限制相匹配，则该测试也被视为失败。

在对话中需要考虑到特殊情况。由于一个模型在一次响应中输出量的限制，文件或解释往往会被切断；在这些情况下，模型将提示“请继续”。“继续”后面的代码通常从前面消息的最后一行之前开始，因此当代码被复制到文件中进行编译和模拟时，它被编辑以形成一个内聚块。然而，没有为该过程添加额外的HDL。类似地，在某些情况下，响应中包含了供用户添加自己代码的注释。如果这些注释会阻止功能，例如留下不完整的数组，则会重新生成响应，否则会保持原样。

功能提示：这个一致且对话风格的提示构建如下：“我正在尝试为[测试名称]创建一个Verilog模型。”然后模型将提供规范，定义输入和输出端口，以及所需的任何进一步细节（例如序列生成器将产生的预期序列），然后是备注“我该如何编写符合这些规范的设计？”。图3显示了8位移位寄存器的设计提示，该寄存器被用作每个LLM的初始评估。

验证提示：对于所有设计，testbench提示（图4）保持不变，因为请求testbench不需要包含关于创建的设计的任何附加信息。这是因为testbench提示将遵循LLM生成的设计，这意味着他们可以考虑所有现有的会话信息。它要求所有testbench都与iverilog兼容，以便于模拟和测试，并有助于确保只使用Verilog-2001标准。

这项工作旨在研究会话生成大语言模型在现实世界硬件设计中的应用，该模型具有综合、预算和流片输出限制。因此，在这个项目中，我们瞄准了现实世界平台Tiny Tapeout 3。这增加了设计的限制：具体来说，是对IO的限制——每个设计只允许8位输入和8位输出。由于标准挑战基准测试的目标是同时实现几个，因此为多路复用器保留了3位输入，以选择哪个基准测试的输出。这意味着每个基准只能包括5位输入，包括时钟和重置。

Tiny Tapeout工具流依赖于OpenLane，这意味着我们仅限于可合成的Verilog-2001 HDL。相对较小的区域虽然不是挑战基准的主要问题，但确实影响了处理器的组件和接口（第四节）。

针对这一挑战的基准测试旨在深入了解不同LLM可以编写的硬件级别。目标功能通常在硬件中实现，并且通常在本科生数字逻辑课程的水平上教授。基准见表一。

表一 基准描述

一些基准测试在初始设计之外有自己的特定要求，以帮助检查LLM如何处理不同的设计约束。序列生成器和检测器都被分别赋予了它们的特定模式来生成或检测，ABRO使用一个热态编码，LFSR具有特定的初始状态和抽头位置。其他基准测试，如移位寄存器，保持最低限度的描述性，以注意在约束较少的情况下，模型的输出是否存在任何模式。

我们评估了四种不同的会话LLM在创建用于硬件设计的Verilog方面的熟练程度，如表II所示。作为初始测试，这些模型中的每一个都被提示了8位移位寄存器基准提示，目的是继续进行第III-B节中的会话流程。每个LLM对设计提示的响应如图5、6、7和8所示。

表二 已评估的会话LLM

图5 来自ChatGPT-4的8位移位寄存器尝试。

图6 来自ChatGPT-3.5的8位移位寄存器尝试。

图7 巴德的8位移位寄存器尝试。第4行的输入太宽。

图8 HuggingChat的8位“移位寄存器”

（截断，格式化）。

这些测试中的每一项都被视为完整会话流的开始，因此，尽管两个ChatGPT模型都能够满足规范并开始通过设计流，但Bard和HuggingChat都未能满足规范的初始标准。根据计划的对话流程，对Bard和HuggingChat最初提示的响应被重新生成了五次，但都一再失败。Bard一直未能满足给定的设计规范，HuggingChat的Verilog输出在模块定义后的语法上也不正确。图7和图8代表了这两个模型的最终尝试。

鉴于Bard和HuggingChat在最初的Challenge Benchmark提示中表现不佳，我们决定继续进行仅针对ChatGPT-4和ChatGPT-3.5的全套测试，这两个测试都能够持续进行对话流。对于整套基准测试，我们运行了三次这些对话，因为LLM是不确定的，并且能够对相同的输入提示做出不同的响应。因此，这种重复提供了一个基本的衡量标准，即他们能够在多大程度上一致地创建不同的基准和testbench，以及在给定相同初始提示的情况下，不同的运行在实现中会有多大差异。

合规与不合规设计：考虑到语言模型创建了功能代码和验证testbench，当设计“通过”testbench时，它可能仍然“不符合”原始规范。因此，我们将每个结果总体上标记为“符合”或“不符合”。

图9为移位寄存器T1提供了与ChatGPT-4对话的剩余部分的示例。为了简洁起见，我们删除了响应中不相关的部分。这个对话流遵循图3中的初始设计提示、图5中返回的设计以及图4中的testbench提示。

（a）有错误的8位移位寄存器testbench部分

（b）8位移位寄存器的工具反馈提示

(c) 已更正部分testbench代码。替换的值加粗/突出显示。

图9 成功移位寄存器T1与ChatGPT-4对话的剩余部分。设计符合要求。

不幸的是，它生成的testbench包含错误的跟踪（相关部分如图9a所示）。模拟时，这将打印错误消息。使用图9b中的消息将这些消息返回给ChatGPT-4。这将提示ChatGPT-4修复testbench，给出图9c中的代码。错误得到了解决，设计和testbench现在相互验证，这意味着满足了会话设计流标准。此外，人工审核显示移位寄存器符合原始规范。

所有聊天日志都在数据存储库中提供。表III显示了使用ChatGPT-4和-3.5运行的脚本基准测试的三个测试集的结果。

表III基准挑战结果

ChatGPT-4表现良好。大多数基准测试都通过了，其中大多数只需要工具反馈。ChatGPT-4在testbench设计中最常需要人工反馈。

几种故障模式是一致的，一个常见的错误是在设计或testbench中添加了SystemVerilog特定的语法。例如，它通常会尝试使用typedef为FSM模型创建状态，或实例化向量数组，这两种方法在Verilog-2001中都不受支持。

总的来说，ChatGPT-4生产的testbench并不是特别全面。尽管如此，通过其配套testbench的大多数设计也被认为是符合要求的。两次不合规的“通过”是掷骰子机，没有产生伪随机输出。为了结束设计循环，我们从Tiny Tapeout 3的ChatGPT-4对话中合成了测试集T1，添加了一个由ChatGPT--4设计但未测试的包装器模块。在所有的设计中，需要85个组合逻辑单元、4个二极管、44个触发器、39个缓冲器和300个抽头来实现。

ChatGPT-3.5：ChatGPT-3.5的表现明显比ChatGPT-4差，大多数对话都导致了基准测试失败，而通过自己testbench的大多数对话都是不合规的。与ChatGPT-4相比，ChatGPT-3.5的故障模式不太一致，每次对话和基准测试之间都会出现各种各样的问题。它比ChatGPT-4更经常地需要对设计和testbench进行修改。

在使用挑战基准测试的四个LLM中，只有ChatGPT-4表现良好，尽管大多数对话仍然需要人工反馈才能成功并符合给定的规范。在修复错误时，ChatGPT-4通常需要几条消息来修复小错误，因为它很难确切了解是什么特定的Verilog行会导致来自iverilog的错误消息。它会添加的错误也往往会在对话之间重复出现。

与功能设计相比，ChatGPT-4在创建功能testbench方面也困难得多。大多数基准测试几乎不需要对设计本身进行修改，而是需要对testbench进行维护。FSM尤其如此，因为该模型似乎无法创建一个testbench，在没有关于状态转换和相应预期输出的重要反馈的情况下，该testbench将正确检查输出。另一方面，ChatGPT-3.5在testbench和功能设计方面都很吃力。

现实世界中的硬件设计将比我们在第三节中调查的要求更广泛、更复杂。考虑到以前使用的方法，这是一个挑战，因为它对人类与LLM交互的方式进行了脚本化和限制。然而，鉴于不同级别的人类反馈相对成功，我们试图调查非结构化对话是否可以提高效率和相互创造力。一般来说，这项研究将通过大规模的用户研究来完成，硬件工程师将在开发过程中与该工具配对。这类研究是在LLM的软件领域进行的，例如谷歌的这个例子，它将其专有LLM与超过一万名软件开发人员配对，并发现对开发人员的生产力产生了可衡量的积极影响（将其编码迭代持续时间减少了6%，上下文切换次数减少了7%）。我们的目标是通过进行概念验证实验来激励硬件领域的这项研究，在该实验中，我们将LLM（性能最好的模型，OpenAI的ChatGPT-4）与经验丰富的硬件设计工程师（论文作者之一）配对，并在负责进行更复杂的设计时对结果进行定性检查。

限制：我们再次遵守第III-C节中规定的要求。我们希望ChatGPT-4编写所有处理器的Verilog（不包括顶级Tiny Tapeout包装器）。为了确保我们可以从处理器加载和卸载数据，我们要求所有寄存器连接在移位寄存器的“扫描链”中。

总体目标：共同设计基于8位累加器的架构。ChatGPT-4的初始提示如图10所示。考虑到空间限制，我们的目标是使用32字节内存（数据和指令相结合）的冯·诺依曼型设计。

图10 基于8位累加器的处理器：启动协同设计提示

任务划分：考虑到所探索的LLM的优势和劣势，并避免产生“不合规”设计（见第III-E节），对于该设计任务，经验丰富的人类工程师负责（a）指导ChatGPT-4，以及（b）验证其输出。同时，ChatGPT-4全权负责处理器的Verilog代码。它还产生了处理器的大部分规格。

一般过程：微处理器设计过程始于定义指令集体系结构（ISA），然后实现ISA所需的组件，然后将这些组件与控制单元组合在数据路径中进行管理。模拟和测试被用来发现错误，然后进行修复。

会话线程：考虑到ChatGPT-4和其他LLM一样，有一个固定大小的上下文窗口（见第II-a节），我们认为与模型会话的最佳方式是将较大的设计分解为子任务，每个子任务在界面中都有自己的“会话线程”。这使总长度保持在16000个字符以下。当长度超过这个值时，一个专有的后端方法会执行某种文本缩减，但关于其实现的细节很少。由于ChatGPT-4不在线程之间共享信息，人类工程师会将前一个线程的相关信息复制到新的第一条消息中，从而形成一个逐步定义处理器的“基本规范”。基本规范最终包括ISA、寄存器列表（累加器“ACC”、程序计数器“PC”、指令寄存器“IR”）、存储器组、ALU和控制单元的定义，以及处理器在每个周期中应该做什么的高级概述。本规范中的大部分信息由ChatGPT-4生成，并由人类复制/粘贴和轻度编辑。

主题：每个线程都有一个适用于处理器早期设计阶段的主题（有一个例外，ALU是在与多周期处理器时钟周期时序计划相同的线程中设计的）。然而，一旦处理器进入模拟阶段，我们在上面运行程序，我们就发现了规范和实现中的错误。设计工程师没有启动新的对话线程并重建以前的上下文，而是选择在适当的情况下继续以前的对话线程。我们在表IV中的流程图中对此进行了说明，其中“Cout. T. ID”列指示它们是否“继续”前一个线程（如果是，则指示哪个线程）。

表IV 会话流程图：处理器是通过11个“会话线程”中18个主题的125条用户消息的线性流构建的。

重新启动：有时ChatGPT-4会输出次优响应。如果是这样，工程师有两个选项：（1）继续对话并推动它以修复响应，或者（2）使用接口强制ChatGPT-4“重新启动”响应，即通过假装以前的答案从未出现来重新生成结果。在这两者之间进行选择需要权衡，需要专业判断：继续对话可以让用户指定之前回应的哪些部分是好的或坏的，但重新生成将使整个对话更短、更简洁（考虑到有限的上下文窗口大小，这很有价值）。尽管如此，从表IV中的“#Restart”列中可以看出，随着工程师在使用ChatGPT-4方面越来越有经验，重新启动的次数往往会减少，主题00-07有57次重新启动，而主题08-18只有8次。在主题04（控制信号规划）中，单个消息的最高重新启动次数为10次，该主题的消息如图11所示。这是一个困难的提示，因为它要求提供具有大量细节的特定类型的输出，但最终得到了令人满意的答案，如图12所示。

图11 在ChatGPT-4生成数据路径控制信号和定义列表后，主题04中的提示最为困难（10次重新启动）。

图12 ChatGPT-4为困难提示生成的代码（第11次尝试）。它仍然缺少一些I/O，稍后的消息对此进行了更正。

所有聊天日志都在数据存储库中提供。在对话00中与ChatGPT-4共同生成的ISA（在10中更新）如表V所示，它是一种相对简单的基于累加器的设计，具有一些显著的特点：（1）在给定大小限制的情况下，内存访问“具有可变数据操作数的指令”仅使用五位来指定内存地址，这意味着处理器将被限制为存储器的绝对最大32字节。（2） 只有一条指令具有即时数据编码。（3） 指令使用完整的256个可能的字节编码。（4）尽管有点笨拙（没有堆栈指针），但JSR指令使实现子例程调用成为可能。（5） 分支指令有一定的局限性，但很有用。向后跳过两条指令可以进行有效的轮询（例如，加载输入，屏蔽相关位，然后检查是否为0）。向前跳过3条指令可以跳过JMP或JSR所需的指令。这些是在多次迭代中共同设计的，包括后来的修改（对话10-12，“分支更新”），将跳转从2条指令增加到3条。在模拟过程中，我们意识到我们无法仅用2条指令轻松编码JMP/JSR。（5） LDAR指令允许对内存加载进行类似指针的解引用。这使我们能够有效地使用内存映射中的常量表（添加在对话17中），将二进制值转换为7段显示器的LED模式。

表V 与CHATGPT-4协同设计（使用所有256个编码）。

处理器数据路径在对话08中进行了组合，如图13所示。冯·诺依曼的设计（用于数据和指令的共享存储器）需要一个双状态多循环控制单元（“FETCH”和“EXECUTE”）。到达HLT指令（重置为退出）后，进入第三个“HALT”状态，它还会设置一个processor_halted输出标志。值得注意的是，由于“FETCH”状态还会增加PC寄存器，因此ISA中的分支指令需要“-3”和“+2”修饰符。内存库是全局参数化的，允许人类工程师从Tiny Tapeout封装类（他们编写的唯一文件，用于执行与处理器无关的布线）内部更改内存大小。处理器最终与17字节的寄存器存储器合成，第17字节用于I/O（7段LED输出，一键输入）。将用于分段模式的10个字节的查找常量存储器表连接起来。合成后，处理器在第IV-E节中产生“GDS”。

图13 GPT-4设计的基于累加器的数据路径（由人工绘制）。用虚线表示的控制信号。

总的来说，ChatGPT-4产生了相对高质量的代码，这可以从短暂的验证周转中看出。编写完Python汇编程序（Conversation 09）后，修复错误的会话（10-13、15-16）只使用了125条消息中的19条。考虑到ChatGPT-4每3小时25条消息的速率限制，此设计的总时间预算为ChatGPT--4的22.8小时（包括重新启动）。每条消息的实际生成平均约为30秒：如果没有速率限制，整个设计本可以在<100分钟内完成，具体取决于人类工程师。尽管ChatGPT-4相对容易地生成了Python汇编程序，但它很难编写为我们的设计编写的程序，而且ChatGPT也没有编写任何重要的测试程序。总体上，我们完成了在模拟和FPGA仿真中评估了一系列全面的人工编写的汇编程序中的所有24条指令。

图14 处理器综合信息。

实际采用的步骤：理想情况下，随着会话LLM的兴起，可以用最少的精力实现从想法到功能设计。尽管人们非常重视它们的单次性能（即单步完成设计），但我们发现，对于硬件应用程序，LLM作为代码签署者的功能更好。如果LLM与经验丰富的工程师步调一致地工作，他们可能会成为一个“能力倍增器”，提供“第一次通过”的设计，然后可以进行调整和快速迭代。

脚本基准测试的一个值得注意的观察结果是，总体结果在很大程度上取决于早期的交互：对最初提示的响应和最初的几个反馈实例。在许多情况下，由于LLM未能理解错误和修复之间的相关性，因此需要多次迭代反馈才能解决简单的错误。因此，我们建议评估对早期提示的反应，如果它们不令人满意，请考虑从早期开始“重新开始”对话。

最先进技术的表现：HuggingFace的HuggingChat显然是表现最差的，有时甚至难以写出连贯的Verilog。谷歌的Bard在这方面做得更好，但仍然无法遵循足够详细的说明进行评估。OpenAI的ChatGPT-3.5和ChatGPT-4都可以遵循规范并编写Verilog，但只有ChatGPT-4可以可靠地做到这一点。尽管如此，它还是在不到一半的对话中成功地在没有人工输入的情况下做出了符合要求的功能性输出。然而，一旦有了这些输入，ChatGPT-4就能够为20/24基准生成兼容的代码；这一表现与聊天流程的联合设计相呼应。在这里，该模型能够帮助创建规范并将其实现到Verilog中。最先进性能的主要限制在于testbench和验证代码的作者身份。我们认为，这反映了合适的开源训练数据的（非）可用性。

可再现性：由于测试的会话LLM是不确定的和模型生成的，因此输出不具有一致的可再现性。这体现在基准测试对话的不同成功率中，其中针对单个基准测试的一些对话通过简单的人工反馈和少量的信息获得了成功，而另一些则完全失败。两个版本的ChatGPT都是封闭源代码的，并且都是远程运行的，因此我们无法检查模型的参数并分析生成输出的方法。这些测试的会话性质阻碍了再现性，因为会话中的每个用户响应都取决于之前的模型响应，因此微小的变化可能会在最终设计中产生实质性的变化。无论如何，我们确实为结果重建提供了完整的会话日志。

统计有效性：由于这项工作的目标是以对话方方式设计硬件，我们没有自动化这个过程的任何部分，每个对话都需要手动完成。这限制了可以进行的实验的规模，而这些实验也受到速率限制和模型可用性的阻碍（在撰写本文时，OpenAI的ChatGPT-4和谷歌的Bard的访问权限仍然有限）。因此，这三个测试案例可能无法提供足够的数据来得出正式的统计结论。

挑战：虽然很明显，使用会话LLM来帮助设计和实现硬件器件总体上是有益的，但该技术还不能仅通过验证工具的反馈来一致地设计硬件。目前最先进的模型在理解和修复这些工具所带来的错误方面表现得不够好，无法仅通过初始的人机交互创建完整的设计和testbench。

机会：尽管如此，当人类的反馈被提供给能力更强的ChatGPT-4模型，或用于联合设计时，语言模型似乎是一个“能力倍增器”，允许快速的设计探索和迭代。一般来说，ChatGPT-4可以生成功能正确的代码，这可以在实现公共模块时节省设计者的时间。未来的潜在工作可能涉及更大规模的用户研究以调查这一潜力，以及开发特定于硬件设计的会话LLM，以改进设计结果。