High completeness verification method suitable for multi-device multi-channel HINOC system

Abstract

The invention discloses a high completeness verification method suitable for a multi-device multi-channel HINOC system, after an HINOC system in which an HB is in butt joint with a plurality of HMs is established to serve as a transmission system to be tested, a verification platform is constructed by adopting an SV language and a UVM verification methodology, through macro definition, the number of the HMs and the number of RGMII interfaces of devices to be tested can be flexibly modified, and the verification efficiency is improved. The verification platform can adaptively adjust the software environment according to the number of the to-be-tested devices; components such as a driver, a monitor and a checker are integrated, a plurality of tasks are packaged to construct a scene, a scene model can be constructed by using a PSS technology to realize a multi-scene randomization capability, and a regression test script is constructed by using a shell language to complete a convenient scene regression test. The verification problem of complex application of the HINOC system is effectively solved, the verification flexibility is improved, various simulation scenes and models for automatically generating verification scenes are provided, and the verification work is more complete and comprehensive.

Description

Technical Field

[0001] The present invention belongs to the technical field of chip verification, and particularly relates to a high-completeness verification method applicable to a multi-device multi-channel HINOC system. Background Art

[0002] High performance Network Over Coax (HINOC) is a broadband access network technology, a new type of Ethernet over Coax (EoC) technology with independent intellectual property rights designed and developed by the State Administration of Radio, Film and Television. At present, the HINOC technology has passed the stable operation of the first and second generations. In order to meet the requirements of the rapid development of network speed, higher rates and lower delays are needed. Therefore, the verification work for HINOC 3.0 technology is very important. In the network of the HINOC transmission system, a connection method is adopted in which a HINOC bridge (HB) is connected to multiple HINOC modems (HM) below. In actual application, the entire network will include connections between multiple devices and multiple channels, which brings a lot of trouble to the verification work. A single verification environment is difficult to perform high-completeness verification on the entire transmission system. Summary of the Invention

[0003] In order to solve the above problems existing in the prior art, the present invention provides a high-completeness verification method applicable to a multi-device multi-channel HINOC system. The technical problems to be solved by the present invention are realized through the following technical solutions:

[0004] A high-completeness verification method applicable to a multi-device multi-channel HINOC system includes:

[0005] Construct a HINOC system with one HB docking multiple HMs as the transmission system to be tested, and set system parameters; wherein, each HB and HM as the device to be tested is equipped with a set of CPU interfaces; the system parameters are used to indicate the number of HMs, and the number of RGMII interfaces in HB and HM;

[0006] Construct a software environment according to the SV language, the Universal Verification Methodology (UVM), and the system parameters, so as to build a verification platform for the transmission system to be tested. Among them, in the software environment, the docking devices of HB and HM are simulated through agents. The docking devices include drivers and monitors. The driver is used to send the CPU signals and RGMII signals generated in the software environment to the corresponding devices to be tested. The CPU signals are responsible for registers, and the RGMII signals are used to transmit Ethernet data. The monitor is used to send the input and output data of the CPU or RGMII interface to the software environment. The software environment also includes a checker, which is used to obtain the input data and output data of the transmission system to be tested from the monitor and compare them.

[0007] Call test cases in the software environment, send data to the transmission system to be tested by setting the sequence of CPU and Ethernet frames, perform simulation of the corresponding scenario model of the test case, and after the simulation is completed, judge the correctness and integrity of data transmission based on the comparison results of the checker, combined with the print information and signal waveforms, to obtain the completeness verification result.

[0008] In an embodiment of the present invention, the system parameters include DEVICE_NUMBER and PORT_NUMBER. DEVICE_NUMBER is used to indicate the number of HMs, and PORT_NUMBER is used to indicate the number of RGMII interfaces in HB and HM. The system parameters are set according to macro definitions.

[0009] In an embodiment of the present invention, the monitor sends the input and output data of the CPU or RGMII interface to the software environment, including:

[0010] The input and output data of the CPU or RGMII interface are sorted into a predetermined format and printed using a predefined printing function, and the printing result is sent to the software environment.

