Design method, device, electronic device, readable storage medium and program product for cross-Die data path

Abstract

The present application relates to a design method, device, electronic device, readable storage medium and program product for a cross-die data path. By designing the chip cross-die data path in stages, generating RTL code for each stage of the cross-die data path, and dividing the chip hardware HW verification by mode, the RTL code of each stage is connected to the verification platform as the design under test DUT, and functional verification under different modes of the cross-die data path is performed. The RTL code of different stages is selected for chip software SW testing to perform functional testing of the cross-die data path. By designing the chip cross-die data path in stages, the design process is simplified and the design complexity is reduced; by connecting the RTL code of each stage as the design under test DUT to the verification platform for verification and software testing, the flexibility and efficiency of verification are improved, and the reliability of chip software testing is increased.

Description

Technical Field

[0001] The present application relates to the field of chip design technology, and in particular to a design method, device, electronic device, readable storage medium and program product for a cross-Die data path. Background Art

[0002] As chip designs continue to grow in size and functionality, the design of inter-die data paths has emerged. (This refers to a single, unpackaged semiconductor chip cut from a wafer, also known as a bare die or die. It is the core of the chip and contains all its functional circuitry.) This is achieved by dividing a complex chip design into multiple dies for manufacturing and then integrating them together through specialized packaging technologies. Inter-die data paths establish data transmission channels between these different dies, enabling them to work together to achieve the overall chip functionality.

[0003] The design of a chip's inter-die datapath typically involves chip hardware (HW) design, HW verification, and software (SW) testing. This is not only highly complex and tedious to verify, but also requires long software testing cycles and frequent iterations. Therefore, simplifying the design, verification, and testing of inter-die datapaths is a pressing issue. Summary of the Invention

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

[0005] In a first aspect, the present application provides a method for designing a cross-die data path, the method comprising:

[0006] Divide the chip hardware HW design into stages and generate RTL code for each stage of the cross-die data path;

[0007] 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 in different modes across the die data path;

[0008] The RTL codes at different stages are subjected to chip software SW testing to perform functional testing of cross-die data paths.

[0009] In one embodiment, the chip hardware HW design is divided into stages to generate RTL code 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 corresponding stage functional design code, shell design code and debug loop design code as the RTL code of the stage.

[0010] In one embodiment, the 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.

[0011] In one embodiment, the debugging loopback design code for each stage is turned on or off by configuring a 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 under different modes of the cross-Die data path, 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 as the design under test DUT to the verification platform in the corresponding mode to perform functional verification on the design under test DUT in different stages under each mode.

[0013] In one embodiment, the mode includes an interconnection mode across dies, an interconnection mode between chip dies and verification tools, and a loopback mode of chip dies; 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, the chip software SW testing of the RTL code at different stages includes: selecting the RTL code at different stages as the object to be tested according to the chip software SW testing requirements; building a software SW testing environment and integrating the selected RTL code into the software SW testing environment; generating test cases and performing cross-Die data path functional testing on the object 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 loopback data path.

[0016] In a second aspect, the present application further provides a device for designing a cross-Die data path, the device comprising:

[0017] 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;

[0018] The verification module is configured to perform chip hardware HW verification according to the 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 the cross-die data path;

[0019] 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.

[0020] In a third aspect, the present application further provides an electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps of the method described in the first aspect when executing the computer program.

[0021] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, which implements the steps of the method described in the first aspect when executed by a processor.

[0022] In a fifth aspect, the present application also provides a computer program product, comprising a computer program, which implements the steps of the method described in the first aspect when executed by a processor.

[0023] The above-mentioned cross-die datapath design method, device, electronic device, computer-readable storage medium, and computer program product generate RTL code for each stage of the cross-die datapath by performing stage-by-stage design on the chip's cross-die datapath. The RTL code for each stage is then connected to a verification platform as the DUT to perform functional verification of the cross-die datapath under different modes. The RTL code for each stage is then selected for chip software SW testing to perform functional testing of the cross-die datapath. By performing stage-by-stage design on the chip's cross-die datapath, the design process is simplified and design complexity is reduced. By connecting the RTL code for each stage as the DUT to the verification platform for verification, verification flexibility and efficiency are improved. By selecting RTL code for different stages for cross-die datapath software SW testing, test selectivity is enhanced, test coverage is improved, test cycles are shortened, iteration times are reduced, and the reliability of chip software testing is increased. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0025] Figure 1 1 is a flow chart of a method for designing a cross-die data path in one embodiment;

