Code verification system and code verification method

Abstract

The application relates to a code verification system and a code verification method. The system comprises an SOC module, a reference module, a comparison module, an agent module and a top module. The top module comprises a first to-be-tested module and a second to-be-tested module. The first to-be-tested module is generated by using a first language code, and the second to-be-tested module is generated by using a second language code. The SOC module is connected with the first to-be-tested module and the second to-be-tested module through the agent module. The reference module is connected with the comparison module. The comparison module is connected with the first to-be-tested module and the second to-be-tested module through the agent module. The same verification system is used to verify two different codes, and the problem of low verification efficiency caused by maintaining two sets of verification environments in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a code verification system and a code verification method. Background Technology

[0002] Virtio is a general-purpose paravirtualized I / O framework, primarily consisting of three parts: front-end drivers, back-end devices, and virtual queues. With the rapid development of the cloud computing industry, some hardware implementations of Virtio have emerged, such as smart network interface cards (NICs) and data processing units (DPUs). A high-quality smart NIC is crucial for a product's market success. This places high demands on verification engineers; an efficient verification solution can quickly identify and resolve defects, ensuring a high-speed, high-quality product launch. High-level synthesis (HLS) offers advantages such as high development efficiency and is therefore widely used in smart NIC code development. HLS automatically converts high-level languages ​​like C and C++ into Verilog, requiring verification personnel to verify both C and Verilog code.

[0003] In the existing technology, for C language code, the C language verification module C TESTBENCH built into HLS is used to verify C language code. For Verilog language code, a verification platform based on Universal Verification Methodology (UVM) is built to verify Verilog language code. However, this method is not very efficient. Summary of the Invention

[0004] Therefore, it is necessary to provide a code verification system and code verification method that can improve verification efficiency to address the above-mentioned technical problems.

[0005] In a first aspect, this application provides a code verification system, including: a system-on-a-chip (SOC) module, a reference module, a comparison module, a proxy module, and a top-level module. The top-level module includes: a first module to be tested and a second module to be tested. The first module to be tested is generated using code in a first language, and the second module to be tested is generated using code in a second language. The SOC module is connected to the first module to be tested and the second module to be tested respectively through the proxy module. The reference module is connected to the comparison module. The comparison module is connected to the first module to be tested and the second module to be tested respectively through the proxy module. The proxy module is configured with a mode corresponding to the first module to be tested and a mode corresponding to the second module to be tested.

[0006] When the first module under test is verified, the proxy module is used to switch to the mode corresponding to the first module under test, the SOC module is used to perform a first configuration on the first module under test, the first module under test is used to generate a first test result in response to the first configuration, and send the first test result to the comparison module through the proxy module, the reference module is used to generate a first reference result, and the comparison module is used to obtain the first test result and the first reference result, and verify whether the first module under test is normal based on the first test result and the first reference result;

[0007] When verifying the second module under test, the proxy module is used to switch to the mode corresponding to the second module under test, the SOC module is used to perform a second configuration on the second module under test, the second module under test is used to generate a second test result in response to the second configuration, and send the second test result to the comparison module through the proxy module, the reference module is used to generate a second reference result, and the comparison module is used to obtain the second test result and the second reference result, and verify whether the second module under test is normal based on the second test result and the second reference result.

[0008] In one embodiment, the code verification system further includes: a bidirectional conversion module, which is used to convert a first language into a second language and to convert the second language into a first language; a proxy module is connected to the second module under test through an interface; and the proxy module is connected to the first module under test through the bidirectional conversion module.

[0009] In one embodiment, the top-level module further includes a clock module, a reset module, and a clock simulation module. The first module under test is connected to the clock simulation module, and the second module under test is connected to both the clock module and the reset module. The clock module is used to generate a clock signal during the verification process of the second module under test, so that the second module under test generates the second test result based on the clock signal. Two adjacent clock signals are separated by one clock cycle. The reset module is used to generate a reset signal during the verification process of the second module under test. The clock simulation module is used to call the first language code once every clock cycle during the verification process of the first module under test, so that the first module under test generates the first test result.

