CN120046552B - 跨Die数据通路的设计方法、装置、电子设备、可读存储介质和程序产品 - Google Patents

Abstract

本申请涉及一种跨Die数据通路的设计方法、装置、电子设备、可读存储介质和程序产品。通过对芯片跨Die数据通路进行阶段设计，产生跨Die数据通路每个阶段的RTL代码，并对芯片硬件HW验证按模式划分，将每个阶段的RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证，并选择不同阶段的RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试。其通过对芯片跨Die数据通路进行阶段设计，简化了设计流程，降低了设计复杂度；通过将每个阶段的RTL代码作为待测设计DUT与验证平台连接进行验证及软件测试，提高了验证的灵活性和效率，增加了芯片软件测试的可靠性。

Description

跨Die数据通路的设计方法、装置、电子设备、可读存储介质和 程序产品

技术领域

本申请涉及芯片设计技术领域，特别是涉及一种跨Die数据通路的设计方法、装置、电子设备、可读存储介质和程序产品。

背景技术

随着芯片设计规模的不断增大和功能的日益复杂化，出现了跨Die（是指从晶圆上切割下来的单个未封装的半导体芯片，也被称为裸芯片或晶粒，它是芯片的核心部分，包含了芯片的所有功能电路）数据通路的设计。其通过将一个复杂的芯片设计分成多个Die进行制造，然后通过特定的封装技术将它们集成在一起。跨Die数据通路就是在这些不同的Die之间建立起数据传输的通道，使得各个Die能够协同工作，共同完成芯片的整体功能。

芯片跨Die数据通路设计通常涉及芯片硬件（Hardware，简称HW）设计、芯片硬件HW验证和芯片软件（Software，简称SW）测试等。不仅设计复杂度高、验证繁琐，且软件测试周期长、迭代频繁。因此，如何简化芯片跨Die数据通路的设计、验证及测试过程，是目前亟待解决的问题。

发明内容

基于此，有必要针对上述技术问题，提供一种能够简化芯片跨Die数据通路设计、验证及测试过程的跨Die数据通路的设计方法、装置、电子设备、可读存储介质和程序产品。

第一方面，本申请提供了一种跨Die数据通路的设计方法，所述方法包括：

对芯片硬件HW设计按阶段划分，产生跨Die数据通路每个阶段的RTL代码；

对芯片硬件HW验证按模式划分，将每个阶段的所述RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证；

对不同阶段的所述RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试。

在其中一个实施例中，所述对芯片硬件HW设计按阶段划分，产生跨Die数据通路每个阶段的RTL代码，包括：根据跨Die数据通路的功能需求，将芯片硬件HW设计划分为多个阶段；针对每个阶段，生成对应阶段的功能设计代码、空壳设计代码和调试回环设计代码，作为所述阶段的RTL代码。

在其中一个实施例中，针对任一阶段的空壳设计代码，作为上一阶段的功能设计代码的顶层代码，且端口信号保持一致。

在其中一个实施例中，针对每个阶段的调试回环设计代码，通过配置开关控制打开或关闭。

在其中一个实施例中，所述对芯片硬件HW验证按模式划分，将每个阶段的所述RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证，包括：根据跨Die数据通路的功能需求，将所述芯片硬件HW验证划分为多个模式；针对每个模式，将每个阶段的所述RTL代码作为待测设计DUT与对应模式下的验证平台连接，以对每个模式下不同阶段的待测设计DUT进行功能验证。

在其中一个实施例中，所述模式包括跨Die的互连模式，芯片Die与验证工具的互连模式以及芯片Die的回环模式；所述验证平台包括子系统验证平台、片上系统验证平台和硬件仿真验证平台中的至少一个。

在其中一个实施例中，所述对不同阶段的所述RTL代码进行芯片软件SW测试，包括：根据芯片软件SW测试需求，选择不同阶段的所述RTL代码作为被测对象；构建软件SW测试环境，将选择的所述RTL代码集成到所述软件SW测试环境中；生成测试用例，对所述被测对象进行跨Die数据通路功能测试。

在其中一个实施例中，所述跨Die数据通路每个阶段包括上行数据通路、下行数据通路和调试回环数据通路中的至少一种。