[0011] In an embodiment of the present invention, the driver sends the CPU signals and RGMII signals generated in the software environment to the corresponding devices to be tested by using data packets. Among them, the sending of CPU signals is achieved by using data packets carrying CPU information, and the sending of RGMII signals is achieved by using data packets carrying Ethernet information. The data packets are randomized as needed, and the contents of each field in the Ethernet frame are generated randomly according to constraints to adapt to the required scenario model.

[0012] In an embodiment of the present invention, the type of the Ethernet frame supported by the data packet carrying Ethernet information is determined by specifying the eth_type field, and the types of the Ethernet frame include ordinary Ethernet frames, Ethernet frames with VLAN information, Ethernet frames with ipv4 information, Ethernet frames with ipv6 information, and Ethernet frames with TCP information.

[0013] In an embodiment of the present invention, the data packet carrying Ethernet information includes an exception attribute, and after the exception attribute is specified, it is used to send a preset error frame.

[0014] In an embodiment of the present invention, during the process that the checker obtains the input data and output data of the transmission system to be tested from the monitor and makes a comparison, by using the built-in address learning model, simulating the address learning function of HB, mapping the data packets sent by different HMs according to the content of their source address fields, and marking the addresses corresponding to different HMs, so as to determine the transmission correspondence relationship between HB and HM.

[0015] In an embodiment of the present invention, the scenario model is constructed using PSS technology, generates the SV code corresponding to the scenario through the Perspec tool, and runs on the verification platform.

[0016] In an embodiment of the present invention, in the software environment, by starting a pre-constructed regression test script, calling all test cases to implement the simulation of all scenario models; wherein, the regression test script is constructed using the Shell language.

[0017] In an embodiment of the present invention, obtaining the completeness verification result is realized by using the predefined functional coverage rate and assertion coverage rate as indicators.

[0018] Advantages of the present invention:

[0019] The present invention provides a verification platform based on UVM technology that can parameterize and configure multiple devices and multiple channels, can flexibly verify the connection and transmission of the HINOC system, effectively solves the verification problem of complex applications of the HINOC system, and significantly improves the flexibility of the HINOC system verification.

[0020] The present invention provides a variety of simulation scenarios and provides a model for automatically generating verification scenarios, making the verification work more complete and the verification scenarios more comprehensive. And it provides convenient reuse conditions for the verification work after the HINOC system is upgraded in the future. Brief Description of the Drawings

[0021] Figure 1Schematic flowchart of a high - completeness verification method for a multi - device multi - channel HINOC system provided by an embodiment of the present invention;

[0022] Figure 2 Schematic structural diagram of a to - be - tested transmission system built according to an embodiment of the present invention;

[0023] Figure 3 Printing result of an ordinary data packet in an embodiment of the present invention;

[0024] Figure 4 Schematic principle diagram of a high - completeness verification method for a multi - device multi - channel HINOC system provided by an embodiment of the present invention;

[0025] Figure 5 An example of data comparison by an inspector in an embodiment of the present invention. Detailed implementation manners

[0026] The following further describes the present invention in detail with reference to specific embodiments, but the implementation manners of the present invention are not limited thereto.

[0027] HINOC technology is a bandwidth access technology that uses the cables of traditional radio and television networks to complete efficient reception and transmission of information. It adopts orthogonal frequency - division multiplexing transmission mode, time - division duplex mode, time - division multiple access mode, and optionally orthogonal frequency - division multiple access mode. At the top of its architecture is a HINOC bridge (HB), which is connected to multiple HINOC modems (HM) below. The HB and HM are directly connected by coaxial cables, and the communication between HMs must be coordinated by the HB uniformly.

[0028] The HINOC system has a two - way communication function. When receiving data, the HB modulates and allocates the gigabit Ethernet data linked above it and then sends it into the HINOC channel, and transmits it to the HM end through the coaxial cable. The HM demodulates the received data and then transmits it to device terminals such as televisions and computers; when sending data, the HM encodes the data input by the terminal, sends it to the HB end through the coaxial cable, then performs corresponding demodulation, and finally uploads it to the Ethernet network.

[0029] In order to achieve the high - completeness verification of a HINOC system with multiple devices and multiple channel connections, an embodiment of the present invention provides a high - completeness verification method for a multi - device multi - channel HINOC system.