[0010] In one embodiment, the SOC module includes three threads capable of running in parallel. The three threads are respectively used to run a control program, a coprocessor, and an Open Virtual Switching Standard (OVS) processor. The control program, the coprocessor, and the OVS processor are used to perform the first configuration and the second configuration.

[0011] In one embodiment, the code verification system further includes a transaction-level model port, through which the SOC module connects to the proxy module.

[0012] In one embodiment, the agent module includes: a register agent (REG agent), a direct memory access agent (DMA agent), a double rate synchronous dynamic random access memory agent (DDR agent), an Ethernet receiver agent (MAC RX agent), and an Ethernet transmitter agent (MAC TX agent).

[0013] In one embodiment, the first language code is C language code, and the second language code is VERILOG language code.

[0014] Secondly, this application also provides a code verification method, including:

[0015] When verifying the first module under test, the proxy module is controlled to switch to the mode corresponding to the first module under test, the first module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a first configuration on the first module under test. The first module under test generates a first test result in response to the first configuration, and sends the first test result to the comparison module through the proxy module. The comparison module verifies whether the first module under test is normal based on the first test result and the first reference result.

[0016] When verifying the second module under test, the proxy module is controlled to switch to the mode corresponding to the second module under test, the second module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a second configuration on the second module under test. The second module under test generates a second test result in response to the second configuration, and sends the second test result to the comparison module through the proxy module. The comparison module verifies whether the second module under test is normal based on the second test result and the second reference result.

[0017] The aforementioned code verification system and method include: a system-on-a-chip (SOC) module, a reference module, a comparison module, a proxy module, and a top-level module. The top-level module includes: a first module to be tested and a second module to be tested. The first module to be tested is generated using code in a first language, and the second module to be tested is generated using code in a second language. The SOC module is connected to both the first and second modules to be tested via the proxy module. The reference module is connected to the comparison module, and the comparison module is also connected to both the first and second modules to be tested via the proxy module. This allows for the verification of two different codes using the same verification system, solving the problem of low verification efficiency caused by maintaining two verification environments in existing technologies. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the structure of a code verification system in one embodiment;

[0019] Figure 2 This is a schematic diagram of the code verification system in another embodiment;

[0020] Figure 3 This is a schematic diagram of the code verification system in another embodiment;

[0021] Figure 4 This is a schematic diagram of the code verification system in another embodiment;

[0022] Figure 5 This is a schematic diagram of the code verification system in another embodiment;

[0023] Figure 6 This is a schematic diagram of the code verification system in another embodiment;

[0024] Figure 7 This is a flowchart illustrating a code verification method in one embodiment;

[0025] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0027] High-level synthesis (HLS) is widely used in the development of smart network interface card (NIC) code due to its high development efficiency. HLS can automatically convert high-level languages ​​such as C and C++ into Verilog. For verification personnel, this requires verifying both the C and Verilog code. In some embodiments, the C language verification module C TESTBENCH, which comes with HLS, is used to verify the C language code. For the Verilog code, a verification platform based on Universal Verification Methodology (UVM) is built. However, this approach requires maintaining two verification environments, increasing the difficulty for verification personnel and resulting in low verification efficiency.

[0028] Therefore, this application proposes to improve a verification platform based on a Verilog language code verification platform, focusing on the differences between C and Verilog languages. The improved platform is designed to be compatible with the verification of both C and Verilog code, thus solving the problem of verification personnel needing to maintain two verification environments. The solution of this application's embodiments is described in detail below with specific examples.

[0029] In one embodiment, see Figure 1 As shown, the verification system provided in this application embodiment includes: a system-on-a-chip (SOC) module, a reference module, a comparison module, a proxy module, and a top-level module.

[0030] The top-level module includes: a first module to be tested and a second module to be tested. The first module to be tested is generated using code in a first language, and the second module to be tested is generated using code in a second language. The SOC module is connected to the first module to be tested and the second module to be tested respectively through a proxy module. The reference module and the comparison module are connected. The comparison module is connected to the first module to be tested and the second module to be tested respectively through a proxy module. The proxy module is configured with the mode corresponding to the first module to be tested and the mode corresponding to the second module to be tested.

