CN112100949A

CN112100949A - 集成电路芯片的自动开发方法及装置、电子设备

Info

Publication number: CN112100949A
Application number: CN202010970288.0A
Authority: CN
Inventors: 钟裕捷; 张钰玫
Original assignee: Beijing Shichangding Technology Co ltd
Current assignee: Beijing Shichangding Technology Co ltd
Priority date: 2020-09-15
Filing date: 2020-09-15
Publication date: 2020-12-18
Anticipated expiration: 2040-09-15

Abstract

本申请提供一种集成电路芯片的自动开发方法及装置、电子设备，该方法包括：获取芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件；根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，生成RTL代码；根据所述模块寄存器定义文件，通过智能仿真引擎生成芯片各个模块寄存器验证用例；依次通过智能综合引擎、智能可测试引擎以及智能形式验证引擎，生成综合运行环境、生成可测试电路运行环境、生成形式验证运行环境。本申请实施例提供的技术方案可以大幅度的降低人为的干预以及人为造成的问题。

Description

集成电路芯片的自动开发方法及装置、电子设备

技术领域

本申请涉及芯片技术领域，特别涉及一种集成电路芯片的自动开发方法及装置、电子设备。

背景技术

芯片的规模越大，芯片设计的复杂度越来越高，芯片设计开发的周期相对的就越长，依照传统的方法学来设计、实现一款大型SoC(集成电路)芯片花费的时间和人力成本则会大幅度的增加，同时也会影响芯片推出市场的时间。

发明内容

本申请实施例提供了集成电路芯片的自动开发方法，用以降低人力和时间成本，加速芯片开发进度。

本申请实施例提供了一种集成电路芯片的自动开发方法，包括：

获取芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件；

根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，生成RTL代码；

根据所述模块寄存器定义文件，通过智能仿真引擎生成芯片各个模块寄存器验证用例；

依次通过智能综合引擎、智能可测试引擎以及智能形式验证引擎，生成综合运行环境、生成可测试电路运行环境、生成形式验证运行环境。

在一实施例中，所述根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，生成RTL代码，包括：

根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，产生寄存器头文件、模块RTL代码、core层RTL代码、chip层RTL 代码。

在一实施例中，所述根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，产生寄存器头文件、模块RTL代码、core层RTL 代码、chip层RTL代码，包括：

读入所有模块的所述模块寄存器定义文件，生成所述寄存器头文件；

将所述模块连接定义文件转换成RTL代码，判断模块连接定义文件的语法是否有错，若无错，产生所述模块RTL代码；

判断模块之间的连接是否有不匹配，若无不匹配，判断是否将所有模块的模块连接定义文件转换成RTL代码，若是，产生所述core层RTL代码；

判断连线是否有不匹配，若无不匹配，读入所述芯片管脚定义文件，生成所述chip层RTL代码。

在一实施例中，所述依次通过智能综合引擎、智能可测试引擎以及智能形式验证引擎，生成综合运行环境、生成可测试电路运行环境、生成形式验证运行环境，包括：

通过所述智能综合引擎依次产生模块综合环境、core层综合环境以及 chip层综合环境；

通过所述智能可测试引擎依次产生模块可测试电路环境、core层可测试电路环境以及chip层可测试电路环境；

通过所述智能形式验证引擎依次产生模块形式验证环境、core层形式验证环境以及chip层形式验证环境。

在一实施例中，所述通过所述智能综合引擎依次产生模块综合环境、 core层综合环境以及chip层综合环境，包括：

读入模块的综合文件列表；

判断是否模块顶层单独综合或跟子系统顶层一起综合，若否，综合工具读入RTL代码或综合库文件，产生底层网表和综合库文件；若是，综合工具读入RTL代码或综合库文件，判断是否需等待底层网表；

若需要等待底层网表，判断所述底层网表是否完成，若没有完成，等待所述底层网表完成，若完成，综合产生网表和综合库文件；若不需要等待所述底层网表，综合产生网表和综合库文件；

判断所有模块是否综合完成，若是，综合产生core层网表和综合库文件，综合产生chip层网表和综合库文件；

移除扫描链使能端口以及重新命名扫描链使能端口，输出尚未生成扫描链的网表和综合库文件。

在一实施例中，所述通过所述智能可测试引擎依次产生模块可测试电路环境、core层可测试电路环境以及chip层可测试电路环境，包括：

产生可测试电路环境；

判断模块或子系统顶层网表是否存在，若存在，插入模块或子系统顶层扫描网表，产生模块或子系统可测试电路规则报告；

判断core层网表是否存在，若存在，插入core层扫描网表，产生core 层可测试电路规则报告；

判断chip层网表是否存在，若存在，连接跟所述芯片管脚定义文件定义的单元库，产生post-scan网表，产生chip层可测试电路规则报告。

在一实施例中，所述通过所述智能形式验证引擎依次产生模块形式验证环境、core层形式验证环境以及chip层形式验证环境，包括：

产生形式验证环境；

判断网表是否存在，若存在，判断是否需读入底层模块形式验证设置文件，如果是，读入所述底层模块形式验证设置文件；

比对所述RTL代码和所述网表是否一致，直到比对结束产生比对报告。

本申请实施例还提供了一种集成电路芯片的自动开发装置，包括：

文件获取模块，用于获取芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件；

代码生成模块，用于根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，生成RTL代码；

芯片验证模块，用于根据所述模块寄存器定义文件，通过智能仿真引擎生成芯片各个模块寄存器验证用例；

环境生成模块，用于依次通过智能综合引擎、智能可测试引擎以及智能形式验证引擎，生成综合运行环境、生成可测试电路运行环境、生成形式验证运行环境。

