Cross-Die data path design method and device, electronic equipment, readable storage medium and program product

Abstract

The invention relates to a cross-Die data path design method and device, electronic equipment, a readable storage medium and a program product. The method comprises the following steps: performing stage design on a chip cross-Die data path, generating RTL codes of each stage of the cross-Die data path, dividing chip hardware HW verification according to modes, connecting the RTL codes of each stage as a design DUT to be tested to a verification platform, performing function verification on the cross-Die data path in different modes, and selecting the RTL codes of different stages to perform chip software SW test. Therefore, the function test of the cross-Die data path is carried out. According to the method, stage design is carried out on a chip cross-Die data path, so that the design process is simplified, and the design complexity is reduced; the RTL code of each stage is used as the to-be-tested design DUT to be connected with the verification platform for verification and software testing, the verification flexibility and efficiency are improved, and the reliability of chip software testing is improved.

Description

Technical Field

[0001] This application relates to the technical field of chip design, and particularly to a design method, device, electronic device, readable storage medium, and program product for a cross-Die data path. Background Art

[0002] With the continuous increase in the scale of chip design and the increasing complexity of functions, the design of cross-Die (which refers to a single unpackaged semiconductor chip cut from a wafer, also known as a bare chip or die, and it is the core part of the chip, containing all the functional circuits of the chip) data paths has emerged. It manufactures a complex chip design by dividing it into multiple Dies and then integrating them together through specific packaging technologies. The cross-Die data path is to establish a data transmission channel between these different Dies, enabling each Die to work together to complete the overall function of the chip.

[0003] The design of the chip cross-Die data path usually involves chip hardware (HW) design, chip hardware HW verification, and chip software (SW) testing, etc. It not only has high design complexity, cumbersome verification, but also has a long software testing cycle and frequent iterations. Therefore, how to simplify the design, verification, and testing process of the chip cross-Die data path is an urgent problem to be solved currently. Summary of the Invention

[0004] Based on this, in view of the above technical problems, it is necessary to provide a design method, device, electronic device, readable storage medium, and program product for a cross-Die data path that can simplify the design, verification, and testing process of the chip cross-Die data path.

[0005] In a first aspect, this application provides a design method for a cross-Die data path, and the method includes:

[0006] Dividing the chip hardware HW design by stages to generate RTL code for each stage of the cross-Die data path;

[0007] Dividing the chip hardware HW verification by modes, connecting the RTL code of each stage as the design under test (DUT) to the verification platform, and performing functional verification of the cross-Die data path in different modes;

[0008] Performing chip software SW testing on the RTL code of different stages to perform functional testing of the cross-Die data path.

[0009] In one embodiment, the chip hardware HW design is divided into stages to generate RTL codes for each stage of the cross-Die data path, including: dividing the chip hardware HW design into multiple stages according to the functional requirements of the cross-Die data path; for each stage, generating the functional design code, shell design code, and debug loop design code corresponding to the stage as the RTL code of the stage.

[0010] In one embodiment, for the shell design code of any stage, it serves as the top-level code of the functional design code of the previous stage, and the port signals remain consistent.

[0011] In one embodiment, for the debug loop design code of each stage, it is controlled to be turned on or off through a configuration switch.

[0012] In one embodiment, the chip hardware HW verification is divided into modes, and the RTL code of each stage is connected to the verification platform as the design under test DUT to perform functional verification of the cross-Die data path in different modes, including: dividing the chip hardware HW verification into multiple modes according to the functional requirements of the cross-Die data path; for each mode, connecting the RTL code of each stage to the verification platform corresponding to the mode as the design under test DUT to perform functional verification of the design under test DUT in different stages of each mode.

[0013] In one embodiment, the modes include the cross-Die interconnection mode, the interconnection mode between the chip Die and the verification tool, and the loopback mode of the chip Die; the verification platform includes at least one of a subsystem verification platform, a system-on-chip verification platform, and a hardware simulation verification platform.

[0014] In one embodiment, performing chip software SW testing on the RTL codes of different stages includes: selecting the RTL codes of different stages as the objects to be tested according to the chip software SW testing requirements; constructing a software SW testing environment and integrating the selected RTL codes into the software SW testing environment; generating test cases to perform cross-Die data path function testing on the objects to be tested.