[0031] Optionally, the verification system provided in this application embodiment can be used to verify the code of the smart network interface card (NIC) written by the developer. As described above, the code of the smart NIC written by the developer exists in two versions: C language code and Verilog language code. In this application embodiment, the first language code can be C language code, and the second language code can be Verilog language code, but this is only an example and does not constitute a limitation on the embodiments of this application.

[0032] Optionally, the above reference module, comparison module, and proxy module are all written in Verilog.

[0033] The proxy module is configured with two modes: one for the first module under test and one for the second module under test. This means the proxy module has two interfaces, one for the first module and one for the second. When verifying the first module, the proxy module opens the interface corresponding to the first module and closes the interface corresponding to the second module, allowing interaction between the proxy module and the first module. Similarly, when verifying the second module, the proxy module opens the interface corresponding to the second module and closes the interface corresponding to the first module, enabling interaction between the proxy module and the second module.

[0034] based on Figure 1 The following describes the role of each module in the verification system when verifying the first module to be tested, and the role of each module in the verification system when verifying the second module to be tested:

[0035] When verifying the first module to be tested, the proxy module is used to switch to the mode corresponding to the first module to be tested, the SOC module is used to perform the first configuration of the first module to be tested, the first module to be tested is used to generate the first test result in response to the first configuration, and send the first test result to the comparison module through the proxy module, the reference module is used to generate the first reference result, and the comparison module is used to obtain the first test result and the first reference result, and verify whether the first module to be tested is normal based on the first test result and the first reference result.

[0036] The first configuration may include basic configurations such as the specifications and features of the smart network card. This application embodiment does not limit this. After the first configuration is completed, the proxy module can send the stimulus to the reference module and the first module under test respectively. The first module under test generates a first test result based on the received stimulus and sends the first test result to the comparison module through the proxy module. The reference module generates a first reference result based on the received stimulus and sends the first reference result to the comparison module. The comparison module compares the first test result and the first reference result. If the two are the same, it is determined that the first module under test is normal. If the two are different, it is determined that the first module under test is abnormal.

[0037] It should be noted that the above method for determining whether the first module to be tested is normal is only an example, and other methods in the industry can also be used. This application does not limit this method.

[0038] When verifying the second module under test, the proxy module is used to switch to the mode corresponding to the second module under test, the SOC module is used to perform a second configuration on the second module under test, the second module under test is used to generate a second test result in response to the second configuration, and sends the second test result to the comparison module through the proxy module, the reference module is used to generate a second reference result, the comparison module is used to obtain the second test result and the second reference result, and verify whether the second module under test is normal based on the second test result and the second reference result.

[0039] Similar to the first module under test, the second configuration may include basic configurations such as the specifications and features of the smart network card. After the second configuration is completed, the proxy module can send stimuli to the reference module and the second module under test respectively. The second module under test generates a second test result based on the received stimuli and sends the second test result to the comparison module through the proxy module. The reference module generates a second reference result based on the received stimuli and sends the second reference result to the comparison module. The comparison module compares the second test result and the second reference result. If they are the same, the second module under test is determined to be normal. If they are different, the second module under test is determined to be abnormal.

[0040] The verification system provided in this application embodiment has a proxy module configured with a mode corresponding to a first module to be tested and a mode corresponding to a second module to be tested. When verifying the first module to be tested, the proxy module switches to the mode corresponding to the first module to be tested to complete the verification; when verifying the second module to be tested, the proxy module switches to the mode corresponding to the second module to be tested to complete the verification. This enables the use of the same verification system to verify two different types of code, solving the problem of low verification efficiency caused by maintaining two verification environments in the prior art.

[0041] When the first language code is C, the second language code is Verilog, and the reference module, comparison module, and proxy module are all written in Verilog, the first module under test cannot directly interact with the proxy module. To solve this problem, in one embodiment, see... Figure 2 As shown, a verification system is proposed, which further includes: a bidirectional conversion module, which is used to convert a first language into a second language and to convert a second language into a first language; a proxy module is connected to the second module under test through an interface; and the proxy module is connected to the first module under test through the bidirectional conversion module.