本申请实施例还提供了一种电子设备，所述电子设备包括：处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行上述集成电路芯片的自动开发方法。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序可由处理器执行以完成上述集成电路芯片的自动开发方法。

本申请上述实施例提供的技术方案，可以大幅度的降低人为的干预以及人为造成的问题，输入文件是csv芯片管脚定义的文本文件、def寄存器定义文件、vconn模块连接定义文件；管脚定义和复用CSV文件适配不同厂家的IO库和管脚信号定义；自动化开发方法整合芯片RTL设计 (Design)、FPGA、EDA验证(Verification)、综合(Synthesis)、形式验证(Formal) 以及软件(Software)等不同阶段所需环境以及工具，可以自动生成对同一层级模块间的连线以及上下层级的模块之间的连线；自动生成每个模块以及每个子系统的顶层RTL文件；自动生成芯片每个模块的寄存器读写的C 验证用例。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍。

图1为本申请实施例提供的集成电路芯片(Soc)的自动开发平台 (SCD-Auto)的架构示意图；

图2是SCD-Auto平台的运行流程示意图；

图3为本申请实施例提供的电子设备的示意图；

图4是本申请实施例提供的一种集成电路芯片的自动开发方法的流程示意图；

图5是VCONN虚拟连接功能示意图；

图6是本申请实施例提供的生成RTL代码的流程图；

图7是本申请实施例提供的生成RTL代码的详细流程图；

图8是本申请实施例提供的寄存器C测试用例产生流程；

图9是本申请实施例提供的生成综合运行环境的流程图；

图10是本申请实施例提供的生成综合运行环境的详细流程图；

图11和图12是esyn引擎生成出的综合环境的一部分示意图；

图13是SCD-Auto的esyn引擎生成的makefile示意图；

图14是本申请实施例提供的生成可测试电路运行环境的流程示意图；

图15是本申请实施例提供的生成可测试电路运行环境的详细流程示意图；

图16和17是edft引擎生成DFT环境的示意图；

图18是本申请实施例提供的生成形式验证运行环境的流程示意图；

图19是本申请实施例提供的生成形式验证运行环境的详细流程示意图；

图20和图21是eformal引擎生成的形式验证环境的部分示意图；

图22是本申请一实施例提供的集成电路芯片的自动开发的详细流程示意图；

图23是本申请一实施例提供的集成电路芯片的自动开发装置的框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

图1为本申请实施例提供的集成电路芯片(Soc)的自动开发平台 (SCD-Auto)的架构示意图。SCD-Auto是一个提供跨操作系统(OS)、跨 EDA厂家工具的一个芯片自动化开发平台。SCD-Auto基于选定的工艺库，提供从芯片架构的功能和管脚定义到芯片设计、验证、综合实现、DFT(可测试电路)实现以及形式验证所需的环境。如图1所示，该SCD-Auto平台包括gen_iomux引擎(智能管脚引擎)、vp引擎(智能虚拟连线引擎)、def 引擎(智能验证引擎)、esyn引擎(智能综合引擎)、edft引擎(智能可测试引擎)、eformal引擎(智能形式验证引擎)、erun引擎(智能仿真引擎)。

SCD-Auto平台根据输入的CSV(芯片管脚定义文件)、vconn(模块连接定义文件)、def(模块寄存器定义文件)，通过上述引擎，可以自动生成 chip.v，iomux.v和iopad.v三个芯片顶层文件，模块之间连线的RTL代码，产生寄存器头文件，生成综合运行环境，生成DFT(可测试电路)运行环境，生成FV(形式验证)运行环境，生成仿真执行命令，最后输出VERILOG 网表和SDC(综合约束文件)。

上述SCD-Auto平台可以部署在服务器中，由服务器执行本申请实施例提供的集成电路芯片的自动开发方法。

图2是SCD-Auto平台的运行流程示意图。SCD-Auto平台可以基于 gmake环境将这几个功能(引擎)整合进来，使用者只需要在项目当前目录下运行make即可，使用者可以基于当前的意图可以单独使用make rtl编译寄存器列表以及整个SoC芯片各个模块的RTL；make ver编译寄存器读写C测试用例；make syn是生成各个模块、各个层级、各个子系统和整个芯片的综合环境；make dft是产生各个模块、各个层级、各个子系统和整个芯片的DFT环境；make formal是产生各个模块、各个层级、各个子系统和整个芯片的形式验证环境；或者用make all将这些功能和环境一次性的生成出来。

图3为本申请实施例提供的电子设备的示意图。本申请下述实施例提供的自动开发方法可以应用于此电子设备200，该电子设备200可以服务器。如图3所示，该电子设备200可以包括处理器210，用于存储处理器210可执行指令的存储器220；其中，所述处理器210被配置为执行本申请下述实施例提供的集成电路芯片的自动开发方法。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序可由处理器210执行以完成本申请实施例提供的集成电路芯片的自动开发方法。

图4是本申请实施例提供的一种集成电路芯片的自动开发方法的流程示意图。如图4所示，该方法包括以下步骤S410-S440。

步骤S410：获取芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件。

其中，CSV(芯片管脚定义文件)是文本文件，如下表一所示。

表一：管脚定义CSV示意格式