[0015] In one embodiment, each stage of the cross-Die data path includes at least one of an upstream data path, a downstream data path, and a debug loop data path.

[0016] In a second aspect, the present application also provides a design device for a cross-Die data path, and the device includes:

[0017] A code generation module, configured to execute the division of the chip hardware HW design into stages to generate RTL codes for each stage of the cross-Die data path;

[0018] A verification module, configured to perform chip hardware HW verification by mode division, connect the RTL code of each stage as a design under test (DUT) to a verification platform, and perform functional verification of the cross-Die data path under different modes.

[0019] A test module, configured to perform chip software SW testing on the RTL code of different stages to perform functional testing of the cross-Die data path.

[0020] In a third aspect, the present application further provides an electronic device, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the steps of the method described in the first aspect above are implemented.

[0021] In a fourth aspect, the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method described in the first aspect above are implemented.

[0022] In a fifth aspect, the present application further provides a computer program product, including a computer program. When the computer program is executed by a processor, the steps of the method described in the first aspect above are implemented.

[0023] For the above-mentioned design method, device, electronic device, computer-readable storage medium, and computer program product of the cross-Die data path, through stage design of the chip cross-Die data path, RTL code of each stage of the cross-Die data path is generated, and chip hardware HW verification is divided by mode. The RTL code of each stage is connected as a DUT to a verification platform to perform functional verification of the cross-Die data path under different modes, and RTL codes of different stages are selected for chip software SW testing to perform functional testing of the cross-Die data path. By performing stage design on the chip cross-Die data path, the design process is simplified and the design complexity is reduced; by connecting the RTL code of each stage as a DUT to a verification platform for verification, the flexibility and efficiency of verification are improved; by selecting RTL codes of different stages for software SW testing of the cross-Die data path, the selectivity of testing is enhanced, the test coverage rate is increased, the test cycle is shortened, the number of iterations is reduced, and the reliability of chip software testing is also increased. Description of the Drawings

[0024] To more clearly illustrate the technical solutions in the embodiments of the present application or the related art, the following will briefly introduce the accompanying drawings required for the description in the embodiments of the present application or the related art. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other related accompanying drawings can also be obtained based on these drawings.

[0025] Figure 1 It is a schematic flowchart of a design method for a cross-Die data path in an embodiment;

[0026] Figure 2 It is a schematic flowchart of the hardware HW design steps in an embodiment;

[0027] Figure 3 It is a schematic architecture diagram of the hardware HW design in an embodiment;

[0028] Figure 4 It is a schematic flowchart of the hardware HW verification steps in an embodiment;

[0029] Figure 5 It is a schematic architecture diagram of the hardware HW verification D2V mode in an embodiment;

[0030] Figure 6 It is a schematic architecture diagram of the hardware HW verification Loopback mode in an embodiment;

[0031] Figure 7 It is a schematic flowchart of the software SW testing steps in an embodiment;

[0032] Figure 8 It is a schematic architecture diagram of the software SW testing in an embodiment;

[0033] Figure 9 It is a structural block diagram of a design device for a cross-Die data path in an embodiment;

[0034] Figure 10 It is an internal structure diagram of an electronic device in an embodiment. Detailed implementation manners

[0035] To make the objectives, technical solutions and advantages of the present application more clear and understandable, the present application will be further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0036] In one embodiment, as Figure 1 shown, a design method for a cross-Die data path is provided, and the method includes the following steps:

[0037] Step 102: Divide the chip hardware HW design into phases to generate the RTL code for each phase of the cross-Die data path.

[0038] In the chip manufacturing process, due to the limited area of a single Die, or to achieve better performance, functionality, and cost-effectiveness, a complex chip design is divided into multiple Dies for manufacturing and then integrated together through specific packaging technologies. As a result, the design of the cross-Die data path is required to establish a data transmission channel between these different Dies so that each Die can work together to complete the overall function of the chip. For example, in some high-performance computing chips, the computing unit and the storage unit may be placed on different Dies, and the cross-Die data path is responsible for efficiently transmitting data between the two.