[0042] Optionally, when verifying the first module to be tested, the proxy module switches to the mode corresponding to the first module to be tested. During the interaction between the proxy module and the first module to be tested, the bidirectional conversion module can be used to encapsulate the DPI function output by the proxy module into a first language so that the first module to be tested can recognize it. The bidirectional conversion module is also used to encapsulate the write and read functions of the C function FIFO output by the first module to be tested into a second language so that the proxy module can recognize it.

[0043] Optionally, the way the proxy module interacts with the second module under test through the interface can be found in the existing Universal Verification Methodology (UVM) architecture, which will not be elaborated here.

[0044] The verification system provided in this application embodiment adds a bidirectional conversion module, which can convert the first language into the second language and vice versa, enabling the first module to be tested to interact with the proxy module. This allows the first module to be tested and the second module to be tested to be verified in the same verification system, solving the problem of low verification efficiency caused by maintaining two verification environments in the prior art.

[0045] When the first language code is C and the second language code is Verilog, there are differences between C and Verilog. For example, Verilog has the concepts of clock and reset, while C does not. To enable the first module under test to be verified under the UVM architecture, this application proposes to add a clock simulation module. Specifically, in one embodiment, see [link to embodiment]. Figure 3 As shown, the top-level module also includes a clock module, a reset module, and a clock simulation module. The first module under test is connected to the clock simulation module, and the second module under test is connected to both the clock module and the reset module. The clock module is used to generate a clock signal during the verification process of the second module under test, so that the second module under test generates a second test result based on the clock signal. There is a one-clock-cycle interval between two adjacent clock signals. The reset module is used to generate a reset signal during the verification process of the second module under test. The clock simulation module is used to call the first language code once every clock cycle during the verification process of the first module under test, so that the first module under test generates a first test result.

[0046] Optionally, during the verification of the first module under test, after the first module under test is started, the clock simulation module calls the first language code once every clock cycle, causing the first module under test to generate a first test result. The first module under test then sends the first test result to the comparison module, allowing the comparison module to verify the first test result. During the verification of the second module under test, after the second module under test is started, the clock module generates a clock signal once every clock cycle. Upon receiving the clock signal, the second module under test runs the second language code once, thereby obtaining a second test result. The second module under test then sends the second test result to the comparison module, allowing the comparison module to verify the second test result.

[0047] The verification system provided in this application embodiment adds a clock simulation module. During the verification of the first module under test, after the first module under test is started, the clock simulation module calls the first language code once every clock cycle to realize the simulation of the clock signal, so that the first module under test can also be verified under the UVM architecture, and solves the problem of compatibility between C language code and VERILOG language code verification.

[0048] In some embodiments, the software behavior on the SOC side needs to be simulated by verification personnel. This requires verification personnel to align not only with the logical design requirements but also with the software developers' requirements. Consequently, verification personnel spend a significant amount of time understanding the SOC-side software behavior, and also need to spend considerable time implementing the software code, understanding the software requirements, implementing software functions, and debugging, increasing their workload and resulting in low efficiency. To address this technical problem, in one embodiment, see... Figure 4 As shown, the SOC module includes three threads that can run in parallel. These three threads are used to run the control program, the coprocessor, and the Open Virtual Switching Standard (OVS) processor, respectively. The control program, the coprocessor, and the OVS processor are used to perform the first and second configurations mentioned above.

[0049] Among them, the control program, coprocessor and Open Virtual Switch (OVS) processing program are developed by software engineers. In other words, the embodiments of this application directly use the programs developed by software engineers in the process of verifying the first and second modules to be tested. This eliminates the need for verification personnel to spend a lot of time understanding the software behavior on the SOC side and to spend a lot of time implementing the software code. Moreover, the hardware and software integration is brought forward, which greatly improves the verification efficiency and verification quality.

[0050] Since the SOC module needs to interact with the proxy module, and the SOC module typically uses C language while the proxy module typically uses Verilog language, this application proposes an embodiment to achieve interaction between the two, see [link to embodiment]. Figure 5 As shown, the verification platform also includes a transaction level modeling (TLM) port, through which the SOC module connects to the proxy module. Requests issued by the SOC module are passed to the proxy module via the TLM port. The proxy module parses the requests and sends the parsing results to the module under test. If the module under test returns data, the proxy module packages the data and returns it to the SOC module via the TLM port, ultimately achieving data interaction between the SOC module and the proxy module.