[0030] As Figure 1 shown, the method may include the following steps:

[0031] S1. Build a HINOC system with one HB connected to multiple HMs as the to-be-tested transmission system, and set system parameters. Each HB and HM, as the to-be-tested devices, is equipped with a set of CPU interfaces. The system parameters are used to indicate the number of HMs and the number of RGMII interfaces in the HB and HMs.

[0032] Among them, the system parameters include DEVICE_NUMBER and PORT_NUMBER. DEVICE_NUMBER is used to indicate the number of HMs, and PORT_NUMBER is used to indicate the number of RGMII interfaces in the HB and HMs. The system parameters are set according to macro definitions.

[0033] In S1, specific numerical values can be set for the system parameters. However, for different scenarios, that is, verification environments, the system parameters can be modified according to macro definitions, thereby changing the number of to-be-tested devices in the verification environment, etc.

[0034] Specifically, please refer to Figure 2 As shown in the figure, based on the traditional HINOC system, after adding the custom parameters DEVICE_NUMBER and PORT_NUMBER, the embodiment of the present invention builds a transmission system with one HB connected to multiple HMs as the to-be-tested transmission system (named DUT) to implement a multi-device and multi-channel HINOC system. The number of HMs in the system is indicated by the parameter DEVICE_NUM (meaning the number of devices), and the number of RGMII interfaces in each to-be-tested device (i.e., HB and HM) is indicated by PORT_NUM (meaning the number of ports). RGMII (Reduced Gigabit Media Independent Interface) is responsible for transmitting Ethernet data as the boundary input and output. Each HB and HM is equipped with a set of CPU interfaces responsible for receiving and executing the instructions transmitted by the CPU.

[0035] Regarding Figure 2 the internal division and functional composition of the HINOC system in the figure, please refer to the related technologies for understanding and no detailed description will be given here.

[0036] S2. Build a software environment according to the SV language, the universal verification methodology UVM, and the system parameters, thereby building a verification platform for the to-be-tested transmission system.

[0037] Among them, in the software environment, a docking device for simulating the docking of HB and HM is provided. The docking device includes a driver and a monitor. The driver is used to send the CPU signals and RGMII signals generated in the software environment to the corresponding device under test. The CPU signals are responsible for registers, and the RGMII signals are used to transmit Ethernet data. The monitor is used to send the input and output data of the CPU or RGMII interface to the software environment. The software environment also includes an inspector for obtaining and comparing the input data and output data of the transmission system under test from the monitor.

[0038] Specifically, the SV language is the SystemVerilog language, and the Universal Verification Methodology (UVM) is a verification methodology based on SystemVerilog. It uses the features of SystemVerilog to build a standardized verification environment.

[0039] The verification platform of the embodiment of the present invention is jointly composed of the transmission system under test determined by system parameters and the designed software environment.

[0040] The verification platform will adaptively change the software environment in the verification platform according to the number of devices under test, etc., so that the number of agents in the environment corresponds to the number of devices under test and is connected. Specifically, in the verification platform, according to the instantiated DEVICE_NUM and PORT_NUM, the corresponding number of interfaces (Interfaces) in the SV language is used, and the number of interfaces is determined in the form of an array, and the interfaces in the array are passed to the verification environment. The verification environment determines the number of agents according to the values of DEVICE_NUMBER and PORT_NUMBER.

[0041] To facilitate the understanding of the solution of the embodiment of the present invention, as an example, both DEVICE_NUMBER and PORT_NUMBER can be defined as 4, and a transmission system under test with HB connected to 4 HMs is generated, where both HB and HM have 4 channels (the channel is the RGMII interface).

[0042] The embodiment of the present invention will instantiate 1 group of interfaces in the SV language sent to HB and 4 groups of interfaces in the SV language sent to HM (referred to as Interface). Each group of interfaces contains RGMII signals connected to 4 channels. Therefore, a total of 20 groups of RGMII signals are generated, and these signals will be converted into virtual signals (Virtual Interface) and sent to the software environment. Each group of signals is distinguished by the group name. It can be understood that the interfaces in the SV language are used to connect the software environment and the corresponding hardware environment of the transmission system under test.