第二方面，本申请还提供了一种跨Die数据通路的设计装置，所述装置包括：

代码生成模块，被配置为执行对芯片硬件HW设计按阶段划分，产生跨Die数据通路每个阶段的RTL代码；

验证模块，被配置为执行对芯片硬件HW验证按模式划分，将每个阶段的所述RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证；

测试模块，被配置为执行对不同阶段的所述RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试。

第三方面，本申请还提供了一种电子设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述方法的步骤。

第四方面，本申请还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述方法的步骤。

第五方面，本申请还提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述第一方面所述方法的步骤。

上述跨Die数据通路的设计方法、装置、电子设备、计算机可读存储介质和计算机程序产品，通过对芯片跨Die数据通路进行阶段设计，产生跨Die数据通路每个阶段的RTL代码，并对芯片硬件HW验证按模式划分，将每个阶段的RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证，并选择不同阶段的RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试。其通过对芯片跨Die数据通路进行阶段设计，从而简化了设计流程，降低了设计复杂度；通过将每个阶段的RTL代码作为待测设计DUT与验证平台连接进行验证，提高了验证的灵活性和效率；通过选择不同阶段的RTL代码进行跨Die数据通路的软件SW测试，增强了测试的可选择性，提高了测试覆盖率，缩短了测试周期，减少了迭代次数，还增加了芯片软件测试的可靠性。

附图说明

为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对本申请实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为一个实施例中跨Die数据通路的设计方法的流程示意图；

图2为一个实施例中硬件HW设计步骤的流程示意图；

图3为一个实施例中硬件HW设计的架构示意图；

图4为一个实施例中硬件HW验证步骤的流程示意图；

图5为一个实施例中硬件HW验证D2V模式的架构示意图；

图6为一个实施例中硬件HW验证Loopback模式的架构示意图；

图7为一个实施例中软件SW测试步骤的流程示意图；

图8为一个实施例中软件SW测试的架构示意图；

图9为一个实施例中跨Die数据通路的设计装置的结构框图；

图10为一个实施例中电子设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅用以解释本申请，并不用于限定本申请。

在一个实施例中，如图1所示，提供了一种跨Die数据通路的设计方法，该方法包括以下步骤：

步骤102，对芯片硬件HW设计按阶段划分，产生跨Die数据通路每个阶段的RTL代码。

在芯片制造工艺中，由于单个Die的面积受到限制，或者为了实现更好的性能、功能和成本效益，会将一个复杂的芯片设计分成多个Die进行制造，然后通过特定的封装技术将它们集成在一起。从而需要进行跨Die数据通路的设计，以在这些不同的Die之间建立起数据传输的通道，使得各个Die能够协同工作，共同完成芯片的整体功能。例如，在一些高性能计算芯片中，可能会将计算单元和存储单元分别放在不同的Die上，跨Die数据通路就负责在两者之间高效传输数据。

在本实施例中，在跨Die数据通路的设计过程中，可以基于设计流程的推进、设计的复杂程度、验证和优化需求等对芯片硬件HW设计进行阶段划分，从而产生跨Die数据通路每个阶段的RTL（Register Transfer Level，指寄存器传输级，是数字电路设计中的一种高级抽象）代码。具体地，由于芯片设计是从系统级的抽象概念逐步细化到具体电路实现的过程，因此，可以从抽象到具体的流程推进，自然地将RTL设计划分为不同阶段，每个阶段都有其特定的输入、输出和任务，从而生成每个阶段的RTL代码。又由于复杂的芯片设计通常包含多个功能模块，如处理器内核、存储模块、通信接口等，因此，基于不同功能模块进行阶段划分，就可以划分出不同的RTL设计阶段，从而生成每个阶段对应功能模块的RTL代码。

本实施例通过对芯片跨Die数据通路进行阶段设计，为后续跨Die数据通路的芯片硬件HW验证和软件SW测试提供了灵活的可选择性，不仅能够提升芯片设计和验证的质量，还能够增加芯片软件SW测试的可靠性。

步骤104，对芯片硬件HW验证按模式划分，将每个阶段的RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证。