[0051] The verification system provided in this application directly uses the program developed by software engineers to verify the first and second modules to be tested. This eliminates the need for verification personnel to spend a significant amount of time understanding the software behavior on the SOC side and implementing the software code. Furthermore, it advances the hardware and software integration process, greatly improving verification efficiency and quality. Additionally, the addition of a TLM port enables interaction between the SOC module and the agent module.

[0052] The following section describes the further detailed design of the verification system.

[0053] In one embodiment, such as Figure 6 As shown, the verification system also includes a verification module, which comprises a stimulus generation module, a stimulus distribution module, and a register module. The stimulus generation module and the stimulus distribution module are connected. The stimulus distribution module is connected to the register module and the proxy module, respectively. The register module is connected to the proxy module and the comparison module, respectively. The proxy module is connected to the comparison module, the reference module, the first module under test, and the second module under test, respectively. Figure 6In this framework, the SOC module is also called `smart_nic_soc`, the top-level module is called `smart_nic_tb_top`, and the verification module is called `smart_nic_testbench`. The stimulus generation modules include: a register stimulus generation unit `reg_seq`, a direct memory access stimulus generation unit `smart_nic_dma_seq`, and an Ethernet port stimulus generation unit `mac*_seq`. The stimulus distribution module is also called `smart_nic_vsqr`, the register module is also called `smart_nic_reg_mdl`, the comparison module is also called `smart_nic_scb`, and the reference module is also called `smart_nic_rm`. The proxy modules include: a register proxy (REG agent), a direct memory access proxy (DMA agent), a double-rate synchronous dynamic random access memory proxy (DDR agent), an Ethernet receiver proxy (MAC RX agent), and an Ethernet transmitter proxy (MAC TX agent).

[0054] The register agent (REG agent) includes a register data receiving unit (REG SQR), a register data acquisition unit (REG MNT), and a register driving unit (REG DRV). The register driving unit (REG DRV) is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test. The register data acquisition unit (REG MNT) is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test (not shown).

[0055] The Direct Memory Access (DMA) agent includes: a Direct Memory Access Data Receiving Unit (DMA MEM), a Direct Memory Access Data Acquisition Unit (DMA MNT), and a Direct Memory Access Driver Unit (DMA DRV). The DMA DRV unit is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test. The DMA MNT unit is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test (not shown).

[0056] The Double Rate Synchronous Dynamic Random Access Memory (DDR) agent includes: a Double Rate Synchronous Dynamic Random Access Memory (DDR) data receiving unit (DDR MEM), a Double Rate Synchronous Dynamic Random Access Memory (DDR) data acquisition unit (DDR MNT), and a Double Rate Synchronous Dynamic Random Access Memory (DDR) driving unit (DDR DRV). The Double Rate Synchronous Dynamic Random Access Memory (DDR) driving unit is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test. The Double Rate Synchronous Dynamic Random Access Memory (DDR) data acquisition unit is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test (not shown).

[0057] The Ethernet transmit port agent (MAC TX agent) includes: an Ethernet transmit port data receiving unit (MAC TXSQR), an Ethernet transmit port data acquisition unit (MAC TX MNT), and an Ethernet transmit port driver unit (MAC TX DRV). The Ethernet transmit port driver unit (MAC TX DRV) is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test. The Ethernet transmit port data acquisition unit (MAC TX MNT) is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test (not shown).

[0058] The Ethernet receiver port agent (MAC RX agent) includes an Ethernet receiver port data acquisition unit (MAC RXMNT), which is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test.

[0059] When verifying the first module to be tested, the mode of each proxy in the proxy module is switched to the mode corresponding to the first module to be tested. That is, the interfaces configured for each proxy that are adapted to the first module to be tested are opened, and the interfaces configured for each proxy that are adapted to the second module to be tested are closed, so that the proxy module and the first module to be tested can interact. When verifying the second module to be tested, the mode of each proxy in the proxy module is switched to the mode corresponding to the second module to be tested. That is, the interfaces configured for each proxy that are adapted to the second module to be tested are opened, and the interfaces configured for each proxy that are adapted to the first module to be tested are closed, so that the proxy module and the second module to be tested can interact.

