Interface verification system and chip

Abstract

The embodiment of the present application provides an interface verification system and chip, which relates to the field of communication technology. The system includes: a verification device and a chip configuration model. The verification device includes a scenario randomization generator, multiple interface modules under test, and a TB component; the scenario randomization generator is used to randomly generate an interface configuration combination scenario based on a pre-configured chip specification set, generate TB component configuration information and a scenario description file based on the interface configuration combination scenario, configure the TB component based on the TB component configuration information, and send the scenario description file to the chip configuration model; the chip configuration model is used to generate a configuration sequence for each target interface module under test based on the scenario description file, and send a configuration sequence to each target interface module under test to configure each target interface module under test; the TB component is used to verify each target interface module under test after the configuration is completed. This can improve the efficiency of interface verification.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to an interface verification system and chip. Background Art

[0002] The network processing chips in current fixed-line core devices can receive Ethernet data packets, process them, and then forward them to the peer device. For example, after receiving an Ethernet data packet, a network router can search its routing table for matching routing information and then forward the Ethernet data packet based on the found routing information.

[0003] Network processing chips have a large number of Ethernet interfaces, each supporting a wide variety of speeds. Consequently, network processing chips can accommodate a wide range of interface configuration combinations. Developing a targeted test case for each interface configuration combination would require the development of a large number of targeted verification cases to perform electronic design assistance (EDA) verification of the various interface configuration combinations supported by network processing chips. Developing a large number of targeted verification cases is labor-intensive and time-consuming, impacting EDA verification progress and code coverage convergence efficiency. Summary of the Invention

[0004] The purpose of the embodiments of the present application is to provide an interface verification system and chip to improve EDA verification progress and code coverage convergence efficiency. The specific technical solution is as follows:

[0005] In a first aspect, an embodiment of the present application provides an interface verification system, comprising: a verification device and a chip configuration model, wherein the verification device includes a scenario randomization generator, a plurality of interface modules under test, and a verification platform TB component;

[0006] The scenario randomizer is configured to randomly generate an interface configuration combination scenario based on a preconfigured chip specification set, generate TB component configuration information and a scenario description file based on the interface configuration combination scenario, configure the TB component based on the TB component configuration information, and send the scenario description file to the chip configuration model; wherein the interface configuration combination scenario includes a target tested interface module among the multiple tested interface modules and occupied interface information of each target tested interface module, and the target tested interface module is the tested interface module to be tested this time;

[0007] The chip configuration model is used to generate a configuration sequence for each target interface module under test based on the scenario description file, and send a configuration sequence to each target interface module under test to configure each target interface module under test so that each target interface module under test matches its own occupied interface information after configuration;

[0008] The TB component is used to verify each target interface module under test after configuration is completed.

[0009] In a possible implementation, the TB component includes a driver component, a plurality of verification IP components, and a first scoreboard SCB module; wherein the number of the verification IP components is the same as the total number of serializer-deserializer channels included in the plurality of interface modules under test;

[0010] The driving component is configured to send a first test message to each target interface module under test after completing its own configuration, and send the first test message sent to each target interface module under test to the first SCB module;

[0011] Each target interface module under test is configured to receive a first test message sent by the driver component, process the first test message to obtain a second test message, and send the second test message to the verification IP component through a serial deserialization channel;

[0012] Each verification IP component is configured to receive a second test message output by the serial deserialization channel connected to itself and forward it to the first SCB module;

[0013] The first SCB module is configured to verify each target interface module under test based on the first test message and the second test message corresponding to the target interface module under test.

[0014] In a possible implementation, the TB component further includes a second SCB module and a plurality of monitoring components, each monitoring component being connected to a tested interface module;

[0015] Each verification IP component is further configured to, after completing its own configuration, send a third test message to the target interface module under test through the serial deserialization channel to which it is connected, and send the third test message sent to the target interface module under test to the second SCB module;

[0016] Each target interface module under test is configured to receive a third test message sent by the verification IP component through its own serial deserialization channel, process the received third test message to obtain a fourth test message, and send the fourth test message to the connected monitoring component;

[0017] The monitoring component is configured to receive a fourth test message sent by a target tested interface module connected to the monitoring component, and forward the message to the second SCB module;

[0018] The second SCB module is configured to verify a target interface module under test based on a third test message and a fourth test message corresponding to the target interface module under test.

[0019] In one possible implementation, the occupied interface information of each target interface module under test includes: the number of occupied interfaces and interface identifiers, the interface rate of each occupied interface, and the number and position of serial deserialization channels used by each occupied interface; the TB component configuration information includes driver configuration information, monitoring configuration information of each monitoring component connected to the target interface module under test, and verification configuration information of each verification IP component connected to the occupied serial deserialization channel; the driver configuration information includes: the identifier of each target interface module under test and the number of occupied interfaces and interface identifier of each target interface module under test; the monitoring configuration information of the monitoring component includes: the identifier of the target interface module under test connected to the monitoring component, the number of occupied interfaces and the occupied interface identifier; the verification configuration information of the verification IP component includes: the position of the serial deserialization channel corresponding to the verification IP component, and the interface identifier and interface rate of the interface to which the serial deserialization channel corresponding to the verification IP component belongs;

