CORE数据集：LLM辅助构建的标准化RTL基准库及其在EDA与ML4EDA中的应用

1. 项目概述：为什么我们需要一个全新的RTL数据集？

在数字芯片设计的日常工作中，我们这些工程师最头疼的事情之一，可能就是找不到一个“趁手”的基准电路来做测试和验证。无论是评估一个新的EDA工具的性能，还是想验证一个优化算法的效果，你总得有个像样的“标尺”来度量。过去几十年里，我们一直依赖着像ISCAS’85、ISCAS’89这样的“古董级”基准电路。这些电路在它们诞生的年代无疑是伟大的，但放到今天，问题就暴露无遗了：设计规模太小，结构固定无法调整，代码风格老旧，而且很多设计理念已经和现代SoC设计脱节了。这就好比你想测试一辆现代跑车的性能，却只能在一条坑坑洼洼的乡间小道上跑，结果显然是不准确的。

另一方面，像OpenCores这样的开源IP库，虽然项目众多、功能丰富，但质量参差不齐。你可能会找到一个功能强大的CPU核心，但它的代码风格可能很糟糕，文档缺失，甚至没有经过充分的验证。更关键的是，这些项目大多不是为“基准测试”而生的，它们的设计目标、参数化程度、验证完备性都千差万别。用这样的集合去做横向对比研究，就像用一堆形状各异的石头去搭建一个标准的天平，结果的可信度和可复现性都大打折扣。

这就是CORE数据集诞生的背景。它不是一个简单的代码仓库，而是一个为EDA研究量身定制的、标准化的、可复现的RTL设计语料库。它的核心目标，就是解决上述痛点，为学术界和工业界的研发人员提供一个高质量、高一致性的“设计素材库”和“测试基准集”。我最初接触到这个项目时，最吸引我的就是它“系统性”的构建方法：不是从网上东拼西凑，而是通过一套结合了大语言模型（LLM）辅助生成和人类专家精修的严谨流程，从头开始构建每一个模块。这意味着从代码风格、接口定义到验证完备性，都处于统一的、高标准的质量控制之下。

对于从事数字前端设计、EDA工具开发、机器学习辅助设计（ML4EDA）或者设计-工艺协同优化（DTCO）的朋友来说，CORE数据集的价值是显而易见的。它提供了137个经过功能验证、可综合的Verilog模块，覆盖了从基础的加法器、移位器到复杂的仲裁器、DMA控制器等24个类别。更重要的是，这些模块大多是高度参数化的，你可以轻松地调整位宽、深度、流水线级数等参数，生成不同规模和结构的电路实例，从而满足从微小型设计到大规模设计空间探索的各种需求。接下来，我将带你深入拆解这个数据集的构建逻辑、使用方法以及它如何能成为你工具箱里的利器。

2. 数据集构建方法论：LLM辅助与专家精修的黄金组合

CORE数据集的构建过程，本身就是一次将现代AI技术与传统硬件设计经验相结合的精彩实践。它没有采用传统的“手工编写所有模块”这种耗时费力的方式，也没有完全依赖AI“黑盒”生成，而是设计了一套人机协同、迭代优化的高效流水线。这套方法论的核心理念在于：利用LLM的“广度”和“速度”来生成多样化的设计草稿，再依靠人类专家的“深度”和“严谨性”来确保最终产出的正确性与工业级质量。

2.1 LLM辅助的HDL与测试平台协同生成

项目的第一步是定义清晰的模块规格。团队为每个目标模块（比如一个参数化的Wallace树乘法器）编写了详细的设计规格书，包括功能描述、输入输出端口列表、可配置参数（如位宽、流水线级数）、以及期望的接口时序。这一步至关重要，它为后续的AI生成提供了明确的“设计蓝图”。

接下来就是“提示工程”环节。团队设计了一套结构化的提示词模板，用于引导LLM生成符合要求的Verilog代码和对应的C++测试平台。一个典型的提示词可能长这样：

你是一位Verilog编程专家。你的任务是生成一段随机的、功能正确的、参数化的Verilog代码及其测试平台，且该模块在当前项目中不存在。你需要使用Verilator和Yosys进行Verilog验证。如果生成的代码有误，请根据Verilator和Yosys的输出定位根本原因，并相应地修正RTL及其测试平台。