[0060] The verification system provided in this application embodiment has refined the proxy module. Based on this verification system, both C language code and Verilog language code can be verified, thereby improving verification efficiency.

[0061] In one embodiment, see Figure 7 As shown, a code verification method is provided, including:

[0062] S701. When verifying the first module under test, control the proxy module to switch to the mode corresponding to the first module under test, control the first module under test to run, and control the SOC module to start, so that the SOC module performs a first configuration on the first module under test. The first module under test generates a first test result in response to the first configuration, and sends the first test result to the comparison module through the proxy module. The comparison module verifies whether the first module under test is normal based on the first test result and the first reference result.

[0063] The first configuration may include basic configurations such as the specifications and features of the smart network interface card (NIC). After the first configuration is completed, the proxy module can send stimuli to the reference module and the first module under test, respectively. The first module under test generates a first test result based on the received stimuli and sends the first test result to the comparison module through the proxy module. The reference module generates a first reference result based on the received stimuli and sends the first reference result to the comparison module. The comparison module compares the first test result and the first reference result. If they are the same, the first module under test is determined to be normal; if they are different, the first module under test is determined to be abnormal. For detailed process, please refer to the description of the verification system in the above embodiments. It will not be repeated here.

[0064] S702. When the first module under test is normal, the second module under test is verified. The proxy module is controlled to switch to the mode corresponding to the second module under test, the second module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a second configuration on the second module under test. The second module under test generates a second test result in response to the second configuration, and sends the second test result to the comparison module through the proxy module. The comparison module verifies whether the second module under test is normal based on the second test result and the second reference result.

[0065] Similar to the first module under test, the second configuration may include basic configurations such as the specifications and features of the smart network interface card. After the second configuration is completed, the proxy module can send stimuli to the reference module and the second module under test respectively. The second module under test generates a second test result based on the received stimuli and sends the second test result to the comparison module through the proxy module. The reference module generates a second reference result based on the received stimuli and sends the second reference result to the comparison module. The comparison module compares the second test result and the second reference result. If they are the same, the second module under test is determined to be normal; if they are different, the second module under test is determined to be abnormal. For detailed process, please refer to the description of the verification system in the above embodiment. It will not be repeated here.

[0066] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores XX data. The network interface communicates with external terminals via a network connection. When the computer program is executed by the processor, it implements a code verification method.

[0067] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0068] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0069] When verifying the first module under test, the proxy module is controlled to switch to the mode corresponding to the first module under test, the first module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a first configuration on the first module under test. The first module under test generates a first test result in response to the first configuration, and sends the first test result to the comparison module through the proxy module. The comparison module verifies whether the first module under test is normal based on the first test result and the first reference result.

[0070] When verifying the second module under test, the proxy module is controlled to switch to the mode corresponding to the second module under test, the second module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a second configuration on the second module under test. The second module under test generates a second test result in response to the second configuration, and sends the second test result to the comparison module through the proxy module. The comparison module verifies whether the second module under test is normal based on the second test result and the second reference result.

[0071] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0072] When verifying the first module under test, the proxy module is controlled to switch to the mode corresponding to the first module under test, the first module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a first configuration on the first module under test. The first module under test generates a first test result in response to the first configuration, and sends the first test result to the comparison module through the proxy module. The comparison module verifies whether the first module under test is normal based on the first test result and the first reference result.

[0073] When verifying the second module under test, the proxy module is controlled to switch to the mode corresponding to the second module under test, the second module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a second configuration on the second module under test. The second module under test generates a second test result in response to the second configuration, and sends the second test result to the comparison module through the proxy module. The comparison module verifies whether the second module under test is normal based on the second test result and the second reference result.

[0074] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0075] When verifying the first module under test, the proxy module is controlled to switch to the mode corresponding to the first module under test, the first module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a first configuration on the first module under test. The first module under test generates a first test result in response to the first configuration, and sends the first test result to the comparison module through the proxy module. The comparison module verifies whether the first module under test is normal based on the first test result and the first reference result.