[0020] The scenario randomizer is specifically configured to send the driver configuration information to the driver component, send monitoring configuration information to the monitoring component connected to each target interface module under test, and send verification configuration information to the verification IP component connected to each occupied serial deserialization channel;

[0021] The driver component is configured to perform configuration operations based on the driver configuration information;

[0022] Each monitoring component is configured to, upon receiving monitoring configuration information, perform a configuration operation based on the received monitoring configuration information;

[0023] Each verification IP component is used to perform configuration operations based on the received verification configuration information when verification configuration information is received, and to establish a communication connection with its corresponding serial deserialization channel.

[0024] In a possible implementation, the scenario description file includes scenario description information of each target interface module under test, where the scenario description information is used to describe occupied interface information of the target interface module under test.

[0025] In a possible implementation, the chip configuration model is specifically used to parse the scenario description file, generate a configuration sequence of each target interface module under test for the scenario description information of the target interface module under test, and send the configuration sequence to the target interface module under test.

[0026] In one possible implementation, the configuration sequence includes a register access format for a target interface module under test;

[0027] Each target interface module under test is specifically used to receive the configuration sequence sent by the chip configuration model, parse the received configuration sequence, and configure its own registers based on the register access format obtained by the parsing, so that the configured target interface module under test matches its own occupied interface information.

[0028] In one possible implementation, the scenario randomizer is specifically used to randomly select chip specification parameters from the chip specification set through a random seed algorithm, and combine the selected chip specification parameters into the interface configuration combination scenario; wherein, the chip specification set includes: rate information applicable to the multiple interface modules under test, and the number and identification of serial-to-deserialization channels included in each interface module under test.

[0029] In a possible implementation, the interface module under test is an Ethernet interface module.

[0030] In a second aspect, an embodiment of the present application provides a chip, which includes an interface module that has passed the system verification described in the first aspect above.

[0031] Beneficial effects of the embodiments of the present application:

[0032] The interface verification system provided by the embodiment of the present application is a scene randomizer in the verification device that can randomly generate an interface configuration combination scene based on a pre-configured chip specification set, and generate TB component configuration information and a scene description file based on the interface configuration combination scene. After the TB component is configured based on the TB component information, the target interface module under test matches its own occupied interface information, that is, the interface configuration combination scene described based on the scene description file has taken effect. Furthermore, after the chip configuration model generates a configuration sequence based on the scene description file and configures the target interface module under test, the TB component can verify each target interface module under test. In this way, each time verification is performed, the scene randomizer can randomly generate an interface configuration combination scene, so there is no need to develop test cases for each chip specification separately, which can save labor costs and time costs, and improve the EDA verification speed and code coverage convergence speed.

[0033] Of course, it is not necessary to achieve all the advantages described above at the same time when implementing any product or method of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other embodiments can also be obtained based on these drawings.

[0035] Figure 1 A schematic diagram of the structure of an interface verification system provided in an embodiment of the present application;

[0036] Figure 2 A schematic diagram of the structure of another interface verification system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field based on this application are within the scope of protection of this application.

[0038] like Figure 1 As shown, Figure 1 This is a structural diagram of an interface verification system provided in an embodiment of the present application. The system includes: a verification device 10 and a chip configuration model 20. The verification device 10 includes a scenario randomization generator 11, multiple interface modules under test 12 and a verification platform (Test Bench, TB) component 13.

[0039] Optionally, the verification device 10 may be a server, and the chip configuration model 20 may be implemented based on Python, which is a computer programming language.

[0040] The scenario randomizer 11 is used to randomly generate an interface configuration combination scenario based on a pre-configured chip specification set, generate TB component configuration information and a scenario description file based on the interface configuration combination scenario, configure the TB component 13 based on the TB configuration information, and send the scenario description file to the chip configuration model 20.

[0041] The interface configuration combination scenario includes a target tested interface module among multiple tested interface modules and occupied interface information of each target tested interface module. The target tested interface module is the tested interface module that needs to be tested this time.

[0042] Optionally, the occupied interface information may include: the number and interface identifiers of the occupied interfaces, the interface rate of each occupied interface, and the number and location of Serdes lanes (Serdes lanes) used by each occupied interface.

[0043] In this embodiment of the present application, the chip specification set includes: applicable rate information for multiple interface modules under test, and the number and identification of the serializer / deserializer channels included in each interface module under test. A scenario randomizer can randomly select a target interface under test, the rate information for the target interface under test, and the identification of the serializer / deserializer channels used by the target interface under test from the chip specification set, thereby generating an interface configuration combination scenario.

[0044] For example, verification device 10 may include five interface modules under test, each of which may include eight SerDes lanes. The interfaces of the interface modules under test may support the following 11 data rates: 1GER1, 10GER1, 25GER1, 50GER1, 50GER2, 40GER4, 100GER4, 100GER2, 200GER4, 400GER8, and 800GER8. GE stands for GigaByte Ethernet, and R1 represents the number of SerDes lanes. For example, 40GER4 indicates that the Ethernet interface has a data rate of 400 Gbit / s, and achieving a data rate of 400 Gbit / s requires four SerDes lanes.