[0043] The agent is used to simulate the device docking with HM or HB in the software environment. Each agent for the device under test includes a driver and a monitor. In the embodiment of the present invention, the number of HB is fixed at 1, and 1 agent (i.e., Agent) simulating HB and 4 agents simulating HM are instantiated according to the value of DEVICE_NUMBER in the software environment. Each agent receives different SV language interfaces from the upper layer, and then sends data to HB or HM through the driver in the agent. Each agent is divided into 4 drivers and 4 monitors, and the use case simulates 4 channels of each device under test.

[0044] The driver is used to send the CPU signal and RGMII signal generated in the software environment to the corresponding device under test, so as to realize the transmission of data from the software environment to the hardware environment. Among them, the CPU signal is used to configure the register, and the RGMII signal is used to transmit Ethernet data;

[0045] Among them, the driver sends the CPU signal and RGMII signal generated in the software environment to the corresponding device under test by using a data packet; the full name of the data packet is transaction packet. Among them, the sending of the CPU signal is realized by using a data packet carrying CPU information, and the sending of the RGMII signal is realized by using a data packet carrying Ethernet information;

[0046] The data packet is randomized as needed and the content of each field in the Ethernet frame is randomly generated according to the constraints to adapt to the required scenario model.

[0047] Specifically, the user can modify the information in the data packet according to the need. In the process of sending data in the software environment, after creating the data packet, the data in it will be randomized, and the content of each field in the Ethernet frame (such as EMAC frame) will be randomly generated according to the constraints. The basic randomization constraints are defined in the data packet, and new randomization constraints will also be added in different scenarios to generate specific information. The purpose is to generate the required data packet content according to the scenario.

[0048] When sending the Ethernet frame data frame, the information in the data frame can be specified, such as the source address, destination address, length, etc. For example, for the scenario of testing the maximum data packet function, the source address can be specified as 0, the length of the length field is 1500, and the trans_type is BASIC (indicating a normal data packet). Then when sending data, the destination address field not specified in the data packet and a 1500-byte data field will be randomly generated, and finally the value of the CRC field will be calculated.

[0049] In the embodiments of the present invention, the type of Ethernet frame supported by the data packet carrying Ethernet information is determined by specifying the eth_type field. The types of Ethernet frames include ordinary Ethernet frames, Ethernet frames with VLAN information, Ethernet frames with ipv4 information, Ethernet frames with ipv6 information, and Ethernet frames with TCP information.

[0050] That is to say, the data packets sent by the driver in the present invention to the RGMII interface can support the above-mentioned various types of Ethernet frames, thereby improving generality, and can also achieve cross-transmission of data packets in various formats, facilitating the simulation of various possible scenarios in reality, and more comprehensively verifying the functions of the transmission system under test.

[0051] It should be noted that the data packet carrying Ethernet information includes an exception attribute. After the exception attribute is specified, it is used to send a preset error frame. Specifically, specifying the exception attribute can send a preset error frame, such as a crc error (cyclic redundancy check error), an overlong frame, an overshort frame, etc. The present invention can send data packets in various error formats to the transmission system under test to check whether the system under test can correctly identify the data packets and check functions such as the judgment and filtering of errors by the transmission system under test.

[0052] The monitor is used to send the input and output data of the CPU or the RGMII interface to the software environment;

[0053] Specifically, the monitor uses a predefined printing function to organize the input and output data of the CPU or the RGMII interface into a predetermined format and print it, and sends the printing result to the software environment.

[0054] In the above process, the input and output data of the CPU or the RGMII interface are also transmitted in the form of data packets. When the monitor detects the existence of input and output data of the CPU or the RGMII interface, it calls a predefined printing function to organize these data into a predetermined format and print them out and send them to the software environment for easy viewing of information during inspection. Among them, the printing function in the embodiments of the present invention uses a string type in the software environment, retrieves the content of each field in the data packet and organizes it into a specific format, and then prints it out using the UVM_INFO mechanism, as Figure 3 The printing result for a certain ordinary data packet.

[0055] In addition, the monitor of the present invention will report an error for data frames that do not conform to the Ethernet format and discard the data frames monitored this time.