这个提示词有几个关键点：第一，它明确了“参数化”和“可综合”的要求；第二，它要求协同生成测试平台，这确保了验证的完整性从一开始就被考虑；第三，它引入了“验证驱动”的迭代机制——LLM需要根据工具反馈进行自我修正。在实际操作中，团队会使用多个不同的设计规格，批量提交给LLM（如GPT-4、CodeLlama等），快速获得数十个甚至上百个不同模块的初始代码版本。这极大地加速了数据集的“素材”积累过程。

2.2 人类专家的核心作用：从“可用”到“可靠”

然而，LLM生成的代码，我们业内常戏称为“第一稿文学”。它可能有正确的语法，甚至能通过简单的语法检查，但在可综合性、时序收敛性、设计意图的精确表达以及代码风格的规范性上，往往存在大量问题。这时，人类专家的角色就不可替代了。

项目团队中的资深硬件工程师会对LLM生成的每一份代码进行严格审查和精修，这个过程包括但不限于：

1. 可综合性检查：确保代码中使用的所有语法和结构（如for循环、generate块）都是主流综合工具（如Synopsys Design Compiler, Cadence Genus, 以及开源的Yosys）所支持的。例如，LLM可能会生成使用initial块给寄存器赋初值的代码，这在仿真中没问题，但大多数ASIC综合流程中是不可综合的，专家会将其改写为复位逻辑。
2. 功能正确性验证：虽然LLM也生成了测试平台，但专家需要审查测试平台的完备性。他们会增加边界情况测试、随机化测试向量，确保模块功能在所有可配置参数下都正确无误。例如，对于一个加法器，不仅要测试常规的加法，还要测试溢出、全0、全1等极端情况。
3. 代码风格与标准化：统一所有模块的代码风格，包括命名规范（如低电平有效的信号用_n后缀）、缩进、注释格式。更重要的是，确保代码严格遵循目标Verilog标准（如Verilog-1995, SystemVerilog-2012）。团队甚至开发了Python脚本来自动检查每个文件对特定语言特性的使用情况。
4. 性能与面积优化：在保证功能正确的前提下，专家会根据经验对关键路径进行微调，或提供不同的架构实现（如选择进位选择加法器还是超前进位加法器），以丰富数据集的多样性。

实操心得：在这个人机协同的流程中，我的体会是，LLM像一个不知疲倦的“初级工程师”，能快速产出大量创意和代码框架，极大地解放了我们的生产力。但最终的质量闸门，必须由经验丰富的“高级工程师”把守。将LLM定位为“高级助手”而非“替代者”，是这类项目成功的关键。一个有效的协作模式是：专家先编写几个高质量的金标准模块，用这些模块去微调LLM，然后再用微调后的LLM去生成新模块，形成质量不断提升的飞轮。

2.3 自动化验证与质量保障流水线

为了保证数据集中每一个模块的质量都是可追溯、可复现的，项目建立了一套全自动化的验证流水线。这套流水线集成在项目的Makefile和GitHub Actions工作流中，任何代码提交都会触发以下检查：

1. 功能仿真验证：使用开源的Verilator工具，将每个Verilog模块编译成C++模型，并运行其对应的C++测试平台。所有137个模块的1921个测试用例都必须100%通过。这一步确保了行为的正确性。
2. 逻辑综合与资源评估：使用开源综合工具Yosys，将每个模块综合到通用的工艺无关单元库。这一步会生成每个模块的门数（Cell Count）、线网数（Wire Count）等关键指标，并记录在DATASET.md中。它不仅验证了代码的可综合性，还为后续的PPA（性能、功耗、面积）研究提供了基线数据。
3. 静态代码分析：通过Python脚本分析代码的复杂度，如代码行数（LoC）、端口数量、参数数量，并统计常见设计结构（如if-else,case,for循环）的使用频率。这为研究代码风格与电路结构的关系提供了数据支持。
4. 标准符合性检查：另一个脚本会扫描代码，确认其使用的语言特性属于哪个Verilog/SystemVerilog标准版本，确保与目标EDA工具的兼容性。

这套自动化流水线是数据集“可信度”的基石。它意味着任何研究者下载这个数据集，运行make verify_all，都应该得到完全一致的结果，真正实现了研究的可复现性。

3. 数据集深度解析：内容、结构与核心价值