[0045] Then, in the embodiment of the present application, the interface configuration combination scenario generated by the scenario randomizer can be a variety of permutations and combinations of chip specification parameters included in the chip specification set, and the interface combination configuration scenario randomly generated by the scenario randomizer is different each time.

[0046] As an example, an interface configuration combination scenario may be to use the interface module under test 1 as the target interface module under test, and the interface module under test 1 occupies 1 interface, which uses 8 Serdes lanes with an interface rate of 400GER8; the number of the first occupied Serdes lane is 0.

[0047] The chip configuration model 20 is used to generate a configuration sequence for each target interface module under test based on the scenario description file, and send a configuration sequence to each target interface module under test respectively to configure each target interface module under test so that each target interface module under test after configuration matches its own occupied interface information.

[0048] The TB component 13 is used to verify each target interface module under test after completing the configuration.

[0049] The interface verification system provided by the embodiment of the present application is a scene randomizer in the verification device that can randomly generate an interface configuration combination scene based on a pre-configured chip specification set, and generate TB component configuration information and a scene description file based on the interface configuration combination scene. After the TB component is configured based on the TB component information, and the chip configuration model generates a configuration sequence based on the scene description file and configures the target interface module under test, the target interface module under test matches its occupied interface information, that is, the interface configuration combination scene described based on the scene description file has taken effect. Then the TB component can verify each target interface module under test. In this way, each time verification is performed, the scene randomizer can randomly generate an interface configuration combination scene, so there is no need to develop test cases for each chip specification separately, which can save labor costs and time costs, and improve the EDA verification speed and code coverage convergence speed.

[0050] In an embodiment of the present application, the scenario randomizer 11 is specifically configured to randomly select chip specification parameters from a chip specification set using a random seed algorithm, and combine the selected chip specification parameters into the interface configuration combination scenario.

[0051] For example, the scenario randomizer 11 may randomly select a tested interface module as a target tested interface module, then randomly generate a random number for each target tested interface module and select a rate corresponding to the random number. For example, random numbers 0-10 correspond to 1GER1, 10GER1, 25GER1, 50GER1, 50GER2, 40GER4, 100GER4, 100GER2, 200GER4, 400GER8, and 800GER8, respectively.

[0052] If the generated random number is 8, it indicates that the selected interface rate is 200GER4, meaning that the interface rate is 200Gbit / s and uses four SerDes channels. Since a target interface under test includes eight SerDes channels, there are still four SerDes channels available. Therefore, the scenario randomizer can generate another random number. The corresponding interface rate must occupy fewer than or equal to four SerDes channels. For example, if the generated random number is 7, it indicates that the selected interface rate is 100GER4, meaning that another interface rate is 100Gbit / s and uses four SerDes channels. At this point, all SerDes channels on the target interface module under test are occupied, confirming that the number of occupied interfaces on the target interface module is four, with interface rates of 200GER4 and 100GER4, respectively.

[0053] Then, the serial deserialization channel position to be used can be randomly selected for each interface. In this case, a random number can be generated for the 200GER4 interface, and the serial deserialization channel number corresponding to the random number is selected as the number of the first serial deserialization channel used by the interface. For example, random numbers 0-7 correspond to serial deserialization channel numbers 0-7. If the random number generated for the 200GER4 interface is 0, it means that the first serial deserialization channel used by the 200GER4 interface is numbered 0. In other words, the 200GER4 interface can use the four serial deserialization channels numbered 0 to 3. Furthermore, it can be determined that the first serial deserialization channel used by the 100GER4 is numbered 7.

[0054] With this system, the scenario randomization generator can randomly generate all possible interface combination configuration scenarios for the multiple interface modules under test included in the verification device. For complex interface configurations, automated verification can also be completed without the need for manual configuration of verification cases, which can improve verification efficiency.

[0055] In an embodiment of the present application, the TB component 13 includes a driver component, multiple verification intellectual property (IP) components, and a first scoreboard (SCB) module; wherein the number of verification IP components is the same as the total number of serial deserialization channels included in the multiple interface modules under test. For example, if there are 5 interface modules under test in the verification device, and each interface module under test includes 8 serial deserialization channels, then the verification device includes 40 verification IP components. Among them, the verification intellectual property (VIP) component is a predefined functional module, and the VIP in the TB component is used to verify the interface module under test.

[0056] The interface module under test in the embodiment of the present application may be an Ethernet Media Access Control (ETH MAC) interface module, or may be another type of chip interface module, which is not limited in the embodiment of the present application. For ease of understanding, the Ethernet Media Access Control interface module will be referred to as the Ethernet interface module below.