[0039] In this embodiment, during the design process of the cross-Die data path, the chip hardware HW design can be divided into phases based on the progress of the design process, the complexity of the design, verification and optimization requirements, etc., so as to generate the RTL (Register Transfer Level, which refers to the register transfer level and is a high-level abstraction in digital circuit design) code for each phase of the cross-Die data path. Specifically, since the chip design is a process of gradually refining from the system-level abstract concept to the specific circuit implementation, the RTL design can be naturally divided into different phases according to the process from abstraction to concreteness. Each phase has its specific inputs, outputs, and tasks, thus generating the RTL code for each phase. Also, because a complex chip design usually includes multiple functional modules, such as a processor core, a storage module, a communication interface, etc., dividing the phases based on different functional modules can divide different RTL design phases, thereby generating the RTL code for the corresponding functional modules in each phase.

[0040] This embodiment provides flexible selectivity for the subsequent chip hardware HW verification and software SW testing of the cross-Die data path by performing phase design on the cross-Die data path of the chip. It can not only improve the quality of chip design and verification but also increase the reliability of chip software SW testing.

[0041] Step 104: Divide the chip hardware HW verification by mode, connect the RTL code of each phase as the design under test (DUT) to the verification platform, and perform functional verification of the cross-Die data path under different modes.

[0042] Hardware HW verification is a crucial step in ensuring that the chip design meets the expected functional and performance requirements. Among them, the modes include the interconnection mode across Dies, the interconnection mode between the chip Die and the verification tool, and the loopback mode of the chip Die. Specifically, the interconnection mode across Dies can be the Die-to-Die (D2D, a technology for direct interconnection between different Dies within the same package) interconnection mode of the RTL of the cross-Die design code. The interconnection mode between the chip Die and the verification tool refers to the D2V interconnection mode between the RTL of the Die design code and the verification tool. Among them, the verification tool can be a Universal Verification Component (UVC for short, a reusable verification component), or it can also be a Verification Intellectual Property (VIP, a pre-verified module with specific functions). The loopback mode of the chip Die refers to the loopback interconnection mode of the RTL of the chip Die design code.

[0043] The Design Under Test (DUT) refers to the part of the target design that needs to be verified for various indicators such as its functions and performance during the chip verification process. The verification platform can include at least one of the subsystem verification platform Testbench, the system-on-chip verification platform, and the hardware simulation verification platform.

[0044] In this embodiment, by dividing the chip hardware HW verification by mode, therefore, for each mode, the RTL code of each stage of the above steps can be functionally verified. That is, the RTL code of each stage is connected to the verification platform as the DUT to perform functional verification under different modes of the cross-Die data path.

[0045] In one scenario, for each verification platform, one or more of the RTL codes generated from the above steps can also be selected as the DUT for functional verification.

[0046] Step 106, perform chip software SW testing on the RTL codes of different stages to perform functional testing of the cross-Die data path.

[0047] Software SW testing plays a crucial role in chip development. It can verify the functions of the chip under actual application scenarios to ensure that the chip can operate stably and reliably in actual use. In this embodiment, the RTL codes at different stages that have completed function verification are used for chip software SW testing to perform functional testing on the cross-Die data path. Specifically, the above verification platform can be replaced with a software SW test driver to conduct functional testing. The test driver can simulate actual application scenarios to send instructions and data to the chip, receive the chip's response and analyze it to verify the correctness of the chip's functions.

[0048] In the above design method of the cross-Die data path, through the stage design of the chip's cross-Die data path, the RTL codes for each stage of the cross-Die data path are generated. The chip hardware HW verification is divided by mode, and the RTL code for each stage is connected to the verification platform as the design under test (DUT) to perform functional verification of the cross-Die data path in different modes. Different stages of RTL codes are selected for chip software SW testing to conduct functional testing on the cross-Die data path. By performing stage design on the chip's cross-Die data path, the design process is simplified and the design complexity is reduced; by connecting the RTL code for each stage to the verification platform as the DUT for verification, the flexibility and efficiency of verification are improved; by selecting different stages of RTL codes for software SW testing of the cross-Die data path, the test selectivity is enhanced, the test coverage is increased, the test cycle is shortened, the number of iterations is reduced, and the reliability of chip software testing is also increased.

[0049] In one embodiment, as Figure 2 shown, in step 102, the chip hardware HW design is divided by stage to generate the RTL code for each stage of the cross-Die data path. Specifically, it may further include:

[0050] Step 202, according to the functional requirements of the cross-Die data path, divide the chip hardware HW design into multiple stages.

[0051] Specifically, during the chip hardware HW design process of the cross-Die data path, based on the different functions of the cross-Die data path, its design can be divided by stage to obtain multiple stages, and each stage can have corresponding functional modules.