[0026] Figure 2 Schematic diagram of the process of hardware HW design in one embodiment;

[0027] Figure 3 A schematic diagram of the hardware HW architecture in one embodiment;

[0028] Figure 4 1 is a flowchart of a hardware HW verification step in one embodiment;

[0029] Figure 5 FIG. 1 is a schematic diagram of the architecture of a hardware HW verification D2V mode in one embodiment;

[0030] Figure 6 FIG. 1 is a schematic diagram of the architecture of the hardware HW verification loopback mode in one embodiment;

[0031] Figure 7 1 is a flowchart of software SW testing steps in one embodiment;

[0032] Figure 8 Schematic diagram of the software SW test architecture in one embodiment;

[0033] Figure 9 A structural block diagram of a design apparatus for a cross-die data path according to an embodiment;

[0034] Figure 10 FIG. 1 is a diagram showing the internal structure of an electronic device in one embodiment. DETAILED DESCRIPTION

[0035] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0036] In one embodiment, Figure 1 As shown, a design method for a cross-die data path is provided, the method comprising the following steps:

[0037] Step 102: Divide the chip hardware HW design into stages and generate RTL code for each stage 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 will be divided into multiple dies for manufacturing, and then integrated together through specific packaging technology. Therefore, it is necessary to design cross-die data paths to establish data transmission channels 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 storage unit may be placed on different dies respectively, and the cross-die data path is responsible for efficiently transmitting data between the two.

[0039] In this embodiment, during the cross-die datapath design process, the chip hardware HW design can be divided into stages based on the design process progression, design complexity, verification and optimization requirements, etc., thereby generating RTL (Register Transfer Level) code for each stage of the cross-die datapath. Specifically, since chip design is a process of gradually refining from system-level abstract concepts to specific circuit implementations, the RTL design can be naturally divided into different stages as the process progresses from abstraction to concreteness. Each stage has its own specific inputs, outputs, and tasks, thereby generating RTL code for each stage. Furthermore, since complex chip designs typically include multiple functional modules, such as processor cores, memory modules, and communication interfaces, dividing the stages based on different functional modules can create different RTL design stages, thereby generating RTL code for the corresponding functional modules in each stage.

[0040] This embodiment provides flexible options for subsequent chip hardware HW verification and software SW testing of cross-Die data paths by performing staged design of the chip cross-Die data path, which not only improves the quality of chip design and verification, but also increases the reliability of chip software SW testing.

[0041] Step 104 , 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 the cross-die data path.

[0042] Hardware verification is a critical step in ensuring that chip designs meet expected functional and performance requirements. Modes include cross-die interconnection modes, chip die-to-verification tool interconnection modes, and chip die loopback modes. Specifically, the cross-die interconnection mode can be a D2D (die-to-die, a technology that enables direct interconnection between different dies within the same package) mode of interconnecting the die design code RTL across the die. The chip die-to-verification tool interconnection mode refers to a D2V mode of interconnecting the die design code RTL with the verification tool. The verification tool can be a Universal Verification Component (UVC, a reusable verification component) or a Verification Intellectual Property (IPVIP, a pre-verification module with specific functions). The chip die loopback mode refers to the loopback interconnection mode of the chip die design code RTL.

[0043] The Design Under Test (DUT) refers to the target design component whose functionality, performance, and other indicators need to be verified during the chip verification process. The verification platform can include at least one of a subsystem verification platform testbench, a system-on-chip verification platform, and a hardware simulation verification platform.

[0044] In this embodiment, the chip hardware HW verification is divided into modes. 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 design under test (DUT), thereby performing functional verification in different modes across the die data path.

[0045] In one scenario, for each verification platform, one or more RTL codes at each stage generated in the above steps may be selected as the design under test (DUT) for functional verification.

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