CSV规定芯片管脚的复用关系、所使用的I/O类型以及I/O管脚的端口名称、管脚属于ASIC还是只用于FPGA以及管脚是否为特殊类型如测试模式、时钟和复位管脚以及控制管脚复用的控制信号。SCD-Auto的gen_iomux 引擎基于这个CSV定义的信息产生chip.v、iopad.v和iomux.v等三个芯片顶层VERILOG RTL代码；如果芯片架构师基于系统考量要改动芯片管脚定义或者使用的不同的IO库时只需改动此CSV，gen_iomux引擎会自动生成这三个顶层RTL代码。传统的开发则基于表一中每一行和每一列定义的信息产生chip.v、iopad.v和iomux.v等三个芯片顶层VERILOG RTL代码。如果芯片架构师基于系统考量要改动芯片管脚定义或者使用的不同的IO库时芯片设计工程师也要相对应的改动这三个芯片顶层RTL代码。

VCONN是模块顶层例化定义以及虚拟连接定义文件(简称模块连接定义文件)，如果例化模块的端口名称和net连线名称相同则只需在VCONN 定义例化的模块名称即可，SCD-Auto自动化平台则会自动将模块之间或者与上层级的模块之间的连线自动连接好以及产生模块顶层的RTL代码。 SCD-Auto芯片自动化平台的VCONN功能大幅度的降低芯片设计工程师在设计或集成时需要的连线以及搭建上一层级的RTL代码。VCONN功能类似搭积木从最底层的模块逐步的往上类似图5所示。模块0-x表示是同一层级0的模块，模块1-x表示是同一层级1的模块，模块N-x表示是同一层级 N的模块，x从0，1，2，…，Y表示同一层级有Y个模块。从图5的连线可以得知SCD-Auto的VCONN功能会将同一层级以及上下不同层级模块之间的连线相连接起来以及产生同一层级顶层模块的RTL代码。VCONN这个功能让芯片设计工程师在建立芯片项目工程时可以专注模块的功能以及性能设计，不需要特别关注连线以及模块顶层RTL代码，因为这些都是基于VCONN虚拟连线定义好之后自动生成的RTL代码。VCONN还有一个功能就是在连线时会对于相对应的端口输入出的属性以及端口的位宽大小看是否匹配，属性或位宽不匹配则不会产生RTL代码且会产生错误报告让芯片设计工程师方便定位问题。

DEF是模块寄存器定义文件，也是SCD-Auto芯片自动化平台的三个输入文件之一，模块寄存器RTL代码是基于模块的DEF文件生成的而且 DEF也会生成整个芯片的.h寄存器列表和.html的寄存器列表。生成的 scd-registers.h除了产生RTL所需的每一个寄存器参数所需的定义之外还包括DMA通道号定义和每一个模块产生的中断在CPU中断处理函数占据的中断号。DMA通道号定义和CPU中断号定义方便验证工程师以及软件工程师得知设计中RTL代码的定义，此方法是保证设计中的RTL代码参数跟验证工程师和软件工程师使用的参数定义一致，这个也是SCD-Auto芯片自动化平台使用DEF的基本精神。特别注意scd-regsiters.h和registers.h中的所有参数定义均是从各个模块的DEF文件生成的。

步骤S420：根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，生成RTL(寄存器转换级电路)代码。

如图6所示，生成RTL代码包括产生寄存器头文件、产生模块RTL代码、产生core层RTL代码、产生chip层RTL代码。

其中，如图7所示，生成RTL代码的详细流程如下：读入所有模块的所述模块寄存器定义文件(def文件)，生成所述寄存器头文件(即全芯片寄存器列表)。将所述模块连接定义文件(vconn文件)转换成RTL代码，判断模块连接定义文件的语法是否有错，若有错，产生错误日志；若无错，产生所述模块RTL代码。在产生所述模块RTL代码之后，判断模块之间的连接连接是否有不匹配，若存在不匹配，产生错误日志；若无不匹配，判断是否将所有模块的模块连接定义文件转换成RTL代码，若是，产生所述 core层RTL代码；判断连线是否有不匹配，若有不匹配，产生错误日志；若无不匹配，读入所述芯片管脚定义文件(csv文件)，生成所述chip层RTL 代码，即生成生成chip.v,iomux.v,iopad.v,chip_fpga.v,iopad_fpga.v等文件。 chip层是整个芯片的顶层文件，底下包括iopad,iomux,以及core三个模块。Iopad模块是整个芯片的管脚定义代码；iomux是芯片定义的管脚复用；core 层是芯片所有功能模块的集合。

每个引擎有自定义的格式，用户只需遵守格式将所想要的代码或环境。如gen_iomux引擎：用户只需将管脚复用和管脚工艺库的信息填入即可生成顶层的RTL代码。

Def文件里面定义寄存器栏位的名称以及读写属性和偏移量，如

这样就可以生成寄存器文件列表。

vp引擎基于vconn文件中定义的虚拟连线的端口和线的对应关系来生成，如果端口名称和连线名称一致则可以不填写。如：

生成的上一级的文件之间的连线如下：

如此以此类推从模块底层一直往上到core层然后到chip层。

下面的定义是SCD-Auto自动生成的registers.h文件中对SYSC模块中的时钟分频寄存器定义的格式包括寄存器偏移地址、寄存器复位值、寄存器读写使能、寄存器栏位及寄存器位宽等等；这些定义足够芯片设计人员利用这些自动产生的参数定义用于硬件描述语言中RTL的电路设计；这个环节主要是为了生成的RTL代码可以确保与寄存器文件列表一致。定义格式如下：

//SYSC_DEVRATIO10:register field definitions

#define寄存器地址地址偏移量

#define寄存器复位值复位默认值

#define寄存器写使能比特写使能

#define寄存器读使能比特读使能

#define寄存器信号栏位比特[M:N]

#define寄存器信号最低比特 N

#define寄存器信号最高比特 M

#define寄存器位宽 M-N+1

#define寄存器信号复位值 VALUE

