Verilog RTL（Register Transfer Level）是从抽象逻辑设计到物理实现的核心桥梁，芯片设计流程的前端核心。RTL 是硬件设计的行为描述，它通过 Verilog 或 VHDL 等硬件描述语言（HDL）描述数字电路的寄存器、组合逻辑以及它们之间的数据传输。它不涉及具体的门电路或物理布局，而是关注数据在寄存器之间的流动和处理过程。

下面是通常的数字电路芯片的设计流程。

需求分析 → RTL设计 → 逻辑综合 → 功能验证 → 物理设计 → 流片 → 测试

在这一流程中，从RTL设计开始，有一系列的EDA工具保证设计的落实执行，这些EDA的工具的目的如同我们熟知的计算机程序一样，精确的保证程序完美的执行下去。但从需求分析到RTL设计这一步，则是更“软”和“虚”的执行。我们通常从需求分析得到设计需求文档，然后根据这一份文档划分模块，然后对模块进行RTL代码的编写，最终得到可以运行下列流程的Verilog RTL代码。

这一“软”和“虚”的一面，就在于这种转换并不是唯一性，不同的团队会得到不同的结果，都是对设计功能和目的的一次转换。如果最终verilog RTL代码已经完成，通过RTL代码的描述实际上是一次对设计功能的诠释和描述。

由于RTL代码是一种特殊的描述，并不对设计者和阅读者友好，它是在开发和执行上的一次折衷。相信业内开发者都会深切体会到Verilog RTL的反向阅读的艰难。现在的AI平台方兴未艾，层出不穷，如果我们把Verilog RTL代码输送给AI平台，会有什么结果？

说干就干，首先得找到源代码。为了进行例证，源代码从开源网站github上寻找，分别找了小、中、大三种规模的源代码 ，列举如下。

• 小型：axis_udp 具有64-bit AXI总线的UDP/IP协议栈，网址：https://github.com/alknvl/axis_udp
• 中型：openE906 RISC-V E906 CPU IP源码**，网址：https://github.com/XUANTIE-RV/wujian100_open
• 大型：openC910 RISC-V C910 CPU IP源码， 网址：https://github.com/XUANTIE-RV/openc910

这里的设计规模和代码的hierarchy层次和.v文件的多少有关。之所以选择这三种，是为了测试AI对于设计复杂度的考验。

AI平台，选择有代表性的，分别是：

• deepseek: 从腾讯元宝介入，直接使用deepseek官方，效果不好。
• 豆包：豆包有自己的程序。

测试之前首先需要解决一个问题。如何让AI能够读取到源码。这个问题问AI，AI的回答如下：

• 文本输入：粘贴代码。
• 文件上传：上传Verilog文件。
• IDE支持：在平台内编写和测试代码。
• API接口：通过脚本接口上传代码。

熟悉verilog的编程者都知道，verilog代码都是很多份文件，通过文本输入不现实，IDE和API对于普通开发者不太现实。可操作的是文件上传。

但是一般的平台的文件支持有限制，如下所示：

虽然有代码文件传输，但不会包括.v文件。幸好，我这有一个Verilog RTL源码转成excel的工具，可以把多个.v文件，聚合成一个excel文件。因此，对这三套.v文件，转换成了三个.xlsx文件，而这些平台都是支持的。

这种“聚合”是采用一个.v文件等价于一个sheet工作表的方式。由于RTL通常是模块调用的方式，因此在一个sheet页面上会调用另外的sheet页面，通过模块调用的方式，会一层层的展示设计的调用架构。AI在阅读这些整合的excel表格后，可以获取整个代码的hierarchy的结构和接口方式。

小型的axis_udp设计

首先从易到难，选择最简单的axis_udp的设计。这一设计总计有15个Verilog文件，顶层模块是：

module udp_top (
   input wire         clk,  
   input wire         reset, 

// Device MAC address config 
   input wire [47:0]  CFG_MAC, 
// Device IP address config
   input wire [31:0]  CFG_IP,


// AXI-Stream from Ethernet MAC
   input wire [63:0]  mac_rx_tdata,
   input wire [7:0]   mac_rx_tkeep,
   input wire         mac_rx_tvalid,
   input wire         mac_rx_tuser,
   input wire         mac_rx_tlast,


// AXI-Stream to Ethernet MAC
   output wire [63:0] mac_tx_tdata,
   output wire [7:0]  mac_tx_tkeep,
   output wire        mac_tx_tvalid,
   output wire        mac_tx_tlast,
   input  wire        mac_tx_tready,


// AXI-Stream for inbound UDP traffic
   output wire [63:0] udp_rx_tdata,
   output wire [7:0]  udp_rx_tkeep,
   output wire        udp_rx_tvalid,
   output wire        udp_rx_tlast,
   input  wire        udp_rx_tready,

   output wire [47:0] udp_rx_src_mac,
   output wire [31:0] udp_rx_src_ip,
   output wire [15:0] udp_rx_src_port,
   output wire [15:0] udp_rx_dst_port,


// AXI-Stream for outbound UDP traffic
   input  wire [63:0] udp_tx_tdata,
   input  wire [7:0]  udp_tx_tkeep,
   input  wire        udp_tx_tvalid,
   input  wire        udp_tx_tlast,
   output wire        udp_tx_tready,

   input  wire [47:0] udp_tx_dst_mac,
   input  wire [31:0] udp_tx_dst_ip,
   input  wire [15:0] udp_tx_dst_port,
   input  wire [15:0] udp_tx_src_port
   
);