[0057] For example, the verification device includes five interface modules under test, each of which includes eight serial deserialization channels. The verification device includes five designs under test (DUTs), each of which is a tested interface module. Specifically, the tested interface module can be an Ethernet interface module. As shown in Figure 2, Figure 2The figure shows a verification device consisting of one driver component, five interface modules under test, and 40 verification IP components. After generating TB component configuration information, the scenario randomizer can configure the driver component, verification IP component, and monitoring component based on the TB component configuration information. Furthermore, the scenario randomizer can invoke a chip configuration model, causing it to generate a configuration sequence based on the scenario description file, thereby configuring the target interface modules under test based on the configuration sequence.

[0058] The driver component is connected to each interface module under test, and is also connected to the first SCB module. The driver component may be a transmit interface driver (TXIFDriver).

[0059] Figure 2 The 40 verification IP components are respectively verification IP component 0, verification IP component 1, ..., verification IP component 39, and each verification IP component has a corresponding relationship with a serial deserialization channel. After the verification IP component is configured, it can be connected to the physical coding sublayer (PCS) interface of the serial decoding channel with which it has a corresponding relationship. In addition, the other end of each verification IP component is connected to the first SCB module. Among them, the initialization module of the verification device can obtain the interface configuration combination scenario generated by the scenario randomization generator in the initialization process, and then configure the clock (CLK) and data bit width of the PCS interface connected to the occupied interface for the interface rate of each occupied interface of each target interface module under test in the interface configuration combination scenario, so that the rate of the PCS interface matches the interface rate of the occupied interface.

[0060] In the case where the interface module under test is an Ethernet interface module, the verification IP component may be an Ethernet Verification Intellectual Property (ETH VIP) component.

[0061] The driving component is configured to send a first test message to each target interface module under test after completing its own configuration, and send the first test message sent to each interface module under test to the first SCB module.

[0062] Among them, after completing the configuration, the driver component can generate a first test message for each target interface under test during the test phase, and the driver component will send the first test message sent to each target interface under test to the first SCB module, so that the first SCB module can subsequently verify the target interface under test.

[0063] Each target tested interface module is used to receive a first test message sent by the driver component, process the first test message to obtain a second test message, and send the second test message to the verification IP component through a serial deserialization channel.

[0064] In an embodiment of the present application, the target interface module under test may process the first test message by searching for routing information in a routing table and forwarding the first test message according to the routing information, or may queue the received first test message according to the message queue priority and perform other processing operations, and the embodiment of the present application does not impose any restrictions on this.

[0065] Each verification IP component is configured to receive a second test message output by the serial deserialization channel connected to itself and forward the second test message to the first SCB module.

[0066] The first SCB module is configured to verify each target interface module under test based on a first test message and a second test message corresponding to the target interface module under test. In other words, the first SCB module can verify the functionality of the target interface module under test by comparing the first test message sent to the target interface module under test with the second test message output by the target interface module under test after processing the first test message.

[0067] Optionally, the driving component can send the data part of the first test message to the first SCB module. Accordingly, after the verification IP component receives the second test message, it can parse the second test message and send the data part of the second test message obtained by parsing to the first SCB module. Then, the first SCB module can verify whether the data parts of the first test message and the second test message corresponding to the same target interface module under test are the same. If they are the same, there is no abnormality in the function of the target interface module under test. If they are different, there is an abnormality in the function of the target interface module under test.

[0068] In an embodiment of the present application, the driver component simulates the operation of the CPU connected to the real network processing chip, and the verification IP component simulates the operation of the external network port connected to the interface of the real network processing chip, that is, the driver component sends a first test message to the target tested interface module, and the target tested interface module sends a second test message to the verification IP component, which is equivalent to simulating the process of the CPU sending a message to the external network port through the interface of the real network processing chip. Then, the first SCB module verifies the target interface based on the first test message and the second test message, which is equivalent to verifying the function of the tested interface module of the network processing chip to send a message to the external network port. In the above verification process, there is no need for developers to develop targeted verification use cases, which can save manpower and improve verification efficiency.

[0069] In another embodiment of the present application, because the network processing chip's interface can perform bidirectional message forwarding, the embodiment of the present application can also verify the network processing chip's interface's ability to forward messages from a peer end. Furthermore, the TB component further includes a second SCB module and multiple monitoring components, each of which is connected to a tested interface module.

[0070] Still taking the verification equipment including 5 tested interface modules as an example, Figure 2 As shown, the TB component may include five monitoring components, each of which is connected to a tested interface module. The monitoring component in the embodiment of the present application may specifically be a transmit interface monitor (RXIF monitor) component.

[0071] Each verification IP component is further configured to send a third test message to the target interface module under test through its own connected serial deserialization channel after completing its own configuration, and send the third test message sent to the target interface module under test to the second SCB module.

[0072] Among them, after completing its own configuration, the verification IP component can generate a third test message in the test phase, and the verification IP component will send the third test message to the serial deserialization channel and the second SCB module connected to itself, so that the second SCB module can subsequently verify the target interface under test.

[0073] Each target interface module under test is used to receive the third test message sent by the verification IP component through its own serial deserialization channel, process the received third test message to obtain a fourth test message, and send the fourth test message to the connected monitoring component.

[0074] In an embodiment of the present application, the target interface module under test may process the third test message by searching for routing information in a routing table and forwarding the third test message according to the routing information, or may queue the received third test message according to the message queue priority and perform other processing operations, and the embodiment of the present application does not impose any restrictions on this.