[0052] Step 204, for each stage, generate the functional design code, empty shell design code, and debug loopback design code corresponding to the stage as the RTL code for the corresponding stage.

[0053] Specifically, for the functional modules in each stage, corresponding functional design codes can be generated; for each stage, the empty shell design codes of the empty shell Shell module and the debug loopback design codes of the debuggable Debug loopback module can also be designed and generated, so as to obtain the RTL codes of the corresponding stage. By performing a staged design on the cross-Die data path, the device process is simplified and the design complexity is reduced.

[0054] In an exemplary embodiment, as Figure 3 shown, the chip hardware HW design may include 2 chip Dies: Chip Die0 and Chip Die1. Among them, Chip Die0 and Chip Die1 can be two instances of the same hardware HW design code RTL in the verification platform Testbench, and the two design codes are connected. The cross-Die data path from Die0 to Die1 is defined as the upstream data path Upstream, and the data path from Die1 to Die0 is defined as the downstream data path Downstream. The hardware HW design can be divided into 3 phases according to the phase Phase, including Phase0, Phase1, and Phase2. Each phase Phase can generate the functional Function design code, the empty shell Shell design code, and the debuggable Debug loopback design code of the cross-Die data path.

[0055] In one scenario, as Figure 3 shown, when the Die hardware HW design is in Phase0, the functional Function design codes of Phase1 and Phase2 are not yet completed. The functional Function design of Phase0 is mainly for the connection of the top layer Top of the Die subsystem Subsystem and the port signals of the system on chip SoC (System on Chip, also known as the system on chip). The data sent from the system on chip SoC to the top layer Top of the Die subsystem Subsystem is the upstream path Upstream data, and the data sent from the top layer Top of the Die subsystem Subsystem to the system on chip SoC is the downstream path Downstream data.

[0056] At this time, the function design code for Phase 1 and Phase 2 has not been completed. The chip hardware (HW) design can generate the design code for the Phase 1 shell (Phase1_Shell), and the design code for the Phase 1 shell (Phase1_Shell) can be instantiated in the function design code for Phase 0. Similarly, for the convenience of debugging the function design code for Phase 0, the chip hardware (HW) design can generate the design code for the Phase 0 debug loopback, and it can be controlled to be turned on or off through the switch enable configuration.

[0057] Therefore, the design code for the shell of each phase can be used as the top-level wrapper of the RTL of the function design code for the previous phase, and the port signals remain consistent.

[0058] As an example, as Figure 3 shown. The top-level RTL design code for Phase 0 is phase0_top.v, the top-level RTL design code for Phase 1 is phase1_top.v, and the top-level RTL design code for Phase 2 is phase2_top.v. The RTL design code for Phase 0 instantiates the RTL design code for Phase 1, and the RTL design code for Phase 1 instantiates the RTL design code for Phase 2. When in Phase 0, the instantiated RTL design code for the Phase 1 shell is phase1_top_shell.v. The port signals of the RTL design code for the Phase 1 shell (phase1_top_shell.v) and the top-level RTL design code for Phase 1 (phase1_top.v) are the same. During the design of Phase 1, the RTL design code for the Phase 1 shell (phase1_top_shell.v) can be directly replaced with its top-level design code (phase1_top.v).

[0059] In one scenario, such as Figure 3As shown, the RTL of the design code for each phase can include a debuggable loopback design code, which can be enabled or disabled through the enable configuration. Usually, the loopback function is default disabled. Specifically, Phase0 includes the RTL of the functional design code for Phase0 and the shell design code for Phase1. During Phase0, the loopback function can be enabled through register configuration. At this time, the upstream data (TX Data, i.e., the transmitted data) in Phase0 is directly sent to the downstream data (RX Data, i.e., the received data), instead of being sent to Phase1, thus completing the loopback function. Similarly, during Phase1 and Phase2, the loopback function for the corresponding phase can also be enabled through register configuration.

[0060] In one scenario, the chip hardware (HW) design can be divided by phase. Different phases can be distinguished using different configurations, and different configurations can be different RTL design codes.

[0061] As an example, as Figure 3 shown, different configurations can be implemented through macro definitions. Three phases, "Phase0, Phase1, Phase2", can be defined through three macro definitions, "Macro Definition PHASE0, Macro Definition PHASE1, Macro Definition PHASE2". Different macro definitions can define the RTL design codes corresponding to different phases.