首先输入xlsx文件：

输入后，呈现出分析的信息：

deepseek(左）/豆包（右）

第一个deepseek: 从上面的axis解析成轴，这个分析总结有些想当然了。但两者都能正确识别到excel表达的各个模块。

既然是进行分析，测一下deepseek/豆包对顶层模块的分析如何：

deepseek(左）/豆包（右）

首先，这里只是对AI输入了RTL代码给的模块名和端口名，以及之间的互联关系，当然最leaf的模块会有assign/always块的描述。没有对功能进行任何的描述输入，但deepseek/豆包能从这些信号关系和命名方式，能够大致暂时确定到各个子模块的作用，以及主要接口的关系。

这里deepseek/豆包发挥了它强大的拟合功能。第一，在它的知识库里面，udp的方方面面它是知道技术背景的，然后根据你们模块的关系，信号的流动，它是能够拟合的方式知道这一模块的功能定位的。这就好比，做过udp设计的工程师，当他打开顶层模块，鼠标翻动几次，大致也能拟合式的知道这些模块的作用。但从AI在获得极少量的信息输入上，能够迅速定位出来，还是很让人吃惊的。

接着，让他总结一下fifo的深度：

deepseek(左）/豆包（右）

deepseek分析的还是准确，实际上有两种FIFO。这个测试是测试它从代码中提炼技术细节的能力。

接着，又让他们分析了一些接口信号：

deepseek(左）/豆包（右）

两者都有疏漏：deepseek的错误是根本不存在mac_txclk端口；豆包的错误是漏掉了mac_tx_tuser。功能是否是如同它们所说的，也许会有错漏。

最后，让两者出了一个总结报告：

所以，AI能够从源码出很详细的报告，至于报告的准确性，需要不断验证。

实际上，这次对verilog RTL源码进行分析和其他以往我们让AI输出一篇文章，一首诗不同。它的这些分析都必须有一个依据，那就是RTL源码提供的模块hierarchy已经确定了。它所有的输出必须基于真实的模块关系，而不是随便从网上找到的技术文档进行输出。

中型的openE906设计

平头哥玄铁E906是一款面向中高端嵌入式场景的RISC-V架构开源处理器。这个源码是它在github上公开的源码。首先载入，规模还是挺大的。

然后对顶层的各个子模块的功能进行分析：

对某一个带有逻辑功能描述的模块进行总结，就遇到问题了。deepseek回答无法解析，豆包也会遇到各种问题：

实际上 ，一旦模块过多，AI工具就会遇到各种各样的问题，回答不那么确切了。

虽然，我们相信AI工具会处理很多事情，但它毕竟是一段程序，在处理时受到各种情况的制约。它也需要根据当下的条件给予执行。只能说使用公用的工具，会受到系统分配资源的困扰。

大型的openC910设计

平头哥玄铁C910是一款基于RISC-V架构的64位高性能处理器IP核，由阿里巴巴旗下平头哥半导体于2019年7月首次发布。它的源码包含的源码更多。在载入时，deepseek直接报解析失败，豆包能够正确载入。

豆包在继续分析时，也是以推测为主：

当然，你如果补充一些信息，豆包也能够据此进行完善：

指定某一个模块，它也能讲一个七七八八：

当然，再深入下去，会出现低级错误：

总体感觉

总体来说，AI是一个具有丰富专业知识的客体，它可以通过你的代码层次布局和信号命名，能够“脑补”出一个功能划分，这个功能划分是相当靠谱的。越是显式的设计目标，越是能够详细的输出合理的回答。

但AI毕竟需要差不多的“即时”问答，那它在有限的时间内，必须对整体的代码进行消化，然后给出结论，因此它的处理能力就是瓶颈。那种希望他能够从全部代码中融汇贯通，得出结论的想法，还是太天真。比如我们能够接入的AI，某种意义上说，是系统分配给你的一段程序，必然受到内存资源等限制，因此结果如何，一定会受到你接入的AI的处理能力的影响。

但AI的这种“脑补”能力，是我们需要的。因为代码随着注释的缺乏，专业知识的缺乏，如果能够让难于读懂的verilog RTL代码有一个代言人，所有的第一手资料，由AI提供，对于一个项目的来说，是非常重要的。

在这里，想到了汽车的自动驾驶。现在的汽车辅助驾驶在新能源电动汽车上，已经成为标配，实际体验下来也还不错。虽然人们期望着实现人不接管，让汽车自动驾驶，这就如同让AI自动写RTL代码，不需要人工干预。虽然可以这么做，但风险是巨大的，因为一旦这么做，一个小小的错误就会导致车毁人亡。同样AI自动写RTL代码，虽然AI进化到这一步，但真的这么做，也会如同汽车自动驾驶一样，会有同样的担心。但现在，使用AI来进行代码的辅助开发，还是可以做到很好的体验的。

AI适合做什么？AI适合对一个精确的复杂设计做代言。比如我们一个项目用到的Verilog RTL代码，无论是注释还是相关的文档，都会想直接对Verilog RTL的代码做一个引导性的解读。但如同本文提供的体验，由AI“吞入”代码，然后由我们提问式的和AI对话，可以让我们迅速对代码获得深入解读。读相关由设计人员提供的注释或文档，达不到这种体验，总会因为主观角度不同，不能获得及时解答，更不要说有可能文档的误导，导致的歧义。开发人员可能离职，可能一波一波的换人，但只要有AI对代码的解释，任何一位接替的工程师，可以迅速获得第一手信息的传递。