[0075] The monitoring component is configured to receive a fourth test message sent by a target tested interface module connected to the monitoring component, and forward the fourth test message to the second SCB module.

[0076] The second SCB module is configured to verify the target interface module under test based on the third test message and the fourth test message corresponding to the target interface module under test. In other words, the second SCB module can verify the functionality of the target interface module under test by comparing the third test message sent to the target interface module under test with the fourth test message output by the target interface module after processing the third test message. Optionally, the second SCB module can specifically compare the data portions of the third test message and the fourth test message corresponding to the same target interface module under test. If the data portions are identical, it indicates that the functionality of the target interface module under test is normal; if the data portions are different, it indicates that the functionality of the target interface module under test is abnormal.

[0077] In the embodiment of the present application, the verification IP component simulates the operation of the external network port connected to the real network processing chip, that is, the verification IP component sends a third test message to the target interface module under test through the serial deserialization channel connected to itself, which is equivalent to the target interface module under test receiving the third test message sent by other devices; the process of the target interface module under test sending the fourth monitoring message to the monitoring component is equivalent to simulating the process of the target interface module under test forwarding the message, and then the second SCB module verifies the target interface module under test based on the third test message and the fourth test message, which is equivalent to verifying the forwarding function of the interface module under test of the network processing chip after receiving the message sent by other devices. In the above verification process, there is no need for developers to develop targeted verification use cases, which can save manpower and improve verification efficiency.

[0078] The TB component in the embodiment of the present application can specifically be a TB component based on a unified verification methodology (Universal Verification Methodology, UVM) verification use case. In the construction phase (build phase) of UVM, a scenario-based random generator can generate TB component configuration information and scenario description files.

[0079] The following introduces the TB component configuration information and scene description file generated by the scene randomization generator in the embodiment of the present application.

[0080] The TB component configuration information may include driver configuration information, monitoring configuration information, and verification configuration information. Specifically, the TB component configuration information includes driver configuration information, monitoring configuration information for each monitoring module connected to the target interface module under test, and verification configuration information for each verification IP component connected to the occupied serial deserialization module channel.

[0081] The driver configuration information includes: the identifier of each target tested interface module and the number and interface identifier of each target tested interface module. Optionally, the driver configuration information may also include the interface rate of each occupied interface, the number of test messages to be sent, and the test message length.

[0082] The scenario randomizer is specifically used to send driver configuration information to the driver component, send monitoring configuration information to the monitoring component connected to each target interface module under test, and send verification configuration information to each verification IP component connected to the occupied serial deserialization channel.

[0083] The driver component is used to perform configuration operations based on the driver configuration information.

[0084] Each monitoring component is configured to, upon receiving monitoring configuration information, perform configuration operations based on the received monitoring configuration information. The monitoring configuration information received by a monitoring component may include: an identifier of a target interface module under test connected to the monitoring component, the number of occupied interfaces of the target interface module under test, and an identifier of an occupied interface of the target interface module under test. Optionally, the monitoring configuration information may also include an interface rate for each occupied interface of the target interface module under test.

[0085] Each verification IP component is configured to, upon receiving verification configuration information, perform configuration operations based on the received verification configuration information and establish a communication connection with its corresponding serial deserialization channel. The verification configuration information received by a verification IP component includes the location of its corresponding serial deserialization channel, the interface identifier of the interface to which the serial deserialization channel belongs, and the interface rate. Optionally, the verification configuration information may also include the number and length of test messages to be sent by the verification IP component.

[0086] It can be understood that in the build phase, the scenario randomizer can complete the sending of the above-mentioned configuration information, and then in the configuration phase (config phase), the driver component, each monitoring component and each verification IP component can complete the configuration operation based on the configuration information they have received, and then in the run phase (run phase), the target interface under test can be verified based on the completed configuration.

[0087] In another embodiment of the present application, the scenario description file includes scenario description information of each target interface module under test, and the scenario description information is used to describe the occupied interface information of the target interface module under test.

[0088] The occupied interface information of each target interface module under test may include: the number of occupied interfaces and interface identifiers, the interface rate of each occupied interface, and the number and position of the serial deserialization channels used by each occupied interface. The position of the serial deserialization channel used by the occupied interface can be represented by the number of the first serial deserialization channel occupied and used by the interface. For example, if an interface uses four serial deserialization channels and the number of the first serial deserialization channel used is 1, then the four serial deserialization channels used by the interface are numbered 1, 2, 3, and 4, respectively.

[0089] The scenario description file is a configuration scenario described in a scenario description language. As an example, Figure 2 For example, if the verification device includes five interface modules under test, namely five ETH MACs, and each ETH MAC includes eight serial and deserialization channels, the scenario description file can be:

[0090] “#mac para config

[0091] MOD=MAC_BE0

[0092] ATTR=PORT_LIST_NUM; TYPE=DEC; VALUE=1

[0093] ATTR=400GE_PORT_SDS_LANE; TYPE=DEC; VALUE=8