[0047] Software SW testing plays a key role in chip development. It can test the functions of the chip in actual application scenarios to ensure that the chip can run stably and reliably in actual use. In this embodiment, the RTL code of the different stages of functional verification is subjected to chip software SW testing to perform functional testing across the Die data path. Specifically, the above-mentioned verification platform can be replaced with a software SW test driver to perform functional testing. The test driver can simulate the actual application scenario to send instructions and data to the chip to receive the chip's response and analyze it to verify the correctness of the chip function.

[0048] In the above-mentioned cross-die datapath design method, the chip cross-die datapath is designed in stages, RTL code for each stage of the cross-die datapath is generated, and the chip hardware HW verification is divided into modes. 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 datapath in different modes. The RTL code of different stages is then selected for chip software SW testing to perform functional testing of the cross-die datapath. By designing the chip cross-die datapath in stages, the design process is simplified and the design complexity is reduced. By connecting the RTL code of each stage as the design under test (DUT) to the verification platform for verification, the flexibility and efficiency of verification are improved. By selecting the RTL code of different stages for cross-die datapath software SW testing, the test selectivity is enhanced, the test coverage is improved, the test cycle is shortened, the number of iterations is reduced, and the reliability of chip software testing is increased.

[0049] In one embodiment, Figure 2 As shown, in step 102, the chip hardware HW design is divided into stages, and RTL code for each stage of the cross-die data path is generated, which may specifically include:

[0050] Step 202: Divide the chip hardware HW design into multiple stages according to the functional requirements of the cross-die data path.

[0051] Specifically, during the chip hardware HW design process of the cross-die data path, the design can be divided into stages based on the different functions of the cross-die data path, thereby obtaining multiple stages, and each stage can have corresponding functional modules.

[0052] Step 204 : For each stage, generate the functional design code, shell design code, and debug loopback design code of the corresponding stage as the RTL code of the corresponding stage.

[0053] Specifically, for each stage's functional module, corresponding functional design code can be generated. For each stage, shell design code for the shell module and debug loopback design code for the debug loopback module can also be designed and generated, resulting in the corresponding stage's RTL code. By designing cross-die data paths in stages, this simplifies the device process and reduces design complexity.

[0054] In an exemplary embodiment, Figure 3 As shown, the chip hardware HW design can include two chip Dies: chip Die0 and chip Die1. Among them, chip Die0 and chip Die1 can be two copies 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 Die1 to Die0 is defined as the downstream data path Downstream. The hardware HW design can be divided into three phases according to the phase, including phase Phase0, phase Phase1 and phase Phase2. Each phase can generate the cross-die data path function design code, shell design code and debuggable loopback design code.

[0055] In one scenario, Figure 3 As shown, during Phase 0 of the die hardware design, the functional design code for Phases 1 and 2 is not yet complete. Phase 0's functional design primarily involves connecting the top layer of the die subsystem to the port signals of the system-on-chip (SoC). Data sent from the SoC to the top layer of the die subsystem is upstream data, while data sent from the top layer of the die subsystem to the SoC is downstream data.

[0056] At this point, the functional design code for Phase 1 and Phase 2 is not yet complete. The chip hardware design can generate Phase 1_Shell design code, which can be instantiated in the functional design code for Phase 0. Similarly, to facilitate debugging of the functional design code for Phase 0, the chip hardware design can generate a loopback design code for Phase 0, which can be enabled or disabled using the Enable switch configuration.

[0057] Therefore, the Shell design code of each Phase can be used as the top-level Wrapper of the Function design code RTL of the previous Phase, and the port signals remain consistent.

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

[0059] In one scenario, Figure 3As shown, each phase Phase design code RTL can include debuggable loopback design code, which can be turned on or off by enabling the Enable configuration. Usually, the default is to disable the Disable loopback function. Specifically, phase Phase0 includes the functional design code RTL of phase Phase0 and the shell design code of phase Phase1. In phase Phase0, the loopback function Enable configuration can be turned on through the register Register configuration. At this time, the upstream Upstream data (TX Data, i.e., transmit data) of phase Phase0 is directly sent to the downstream Downstream data (RX Data, i.e., receive data) instead of being sent to phase Phase1, thereby completing the loopback function. Similarly, in phases Phase1 and Phase2, the loopback function Enable configuration of the corresponding phase can also be turned on through the register Register configuration.