理解了CORE是如何被构建出来的，我们再来深入看看这个“宝箱”里到底装了些什么，以及如何高效地利用它。

3.1 模块分类与设计多样性

CORE数据集目前包含137个独立的Verilog模块，并被精心分类到24个不同的目录中。这种分类方式非常贴近实际工程项目的组织习惯。主要的类别包括：

• 算术运算单元：adders（加法器）,multipliers（乘法器）,alu（算术逻辑单元）等。这是数字设计的基石，包含了从行波进位加法器到华莱士树乘法器等多种架构。
• 存储与缓存：fifos（先进先出队列）,rams（随机存储器）,caches（缓存控制器）。这些模块对于理解数据流和存储层次结构至关重要。
• 控制与仲裁逻辑：arbiters（仲裁器）,encoders_decoders（编码器/解码器）,fsm（有限状态机）。它们代表了数字系统中复杂的控制路径设计。
• 通信与接口：uart（通用异步收发器）,spi（串行外设接口）。虽然相对简单，但提供了标准的通信协议实现。
• 其他专用模块：crc（循环冗余校验）,filters（滤波器）,voters（表决器）等，覆盖了更广泛的应用场景。

这种分类的价值在于，当你需要研究某一类特定电路（比如仲裁器）的优化算法时，你可以直接进入libraries/arbiters/目录，里面有多个不同实现（如固定优先级、轮询、矩阵仲裁）的、参数化的模块供你比较和测试，无需再四处寻找或自己从头搭建。

3.2 参数化设计：一把打开设计空间的钥匙

CORE数据集最强大的特性之一就是其广泛的参数化支持。几乎每个模块都通过parameter或localparam定义了可配置项。我们以加法器为例，在libraries/adders/目录下，你可能会找到一个configurable_adder.v文件，它的模块声明可能类似于：

module configurable_adder #( parameter WIDTH = 32, // 操作数位宽，默认32位 parameter PIPELINE_STAGES = 0, // 流水线级数，0表示组合逻辑 parameter ADDER_TYPE = "RCA" // 加法器类型："RCA"(行波进位), "CLA"(超前进位), "CSA"(进位选择) ) ( input wire [WIDTH-1:0] a, input wire [WIDTH-1:0] b, input wire cin, output wire [WIDTH-1:0] sum, output wire cout ); // 根据参数选择不同的加法器实现 generate if (ADDER_TYPE == "RCA") begin ripple_carry_adder #(.WIDTH(WIDTH)) rca_inst (.a(a), .b(b), .cin(cin), .sum(sum), .cout(cout)); end else if (ADDER_TYPE == "CLA") begin carry_lookahead_adder #(.WIDTH(WIDTH)) cla_inst (.a(a), .b(b), .cin(cin), .sum(sum), .cout(cout)); end // ... 其他类型 endgenerate // 流水线逻辑（如果PIPELINE_STAGES > 0） // ... endmodule

通过简单地修改实例化时的参数，你可以瞬间得到从8位到256位、从组合逻辑到多级流水、从面积优先到速度优先的各种加法器变体。这种能力对于以下研究是无价的：

• 设计空间探索：快速评估不同架构和参数对面积、时序、功耗的影响。
• EDA工具基准测试：用同一模块的不同规模实例，测试综合工具在处理大规模设计时的能力和效率。
• 机器学习数据集生成：为ML4EDA模型生成海量的、标签化的（对应不同PPA结果）训练数据。

3.3 完备的配套：不仅仅是RTL代码

一个高质量的IP或基准，代码本身只占一半价值，另一半在于其配套的“基础设施”。CORE在这方面做得非常到位：

1. 可执行的测试平台：每个.v文件都对应一个tb_*.cpp文件。这个测试平台不是简单的波形打印，而是使用SystemC或类似方法进行自检的。它会在仿真结束时自动报告PASS或FAIL。你可以直接使用make verify_<module_name>来运行针对单个模块的仿真。
2. 详细的文档：每个类别目录下都有一个README_*.md文件（如docs/README_ADDERS.md），里面详细说明了该类模块的功能、所有可配置参数的含义、接口时序图（如果有）、以及使用示例。这大大降低了上手门槛。
3. 自动化脚本：项目根目录的Makefile和scripts/下的Python脚本，将验证、综合、分析流程全部自动化。你不需要自己写脚本去遍历所有模块，一个make verify_all和make analyze_all就能得到完整的验证报告和数据集分析报告（REPORT.md和DATASET.md）。