[0094] ATTR=400GE_PORT_LIST; TYPE=STR_LIST; VALUE=[0]

[0095] MOD=MAC_BE1

[0096] ATTR=PORT_LIST_NUM; TYPE=DEC; VALUE=3

[0097] ATTR=200GE_PORT_SDS_LANE; TYPE=DEC; VALUE=4

[0098] ATTR=200GE_PORT_LIST; TYPE=STR_LIST; VALUE=[0]

[0099] ATTR=100GE_R2_PORT_SDS_LANE; TYPE=DEC; VALUE=2

[0100] ATTR=100GE_R2_PORT_LIST; TYPE=STR_LIST; VALUE=[4,6]

[0101] MOD=MAC_BE2

[0102] ATTR=PORT_LIST_NUM; TYPE=DEC; VALUE=3

[0103] ATTR=200GE_PORT_SDS_LANE; TYPE=DEC; VALUE=4

[0104] ATTR=200GE_PORT_LIST; TYPE=STR_LIST; VALUE=[0]

[0105] ATTR=100GE_R2_PORT_SDS_LANE; TYPE=DEC; VALUE=2

[0106] ATTR=100GE_R2_PORT_LIST; TYPE=STR_LIST; VALUE=[6,4]

[0107] MOD=MAC_BE3

[0108] ATTR=PORT_LIST_NUM; TYPE=DEC; VALUE=0

[0109] MOD=MAC_BE4

[0110] ATTR=PORT_LIST_NUM; TYPE=DEC; VALUE=0”

[0111] The MOD keyword is used to indicate the target interface module under test to which the described DUT belongs. For example, MOD=MAC_BE0 indicates that the description information of ETH MAC module 0 follows.

[0112] The ATTR keyword indicates a descriptive message, and the PORT_LIST_NUM keyword indicates the number of MAC ports configured for this descriptive message. The MAC port number refers to the number of interfaces occupied by the target interface module under test. The TYPE keyword specifies the format of the VALUE value field. DEC specifies that the VALUE value is interpreted in decimal. The VALUE value represents the specific value of the descriptive message, that is, the actual number of MAC ports.

[0113] "XXX"GE_PORT_SDS_LANE indicates the interface speed is "XXX". For example, "200GE_PORT_SDS_LANE" indicates the interface speed is 200GE. The value corresponding to "XXX"GE_PORT_SDS_LANE indicates the number of SerDes lanes occupied by the interface with a speed of "XXX" GE.

[0114] "XXX" GE_PORT_LIST is used to indicate the location information list of the SerDes lanes occupied by interfaces with a rate of "XXX" GE. The value of VALUE indicates the number of the first SerDes lane used by the interface.

[0115] Based on the definition of the scenario description language, the configuration scenarios described in the scenario description file include:

[0116] Take ETH MAC0 represented by MAC_BE0 as a target interface module under test. The random scenario for ETH MAC0 is: the number of occupied interfaces is 1, the interface rate is 400GER8, 8 Serdes lanes are occupied, and the number of the first Serdes lane occupied is 0.

[0117] Take ETH MAC1 represented by MAC_BE1 as the target interface module under test. Random scenarios for ETH MAC1 are as follows: 3 occupied interfaces, one of which operates at 200GER4, occupies four Serdes lanes, and the first occupied Serdes lane is numbered 0. The other two interfaces operate at 100GER2, each occupying two Serdes lanes, with the first occupied Serdes lanes numbered 4 and 6, respectively.

[0118] The ETH MAC2 represented by MAC_BE2 is used as the target interface module under test. The following random scenarios are generated for the ETH MAC2: 3 occupied interfaces, one of which operates at 200GER4, occupies 4 Serdes lanes, and the first occupied Serdes lane is numbered 0. The other two interfaces operate at 100GER2, each occupying 2 Serdes lanes, with the first occupied Serdes lanes numbered 6 and 4, respectively.

[0119] In this scenario, ETH MAC3 represented by MAC_BE3 and ETH MAC4 represented by MAC_BE2 are not occupied and are in idle state, requiring no configuration.

[0120] In another embodiment of the present application, the chip configuration model is specifically used to parse the above-mentioned scenario description file, generate a configuration sequence of the target interface module under test for the scenario description information of each target interface module under test, and send the configuration sequence to the target interface module under test.

[0121] When the interface module under test is an Ethernet interface module, the chip configuration model in the embodiment of the present application can be an ETH MAC register configuration model developed using the python scripting language based on the DUT register programming guide.

[0122] The chip configuration model can process the scenario description configuration file described above into a configuration sequence recognizable by the registers of the target interface module under test using the Python scripting language. Generating the configuration sequence based on the Python scripting language facilitates unified management of the configuration sequence and enables the structure of the configuration sequence and TB component configuration information. Furthermore, the configuration sequence for the target interface under test can be applied to verification systems at other levels of EDA verification.

[0123] The configuration sequence includes a register access format for the target interface module under test. Accordingly, the target interface module under test is specifically configured to receive the configuration sequence sent by the chip configuration model, parse the received configuration sequence, and configure its own registers based on the parsed register access format so that the configured target interface module under test matches its own occupied interface information.