[0056] The software environment also includes an inspector, which is used to obtain the input data and output data of the transmission system to be tested from the monitor and compare them, so as to check the correctness of data transmission;

[0057] Furthermore, during the process that the inspector obtains the input data and output data of the transmission system to be tested from the monitor and compares them, by using the built-in address learning model to simulate the address learning function of HB, the data packets sent by different HMs are mapped according to the content of their source address fields, and the addresses corresponding to different HMs are marked, so as to determine the transmission correspondence relationship between data among HB and HMs.

[0058] In the HINOC system, HB and multiple HMs can communicate through the built-in address learning model. HB uses the address learning model to simulate the address learning function and processes data packets from different HMs. Through the built-in address learning model, the addresses of HMs are automatically identified and recorded to ensure the correct transmission of data packets. The specific process can be as follows:

[0059] Data packet reception: HB receives data packets from multiple HMs.

[0060] Source address extraction: HB extracts the address of the sending HM from the source address field of the data packet.

[0061] Address mapping: HB maps the extracted source address to the corresponding HM and marks the address of each HM.

[0062] Address table update: HB updates the internal address table to record the address information of each HM.

[0063] Data packet processing: When HB receives a data packet with the destination address in the address table again, it sends the data packet to the HM corresponding to the address.

[0064] For example, suppose there are three HMs (HM1, HM2, HM3), which respectively send data packets to HB:

[0065] HM1 sends a data packet with the source address of A.

[0066] HB extracts the address A, maps it to HM1, and updates the address table.

[0067] HM2 sends a data packet with the source address of B.

[0068] HB extracts the address B, maps it to HM2, and updates the address table.

[0069] HM3 sends a data packet with the source address of C.

[0070] HB extracts the address C, maps it to HM3, and updates the address table.

[0071] Finally, the address table of HB will contain the mapping relationships of HM1-A, HM2-B, and HM3-C to ensure the correct routing of data packets.

[0072] Through the address learning model of the present invention, the HM corresponding to the data packet can be determined, and the corresponding relationship between the two can be established, so as to determine a correct set of input data and output data to be compared.

[0073] S3. Call test cases in the software environment, send data to the to-be-tested transmission system by setting the sequence of the CPU and the Ethernet frame, perform simulation of the scenario model corresponding to the test case, and after the simulation is completed, judge the correctness and integrity of the data transmission by combining the comparison results of the checker, the printed information, and the signal waveform to obtain the completeness verification result.

[0074] The construction of the to-be-tested transmission system and its verification platform is completed through S1 and S2, and S3 is the actual operation process.

[0075] In the embodiment of the present invention, scenario models and corresponding test cases test can be pre-constructed for different scenarios (i.e., verification environments), and the scenario models can be constructed manually;

[0076] Alternatively, the scenario model is constructed using PSS (Portable Stimulus Standard) technology, and the SV code corresponding to the scenario is generated through the Perspec tool and run on the verification platform.

[0077] Specifically, the present invention defines a scenario model through PSS technology, randomly generates various transmission scenario codes in cooperation with the scenario random characteristics of PSS, and can run the generated scenarios on the built verification platform for simulation and collect data.

[0078] The present invention uses PSS technology through the Perspec tool, defines components through the DSL language dedicated to PSS, and the components contain various actions and members. Among them, the members are responsible for representing the data in the scenario, such as Ethernet frames, CPU instructions, etc., and the actions are responsible for simulating the behaviors in the scenario, such as sending sequences, configuring registers, etc. In the component, various actions are combined, and the order relationship and transmission direction between the actions are specified through constraints, and the scenario model is constructed in turn.

[0079] In the embodiments of the present invention, a model for multi-channel parallel data transmission is constructed through the PSS technology, which can specify the channels for parallel or serial data transmission, and randomly determine the channel order and the data to be transmitted when generating scenarios, so as to simulate multi-channel data transmission in reality. After the scenario construction is completed, the Perspec tool will generate various random scenarios according to the model and generate code in the SV language to implement the sequence of the scenarios, which can be directly used to run simulations in the above verification platform and view the simulation results.