注意事项：初次使用数据集时，建议先花点时间阅读顶层的README.md，并确保你的开发环境已经安装了必要的工具链（Verilator, Yosys, Python依赖包）。运行make help可以查看所有可用的命令。一个小技巧是，可以先在一个简单的模块（比如一个小的加法器）上跑通整个流程，熟悉环境后再扩展到整个数据集。

4. 核心应用场景：从研究到教育再到工程

CORE数据集的设计目标决定了它不仅仅是一个代码合集，而是一个多功能的平台。下面我结合自己的经验，谈谈它在几个关键领域的应用。

4.1 机器学习辅助EDA研究的“ImageNet”

近年来，ML4EDA是学术界和工业界的一大热点。但训练一个有效的模型，需要大量高质量、标注好的数据。在EDA领域，这就是“RTL代码 -> 综合后网表 -> PPA指标”的配对数据。手动创建这样的数据集成本极高。CORE数据集恰好填补了这个空白。

你可以利用其参数化特性，批量生成成千上万个不同配置的模块实例。然后，使用统一的脚本（项目已提供部分基础）调用Yosys或商业工具进行综合，提取出门数、关键路径延时等指标。这样，你就得到了一个规模可观、质量统一的“RTL-PPA”配对数据集。这个数据集可以用于：

• RTL级PPA预测：训练一个模型，输入RTL代码（或其特征），直接预测其综合后的面积和时序，在设计的早期阶段提供快速反馈。
• 自动代码优化：训练一个强化学习模型，以PPA��奖励，探索对给定RTL代码进行微调（如流水线打拍、操作符变换）的最佳策略。
• 设计空间探索加速：用模型替代耗时的综合过程，快速在庞大的参数空间中寻找Pareto最优解。

4.2 硬件加速仿真器的理想基准测试集

RTL仿真是芯片设计验证中最耗时的环节之一。利用GPU或FPGA对仿真进行硬件加速是一个重要的研究方向。然而，评估一个硬件加速器的好坏，需要一个能代表真实设计多样性的基准测试集。

CORE数据集完美契合这个需求。它的模块在结构上具有高度的多样性：

• 计算密集型/规则结构：如configurable_fir_filter.v（FIR滤波器），具有高度的数据并行性和规则的数据流，非常适合在GPU的SIMD架构上加速。
• 控制密集型/不规则结构：如dma_controller.v（DMA控制器）或sequence_detector_fsm.v（序列检测状态机），控制逻辑复杂，分支多，内存访问模式不规则，这对硬件加速器提出了巨大挑战，更能体现代码的通用性。

研究者可以测量同一个硬件加速器在不同类型模块上的仿真速度，绘制出性能谱系图，从而清晰地揭示该加速器的优势场景和瓶颈所在。数据集的参数化特性还允许进行可扩展性测试：不断增加模块的位宽或深度，观察加速器的性能如何变化，是线性增长还是会出现“墙”？

4.3 设计-工艺协同优化的可靠输入

在先进工艺节点，芯片设计不再是独立的环节，必须与制造工艺紧密协同，即DTCO。DTCO流程的起点正是RTL描述。一个参数化、可扩展的RTL数据集，使得系统性地研究工艺变动对电路PPA的影响成为可能。

例如，你可以将CORE中的模块，使用不同的工艺设计套件（PDK），如开源的SkyWater 130nm或ASAP7，进行综合和物理实现。然后，分析同一模块在不同工艺角（TT, FF, SS）下的频率、功耗和面积变化趋势。由于模块是参数化的，你还可以研究“规模效应”：对于一个乘法器，当其位宽从16位增加到64位时，在不同工艺下的面积增长是否还是线性的？时序恶化是否可控？这些基于统一代码库的、可复现的实验结果，能为工艺选择和架构决策提供宝贵的定量依据。

4.4 教育与培训的绝佳素材

对于高校学生和初入行业的工程师而言，CORE是一个不可多得的学习资源。它提供了从简单到复杂、风格统一、验证完备的“代码范本”。学生可以：