[0062] Specifically, different macro definitions (Define) can be used to select different function (Funtion) design codes and shell (Shell) design codes. For example, in Phase0, the macro definition PHASE0 can be used to select the function design code of Phase0 and the shell design code of Phase1 (Phase1_Shell) for use. In Phase1, the macro definition PHASE1 can be used to select the function design code of Phase0, the function design code of Phase1, and the shell design code of Phase2 (Phase2_Shell) for use. In Phase2, the macro definition PHASE2 can be used to select the function design code of Phase0, the function design code of Phase1, and the function design code of Phase2 for use.

[0063] In one embodiment, as Figure 4 shown, in step 104, for the chip hardware (HW) verification, it is divided by mode. The RTL code of each phase is used as the design under test (DUT) to be connected to the verification platform for functional verification in different modes of the cross-Die data path. Specifically, it may further include:

[0064] Step 402: According to the functional requirements of the cross-Die data path, divide the chip hardware (HW) verification into multiple modes.

[0065] Specifically, during the chip hardware (HW) verification of the cross-Die data path, according to the functional requirements of the cross-Die data path, the chip hardware (HW) verification can be divided into multiple modes, and each mode can correspond to different functional verification scenarios.

[0066] Step 404: For each mode, connect the RTL code of each phase as the design under test (DUT) to the verification platform corresponding to that mode to perform functional verification on the design under test (DUT) of different phases in each mode.

[0067] Specifically, based on the above-mentioned divided modes and phases, for each mode, the RTL codes of each phase can be connected as the design under test (DUT) to the verification platform corresponding to that mode for verification, so as to achieve functional verification of the design under test (DUT) of different phases in each mode. For example, based on various boundary conditions, abnormal situations, etc., the functional correctness of the design under test (DUT) can be comprehensively verified. This not only improves the flexibility and efficiency of verification but also enables flexible verification for different phases.

[0068] In an exemplary embodiment, a verification platform (Testbench) can be built for the chip hardware (HW) verification. AsFigure 3 As shown, the Die0 general verification component UVC in the verification platform is connected to the Interface of Die0, and the Die1 general verification component UVC is connected to the Interface of Die1. The verification platform scoreboard is used to check the function verification results. The Die hardware HW verification can also be divided into 3 phases according to the Die hardware HW design phase: Phase0, Phase1, and Phase2. The chip Die data path hardware HW verification can also be divided according to the mode. Specifically, it can include: D2D mode (i.e., the mode of interconnection between chip Die0 and chip Die1, that is, the cross-Die interconnection mode), D2V mode (i.e., the interconnection mode between the chip Die and the verification tool, such as the mode of interconnection between the RTL design code of the chip Die and the general verification component UVC or the verification IP VIP), and the loopback mode of the chip Die (i.e., the design code loopback interconnection mode). Thus, the RTL design code generated in each phase is used as the design under test DUT and connected to the verification platform Testbench to perform function verification for each phase in different modes of the cross-Die data path.

[0069] Specifically, as Figure 3 shown, the path from chip Die0 to chip Die1 is the upstream path. The transmit data TX Data of chip Die0 is sent to chip Die1 through the upstream path. Chip Die1 then receives the data RX Data and sends it to the Die1 general verification component UVC. The transmit data TX Data of chip Die1 is sent to chip Die0 through the downstream path. Then chip Die0 receives the data RX Data and sends it to the Die0 general verification component UVC. Thus, the function verification of the cross-Die data path is achieved.

[0070] In one scenario, the chip Die data path hardware HW verification can be divided according to the phase. Different phases with different configurations use different design code file lists Filelist to perform function verification on the RTL design code of different phases.

[0071] Specifically, as Figure 3As shown in the figure. The macro definition PHASE0 configures the list of design code files Filelist used in Phase0, which includes the functional Function design code of Phase0 and the shell Phase1_Shell design code of Phase1. In the D2D mode Mode, the chips Die0 and Die1 are interconnected, that is, the shell Phase1_Shell design code ports Port of Phase1 of chip Die0 and the shell Phase1_Shell design code ports Port of Phase1 of chip Die1 are interconnected. And so on, the macro definition PHASE1 also configures the list of design code files Filelist used in Phase1, which includes the functional Function design codes of Phase0 and Phase1, and the shell Phase1_Shell design code of Phase2. The macro definition PHASE2 configures the list of design code files Filelist used in Phase2, including the functional Function design codes of Phase0, Phase1, and Phase2. Thus, functional verification of the design code RTL in different phases is achieved.