下面的定义是SCD-Auto自动生成的scd-registers.h文件中对SYSC模块中的时钟分频寄存器定义的格式包括寄存器物理绝对地址、寄存器复位值、寄存器读写使能、寄存器栏位及寄存器位宽等等；这些定义主要是让验证和软件人员基于此寄存器文件列表开发测试用例和硬件底层驱动；因为此寄存器文件列表和芯片设计人员使用的寄存器文件列表都是经由def 引擎生成可以保证一致性进而保证验证和软件人员使用的文件跟电路设计的代码一致性。定义格式如下：

//SCD_LB_SYSC_DEVRATIO10:register field definitions

//Register Def offset 0xb0 for device clock dividsor

#define寄存器地址绝对地址

#define寄存器复位值复位默认值

#define寄存器写使能比特写使能

#define寄存器读使能比特读使能

#define寄存器信号栏位比特[M:N]

#define寄存器信号最低比特 N

#define寄存器信号最高比特 M

#define寄存器位宽 M-N+1

#define寄存器信号复位值 VALUE

下面是上述寄存器列表描述的寄存器源代码，从代码看寄存器的位宽定义、寄存器复位值以及寄存器信号在寄存器地址所占的栏位。下面是vp 的源代码：

下面是利用SCD-Auto芯片自动化平台内的vp引擎生成的寄存器RTL 代码，vp引擎将源代码中的参数转换成数值，这些数值包括寄存器位宽、寄存器复位值以及寄存器信号所占寄存器地址的栏位：

上面生成出来的RTL代码寄存器参数定义比特位宽和寄存器比特栏位跟SCD-Auto芯片自动化平台生成出来的registers.h参数定义是匹配的；这部份可以最大限度的保证芯片设计工程师交付的代码质量和文件的一致性，大幅度的降低多方沟通不良造成的信息不对称以及因为信息不对称造成项目进度的延迟。

下面参数定义是芯片中每一个模块或外设的中断对应于CPU的中断号定义：

//

//Interrupt sources

//

#define 模块一 0

#define 模块二 1

在开发中断相关的RTL代码时将中断号直接用SCD-Auto生成的寄存器文件列表中的参数用于vp源代码，之后再用def引擎生成符合VERILOG 硬件描述语言的代码。

下面是中断处理函数中vp的代码：

下面是经由SCD-Auto芯片自动化平台生成出来的中断处理函数的RTL代码如下：

从上述的三段描述可以知道生成后的RTL代码跟scd-registers.h定义的参数一致，确保RTL代码和验证或软件工程师使用的寄存器列表文件一致，降低因为信息不对称或多方沟通不良造成效率低落或影响项目的进度。

除了上述的寄存器和中断号参数的转换之外，SCD-AUTO还可以将 DMA通道号参数化，这样可以确保SoC芯片开发的整个流程所需的寄存器、中断号以及DMA通道都可以用参数化表示来保证设计代码和交付给验证和软件的寄存器文件列表描述的一致性。

下面是每个外设的DMA信号对应到DMA控制器的通道号定义参数：

//

//DMA input channels

//

#define 模块一 0

#define 模块二 2

//

//DMA output channels

//

#define 模块一 1

#define 模块二 3

#

步骤S430：根据所述模块寄存器定义文件，通过智能仿真引擎生成芯片各个模块寄存器验证用例。

一般开发测试用例的验证人员都需要单独编写寄存器定义文件或者在用例中直接访问寄存器的绝对地址，但这些对于可移植性方面相对低，且设计开发人员改动寄存器定义栏位或寄存器地址则验证人员需要做相对应的调整；使用SCD-AUTO中的def引擎则无需这方面的迭代。

下面是def引擎生成的寄存器读写C测试用例：

可以看到def引擎产生的C测试用例均是以scd-registers.h生成的寄存器参数定义来完成，不用寄存器的绝对地址和寄存器的绝对比特栏位，这部份是最大限度让生成出来的测试用例的移植性。

如图8所示，寄存器C测试用例产生流程如下：判断是否存在 scd-registers.h文件，若不存在，产生错误报告；若存在，继续判断哪些模块徐产生寄存器读写测试用例，之后生成寄存器读写验证C用例。

从上述的几个例子可以知道SCD-Auto芯片自动化平台可以保证芯片设计工程交付的RTL代码和寄存器文件内容的一致性。SCD-Auto芯片自动化平台中的VCONN文件和vp引擎可以将整个芯片设计中的core层以下的代码很好的处理代码和寄存器文件的一致性和连线的连接性和正确性。 SCD-Auto芯片自动化平台的gen_iomux引擎可以将芯片规格定义的文件转换成RTL代码，降低了芯片架构师定义芯片规格和芯片设计工程师对于文档的理解偏差造成芯片功能的不一致或者错误的功能；而且gen_iomux引擎也减少了芯片设计工程师这一部份的设计工作。上面描述的是SCD-Auto 芯片自动化平台从芯片规格定义到芯片设计、验证和软件的流程，SCD-Auto 可以满足芯片设计工程师交付物的质量。从图6和图7可以知道SCD-Auto 在芯片设计阶段负责的工作内容和流程。

步骤S440：依次通过智能综合引擎、智能可测试引擎以及智能形式验证引擎，生成综合运行环境、生成可测试电路运行环境、生成形式验证运行环境。

如图9所示，生成综合运行环境包括通过所述智能综合引擎依次产生模块综合环境、core层综合环境以及chip层综合环境。