• 学习规范的Verilog编码风格：看看专业的、可综合的代码应该怎么写。
• 理解不同架构的权衡：对比同一个功能（如加法）的不同实现（RCA vs. CLA），通过综合报告直观感受速度与面积的trade-off。
• 实践完整的EDA流程：从RTL编写、仿真验证、逻辑综合到简单的时序分析，在一个高质量的项目上走通全流程。
• 进行课程项目或毕业设计：基于这些可靠的“积木”，快速搭建更复杂的系统，如一个简单的CPU或通信协处理器，将精力集中在系统集成和创新上，而不是重复造轮子。

5. 使用指南与实战技巧

理论说了这么多，最后我们来点“干货”，看看如何实际动手把CORE数据集用起来。

5.1 环境搭建与快速上手

首先，克隆仓库并搭建环境：

git clone https://github.com/sjtu-yongfu-research-grp/core.git cd core # 安装Python依赖（建议使用虚拟环境） pip install -r requirements.txt # 确保系统已安装Verilator和Yosys # Ubuntu/Debian示例：sudo apt-get install verilator yosys

然后，进行快速完整性验证：

# 运行完整的自动化验证流程（这可能需要一些时间） make verify_all # 运行综合与分析，生成数据集报告 make analyze_all

运行成功后，你会看到REPORT.md中所有测试通过，DATASET.md中包含了所有模块的详细统计信息和图表，plots/目录下会生成各种分析图。

5.2 如何集成到自己的项目中

假设你正在研究加法器优化算法，想用CORE的加法器模块作为基准。你不需要复制整个仓库，可以只提取所需部分。

方法一：作为子模块引用（推荐）在你的项目目录中：

git submodule add https://github.com/sjtu-yongfu-research-grp/core.git core_dataset

这样，你可以在自己的RTL代码中直接实例化CORE的模块：

`include “core_dataset/libraries/adders/configurable_adder.v” module my_top_design #(parameter DATA_WIDTH = 64) ( input [DATA_WIDTH-1:0] op_a, op_b, output [DATA_WIDTH-1:0] result ); wire cout; // 实例化一个64位、2级流水线的超前进位加法器 configurable_adder #( .WIDTH(DATA_WIDTH), .PIPELINE_STAGES(2), .ADDER_TYPE(“CLA”) ) u_adder ( .a(op_a), .b(op_b), .cin(1‘b0), .sum(result), .cout(cout) ); endmodule

方法二：使用FuseSoC（如果项目支持）CORE数据集的结构也兼容FuseSoC这样的IP管理工具。你可以创建一个.core文件来描述这些模块，从而更方便地进行版本管理和依赖解析。

5.3 扩展与贡献：让数据集持续生长

CORE是一个开源项目，其价值会随着社区的贡献而不断增长。如果你设计了一个新的、高质量的参数化模块，并愿意分享，向项目提交Pull Request是一个很好的方式。提交前请确保：

1. 模块是可综合的，并遵循项目已有的代码风格（参考VERILOG_STANDARDS.md）。
2. 提供完备的、可自检的C++测试平台，并且测试覆盖率足够。
3. 将模块放入合适的分类目录，或与维护者讨论创建新目录。
4. 更新对应的文档（docs/README_*.md）。
5. 确保你的模块能通过项目现有的自动化验证流程（make verify_all）。

5.4 常见问题与排查

在实际使用中，你可能会遇到以下问题：

踩坑记录：我在最初尝试用Vivado综合其中一个较复杂的FIFO模块时，遇到了时序不收敛的问题。后来发现，CORE数据集中的模块在编写时，侧重于功能正确性和代码风格，并没有添加针对特定FPGA或ASIC库的时序约束。这是有意为之的，因为它要保持工艺无关性。在实际工程使用时，用户必须根据自己的目标平台（FPGA型号或ASIC工艺库）自行添加合理的时序约束（如create_clock,set_input_delay等）。这也提醒我们，将研究数据集应用到实际项目时，“集成验证”和“时序约束”是必不可少的两步。

CORE数据集的出现，为EDA社区提供了一个久违的、高质量的公共基准。它像一套精心校准的“标准砝码”，让我们在比较不同算法、工具和方法时，有了一个公平、统一的起点。无论你是想验证一个新的综合策略，训练一个AI设计助手，还是教授学生规范的硬件设计，它都能为你节省大量搭建基础框架的时间，让你更专注于创新本身。开源和社区的力量将使这个数据集不断进化，我期待看到它未来在更多前沿领域发挥作用。