[0072] In one scenario, the hardware HW verification of the chip Die data path can also be divided according to the mode Mode, so as to perform functional verification on the design code RTL in each phase in different modes.

[0073] Specifically, the verification platform Testbench can include 3 modes Mode: D2D mode Mode, D2V mode Mode, and Loopback mode Mode. Among them, the D2D mode Mode is the mode Mode for interconnection between the chip Die design code RTLs; the D2V mode Mode is the interconnection mode Mode between the chip Die design code RTL and the general verification component UVC or the verification IP VIP; the Loopback mode Mode is the loopback mode Mode of the chip Die design code RTL.

[0074] It can be understood that each mode Mode includes the design code RTLs of 3 phases Phase. As Figure 3 shown in the D2D mode Mode, it includes the design code RTLs of Phase0, Phase1, and Phase2. As Figure 5 shown in the D2V mode Mode and Figure 6 shown in the Loopback mode Mode, they both include the design code RTLs of Phase0, Phase1, and Phase2.

[0075] Therefore, the RTL design code generated in each Phase can be used as the Design Under Test (DUT), and functional verification can be performed according to the Phase division. For example, Figure 3 in the D2D mode shown, the RTL design code used in Phase0 configured by the macro definition PHASE0 can be used as the DUT for functional verification, so as to verify the upstream data TX Data transmission and downstream data RX Data reception functions of Phase0.

[0076] In one scenario, the verification platform may include at least one of a subsystem verification platform, a system-on-chip verification platform, and a hardware simulation verification platform. For each verification platform, at least one phase of the RTL design code from the above three Phases can be selected for verification.

[0077] As an embodiment, for example, Figure 3 as shown, for the verification of a system-on-chip (SoC) or hardware emulation (Emu), the RTL design code of Phase2 in the D2D mode of cross-Die design code interconnection can be selected for verification. During the verification of the system-on-chip (SoC), the stimulus generation of the verification platform (Testbench) changes from the Die0 and Die1 universal verification components (UVC) of the subsystem verification platform (Testbench) to the upstream and downstream subsystems connected to the subsystem. At this time, the RTL file list of the design code of chip Die0 and chip Die1 includes the functional design code of Phase0, Phase1, and Phase2, and the RTL design code of chip Die0 and chip Die1 is interconnected.

[0078] Similarly, for hardware emulation (Emu) verification, the RTL design code of Phase2 in the D2D mode of cross-Die design code interconnection can also be selected for verification, so that the cross-Die design code RTL of the system-on-chip (SoC) and hardware emulation (Emu) verification is consistent.

[0079] In addition, the verification environment can also connect the TX (Transmit) and RX (Receive) signals connected by Phase0 and Phase1 through Force for external loopback testing.

[0080] In one embodiment, for example, Figure 7As shown, in step 106, the RTL code at different stages is subjected to chip software SW testing to perform functional testing on the cross-Die data path. Specifically, it may further include:

[0081] Step 702, according to the chip software SW testing requirements, select the RTL code at different stages as the object under test.

[0082] Specifically, during the chip software SW testing of the cross-Die data path, the RTL code at different stages can be selected as the object under test according to the chip software SW testing requirements. For example, the RTL code of phase Phase0 or phase Phase1 can be selected as the object under test. This can enhance the selectivity of software testing, shorten the testing cycle, and reduce the number of iterations.

[0083] Step 704, construct a software SW testing environment and integrate the selected RTL code into the software SW testing environment.

[0084] Among them, the testing environment may include simulators, debugging tools, etc. By constructing a software SW testing environment and integrating the selected RTL code into the software SW testing environment, subsequent testing is facilitated.

[0085] Step 706, generate test cases to perform cross-Die data path functional testing on the object under test.

[0086] Among them, the test cases can cover various normal and abnormal situations to comprehensively test the functional correctness of the object under test.