如图10所示，生成综合运行环境的详细流程如下：读入模块的综合文件列表；判断是否模块顶层单独综合或跟子系统顶层一起综合，若否，综合工具读入RTL代码(VHDL、VERILOG、SVERILOG文件，)或综合库文件(如read_ddc)，产生底层网表和综合库文件(如ddc)；若是，综合工具读入RTL代码(VHDL、VERILOG、SVERILOG文件)或综合库文件(如 read_ddc)，判断是否需等待底层网表；若需要等待底层网表，判断所述底层网表是否完成，若没有完成，等待所述底层网表完成，若完成，综合产生网表和综合库文件(如ddc)；若不需要等待所述底层网表，综合产生网表和综合库文件(如ddc)；判断所有模块是否综合完成，若是，综合产生core层网表和综合库文件(如ddc)，综合产生chip层网表和综合库文件(如 ddc)；移除扫描链使能(ScanEnable)端口以及重新命名扫描链使能 ScanEnable端口，输出尚未生成扫描链的网表(pre-scan网表)和综合库文件(如ddc)。

图9和图10描述的是esyn引擎的流程。从图9可以知道esyn产生的综合环境是由底层一直往上到core层甚至到chip层。图10描述的是esyn 引擎如何处理整个芯片综合的流程，esyn引擎基于使用者指定的代码层次结构和综合策略Bottom-Up或Top-Down策略产生相对应所需的综合环境。 esyn引擎也会针对不同的RTL代码语言使用不同的读取RTL代码的命令，如read_vhdl是读取VHDL代码，read_verilog是读取verilog代码， read_sverilog是读取SystemVerilog代码。如果服务器配置有qsub或bsub 引擎的话esyn引擎在Bottom-Up综合策略可以一次提交然后由esyn引擎调用qsub或bsub根据芯片层次结构依序综合，减少人员的等待以及提升综合的效率。

图11和图12是esyn引擎生成出的综合环境的一部分。图11和图12 是core层的综合环境，表达的是SCD-Auto在生成综合环境时会根据使用者定义的综合策略(Bottom-Up)，因此core层之下的子系统会直接读取综合好的网表或综合库文件(如ddc)，读取网表或综合库文件(如ddc)由使用者定义。

图13是SCD-Auto的esyn引擎生成的makefile，由图1知道整个 SCD-Auto是基于gmake来搭建环境的。从生成的makefile可以知道core 层之下有periph、ddr、axi和cpu等4个子系统，而且core层的综合环境会等待4个子系统综合完毕之后才会开始综合core层的代码。

chip层的综合环境类似core层，唯一的差异是chip层次的代码chip.v、 iomux.v和iopad.v都是网表级别的代码并在chip层的综合环境不需要编译只需要链接即可。这个是为了芯片实现的DFT阶段以及APR阶段可以更容易的定义群组和约束。esyn引擎除了支持Bottom-Up和Top-Down的综合策略之外，还支持生成的综合环境已经把综合工具的选项以及工艺库指定的路径一并生成出来，此方法的好处是避免负责不同模块或子系统的工程师使用的选项不同造成顶层工程师的困扰；项目的工艺库一并在生成的综合环境指定的好处是避免不同工程师指定到不同工艺库造成后续阶段的困扰以及重工。在生成出来chip层的综合环境还会一并改变ScanEnable net 的命名以及移除ScanEnable在chip的端口，这是为了跟CSV定义的管脚复用匹配也是为了在下一DFT阶段预先做的准备。

如图14所示，生成可测试电路运行环境包括：通过所述智能可测试引擎依次产生模块dft(可测试电路)环境、core层dft环境以及chip层dft 环境。

如图15所示，生成可测试电路运行环境的详细流程如下：产生可测试电路环境；判断模块或子系统顶层网表是否存在，若不存在，产生错误报告；若存在，插入scan_en,scan_di和scan_do的模块或子系统顶层扫描网表，产生模块或子系统可测试电路规则报告；判断core层网表是否存在，若不存在，产生错误报告；若存在，插入core层扫描网表，产生core层可测试电路规则报告；判断chip层网表是否存在，若不存在，产生错误报告，若存在，连接跟CSV(芯片管脚定义文件)定义的scan_en,scan_di和scan_do 单元库以及产生post-scan网表，产生chip层可测试电路规则报告。

图14和图15描述的是edft引擎生成DFT环境的方法，跟esyn引擎一样也是从底层模块逐步往上到子系统、core层再到chip层。在模块、子系统或core层edft引擎生成的环境均会自动插入ScanEnable,scan_di和 scan_do等信号；在chip层时edft引擎则会依据CSV的管脚复用将 ScanEnable,scan_di和scan_do等端口链接到CSV定义的管脚上。

图16和图17可以知道SCD-Auto芯片自动化平台的edft引擎在chip 层级生成的DFT环境会依据CSV管脚复用的文本文件自动链接SCAN_EN, SCAN_CLK,SCAN_RST,SCAN_DI和SCAN_DO等信号。复杂SoC芯片设计电路有可能需要更多的SCAN_CLK和SCAN_RST，SCD-Auto平台中的edft引擎同时使用者定义更多的SCAN_CL和SCAN_RST，只要使用者确保CSV和iomux管脚复用中链接电路的点一致即可。在core层以及core 层以下如模块或子系统层级的DFT环境，从图17也可以知道SCD-Auto的 edft引擎生成出来的DFT环境会自动生成ScanEnable,scan_di和scan_do等信号。在开发阶段时，edft引擎会根据不同层级的设计生成不同的 *.checktest.dft.rpt，如果是core层则生成core.checktest.dft.rpt，如果是chip 层则生成chip.checktest.dft.rpt。使用者可以根据这个报告中违例的单元是因为时