硬件HW验证是确保芯片设计符合预期功能和性能要求的关键环节。其中，模式包括跨Die的互连模式，芯片Die与验证工具的互连模式以及芯片Die的回环模式。具体地，跨Die的互连模式可以是跨Die设计代码RTL的互连D2D（Die-to-Die，是一种在同一封装内部不同Die之间实现直接互联的技术）模式。芯片Die与验证工具的互连模式是指Die的设计代码RTL与验证工具互连D2V模式。其中，验证工具可以是通用验证组件（UniversalVerification Component，简称UVC，是一种可复用的验证组件），或者也可以是验证 IPVIP（Verification Intellectual Property，是具有特定功能的预验证模块）。芯片Die的回环模式是指芯片Die的设计代码RTL的回环互连模式。

待测设计DUT（Design Under Test）指的是在芯片验证过程中，需要对其功能、性能等各项指标进行验证的目标设计部分。验证平台则可以包括子系统验证平台Testbench、片上系统验证平台和硬件仿真验证平台中的至少一个。

在本实施例中，通过对芯片硬件HW验证按模式划分，因此，针对每种模式，均可以对上述步骤各个阶段的RTL代码进行功能验证。即将每个阶段的RTL代码作为待测设计DUT与验证平台连接，从而进行跨Die数据通路不同模式下的功能验证。

在一种场景下，针对各个验证平台，也可以从上述步骤产生的各个阶段的RTL代码中选择一种或多种作为待测设计DUT，进行功能验证。

步骤106，对不同阶段的RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试。

软件SW测试在芯片开发中起着关键作用，它能够对芯片的功能进行实际应用场景下的检验，确保芯片在实际使用中能稳定、可靠地运行。在本实施例中，通过将上述完成功能验证的不同阶段的RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试。具体地，可以将上述验证平台替换为软件SW测试驱动Driver来进行功能测试。测试驱动Driver可模拟实际应用场景向芯片发送指令和数据，以接收芯片的响应并进行分析，以此来验证芯片功能的正确性。

上述跨Die数据通路的设计方法中，通过对芯片跨Die数据通路进行阶段设计，产生跨Die数据通路每个阶段的RTL代码，并对芯片硬件HW验证按模式划分，将每个阶段的RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证，并选择不同阶段的RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试。其通过对芯片跨Die数据通路进行阶段设计，从而简化了设计流程，降低了设计复杂度；通过将每个阶段的RTL代码作为待测设计DUT与验证平台连接进行验证，提高了验证的灵活性和效率；通过选择不同阶段的RTL代码进行跨Die数据通路的软件SW测试，增强了测试的可选择性，提高了测试覆盖率，缩短了测试周期，减少了迭代次数，还增加了芯片软件测试的可靠性。

在一个实施例中，如图2所示，在步骤102中，对芯片硬件HW设计按阶段划分，产生跨Die数据通路每个阶段的RTL代码，具体还可以包括：

步骤202，根据跨Die数据通路的功能需求，将芯片硬件HW设计划分为多个阶段。

具体地，在跨Die数据通路的芯片硬件HW设计过程中，可以基于跨Die数据通路的不同功能，对其设计进行阶段划分，从而得到多个阶段，每个阶段可以具有相应的功能模块。

步骤204，针对每个阶段，生成对应阶段的功能设计代码、空壳设计代码和调试回环设计代码，作为对应阶段的RTL代码。

具体地，针对每个阶段的功能模块，可以生成对应的功能设计代码；针对每个阶段，还可以设计并生成空壳Shell模块的空壳设计代码和可调试Debug的回环Loopback模块的调试回环设计代码，从而得到对应阶段的RTL代码。其通过对跨Die数据通路进行阶段化设计，从而简化了设备流程，降低了设计复杂度。

在一个示例性的实施例中，如图3所示，芯片硬件HW设计可以包括2个芯片Die：芯片Die0和芯片Die1。其中，芯片Die0和芯片Die1可以是同一份硬件HW设计代码RTL在验证平台Testbench中例化2份，将2份设计代码连接起来。跨Die数据通路Die0到Die1定义为上行数据通路Upstream，Die1到Die0定义为下行数据通路Downstream。硬件HW设计可以按照阶段Phase可以分为3个阶段Phase，包括阶段Phase0、阶段Phase1和阶段Phase2。每个阶段Phase可以产生跨Die数据通路的功能Function设计代码、空壳Shell设计代码和可调试Debug的回环Loopback设计代码。