[0124] After receiving the configuration sequence, the target interface under test may parse the received configuration sequence based on registers in a registration mode during a main phase simulation phase included in the run phase, and further configure its own registers based on the parsing result.

[0125] For example, for the target interface module under test ETH MAC0, the occupied interface information includes: the number of occupied interfaces is 1, the interface rate is 400GER8, 8 Serdes lanes are occupied, and the number of the first occupied Serdes lane is 0. After the target interface module under test configures its own registers, one interface of the target interface module under test will be able to achieve an interface rate of 400GER8 through the eight Serdes lanes numbered 0 to 8.

[0126] Since the target interface module under test can parse the configuration sequence and perform configuration operations during simulation, there is no need to compile the configuration sequence in advance, which can reduce the number of compilations and improve simulation efficiency and disk utilization.

[0127] As an example, based on the scenario description information of the first target interface module under test (ie, EHT MAC0) in the scenario description file described in the above embodiment, the generated configuration sequence is as follows:

[0128] "wait 100

[0129] indwrite NET_IF_PORT_0 0 1A00 FF

[0130] indwrite NET_IF_PORT_0 0 1A01 FF

[0131] indwrite NET_IF_PORT_0 0 1A03 fe

[0132] indwrite NET_IF_PORT_0 0 1A04 fe

[0133] write NET_IF_PORT_0CFG_1588_GLOB_REG 10009

[0134] write NET_IF_PORT_0CFG_1588_PORT_RX_REG ff

[0135] write NET_IF_PORT_0CFG_1588_PORT_TX_REG aaaa

[0136] write NET_IF_PORT_0CFG_1588_LENGTH_REG f6003c

[0137] write NET_IF_PORT_0CFG_PORT_TXEN_REG ff

[0138] write NET_IF_PORT_0CFG_PORT_RXEN_REG ff

[0139] write NET_IF_PORT_0CFG_MAC_ILKN_ETH_Tx_SEL_REG 0

[0140] write NET_IF_PORT_0CFG_MAC_ILKN_ETH_RX_SEL_REG 0

[0141] write NET_IF_PORT_0CFG_LINK_STATUS_MASK ff0ff

[0142] write NET_IF_PORT_0CFG_SD_SIGDET_MASK 0

[0143] write NET_IF_PORT_0CFG_400GR8_CH_REG 3

[0144] write NET_IF_PORT_0CFG_400GR8_AD_REG 1

[0145] write NET_IF_PORT_0CEMAC_CFG_400G_TF_CTRL_REG 1

[0146] indwrite NET_IF_PORT_0 0 1000FC1C0

[0147] indwrite NET_IF_PORT_0 0 1001 80008

[0148] indwrite NET_IF_PORT_0 0 1003 30003000

[0149] indwrite NET_IF_PORT_0 0FF 80

[0150] indwrite NET_IF_PORT_0 0 1A00 00

[0151] indwrite NET_IF_PORT_00 1A01 00”

[0152] Based on this configuration sequence, some read and write operations, read and write operations with mask bits, and read and compare operations with mask bits can be performed on the register.

[0153] Among them, in the above configuration sequence, write and indwrite are different types of write operations, NET_IF_PORT0 indicates that a write operation needs to be performed on the register in EHT MAC0, and the field between NET_IF_PORT0 in each row and the value represented at the end of each row indicates the identifier of the register, for example, "1A00" indicates register 1A00, "1A01" indicates register 1A01, and "CFG_SD_SIGDET_MASK" indicates register CFG_SD_SIGDET_MASK.

[0154] Taking write NET_IF_PORT0 CFG_SD_SIGDET_MASK 0 as an example, write NET_IF_PORT0CFG_SD_SIGDET_MASK 0 is used to indicate writing 0 to the CFG_SD_SIGDET_MASK register of ETH MAC 0.

[0155] It is understandable that after each target interface module under test completes configuration of its own register and the TB component completes configuration, the verification process can be started to verify each target interface module under test to obtain simulation results.

[0156] It should be noted that the above embodiments of the present application are all described using an Ethernet interface as an example. In actual implementation, the interface module under test can also be another type of interface module, such as an ILKN interface or a HiGi interface. That is, the embodiments of the present application can achieve full coverage verification of various configuration scenarios for complex configuration scenarios.

[0157] Among them, ILKN is the abbreviation of Interlaken bus, which is a high-speed transmission bus protocol, and HiGi is a communication interface MAC layer protocol based on Ethernet.

[0158] Through practice, the application of this system can reduce the verification manpower from 5 people to 1 person at least, and discovered Register Transfer Level (RTL) problems in 10 configuration combinations, effectively improving verification efficiency.

[0159] An embodiment of the present application also provides a chip, which may include an interface module verified by the above system.

[0160] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0161] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0162] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referenced to each other.

[0163] The above description is only a preferred embodiment of the present application and is not intended to limit the scope of protection of the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application are included in the scope of protection of the present application.

Claims