[0060] In one scenario, chip hardware HW design can be divided into phases. Different phases can be distinguished by different configurations. Different configurations can be different design codes RTL.

[0061] As an example, Figure 3 As shown, different configurations can be implemented through macro definitions. The three phases (Phase 0, Phase 1, and Phase 2) can be defined through three macro definitions (Macro Definition PHASE0, Macro Definition PHASE1, and Macro Definition PHASE2). Different macro definitions define the RTL code corresponding to different phases.

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

[0063] In one embodiment, Figure 4 As shown, in step 104, 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 the cross-die data path. Specifically, the following steps may be included:

[0064] Step 402: Divide chip hardware HW verification into multiple modes according to the functional requirements of the cross-die data path.

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

[0066] Step 404 : For each mode, the RTL code of each stage is connected as the DUT to the verification platform in the corresponding mode to perform functional verification on the DUT at different stages in each mode.

[0067] Specifically, based on the aforementioned modes and phases, for each mode, the RTL code at each phase can be connected to the verification platform in the corresponding mode as the DUT, thereby enabling functional verification of the DUT at different phases within each mode. For example, the functional correctness of the DUT can be fully verified based on various boundary conditions and abnormal situations. This not only improves verification flexibility and efficiency, but also allows for flexible verification at different phases.

[0068] In an exemplary embodiment, the chip hardware HW verification can build a verification platform Testbench. Figure 3 As shown, the Die0 universal verification component UVC in the verification platform is connected to the Die0 interface, and the Die1 universal verification component UVC is connected to the Die1 interface. The verification platform scoreboard (Scoreboard) is used to check the function verification results. Die hardware HW verification can also be divided into three phases based on the die hardware HW design phase: Phase 0, Phase 1, and Phase 2. Chip die datapath hardware HW verification can also be divided according to mode. Specifically, it can include the D2D mode (the mode of interconnection between Die0 and Die1, also known as the cross-die interconnection mode), the D2V mode (the mode of interconnection between the chip die and the verification tool, such as the mode of interconnection between the chip die design code RTL and the universal verification component UVC or the verification IP VIP), and the chip die loopback mode (the mode of design code loopback interconnection mode). The design code RTL generated at each phase is connected to the verification platform Testbench as the design under test (DUT) to perform functional verification of each phase under different modes across the die data path.

[0069] Specifically, if Figure 3 As shown, the upstream path from Die0 to Die1 is Upstream. Die0 transmits TX Data via the Upstream path to Die1. Die1 receives RX Data and sends it to the Die1 universal verification component (UVC). Die1 transmits TX Data via the Downstream path to Die0. Die0 receives RX Data and sends it to the Die0 universal verification component (UVC). This enables cross-die data path functional verification.

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

[0071] Specifically, if Figure 3As shown. The macro definition PHASE0 configures the design code file list Filelist used by phase Phase0, which includes the function Function design code of phase Phase0 and the empty shell Phase1_Shell design code of phase Phase1. In D2D mode Mode, chip Die0 and chip Die1 are interconnected, that is, the empty shell Phase1_Shell design code port Port of chip Die0's phase Phase1 and the empty shell Phase1_Shell design code port Port of chip Die1's phase Phase1 are interconnected. Similarly, the macro definition PHASE1 also configures the design code file list Filelist used by phase Phase1, which includes the function Function design code of phase Phase0 and phase Phase1, and the empty shell Phase1_Shell design code of phase Phase2. The macro definition PHASE2 configures the design code file list Filelist used by phase Phase2, including the function Function design code of phase Phase0, phase Phase1 and phase Phase2. This enables functional verification of the RTL design code at different stages.

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

[0073] Specifically, the testbench can include three modes: D2D mode, D2V mode, and Loopback mode. The D2D mode is for interconnecting the chip die design code (RTL); the D2V mode is for interconnecting the chip die design code (RTL) and the universal verification component (UVC) or verification IP (VIP); and the Loopback mode is for looping back the chip die design code (RTL).