在一种场景下，如图3所示，Die硬件HW设计在阶段Phase0时，阶段Phase1和阶段Phase2的功能Function设计代码尚未完成。阶段Phase0的功能Function设计主要为Die子系统Subsystem的顶层Top和片上系统SoC（System on Chip，系统级芯片，也称片上系统）端口信号连接，片上系统SoC发送给Die子系统Subsystem的顶层Top的数据为上行通路Upstream数据，Die子系统Subsystem的顶层Top发给片上系统SoC的数据为下行通路Downstream数据。

此时，阶段Phase1和阶段Phase2的功能Function设计代码尚未完成，芯片硬件HW设计可以产生阶段Phase1的空壳Phase1_Shell设计代码，阶段Phase1的空壳Phase1_Shell设计代码可以例化在阶段Phase0的功能Function设计代码中。同样，阶段Phase0为方便阶段Phase0功能Function设计代码的调试Debug，芯片硬件HW设计可以产生阶段Phase0的调试Debug回环Loopback设计代码，并通过开关使能Enable配置来控制打开或者关闭。

因此，每个阶段Phase的空壳Shell设计代码可以作为上一个阶段Phase的功能Function设计代码RTL的顶层Wrapper，且端口Port信号保持一致。

作为一种实施例，如图3所示。阶段Phase0设计代码RTL的顶层Top设计代码RTL为phase0_top.v，阶段Phase1设计代码RTL的顶层Top设计代码RTL为phase1_top.v，阶段Phase2设计代码RTL的顶层Top设计代码RTL为phase2_top.v。阶段Phase0设计代码RTL例化了阶段Phase1设计代码RTL，阶段Phase1设计代码RTL例化了阶段Phase2设计代码RTL。若在阶段Phase0时，例化的阶段Phase1空壳Shell设计代码RTL为phase1_top_shell.v。阶段Phase1空壳Shell设计代码RTL phase1_top_shell.v和阶段Phase1设计代码RTL的顶层Top设计代码RTL phase1_top.v的端口Port信号一致，在阶段Phase1设计时，可以直接将阶段Phase1空壳Shell设计代码phase1_top_shell.v替换为其顶层Top设计代码phase1_top.v。

在一种场景下，如图3所示，每个阶段Phase设计代码RTL均可以包括可调试Debug的回环Loopback设计代码，可通过使能Enable配置打开或关闭，通常默认为不使能Disable回环Loopback功能。具体地，阶段Phase0包括阶段Phase0的功能设计代码RTL和阶段Phase1的空壳Shell设计代码。阶段Phase0时，可以通过寄存器Register配置打开回环功能使能Enable配置。此时，阶段Phase0上行Upstream数据（TX Data，即发送数据）直接发送给下行Downstream数据（RX Data，即接收数据），而不会发送给阶段Phase1，从而完成回环Loopback功能。同理，在阶段Phase1和阶段Phase2也均可通过寄存器Register配置打开对应阶段Phase的回环功能使能Enable配置。

在一种场景下，芯片硬件HW设计可以按照阶段Phase划分，不同的阶段Phase可以使用不同的配置Configuration来区分，不同的配置Configuration可以是不同的设计代码RTL。

作为一种实施例，如图3所示，不同的配置Configuration可以通过宏定义Define来实现。3种阶段Phase“阶段Phase0、阶段Phase1、阶段Phase2”可以通过3种宏定义“宏定义PHASE0、宏定义PHASE1、宏定义PHASE2”来定义，不同的宏定义Define可以定义不同阶段Phase所对应的设计代码RTL。

具体地，可以通过不同的宏定义Define来选择使用不同的功能Funtion设计代码和空壳Shell设计代码。例如，在阶段Phase0，可以使用宏定义PHASE0来选择阶段Phase0的功能Function设计代码和阶段Phase1的空壳Phase1_Shell设计代码使用。在阶段Phase1，可以使用宏定义PHASE1来选择阶段Phase0的功能Function设计代码、阶段Phase1的功能Function设计代码和阶段Phase2的空壳Phase2_Shell设计代码使用。在阶段Phase2，可以使用宏定义PHASE2来选择阶段Phase0的功能Function设计代码、阶段Phase1的功能Function设计代码和阶段Phase2的功能Function设计代码使用。