[0080] See Figure 4 Understand that Figure 4 is a schematic diagram of the principle of the high-completeness verification method for a multi-device multi-channel HINOC system according to the embodiments of the present invention. Among them, Testbench is the verification platform, test is the test case, sequence is the sequence, Virtual sequencer is the virtual sequencer, monitor is the monitor; driver is the driver, Analysis port is the analysis port, Scoreboard is the scoreboard, coverage model is the coverage model, virtual interface- is the virtual interface, and DUT is the transmission system to be tested.

[0081] In the embodiments of the present invention, different scenarios are simulated by calling different tests during software environment simulation. The test is the highest level of the simulation. For the called test, data is sent by calling the sequence in the test, that is, the data packet is implemented in the form of a sequence. Specifically, the sending sequence of the CPU is called, and the desired information is sent by specifying the address and data in the sequence; the sending sequence of the RGMII is called, and the desired information is sent by specifying the length, data, etc. It can be understood by referring to the foregoing that the verification environment includes sequences for sending various Ethernet frame data frames, such as ordinary Ethernet frames, Ethernet frames containing ipv4 information, Ethernet frames containing ipv6 information, etc.

[0082] Moreover, before transmitting data, it is necessary to use CPU signals to perform basic register configuration on HB and HM in the simulation environment to enable the transmission function. In the present invention, the basic configuration is encapsulated into tasks such as preparae_hb and prepare_hm, and the basic register configuration can be directly completed by calling the tasks.

[0083] The simulation environment starts the simulation by specifying different tests. Take the test case test of transmitting basic Ethernet frames as an example: when running the simulation, the test will first complete the instantiation and connection of all components, and then complete the configuration of basic registers by calling the encapsulated tasks prepare_hb and prepare_hm. After the configuration is completed, the sequence of sending basic Ethernet frames is called. When calling, the source address, destination address, length, data and other information can be specified.

[0084] As described in S2, the data packet (sequence) is randomized as needed before it is sent. Specifically, if the parameters of the sequence are specified, it will be sent according to the specified parameters. If no parameters are specified, data will be randomly generated according to the requirements of the Ethernet protocol. When sending a sequence, the channel corresponding to the data is confirmed by specifying the agent and the channel number in the agent. Different agents and different channel numbers are used to send data to verify the data receiving and sending function. Specifically, the agent number corresponding to HB is 0, the agent number corresponding to HM1 is 1, and so on; for example, when sending a sequence, the channel number in the agent number 0 is specified to be 1, indicating that the software environment will send the Ethernet frame data carried in the sequence to channel 1 of HB.

[0085] After the simulation is completed, the correctness of the data transmission is judged by the results printed by the checker, and the correctness of the timing is judged by checking the printed result information and the waveform diagram. Specifically, after the simulation is completed, the checker takes out all the received output data packets in turn, finds the source device and channel of each data packet according to the address learning model, and then compares the various fields of this output data packet with the input data packet. If there are unequal fields, they are recorded and an error is reported. If there are no errors, the check is recorded as successful. For example, Figure 5 The information in indicates that the checker performed 20 data comparisons in total, with 0 errors, indicating that the device transmitted data correctly.

[0086] It should be noted that, in the embodiment of the present invention, the completeness verification result is obtained by using predefined function coverage and assertion coverage as indicators. Specifically, the function coverage and assertion coverage are designed in the software environment of the present invention. By running the coverage model (Coverage model) during the simulation process to collect simulation data, the collected coverage data can be analyzed to reflect the verification of each function. Functions such as the reading and writing of each register of the transmission system to be tested, the reception and transmission of various types of data packets, the timing logic of the channel, etc.

[0087] Functional coverage and assertion coverage are two important indicators in software testing, which are used to evaluate the comprehensiveness and effectiveness of testing.

[0088] Functional coverage measures the degree to which test cases cover software functional requirements, ensuring that all functional points are tested. It focuses on whether the functional requirements are fully verified.

[0089] The calculation method is as follows:

[0090] Assertion coverage measures the degree to which assertions in test cases cover code logic, ensuring that all parts of the code are verified. It focuses on whether the code logic is fully tested.

[0091] The calculation method is as follows:

[0092] Functional coverage is used to ensure that all functional points are tested. Assertion coverage is used to ensure that code logic is fully verified. Using both in combination can more comprehensively evaluate the effectiveness of testing.

[0093] In the embodiments of the present invention, for functional coverage, for example, each field of an Ethernet data packet is defined as a set of functional coverage groups, and the type field therein is defined as a functional coverage point. The coverage point contains the above-mentioned BASIC, IPV4, IPV6, etc. When the type field in the data packet sampled by the sampling function appears as the BASIC field, the BASIC part in the coverage point will be covered, and the same applies to the rest. When all simulations are run to completion, checking the coverage rate can determine whether various types of data packets are used in the simulation.

[0094] For assertion coverage, for example, the preamble field at the start of an Ethernet frame is defined as a set of assertion checks. Whenever the start of an Ethernet frame transmission is detected, the assertion checks will start simultaneously. If the start part of the Ethernet frame conforms to the timing and data specified by the preamble, the check is judged to be correct; otherwise, the check is judged to be incorrect. When all simulations are run to completion, checking the assertion coverage rate can determine whether there is a violation of the timing logic of the check.

[0095] In the embodiments of the present invention, various simulation test scenarios have been implemented using a scenario model and corresponding test cases, and the simulation can be directly run or used as a reference to implement other complex scenarios.

[0096] As can be understood from the above, for a selected scenario, the corresponding verification simulation process can be implemented. Further, the verification simulation processes for all scenarios can be run at once. Specifically, in the software environment, by starting a pre-built regression test script, all test cases are called to implement the simulation of all scenario models; wherein, the regression test script is built using the Shell language.

[0097] The present invention has pre-implemented a regression test script through shell language. After calling the script and inputting a file with the suffix of.f containing all test names (i.e., the test list), the simulation of all tests can be started. After the simulation ends, the script stores all output data in the out folder under the script directory for easy result viewing. For example, inputting the following command will start the simulation of all test cases in the present invention:

[0098] bash himac_regr_run.sh -o. / out -c 1 -f 1 himac_regr_list.f;

[0099] In summary, the present invention uses SystemVerilog language and UVM verification methodology to build a dynamic verification platform. In the platform, by macro-defining the values of DEVICE_NUM and PORT_NUM, the number of instantiated HMs and the number of channels used in the platform are changed, so as to realize an adaptive multi-channel and multi-device verification platform. The present invention can realize various verification scenarios in combination with the characteristics of UVM and SV languages.

[0100] Moreover, the scenario model can be defined through PSS technology. Combining with the scenario randomness characteristics of PSS, various transmission scenario codes can be randomly generated, and the generated scenarios can be run for simulation on the built verification platform and data can be collected. In a specific implementation manner, a model for multi-channel parallel data transmission is constructed through PSS technology. In it, 16 data sending actions of 4 devices and 4 channels are defined. When generating scenarios, the channel order and data to be sent are randomly selected to simulate multi-channel data transmission in reality. Use the Perspec tool to generate the sequence of scenarios, run it in the verification platform and view the simulation results. Through multiple regression tests and different randomizations, the defined functional coverage rate and assertion coverage rate can be collected to 100%.

[0101] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0102] The present invention provides a UVM technology-based verification platform that can be parametrically configured with multiple devices and multiple channels, which can flexibly verify the connection and transmission of the HINOC system, effectively solves the verification problem of complex applications of the HINOC system, and significantly improves the flexibility of HINOC system verification.

[0103] The present invention provides a variety of simulation scenarios and a model for automatically generating verification scenarios, making the verification work more complete and the verification scenarios more comprehensive. And it provides convenient reuse conditions for the verification work after the HINOC system is upgraded in the future.

[0104] It should be noted that in the description of the present invention, the terms "first" and "second" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance or implicitly specifying the quantity of the indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the present invention, "a plurality" means two or more unless otherwise specifically defined.

[0105] In the description of this specification, the description with reference to terms such as "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine the different embodiments or examples described in this specification.