[0074] It is understandable that each mode includes the design code RTL of three phases. Figure 3 The D2D mode Mode shown in FIG. 1 includes the design code RTL of phase 0, phase 1 and phase 2. Figure 5 The D2V mode shown is Mode and Figure 6 The Loopback mode Mode shown includes the design code RTL of phase Phase0, phase Phase1 and phase Phase2.

[0075] Therefore, the design code RTL generated in each phase can be used as the design under test (DUT), and functional verification can be performed according to the phase division. Figure 3 In the D2D mode shown in the figure, the design code RTL used in the phase 0 configured by the macro definition PHASE0 can be used as the DUT for functional verification, thereby verifying the upstream data TX Data sending and the downstream data RX Data receiving 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, the design code RTL of at least one phase can be selected from the three aforementioned phases for verification.

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

[0078] Similarly, the hardware simulation Emu verification can also select the design code RTL of Phase 2 in the D2D mode of cross-die design code RTL interconnection for verification, so that the cross-die design code RTL verified by the system on chip SoC and the hardware simulation Emu verification are consistent.

[0079] In addition, the verification environment can also connect the TX (Transmit) and RX (Receive) signals of Phase 0 and Phase 1 through Force as an external loopback test.

[0080] In one embodiment, Figure 7As shown, in step 106, chip software SW testing is performed on the RTL codes at different stages to perform functional testing of the cross-die data path, which may specifically include:

[0081] Step 702: Select RTL codes at different stages as the test objects according to the chip software SW test requirements.

[0082] Specifically, during cross-die datapath chip software testing, RTL code at different stages can be selected as the test target based on the chip software testing requirements. For example, the RTL code at Phase 0 or Phase 1 can be selected as the test target. This enhances software testing selectivity, shortens testing cycles, and reduces the number of iterations.

[0083] Step 704 : constructing a software SW test environment and integrating the selected RTL code into the software SW test environment.

[0084] The test environment may include a simulator, debugging tools, etc. By building a software SW test environment and integrating the selected RTL code into the software SW test environment, subsequent testing is facilitated.

[0085] Step 706: Generate a test case to perform a cross-die data path functional test on the object under test.

[0086] Among them, 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 of different phases can be selected for function testing. Figure 8 As shown in the figure, similar to die datapath hardware verification, die datapath software SW testing targets the RTL code from each stage of the die hardware design process. Die datapath software SW testing can test the functionality of one or more RTL codes from Phase 0, Phase 1, and Phase 2 of the die hardware design process.

[0088] It's understandable that during chip software testing, different phases can be selected to complete the software driver test. The driver version should correspond to the selected hardware phase. Specifically, chip software and hardware version management can ensure that the RTL version of the hardware HW design phase and the driver version of the software SW test are consistent, facilitating the location of functional issues.

[0089] In one scenario, software SW testing performs functional testing on the design code RTL. You can choose to test the functional points that cannot be covered by the subsystem verification environment or the system-on-chip SoC verification. You can also consider functional testing associated with the system. Figure 8 As shown, software SW drives the Driver, interacting with chips Die0 and Die1 via chip interfaces such as PCIe. It then interacts with subsystems via the network-on-chip (NoC). Because software SW testing reflects real-world application scenarios, it can test functions that are not covered by subsystem or system-on-chip (SoC) verification. This improves test coverage and enhances the reliability of chip software testing.

[0090] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0091] Based on the same inventive concept, an embodiment of the present application further provides a cross-die data path design device for implementing the cross-die data path design method involved above. The implementation solution provided by the device is similar to the implementation solution described in the above method. Therefore, the specific limitations in the embodiments of one or more cross-die data path design devices provided below can be found in the above limitations of the cross-die data path design method, and will not be repeated here.

[0092] In an exemplary embodiment, Figure 9 As 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, wherein:

[0093] The code generation module 902 is configured to divide the chip hardware HW design into stages and generate RTL code for each stage of the cross-die data path;