在一个实施例中，如图4所示，在步骤104中，对芯片硬件HW验证按模式划分，将每个阶段的RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证，具体还可以包括：

步骤402，根据跨Die数据通路的功能需求，将芯片硬件HW验证划分为多个模式。

具体地，在跨Die数据通路的芯片硬件HW验证过程中，可以根据跨Die数据通路的功能需求，将芯片硬件HW验证划分为多个模式，每个模式可以对应不同的功能验证场景。

步骤404，针对每个模式，将每个阶段的RTL代码作为待测设计DUT与对应模式下的验证平台连接，以对每个模式下不同阶段的待测设计DUT进行功能验证。

具体地，可以基于上述划分的模式和阶段，针对每个模式，将各个阶段的RTL代码作为待测设计DUT与对应模式下的验证平台连接进行验证，从而实现对每个模式下不同阶段的待测设计DUT进行功能验证。例如，可以基于各种边界条件、异常情况等，以全面验证待测设计DUT的功能正确性。不仅提高了验证的灵活性和效率，还可以针对不同的阶段进行灵活的验证。

在一个示例性的实施例中，芯片硬件HW验证可以搭建验证平台Testbench。如图3所示，验证平台中的Die0通用验证组件UVC与Die0的接口Interface连接，Die1通用验证组件UVC与Die1的接口Interface连接，验证平台记分板Scoreboard用于功能Function验证结果检查。Die硬件HW验证按照Die硬件HW设计阶段Phase也可以分为3个阶段Phase：阶段Phase0、阶段Phase1和阶段Phase2。芯片Die数据通路硬件HW验证还可以按照模式Mode划分，具体可以包括：D2D模式Mode（即芯片Die0和芯片Die1互连的模式，也即跨Die的互连模式）、D2V模式Mode（即芯片Die与验证工具的互连模式，如芯片Die的设计代码RTL与通用验证组件UVC或者验证IP VIP互连的模式）和芯片Die的回环模式（即设计代码回环Loopback互连模式Mode）。从而将每个阶段Phase产生的设计代码RTL作为待测设计DUT与验证平台Testbench连接，以进行跨Die数据通路不同模式Mode下每个阶段Phase的功能Function验证。

具体地，如图3所示，芯片Die0到芯片Die1为上行通路Upstream。芯片Die0的发送数据TX Data通过上行通路Upstream发送到芯片Die1，芯片Die1则接收数据RX Data，并发送到Die1通用验证组件UVC。芯片Die1的发送数据TX Data通过下行通路Downstream发送到芯片Die0，则芯片Die0接收数据RX Data，并发送到Die0通用验证组件UVC。从而实现跨Die数据通路的功能验证。

在一种场景下，芯片Die数据通路硬件HW验证可以按照阶段Phase划分，不同配置Configuration的阶段Phase使用不同的设计代码文件列表Filelist，以对不同阶段的设计代码RTL进行功能验证。

具体地，如图3所示。宏定义PHASE0配置了阶段Phase0使用的设计代码文件列表Filelist，其包括阶段Phase0的功能Function设计代码和阶段Phase1的空壳Phase1_Shell设计代码。在D2D模式Mode下，芯片Die0和芯片Die1互连即芯片Die0的阶段Phase1的空壳Phase1_Shell设计代码端口Port和芯片Die1的阶段Phase1的空壳Phase1_Shell设计代码端口Port互连。依此类推，宏定义PHASE1还配置了阶段Phase1使用的设计代码文件列表Filelist，其包括阶段Phase0和阶段Phase1的功能Function设计代码，阶段Phase2的空壳Phase1_Shell设计代码。宏定义PHASE2则配置了阶段Phase2使用的设计代码文件列表Filelist，包括阶段Phase0、阶段Phase1和阶段Phase2的功能Function设计代码。从而实现对不同阶段的设计代码RTL进行功能验证。

在一种场景下，芯片Die数据通路硬件HW验证还可以按照模式Mode划分，从而在不同模式下对各个阶段的设计代码RTL进行功能验证。