如图18所示，生成形式验证运行环境包括：通过所述智能形式验证引擎依次产生模块formal(形式验证)环境、core层formal环境以及chip层 formal环境。

如图19所示，生成形式验证运行环境的详细流程如下：产生形式验证环境；判断网表是否存在，若不存在，产生错误报告；若存在，判断是否需读入底层模块形式验证设置文件(如svf文件)，如果是，读入所述底层模块形式验证设置文件；比对所述RTL代码和所述网表是否一致，直到比对结束产生比对报告。

在SCD-Auto芯片自动化平台中已经部署形式验证eformal引擎，跟esyn 引擎类似，会根据芯片设计的层级以及综合策略Bottom-Up或Top-Down 来决定eformal引擎生成的形式验证环境要如何调用形式验证的信息或资源。基本上只要RTL vs.Gate的比对都需要调用形式验证的信息或资源，这是为了保证综合工具在综合是改变信号名称的信息可以让形式验证工具得知，增加形式验证比对的正确率。

如图20所示，是SCD-Auto芯片自动化平台中eformal引擎生成的形式验证环境的开头一部分，可以知道支持多核处理器操作，只要工具和服务器支持eformal引擎即可调用多核处理器运行形式验证工具，如果工具或服务器不具备多核处理操作则eformal引擎则会忽略多核的操作。另外使用者也可以依据综合的策略定义该层级的形式验证是Bottom-Up或者是 Top-Down，eformal引擎生成的形式验证环境跟esyn和edft引擎生成的环境一样所有的参数定义都是生成出来的，并不需要所有的模块负责人改动参数，这些参数定义只有项目负责人有改动的权限，这样可以保证SoC芯片开发阶段所有模块或子系统所使用的参数定义均一致，避免模块工程师为了比对通过使用不符合规定的手段或工具命令选项，造成芯片在顶层遇到不可预期的问题、造成项目时间的延期和项目交付质量问题；因此SCD-Auto芯片自动化开发平台中eformal，esyn和edft引擎均是秉持相同理念，在这些环节生成出来的环境中的参数定义均由项目负责人统一定义，确保在项目中所有工具的选项以及策略都是可控范围下，保证项目在可控的情况下进行。

如图21所示，截图的定义也是eformal引擎生成的，以业界一家EDA 工具为例，其中chip.svf的chip是根据生成时的层级生成的，截图显示的是chip层，所以显示的是chip，如果是core层级则生成出来的会是core.svf，如果是cpu层级则以此类推生成出来的是cpu.svf。eformal引擎读取RTL比对的文件跟esyn综合读取的文件是同一个且是SCD-Auto芯片自动化平台自动生成的，也因此eformal引擎也会基于读取的RTL代码是VHDL、VERILOG还是SVERLOG来判断用read_vhdl、read_verilog还是 read_sverilog命令来读取相对应的RTL代码，这样可以确保避免人为疏失造成不可预期的错误。SCD-Auto芯片自动化平台的eformal引擎在每次运行形式验证均会生成报告方便使用者在比对不通过时可以容易的定位出问题点。

图22是本申请一实施例提供的集成电路芯片的自动开发的流程示意图。通过gen_iomux引擎(智能管脚引擎)、vp引擎(智能虚拟连线引擎)、 def引擎(智能验证引擎)、esyn引擎(智能综合引擎)、edft引擎(智能可测试引擎)、eformal引擎(智能形式验证引擎)简化从芯片规格定义、芯片设计/集成、验证、综合、DFT、形式验证等不同阶段所需的繁琐工作。

在芯片规格定义阶段，在CSV提供芯片管脚定义以及复用关系， SCD-Auto会自动生成chip.v，iomux.v和iopad.v三个芯片顶层文件；chip.v 是整个芯片所需要的IO端口，以及包括,iomux，iopad和core；iomux是规格定义时定义管脚复用以及边界扫描链的管脚RTL代码，iopad是chip端口定义所需IO类型和连接RTL代码，core是整个芯片内部模块的顶层RTL 文件。

在芯片设计、集成开发和验证阶段SCD-Auto可以将一些人为的错误提前暴露出来，以及提供智能的连线；在生成RTL代码时SCD-Auto平台会检查连线位宽是否匹配以及端口输入/输出属性是否匹配。另外在这个阶段会产生寄存器头文件，RTL代码的参数、验证用例参数以及软件寄存器参数均使用此寄存器参数定义确保设计、验证和软件均使用同一个寄存器参数定义文件。

在芯片综合阶段SCD-Auto支持Bottom-Up和Top-Down策略，会产生各个模块、各个子系统的综合环境。综合环境包括工艺库路径、业界标准综合工具的综合选项以及运行的Makefile；此阶段也支持排序假如服务器支持qsub或bsub等排序引擎，此阶段的排序如果是Bottom-Up会根据设计的层次结构以及子系统的层次从最底层开始综合，然后依次往上一层次最终到core层以及chip顶层；如果是Top-Down策略则会从chip层往下综合整个芯片。

在芯片DFT阶段SCD-Auto会产生各个模块、各个子系统的DFT环境，可以检查设计是否符合SCAN的规则。SCD-Auto产生的DFT环境包括DFT 工具的参数选择和运行的Makefile以及调用第三方DFT工具。顶层会依据定义的扫描链使能、扫描链输入、扫描链输出、扫描链时钟、扫描链复位以及扫描压缩等在CSV管脚定义的电路链接到指定标准单元。SCD-Auto 同时支持指定扫描链数、每个扫描链的寄存器个数以及DFT工具的一些参数选项。