[0076] When verifying the second module under test, the proxy module is controlled to switch to the mode corresponding to the second module under test, the second module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a second configuration on the second module under test. The second module under test generates a second test result in response to the second configuration, and sends the second test result to the comparison module through the proxy module. The comparison module verifies whether the second module under test is normal based on the second test result and the second reference result.

[0077] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile 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 many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0078] The technical features of the above embodiments can be combined in any way. For the sake of brevity, 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 specification.

[0079] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A code verification system, characterized in that, include: The system-on-a-chip (SoC) module includes a reference module, a comparison module, a proxy module, and a top-level module. The top-level module includes a first module under test and a second module under test. The first module under test is generated using code in a first language, and the second module under test is generated using code in a second language. The SoC module is connected to the first module under test and the second module under test through the proxy module. The reference module is connected to the comparison module, and the comparison module is connected to the first module under test and the second module under test through the proxy module. The proxy module is configured with a mode corresponding to the first module under test and a mode corresponding to the second module under test. When the first module under test is verified, the proxy module is used to switch to the mode corresponding to the first module under test, the SOC module is used to perform a first configuration on the first module under test, the first module under test is used to generate a first test result in response to the first configuration, and send the first test result to the comparison module through the proxy module, the reference module is used to generate a first reference result, and the comparison module is used to obtain the first test result and the first reference result, and verify whether the first module under test is normal based on the first test result and the first reference result; When verifying the second module under test, the proxy module is used to switch to the mode corresponding to the second module under test, the SOC module is used to perform a second configuration on the second module under test, the second module under test is used to generate a second test result in response to the second configuration, and send the second test result to the comparison module through the proxy module, the reference module is used to generate a second reference result, and the comparison module is used to obtain the second test result and the second reference result, and verify whether the second module under test is normal based on the second test result and the second reference result.

2. The system according to claim 1, characterized in that, The code verification system further includes: a bidirectional conversion module, which is used to convert the first language into the second language and the second language into the first language; a proxy module is connected to the second module under test through an interface; and the proxy module is connected to the first module under test through the bidirectional conversion module.

3. The system according to claim 2, characterized in that, The top-level module further includes a clock module, a reset module, and a clock simulation module. The first module under test is connected to the clock simulation module, and the second module under test is connected to both the clock module and the reset module. The clock module generates a clock signal during the verification process of the second module under test, so that the second module under test generates the second test result based on the clock signal. Two adjacent clock signals are separated by one clock cycle. The reset module generates a reset signal during the verification process of the second module under test. The clock simulation module calls the first language code once every clock cycle during the verification process of the first module under test, so that the first module under test generates the first test result.

4. The system according to any one of claims 1-3, characterized in that, The SOC module includes three threads that can run in parallel. The three threads are respectively used to run a control program, a coprocessor, and an Open Virtual Switching Standard (OVS) processor. The control program, the coprocessor, and the OVS processor are used to perform the first configuration and the second configuration.

5. The system according to claim 4, characterized in that, The code verification system also includes a transaction-level model port, through which the SOC module connects to the proxy module.

6. The system according to claim 4, characterized in that, The agent module includes: register agent REGagent, direct memory access agent DMA agent, double rate synchronous dynamic random access memory agent DDR agent, Ethernet receiver agent MAC RX agent, and Ethernet transmitter agent MAC TX agent.

7. The system according to claim 4, characterized in that, The first language code is C language code, and the second language code is Verilog language code.

8. A code verification method, characterized in that, Applied to the system as described in any one of claims 1-7, the method comprises: When verifying the first module under test, the proxy module is controlled to switch to the mode corresponding to the first module under test, the first module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a first configuration on the first module under test. The first module under test generates a first test result in response to the first configuration, and sends the first test result to the comparison module through the proxy module. The comparison module verifies whether the first module under test is normal based on the first test result and the first reference result. When the first module under test is running normally, the second module under test is verified. The proxy module is controlled to switch to the mode corresponding to the second module under test, the second module under test is controlled to run, and the SOC module is controlled to start, so that the SOC module performs a second configuration on the second module under test. The second module under test generates a second test result in response to the second configuration, and sends the second test result to the comparison module through the proxy module. The comparison module verifies whether the second module under test is normal based on the second test result and the second reference result.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method of claim 8.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method of claim 8.

Images