具体地，验证平台Testbench可以包括3种模式Mode：D2D模式Mode、D2V模式Mode和Loopback模式Mode。其中，D2D模式Mode为芯片Die设计代码RTL之间互连的模式Mode；D2V模式Mode为芯片Die设计代码RTL和通用验证组件UVC或者验证IP VIP互连模式Mode；Loopback模式Mode为芯片Die设计代码RTL回环模式Mode。

可以理解的是，每种模式Mode均包括3个阶段Phase的设计代码RTL。如图3所示的D2D模式Mode，其包括阶段Phase0、阶段Phase1和阶段Phase2的设计代码RTL。如图5所示的D2V模式Mode和图6所示的Loopback模式Mode，其均包括阶段Phase0、阶段Phase1和阶段Phase2的设计代码RTL。

因此，每个阶段Phase产生的设计代码RTL均可以作为待测设计DUT，按照阶段Phase划分进行功能Function验证。如图3所示的D2D模式Mode下，可以将宏定义PHASE0配置的阶段Phase0使用的设计代码RTL作为DUT进行功能Function验证，从而验证Phase0上行Upstream数据TX Data发送和下行Downstream数据RX Data接收功能。

在一种场景下，验证平台可以包括子系统验证平台、片上系统验证平台和硬件仿真验证平台中的至少一个。则针对每种验证平台，可以从上述3个阶段Phase的设计代码RTL中选择至少一个阶段Phase的设计代码RTL进行验证。

作为一种实施例，如图3所示，针对片上系统SoC或者硬件仿真Emu的验证，可以选择跨Die设计代码RTL互连D2D模式Mode下的阶段Phase2的设计代码RTL进行验证。在片上系统SoC验证时，验证平台Testbench的激励产生由子系统Subsystem验证平台Testbench的Die0和Die1通用验证组件UVC变为与子系统Subsystem连接的上游和下游的子系统Subsystem。此时芯片Die0和芯片Die1的设计代码RTL文件列表Filelist包括阶段Phase0、阶段Phase1和阶段Phase2的功能Function设计代码，芯片Die0和芯片Die1的设计代码RTL互连。

同理，硬件仿真Emu验证同样可以选择跨Die的设计代码RTL互连D2D模式Mode下的阶段Phase2的设计代码RTL进行验证，如此使片上系统SoC和硬件仿真Emu验证的跨Die的设计代码RTL保持一致。

此外，验证环境还可以将阶段Phase0和Phase1连接的TX（Transmit，发送）和RX（Receive，接收）信号通过Force连接起来，以作为外回环测试。

在一个实施例中，如图7所示，在步骤106中，对不同阶段的RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试，具体还可以包括：

步骤702，根据芯片软件SW测试需求，选择不同阶段的RTL代码作为被测对象。

具体地，在跨Die数据通路的芯片软件SW测试过程中，可以根据芯片软件SW测试需求，选择不同阶段的RTL代码作为被测对象。例如，可以选择阶段Phase0或阶段Phase1的RTL代码作为被测对象。从而能够增强软件测试的可选择性，缩短了测试周期，且能够减少迭代次数。

步骤704，构建软件SW测试环境，将选择的RTL代码集成到软件SW测试环境中。

其中，测试环境可以包括模拟器、调试工具等。通过构建软件SW测试环境，并将选择的RTL代码集成到软件SW测试环境中，从而便于后续的测试。

步骤706，生成测试用例，对被测对象进行跨Die数据通路功能测试。

其中，测试用例可以覆盖各种正常情况和异常情况，以全面测试被测对象的功能正确性。

在一个示例性的实施例中，在芯片软件SW测试过程中，可以选择不同阶段Phase的设计代码RTL进行功能Function测试。如图8所示，与芯片Die数据通路硬件HW验证类似，芯片Die数据通路软件SW测试的被测对象仍为芯片Die硬件HW设计过程中各阶段的设计代码RTL。芯片Die数据通路软件SW测试可选择芯片Die硬件HW设计阶段Phase0、阶段Phase1和阶段Phase2中的一种或多种代码RTL进行功能Function测试。

可以理解的是，芯片软件SW测试过程中可以选择不同阶段Phase，完成软件SW测试驱动Driver，其中，软件SW测试驱动Driver的版本应该与选择的硬件HW的阶段Phase相对应。具体可以通过芯片软硬件版本管理，使得硬件HW设计阶段Phase设计代码RTL的版本和软件SW测试驱动Driver的版本保持一致，从而便于功能Function问题定位。