[0087] In an exemplary embodiment, during the chip software SW testing process, the design code RTL at different phases can be selected for function testing. As Figure 8 shown, similar to the hardware HW verification of the chip Die data path, the object under test for the software SW testing of the chip Die data path is still the design code RTL at each stage in the chip Die hardware HW design process. For the software SW testing of the chip Die data path, one or more of the code RTLs in the chip Die hardware HW design phases Phase0, Phase1, and Phase2 can be selected for function testing.

[0088] It is understandable that different phases can be selected during the chip software SW testing process to complete the software SW test driver. Among them, the version of the software SW test driver should correspond to the phase of the selected hardware HW. Specifically, through the chip software and hardware version management, the version of the RTL design code in the hardware HW design phase can be made consistent with the version of the software SW test driver, so as to facilitate the positioning of function problems.

[0089] In one scenario, when the software SW test performs function testing on the design code RTL, it can be selected to test at the function points that cannot be covered by the subsystem verification environment or the system-on-chip SoC verification, and the function testing associated with the system can also be considered. Specifically, as Figure 8 shown, the software SW driver runs, interacts with the chip Die0 and Die1 through the chip interface such as PCIe, and then interacts with the subsystem through the network-on-chip (NoC). Since the software SW test is a real application scenario, it can test the functions that cannot be tested by the subsystem or the system-on-chip SoC verification. Thus, the test coverage can be improved, and the reliability of the chip software test is increased.

[0090] It should be understood that although the steps in the flowcharts involved in the above-described embodiments are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear description in this article, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least some of the steps in the flowcharts involved in the above-described embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or alternately with at least some of the steps or stages in other steps or other steps.

[0091] Based on the same inventive concept, the embodiments of the present application also provide a cross-Die data path design device for implementing the cross-Die data path design method described above. The implementation solutions provided by this device to solve problems are similar to the implementation solutions described in the above method. Therefore, the specific limitations in one or more cross-Die data path design device embodiments provided below can refer to the limitations on the cross-Die data path design method in the above text, and will not be repeated here.

[0092] In an exemplary embodiment, as Figure 9 shown, a design device for a cross-Die data path is provided, including: a code generation module 902, a verification module 904, and a test module 906, where:

[0093] The code generation module 902 is configured to perform stage division on the chip hardware HW design, and generate RTL codes for each stage of the cross-Die data path;

[0094] The verification module 904 is configured to perform mode division on the chip hardware HW verification, connect the RTL code of each stage as the design under test DUT to the verification platform, and perform functional verification of the cross-Die data path in different modes;

[0095] The test module 906 is configured to perform chip software SW testing on the RTL codes of different stages to perform functional testing of the cross-Die data path.

[0096] In an exemplary embodiment, the code generation module is specifically configured to perform: according to the functional requirements of the cross-Die data path, divide the chip hardware HW design into multiple stages; for each stage, generate the functional design code, the shell design code, and the debug loopback design code corresponding to the stage as the RTL code of the stage.

[0097] In an exemplary embodiment, for the shell design code of any stage, it is used as the top-level code of the functional design code of the previous stage, and the port signals are kept consistent.

[0098] In an exemplary embodiment, for the debug loopback design code of each stage, it is controlled to be turned on or off through a configuration switch.

[0099] In an exemplary embodiment, the verification module is specifically further configured to perform: according to the functional requirements of the cross-Die data path, divide the chip hardware HW verification into multiple modes; for each mode, connect the RTL code of each stage as the design under test DUT to the verification platform corresponding to the mode, so as to perform functional verification on the design under test DUT of different stages in each mode.

[0100] In an exemplary embodiment, the modes include the cross-Die interconnection mode, the interconnection mode between the chip Die and the verification tool, and the loopback mode of the chip Die; the verification platform includes at least one of a subsystem verification platform, a system-on-chip verification platform, and a hardware simulation verification platform.

[0101] In an exemplary embodiment, the test module is further specifically configured to perform: selecting the RTL code at different stages as the object under test according to the chip software SW test requirements; constructing a software SW test environment and integrating the selected RTL code into the software SW test environment; generating test cases, and performing a cross-Die data path function test on the object under test.

[0102] In an exemplary embodiment, each stage of the cross-Die data path includes at least one of an upstream data path, a downstream data path, and a debug loop data path.

[0103] Each module in the above-mentioned design device of the cross-Die data path can be implemented in whole or in part by software, hardware, and their combination. The above-mentioned modules can be embedded in the processor in the computer device in hardware form or be independent of it, or can be stored in the memory in the computer device in software form, so that the processor can call and execute the operations corresponding to the above-mentioned modules.