1. An interface verification system, characterized in that: include: Verification equipment and chip configuration model, wherein the verification equipment includes a scenario randomization generator, multiple interface modules under test and a verification platform TB component; The scenario randomizer is configured to randomly generate an interface configuration combination scenario based on a preconfigured chip specification set, generate TB component configuration information and a scenario description file based on the interface configuration combination scenario, configure the TB component based on the TB component configuration information, and send the scenario description file to the chip configuration model; wherein the interface configuration combination scenario includes a target tested interface module among the multiple tested interface modules and occupied interface information of each target tested interface module, and the target tested interface module is the tested interface module to be tested this time; The chip configuration model is used to generate a configuration sequence for each target interface module under test based on the scenario description file, and send a configuration sequence to each target interface module under test to configure each target interface module under test so that each target interface module under test matches its own occupied interface information after configuration; The TB component is used to verify each target interface module under test after configuration is completed.

2. The system according to claim 1, wherein: The TB component includes a driver component, a plurality of verification IP components and a first scoreboard SCB module; wherein the number of the verification IP components is the same as the total number of serial deserialization channels included in the plurality of interface modules under test; The driving component is configured to send a first test message to each target interface module under test after completing its own configuration, and send the first test message sent to each target interface module under test to the first SCB module; Each target interface module under test is configured to receive a first test message sent by the driver component, process the first test message to obtain a second test message, and send the second test message to the verification IP component through a serial deserialization channel; Each verification IP component is configured to receive a second test message output by the serial deserialization channel connected to itself and forward it to the first SCB module; The first SCB module is configured to verify each target interface module under test based on the first test message and the second test message corresponding to the target interface module under test.

3. The system according to claim 2, characterized in that The TB assembly further includes a second SCB module and a plurality of monitoring components, each monitoring component being connected to a tested interface module; Each verification IP component is further configured to, after completing its own configuration, send a third test message to the target interface module under test through the serial deserialization channel to which it is connected, and send the third test message sent to the target interface module under test to the second SCB module; Each target interface module under test is configured to receive a third test message sent by the verification IP component through its own serial deserialization channel, process the received third test message to obtain a fourth test message, and send the fourth test message to the connected monitoring component; The monitoring component is configured to receive a fourth test message sent by a target tested interface module connected to the monitoring component, and forward the message to the second SCB module; The second SCB module is configured to verify a target interface module under test based on a third test message and a fourth test message corresponding to the target interface module under test.

4. The system according to claim 2, wherein: The occupied interface information of each target tested interface module includes: the number of occupied interfaces and interface identifiers, the interface rate of each occupied interface, and the number and position of serial deserialization channels used by each occupied interface; The TB component configuration information includes driver configuration information, monitoring configuration information of each monitoring component connected to the target interface module under test, and verification configuration information of each verification IP component connected to the occupied serial deserialization channel; the driver configuration information includes: the identifier of each target interface module under test and the number of occupied interfaces and interface identifiers of each target interface module under test; the monitoring configuration information of the monitoring component includes: the identifier of the target interface module under test connected to the monitoring component, the number of occupied interfaces and the occupied interface identifiers; the verification configuration information of the verification IP component includes: the position of the serial deserialization channel corresponding to the verification IP component, and the interface identifier and interface rate of the interface to which the serial deserialization channel corresponding to the verification IP component belongs; The scenario randomizer is specifically configured to send the driver configuration information to the driver component, send monitoring configuration information to the monitoring component connected to each target interface module under test, and send verification configuration information to the verification IP component connected to each occupied serial deserialization channel; The driver component is configured to perform configuration operations based on the driver configuration information; Each monitoring component is configured to, upon receiving monitoring configuration information, perform a configuration operation based on the received monitoring configuration information; Each verification IP component is used to perform configuration operations based on the received verification configuration information when verification configuration information is received, and to establish a communication connection with its corresponding serial deserialization channel.

5. The system according to claim 1, wherein: The scenario description file includes scenario description information of each target interface module under test, and the scenario description information is used to describe occupied interface information of the target interface module under test.

6. The system according to claim 5, characterized in that The chip configuration model is specifically used to parse the scenario description file, generate a configuration sequence of each target interface module under test for the scenario description information of the target interface module under test, and send the configuration sequence to the target interface module under test.

7. The system according to claim 6, characterized in that The configuration sequence includes a register access format for the target interface module under test; Each target interface module under test is specifically used to receive the configuration sequence sent by the chip configuration model, parse the received configuration sequence, and configure its own registers based on the register access format obtained by the parsing, so that the configured target interface module under test matches its own occupied interface information.

8. The system according to any one of claims 1 to 7, characterized in that: The scenario randomizer is specifically used to randomly select chip specification parameters from the chip specification set through a random seed algorithm, and combine the selected chip specification parameters into the interface configuration combination scenario; wherein the chip specification set includes: rate information applicable to the multiple tested interface modules, and the number and identification of serial deserialization channels included in each tested interface module.

9. The system according to any one of claims 1 to 7, characterized in that: The interface module under test is an Ethernet interface module.

10. A chip, characterized in that: The chip includes an interface module verified by the system according to any one of claims 1-9.

Images