在芯片形式验证阶段SCD-Auto会产生各个模块、各个子系统的形式验证环境，检查设计的RTL是否跟综合后的网表行为一致。SCD-Auto产生的形式验证环境包括Formal工具的参数选择和运行的Makefile。SCD-Auto 产生的Formal环境会依据设计的层次结构采用Bottom-Up或Top-Down的策略，Bottom-Up综合策略时在上一层级设计时形式验证会调用形式验证设置文件(如svf)保证RTL和网表比对时的正确性，另外SCD-Auto支持业界标准的形式验证工具。

因为SCD-Auto将个别单独的引擎利用gmake串联起来，生成好的环境依然可以利用gmake来运行；也就是说SCD-Auto芯片自动化平台可以直接运行生成好的运行文件或者直接运行makefile。利用makefile还可以跟 grid engine或load balance负载均衡等软硬件搭配使用，可以让服务器利用率大幅度的提升和释放工程师资源。

同时SCD-Auto芯片自动化平台所有的操作均在单一平台Linux或 UNIX下完成，不需要跨不同OS来完成。比如在Windows环境下定义好寄存器再经由套件生成RTL代码后再回传至Linux或UNIX环境，因为文件导出和导入容易导致操作文件疏失或传输造成文件不匹配而且可能文件传输有可能有档案传输权限的问题。SCD-Auto芯片自动化平台不管是产生寄存器的RTL代码、模块之间的连线或者顶层chip层级的RTL代码产生均在 Linux或UNIX环境下，而且只需要make rtl简单的操作，可以让刚开始接触此平台不熟悉环境的工程师能够很快的上手。

SCD-Auto芯片自动化开发平台还有个最大的优势是所有在项目中的使用者都可以更新检查，每一个人都可以是检查者确保整个项目的数据是否完整有无上传未被验证过的代码破坏项目当前的数据库，另外SCD-Auto 芯片自动化平台再搭配类似SCDTek内部的mini regression环境可以实时在预设的时间运行预先设置好的测试用例确保项目的数据库如果被破坏最长不会超过半天12小时，如果出问题可以将出问题的时间窗缩小到12小时内或者更短，这取决于mini regression一次的最长时间多长；如果跑一轮 miniregression只需要4小时则可以设置每6小时运行一次mini regression 将出问题的时间窗缩小到6小时内。这些都是为了能尽早发现项目数据库有没有被破坏，如果破坏可以尽可能的提早知道。另外SCD-Atuo芯片自动化平台更适合多地同时开发，因为数据上传数据库在预先设置的时间窗内就可以知道上传的数据是否有无问题；因为可以多地、甚至不同时区同时开发，因此对于这个项目的进度可以更好的推进。如果再搭配版本控制以及gridengine则每次自动运行可以确保项目的数据库都是最新的RTL代码、验证环境和测试用例且可以平衡服务器的负载和提高服务器的利用率。

这也是为什么SCDTek的SCD-Auto芯片自动化开发平台会在各个独立的引擎架设在gmake环境以及搭配Linux/UNIX服务器上的grid engine功能，因为这样可以才能让基于SCD-Auto流程开发的芯片环境是一个针对芯片设计开发的一个系统平台工具；同时SCD-Auto芯片自动化平台可以让使用者基于自身的习惯做更好的扩充功能。

本申请上述提供的技术方案：

1、整个SoC自动化开发平台大幅度的降低人为的干预以及人为造成的问题；

2、整个SoC自动化开发平台尽可能的不改变RTL设计工程师的开发习惯；

3、整个SoC自动化开发环境均在同一个操作系统平台(Linux或 Unix)；

4、整个SoC自动化开发平台输入文件是csv文本文件以及def寄存器定义文件；

5、整个SoC自动化开发平台的管脚定义和复用CSV文件适应不同厂家的IO库和管脚信号定义；

6、整个SoC自动化开发平台整合芯片RTL设计(Design)、FPGA、EDA 验证(Verification)、综合(Synthesis)、形式验证(Formal)以及软件(Software) 等不同阶段所需环境以及工具；

7、SoC自动化开发平台会自动对同一层级模块间的连线以及上下层级的模块之间的连线；

8、SoC自动化开发平台会自动生成每个模块以及每个子系统的顶层 RTL文件

9、SoC自动化开发平台会自动生成寄存器头文件给设计、验证以及软件确保三个阶段的寄存器文件跟RTL代码一致；

10、SoC自动化开发平台同时生成html的寄存器文件；

11、SoC自动化开发平台会自动生成芯片每个模块的寄存器读写的C 验证用例；

12、SoC自动化开发平台会自动生成综合(Synthesis)、DFT、形式验证环境的执行文件；

13、SoC自动化开发平台支持不同EDA厂家的工具；

14、SoC自动化开发平台的csv负责整个SoC芯片的管脚复用，每个 I/O管脚的复用可以基于芯片实际应用扩展4个、8个、16种或者更多的功能复用；

15、SoC自动化开发平台的def寄存器环境支持8比特、32比特以及 64比特CPU处理器类型；

16、SoC自动化开发平台保证RTL代码的在不同工艺节点的可移植性。整个芯片设计所使用的标准单元库、时钟门控单元、时钟选择单元、 SRAM以及异步处理单元均由自动化开发平台提供，可以最大幅度的在不同工艺节点之间移植；

17、SoC自动化开发平台基于csv自动生成芯片的最顶层RTL文件 chip.v、管脚复用RTL、文件iomux.v以及基于工艺I/O库的RTL文件iopad.v；

18、SoC自动化开发平台的csv支持不同I/O库的特性如输出使能的极性、I/O的上下拉电阻、slew rate、输出驱动能力、输入迟滞、输入使能、开漏类型I/O，…，等I/O特性；