[0094] Verification module 904 is configured to perform chip hardware HW verification by mode, connect the RTL code of each stage as the design under test (DUT) to the verification platform, and perform functional verification in different modes across the die data path;

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

[0096] In an exemplary embodiment, the code generation module is specifically configured to perform: 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, empty shell design code and debug loop design code of the corresponding stage as the RTL code of the stage.

[0097] In an exemplary embodiment, the 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.

[0098] In an exemplary embodiment, the debugging loopback design code for each stage is turned on or off by configuring a switch.

[0099] In an exemplary embodiment, the verification module is further configured to perform: 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 as the design under test DUT to the verification platform in the corresponding mode to perform functional verification on the design under test DUT at different stages under each mode.

[0100] In an exemplary embodiment, the modes include a cross-die interconnection mode, a chip die and 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.

[0101] In an exemplary embodiment, the test module is specifically configured to perform: selecting the RTL code at different stages as the object under test according to the chip software SW test requirements; building a software SW test environment and integrating the selected RTL code into the software SW test environment; generating test cases and performing cross-Die data path functional testing 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 loopback data path.

[0103] Each module in the above-mentioned cross-die data path design device can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in the memory of the computer device in the form of software, so that the processor can call and execute the corresponding operations of each module.

[0104] In an exemplary embodiment, an electronic device is provided, the internal structure of which can be as shown in FIG. Figure 10 As shown. The electronic device includes a processor, memory, an input / output interface, a communication interface, a display unit, and an input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are connected to the system bus via the input / output interface. 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 computer program in the non-volatile storage medium. The input / output interface of the electronic device is used to exchange information between the processor and an external device. The communication interface of the electronic device is used to communicate with an external terminal via wired or wireless communication, and the wireless communication can be achieved via Wi-Fi, a mobile cellular network, near field communication (NFC), or other technologies. When the computer program is executed by the processor, a cross-die data path design method is implemented. The display unit of the electronic device is used to form a visually visible image, and 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, and the input device of the electronic device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the electronic device casing, or an external keyboard, touchpad or mouse.

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

[0106] In an exemplary embodiment, an electronic device is provided, including a memory and a processor. The memory stores a computer program, and the processor implements the steps in the above method embodiments when executing the computer program.

[0107] In one 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-mentioned method embodiments are implemented.

[0108] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[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 used 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 must comply with relevant regulations.

[0110] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the 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-mentioned methods. In particular, any reference to memory, database, or other media used in the embodiments provided in this 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), magnetic 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 take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), quantum computing-based data processing logic devices, artificial intelligence (AI) processors, and the like.

[0111] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, 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, they should be considered to be within the scope of this application.

[0112] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by 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 in different modes across the die data path; Perform chip software SW testing on the RTL codes at different stages to perform functional testing of cross-die data paths; The chip hardware HW design is divided into stages, and RTL code for each stage of the cross-die data path is generated, including: Divide chip hardware HW design into multiple stages based on the functional requirements of cross-die data paths; For each stage, the functional design code, shell design code and debug loop design code of the corresponding stage are generated as the RTL code of the stage; the debug loop design code of each stage is turned on or off by configuring a switch.

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

3. 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 the cross-die data path, including: Divide 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 DUT to be tested and connected to the verification platform in the corresponding mode to perform functional verification on the DUT to be tested at different stages in each mode.

4. The method according to claim 3, characterized in that The modes include cross-die interconnection mode, chip die and verification tool interconnection mode, and 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.

5. The method according to claim 1, characterized in that The chip software SW test of the RTL code at different stages includes: According to the chip software SW test requirements, the RTL code at different stages is selected as the object 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.

6. The method according to any one of claims 1 to 5, 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.

7. 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 according to the 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 the cross-die data path; A test module is configured to perform chip software SW testing on the RTL code at different stages to perform functional testing of cross-die data paths; The code generation module is specifically configured to perform the following: 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 corresponding stage's functional design code, shell design code and debug loop design code as the RTL code of the stage; for each stage's debug loop design code, controlling whether it is turned on or off by configuring a switch.

8. 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 6 are implemented.

9. 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 6 are implemented.

10. 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 6 are implemented.

Images