在一种场景下，软件SW测试对设计代码RTL进行功能Function测试，可以选择在子系统Subsystem验证环境或者片上系统SoC验证无法覆盖的功能点进行测试，还可以考虑与系统System的相关联的功能Function测试。具体如图8所示，软件SW驱动Driver运行，通过芯片接口例如PCIe与芯片Die0和Die1进行交互，再通过片上网络（network-on-chip，简称NoC）和子系统Subsystem交互。由于软件SW测试为真实的应用场景，因此能够测试到子系统Subsystem或者片上系统SoC验证无法测试到的功能Function。从而能够提高测试覆盖率，增加了芯片软件测试的可靠性。

应该理解的是，虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

基于同样的发明构思，本申请实施例还提供了一种用于实现上述所涉及的跨Die数据通路的设计方法的跨Die数据通路的设计装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似，故下面所提供的一个或多个跨Die数据通路的设计装置实施例中的具体限定可以参见上文中对于跨Die数据通路的设计方法的限定，在此不再赘述。

在一个示例性的实施例中，如图9所示，提供了一种跨Die数据通路的设计装置，包括：代码生成模块902、验证模块904和测试模块906，其中：

代码生成模块902，被配置为执行对芯片硬件HW设计按阶段划分，产生跨Die数据通路每个阶段的RTL代码；

验证模块904，被配置为执行对芯片硬件HW验证按模式划分，将每个阶段的所述RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证；

测试模块906，被配置为执行对不同阶段的所述RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试。

在一个示例性的实施例中，代码生成模块具体被配置为执行：根据跨Die数据通路的功能需求，将芯片硬件HW设计划分为多个阶段；针对每个阶段，生成对应阶段的功能设计代码、空壳设计代码和调试回环设计代码，作为所述阶段的RTL代码。

在一个示例性的实施例中，针对任一阶段的空壳设计代码，作为上一阶段的功能设计代码的顶层代码，且端口信号保持一致。

在一个示例性的实施例中，针对每个阶段的调试回环设计代码，通过配置开关控制打开或关闭。

在一个示例性的实施例中，验证模块具体还被配置为执行：根据跨Die数据通路的功能需求，将所述芯片硬件HW验证划分为多个模式；针对每个模式，将每个阶段的所述RTL代码作为待测设计DUT与对应模式下的验证平台连接，以对每个模式下不同阶段的待测设计DUT进行功能验证。

在一个示例性的实施例中，所述模式包括跨Die的互连模式，芯片Die与验证工具的互连模式以及芯片Die的回环模式；所述验证平台包括子系统验证平台、片上系统验证平台和硬件仿真验证平台中的至少一个。

在一个示例性的实施例中，测试模块具体还被配置为执行：根据芯片软件SW测试需求，选择不同阶段的所述RTL代码作为被测对象；构建软件SW测试环境，将选择的所述RTL代码集成到所述软件SW测试环境中；生成测试用例，对所述被测对象进行跨Die数据通路功能测试。

在一个示例性的实施例中，所述跨Die数据通路每个阶段包括上行数据通路、下行数据通路和调试回环数据通路中的至少一种。

上述跨Die数据通路的设计装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个示例性的实施例中，提供了一种电子设备，其内部结构图可以如图10所示。该电子设备包括处理器、存储器、输入/输出接口、通信接口、显示单元和输入装置。其中，处理器、存储器和输入/输出接口通过系统总线连接，通信接口、显示单元和输入装置通过输入/输出接口连接到系统总线。其中，该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的输入/输出接口用于处理器与外部设备之间交换信息。该电子设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、移动蜂窝网络、近场通信（Near Field Communication，NFC）或其他技术实现。该计算机程序被处理器执行时以实现一种跨Die数据通路的设计方法。该电子设备的显示单元用于形成视觉可见的画面，可以是显示屏、投影装置或虚拟现实成像装置。显示屏可以是液晶显示屏或者电子墨水显示屏，该电子设备的输入装置可以是显示屏上覆盖的触摸层，也可以是电子设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图10中示出的结构，仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个示例性的实施例中，提供了一种电子设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