19、SoC自动化开发平台自动生成BSD边界扫描链电路逻辑；

20、SoC自动化开发平台支持Bottom-Up和Top-Down芯片实现流程

21、SoC自动化开发平台生成的综合环境限制每个模块或子系统的负责人改动调用的工艺库以及综合工具的选项，避免负责人改动造成整个芯片实现策略不同引起不可预期的问题；

22、SoC自动化平台生成的形式验证环境限制每个模块或子系统的负责人调用工具的选项，避免负责人改动造成整个芯片实现策略改变造成不可预期的问题；

23、SoC自动化平台对于相同模块不同个数的例化可以直接使用回圈的方式然后生成RTL代码。此方法大幅度减少代码输入错误的可能性以及 RTL代码功能错误后容易定位问题，因为此方法造成的功能错误都会是整体错误而不会是只有某几个被例化模块出错；

24、SoC自动化开发平台可以基于def寄存器定义文件自动生成每个模块的寄存器RTL代码，此寄存器的接口支持APB和AHB从设备接口；

25、SoC自动化平台支持芯片开发阶段的综合设计检查，确保每个模块和子系统负责人交付给上一级综合负责人时是符合规定的；

26、SoC自动化开发平台支持芯片开发阶段的DFT规则检查，确保每个模块或子系统负责人交付给上一级DFT负责人时的DFT规则是符合规定

27、SoC自动化开发平台的形式验证环境确保每个模块或子系统负责人交付给上一级形式验证负责人时的形式验证结果是符合规定；

28、SoC自动化开发平台支持项目管理人员检查开发人员的结果是否符合要求；

29、SoC自动化开发平台提供项目管理人员对于项目进度可从多方面来评估进度是否如工程师评估的一致以及差异；

30、SoC自动开发平台会自动检查连线之间的位宽是否匹配，不匹配则不会正常生成RTL代码；

31、SoC自动开发平台会自动检查连线之间的方向属性是否匹配，不匹配则不会正常生成RTL代码；

32、SoC自动开发平台整合全芯片的中断号以及DMA通道号；

33、SoC自动开发平台的寄存器测试用例使用生成的寄存器头文件定义参数完成寄存器地址寻址以及寄存器比特的读写；

34、SoC自动化开发平台尽可能的保证ASIC和FPGA两者RTL代码的一致性；也就是说，RTL设计代码中的标准单元库、Memory、时钟门控单元、时钟选择单元、I/O、chip.v、iomux.v和iopad.v这些代码ASIC和 FPGA都一致；

35、SoC自动化开发平台在FPGA环境中基于csv自动生成用户基于项目所需的chip.v和iopad.v。

下述为本申请装置实施例，可以用于执行本申请上述集成电路芯片的自动开发方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请集成电路芯片的自动开发方法实施例。

图23为本申请一实施例示出的集成电路芯片的自动开发装置的框图。如图23所示，该装置包括：文件获取模块2310、代码生成模块2320、芯片验证模块2330以及环境生成模块2340。

文件获取模块2310，用于获取芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件；

代码生成模块2320，用于根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，生成RTL代码；

芯片验证模块2330，用于根据所述模块寄存器定义文件，通过智能仿真引擎生成芯片各个模块寄存器验证用例；

环境生成模块2340，用于依次通过智能综合引擎、智能可测试引擎以及智能形式验证引擎，生成综合运行环境、生成可测试电路运行环境、生成形式验证运行环境。

上述装置中各个模块的功能和作用的实现过程具体详见上述集成电路芯片的自动开发方法中对应步骤的实现过程，在此不再赘述。

在本申请所提供的几个实施例中，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

Claims

1.一种集成电路芯片的自动开发方法，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，生成RTL代码，包括：

根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，产生寄存器头文件、模块RTL代码、core层RTL代码、chip层RTL代码。

3.根据权利要求2所述的方法，其特征在于，所述根据所述芯片管脚定义文件、模块连接定义文件以及模块寄存器定义文件，产生寄存器头文件、模块RTL代码、core层RTL代码、chip层RTL代码，包括：

4.根据权利要求1所述的方法，其特征在于，所述依次通过智能综合引擎、智能可测试引擎以及智能形式验证引擎，生成综合运行环境、生成可测试电路运行环境、生成形式验证运行环境，包括：

通过所述智能综合引擎依次产生模块综合环境、core层综合环境以及chip层综合环境；

5.根据权利要求1所述的方法，其特征在于，所述通过所述智能综合引擎依次产生模块综合环境、core层综合环境以及chip层综合环境，包括：

读入模块的综合文件列表；

6.根据权利要求1所述的方法，其特征在于，所述通过所述智能可测试引擎依次产生模块可测试电路环境、core层可测试电路环境以及chip层可测试电路环境，包括：

产生可测试电路运行环境；

判断core层网表是否存在，若存在，插入core层扫描网表，产生core层可测试电路规则报告；

判断chip层网表是否存在，若存在，连接所述芯片管脚定义文件定义的单元库，产生post-scan网表，产生chip层可测试电路规则报告。

7.根据权利要求1所述的方法，其特征在于，所述通过所述智能形式验证引擎依次产生模块形式验证环境、core层形式验证环境以及chip层形式验证环境，包括：

产生形式验证运行环境；

8.一种集成电路芯片的自动开发装置，其特征在于，包括：

9.一种电子设备，其特征在于，所述电子设备包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行权利要求1-7任意一项所述的集成电路芯片的自动开发方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序可由处理器执行以完成权利要求1-7任意一项所述的集成电路芯片的自动开发方法。