[0106] The above are only the preferred embodiments of the present invention and are not intended to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A high integrity verification method for a multi-device multi-channel HINOC system, characterized in that: include: A HINOC system in which a HB is connected to multiple HMs is built as a transmission system to be tested, and system parameters are set; wherein each HB and HM as a device to be tested has a set of CPU interfaces; the system parameters are used to indicate the number of HMs and the number of RGMII interfaces in the HB and HM; According to the SV language, the universal verification methodology UVM and the system parameters, a software environment is constructed to build a verification platform for the transmission system to be tested; wherein, in the software environment, a docking device of HB and HM is simulated by an agent, and the docking device includes a driver and a monitor; the driver is used to send the CPU signal and RGMII signal generated in the software environment to the corresponding device to be tested, the CPU signal is used to be responsible for the register, and the RGMII signal is used to transmit Ethernet data; the monitor is used to send the input and output data of the CPU or RGMII interface to the software environment; the software environment also includes a checker, which is used to obtain the input data and output data of the transmission system to be tested from the monitor and compare them; The test case is called in the software environment, and data is sent to the transmission system to be tested by setting the sequence of CPU and Ethernet frames. The scenario model corresponding to the test case is simulated. After the simulation is completed, the correctness and integrity of the data transmission are judged through the comparison results of the checker combined with the printed information and signal waveform to obtain the completeness verification result.

2. The high integrity verification method applicable to a multi-device multi-channel HINOC system according to claim 1, characterized in that: The system parameters include DEVICE_NUMBER and PORT_NUMBER, DEVICE_NUMBER is used to indicate the number of HMs, PORT_NUMBER is used to indicate the number of RGMII interfaces in HBs and HMs, and the system parameters are set according to macro definitions.

3. The high integrity verification method applicable to a multi-device multi-channel HINOC system according to claim 1, characterized in that: The monitor sends the input and output data of the CPU or RGMII interface to the software environment, including: The input and output data of the CPU or RGMII interface are sorted into a predetermined format and printed using a predefined printing function, and the printed result is sent to the software environment.

4. The high integrity verification method applicable to a multi-device multi-channel HINOC system according to claim 1, characterized in that: The driver sends the CPU signal and RGMII signal generated in the software environment to the corresponding device under test using data packets; wherein the sending of the CPU signal is implemented using data packets carrying CPU information, and the sending of the RGMII signal is implemented using data packets carrying Ethernet information; the data packets are randomized as needed, and the contents of each field in the Ethernet frame are randomly generated according to constraints to adapt to the required scenario model.

5. The high integrity verification method applicable to a multi-device multi-channel HINOC system according to claim 4, characterized in that: The type of Ethernet frame supported by the data packet carrying Ethernet information is determined by specifying the eth_type field, and the types of Ethernet frames include ordinary Ethernet frames, Ethernet frames with VLAN information, Ethernet frames with ipv4 information, Ethernet frames with ipv6 information, and Ethernet frames with TCP information.

6. The high integrity verification method applicable to a multi-device multi-channel HINOC system according to claim 4, characterized in that: The data packet carrying Ethernet information includes an exception attribute, and the exception attribute is used to send a preset error frame after being specified.

7. The high integrity verification method applicable to a multi-device multi-channel HINOC system according to claim 1, characterized in that: In the process of obtaining the input data and output data of the transmission system to be tested from the monitor and comparing them, the checker uses the built-in address learning model to simulate the address learning function of HB, maps the data packets sent by different HMs according to the contents of their source address fields, marks the addresses corresponding to different HMs, and thus determines the transmission correspondence between the data and the HB.

8. The high integrity verification method applicable to a multi-device multi-channel HINOC system according to claim 1, characterized in that: The scenario model is constructed using the PSS technology, and the SV code corresponding to the scenario is generated by the Perspec tool and run on the verification platform.

9. The high integrity verification method applicable to a multi-device multi-channel HINOC system according to claim 1, characterized in that: In the software environment, all test cases are called to realize the simulation of all scenario models by starting a pre-built regression test script; wherein the regression test script is built using Shell language.

10. The high integrity verification method applicable to a multi-device multi-channel HINOC system according to claim 1, characterized in that: The completeness verification results are obtained by using pre-defined functional coverage and assertion coverage as indicators.

Images