需要说明的是，本申请所涉及的用户信息（包括但不限于用户设备信息、用户个人信息等）和数据（包括但不限于用于分析的数据、存储的数据、展示的数据等），均为经用户授权或者经过各方充分授权的信息和数据，且相关数据的收集、使用和处理需要符合相关规定。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性存储器和易失性存储器中的至少一种。非易失性存储器可包括只读存储器（Read-Only Memory，ROM）、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器（Resistive Random Access Memory，ReRAM）、磁变存储器（Magnetoresistive RandomAccess Memory，MRAM）、铁电存储器（Ferroelectric Random Access Memory，FRAM）、相变存储器（Phase Change Memory，PCM）、石墨烯存储器等。易失性存储器可包括随机存取存储器（Random Access Memory，RAM）或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器（Static Random Access Memory，SRAM）或动态随机存取存储器（Dynamic Random Access Memory，DRAM）等。本申请提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器、人工智能（Artificial Intelligence，AI）处理器等，不限于此。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本申请记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (10)

1.一种跨Die数据通路的设计方法，其特征在于，所述方法包括：

对芯片硬件HW设计按阶段划分，产生跨Die数据通路每个阶段的RTL代码；

对芯片硬件HW验证按模式划分，将每个阶段的所述RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证；

对不同阶段的所述RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试；

所述对芯片硬件HW设计按阶段划分，产生跨Die数据通路每个阶段的RTL代码，包括：

根据跨Die数据通路的功能需求，将芯片硬件HW设计划分为多个阶段；

针对每个阶段，生成对应阶段的功能设计代码、空壳设计代码和调试回环设计代码，作为所述阶段的RTL代码；针对每个阶段的调试回环设计代码，通过配置开关控制打开或关闭。

2.根据权利要求1所述的方法，其特征在于，

针对任一阶段的空壳设计代码，作为上一阶段的功能设计代码的顶层代码，且端口信号保持一致。

3.根据权利要求1所述的方法，其特征在于，所述对芯片硬件HW验证按模式划分，将每个阶段的所述RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证，包括：

根据跨Die数据通路的功能需求，将所述芯片硬件HW验证划分为多个模式；

针对每个模式，将每个阶段的所述RTL代码作为待测设计DUT与对应模式下的验证平台连接，以对每个模式下不同阶段的待测设计DUT进行功能验证。

4.根据权利要求3所述的方法，其特征在于，

所述模式包括跨Die的互连模式，芯片Die与验证工具的互连模式以及芯片Die的回环模式；

所述验证平台包括子系统验证平台、片上系统验证平台和硬件仿真验证平台中的至少一个。

5.根据权利要求1所述的方法，其特征在于，所述对不同阶段的所述RTL代码进行芯片软件SW测试，包括：

根据芯片软件SW测试需求，选择不同阶段的所述RTL代码作为被测对象；

构建软件SW测试环境，将选择的所述RTL代码集成到所述软件SW测试环境中；

生成测试用例，对所述被测对象进行跨Die数据通路功能测试。

6.根据权利要求1至5任一项所述的方法，其特征在于，所述跨Die数据通路每个阶段包括上行数据通路、下行数据通路和调试回环数据通路中的至少一种。

7.一种跨Die数据通路的设计装置，其特征在于，所述装置包括：

代码生成模块，被配置为执行对芯片硬件HW设计按阶段划分，产生跨Die数据通路每个阶段的RTL代码；

验证模块，被配置为执行对芯片硬件HW验证按模式划分，将每个阶段的所述RTL代码作为待测设计DUT与验证平台连接，进行跨Die数据通路不同模式下的功能验证；

测试模块，被配置为执行对不同阶段的所述RTL代码进行芯片软件SW测试，以进行跨Die数据通路的功能测试；

所述代码生成模块具体被配置为执行：根据跨Die数据通路的功能需求，将芯片硬件HW设计划分为多个阶段；针对每个阶段，生成对应阶段的功能设计代码、空壳设计代码和调试回环设计代码，作为所述阶段的RTL代码；针对每个阶段的调试回环设计代码，通过配置开关控制打开或关闭。

8.一种电子设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述的方法的步骤。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。

10.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。