[0104] In an exemplary embodiment, an electronic device is provided, and its internal structure diagram can be as Figure 10 shown. The electronic device includes a processor, a memory, an input / output interface, a communication interface, a display unit, and an input device. Among them, the processor, the memory, and the input / output interface are connected through a system bus, and the communication interface, the display unit, and the input device are connected to the system bus through the input / output interface. Among them, the processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the electronic device is used for exchanging information between the processor and external devices. The communication interface of the electronic device is used for communicating with an external terminal in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (NFC), or other technologies. When the computer program is executed by the processor, it realizes a design method of a cross-Die data path. The display unit of the electronic device is used to form a visually visible picture, which can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen. The input device of the electronic device can be a touch layer covering the display screen, or a button, a trackball, or a touchpad provided on the outer shell of the electronic device, or an external keyboard, touchpad, or mouse, etc.

[0105] Those skilled in the art can understand that Figure 10The structure shown is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0106] In an exemplary embodiment, an electronic device is provided, including a memory and a processor. A computer program is stored in the memory, and when the processor executes the computer program, the steps in the above method embodiments are implemented.

[0107] In an embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0108] In an embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0109] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with relevant regulations.

[0110] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logic devices, data processing logics based on quantum computing, artificial intelligence (AI) processors, etc., without limitation.

[0111] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in the present application.

[0112] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the patent scope of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all fall within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the appended claims.

Claims

1. A design method for a cross-die data path, characterized in that: The method comprises: Divide the chip hardware HW design into stages and generate RTL code for each stage of the cross-die data path; The chip hardware HW verification is divided into modes, and the RTL code of each stage is connected to the verification platform as the design under test (DUT) to perform functional verification under different modes of cross-die data paths; The RTL codes at different stages are subjected to chip software SW testing to perform functional testing of cross-die data paths.

2. The method according to claim 1, characterized in that The chip hardware HW design is divided into stages to generate RTL code for each stage of the cross-die data path, including: According to the functional requirements of the cross-die data path, the chip hardware HW design is divided into multiple stages; For each stage, a functional design code, an empty shell design code and a debugging loopback design code of the corresponding stage are generated as the RTL code of the stage.

3. The method according to claim 2, characterized in that The empty shell design code at any stage is used as the top-level code of the functional design code at the previous stage, and the port signals remain consistent.

4. The method according to claim 2, characterized in that: Design the code for the debug loop at each stage and turn it on or off by configuring the switch.

5. The method according to claim 1, characterized in that The chip hardware HW verification is divided into modes, and the RTL code of each stage is connected to the verification platform as the design under test (DUT) to perform functional verification under different modes of cross-die data paths, including: Dividing the chip hardware HW verification into multiple modes according to the functional requirements of the cross-die data path; For each mode, the RTL code of each stage is used as the design under test (DUT) and connected to the verification platform in the corresponding mode to perform functional verification on the design under test (DUT) at different stages in each mode.

6. The method according to claim 5, characterized in that The modes include a cross-die interconnection mode, a chip die and a verification tool interconnection mode, and a chip die loopback mode; The verification platform includes at least one of a subsystem verification platform, a system-on-chip verification platform, and a hardware simulation verification platform.

7. The method according to claim 1, characterized in that The chip software SW test is performed on the RTL code at different stages, including: According to the chip software SW test requirements, the RTL codes at different stages are selected as the objects to be tested; Building a software SW test environment, and integrating the selected RTL code into the software SW test environment; Generate a test case and perform a cross-Die data path functional test on the object under test.

8. The method according to any one of claims 1 to 7, characterized in that: Each stage of the cross-Die data path includes at least one of an uplink data path, a downlink data path and a debug loopback data path.

9. A device for designing a cross-die data path, characterized in that: The device comprises: The code generation module is configured to divide the chip hardware HW design into stages and generate RTL code for each stage of the cross-die data path; The verification module is configured to perform chip hardware HW verification divided by mode, connect the RTL code of each stage as the design under test DUT to the verification platform, and perform functional verification under different modes of cross-die data paths; The test module is configured to perform chip software SW testing on the RTL codes at different stages to perform functional testing on cross-Die data paths.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 8 are implemented.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

12. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images