UTMI-based short-process software and hardware collaborative verification system

Abstract

The invention discloses a short-process software and hardware collaborative verification system based on UTMI, and relates to the field of software and hardware collaborative simulation. The BFM receives the test data, splits and extracts BFM transaction data, the data exchange state machine receives the BFM transaction data, analyzes and configures the BFM transaction data, and performs data interaction between the analyzed and configured UTMI data and the device to be tested through the serial port engine; and the speed negotiation module outputs a UTMI protocol signal for simulating a PHY layer behavior by being butted with the UTMI interface, generates a speed negotiation signal and feeds back the speed negotiation signal to the data exchange state machine, so that the data exchange state machine switches a driving working mode of the serial port engine. According to the scheme, the logic of the PHY part is removed, one link in the verification structure is reduced, the UTMI interface is directly butted with the DUT, the design complexity is reduced, the verification process is shortened, and the verification speed is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of software-hardware co-simulation, and in particular to a UTMI-based short-process software-hardware co-verification system. Background Art

[0002] With the continuous development of integrated circuit manufacturing technology, the development of system chips has become more mature, but the development of system chips has encountered many challenges, such as system chip verification. Verification has often become a bottleneck in chip design, and its workload accounts for about 70% of the entire chip design, and its proportion will continue to rise with the increase in the scale and complexity of integrated circuit design. Therefore, in chip design, it is necessary to reduce the complexity of verification as much as possible. How to quickly verify these IP modules and the entire system has become a difficulty and hot spot in system chip verification.

[0003] UTMI is a common communication protocol in system-level verification. Its full name is USB 2.0 TransceiverMacrocell Interface. This protocol is defined based on the signal characteristics of USB2.0. Its purpose is to reduce development workload, shorten product design cycle and reduce risks. This interface module mainly processes the USB protocol and signals at the physical bottom layer. It can be integrated with SIE to design a dedicated ASIC chip, or it can be used independently as a transceiver chip of PHY. This protocol realizes the direct transmission of data between USB devices. The verification environment of UTMI in related technologies is analyzed from a structural perspective. In the verification work of UTMI of system-level SOC, in addition to the complex logic of the transaction level, the implementation of PHY involves high-speed signal processing and encoding and decoding technologies, which require a long time for coding and debugging. In addition, because the data passes through redundant multi-layer logic, the clock overhead of a transaction verification is large, the process is too long, and in the case of software simulation verification, it is impossible to effectively avoid the post-simulation problem that some logic only appears on the chip. Summary of the invention

[0004] The embodiment of the present application provides a short-process software and hardware collaborative verification system based on UTMI to solve the problems of large clock overhead and long process in the verification of related technical affairs.

[0005] The short-process hardware-software co-verification system based on UTMI embeds the bus function model BFM, data exchange state machine, serial port engine, and speed negotiation module in the HOST module; The BFM receives test data, splits and extracts BFM transaction data, and the output of the BFM is connected to the data exchange state machine; the data exchange state machine receives the BFM transaction data and parses and configures it, and sends the parsed and configured UTMI data to the serial port engine; The device under test receives UTMI input data and feeds back UTMI output data through the serial port engine, and performs data interaction with the data exchange state machine; The speed negotiation module is connected to the device under test by docking with the UTMI interface, generates a speed negotiation signal according to the UTMI protocol signal simulating the PHY layer behavior output by the device under test, and feeds it back to the data exchange state machine. The data exchange state machine switches the driving working mode of the serial port engine according to the negotiation signal.

[0006] Specifically, when the data exchange state machine receives the BFM transaction data and performs parsing and configuration, it monitors the speed negotiation signal output by the speed negotiation module, performs initial speed negotiation according to the signal level value, and exchanges data with the device under test through the serial port engine.

[0007] Specifically, the data exchange state machine includes a parsing module, an enumeration module, an output module and an input module; the enumeration module, the output module and the input module are respectively used to drive the data exchange state machine to enter the enumeration state, the sending state, and the receiving state; the parsing module is used to parse the transaction token, send corresponding state switching instructions to the enumeration module, the output module and the input module, and control the state of the data exchange state machine; The data exchange state machine switches three states based on the BFM transaction data to complete the data exchange process.

[0008] Specifically, when the data exchange state machine executes a normal data interaction transaction, it switches to the sending state by outputting a transaction command after parsing the transaction token state, and outputs UTMI data to the device under test through the serial port engine; when the device under test feeds back input UTMI data, the data exchange state machine switches to the data receiving state by inputting a transaction command, and forwards the data to the BFM.

[0009] Specifically, when the data exchange state machine performs the enumeration output task, it enters the enumeration state through the enumeration instruction after parsing the transaction token state, and then switches to the sending state through the output transaction command, and outputs the UTMI data containing the enumeration transaction to the device under test; When the device under test determines the enumeration transaction and is ready to receive configuration data, the data exchange state machine reads the local initialization configuration data based on the enumeration instruction and generates enumeration data; then the data exchange state machine switches to the sending state and outputs the enumeration data to the device under test according to the timing requirements.

[0010] Specifically, when the data exchange state machine executes the enumeration input task, it enters the enumeration state through the enumeration instruction after parsing the transaction token state, and then switches to the sending state through the output transaction command; When the device under test obtains and samples and determines the required enumeration transaction and prepares the UTMI data packet for feedback, the data exchange state machine switches to the data receiving state based on the input transaction command, receives the UTMI data packet and extracts the enumeration data, and performs logical judgment on the enumeration data contained in the enumeration state.

[0011] Specifically, the speed negotiation module is connected to the device under test and the analysis module respectively; the operation priority of the device under test is higher than that of the HOST module. When the speed negotiation module receives the UTMI protocol signal output by the device under test, it feeds back the mode signal after speed negotiation and sends a negotiation signal to the analysis module.

[0012] Specifically, the driving working mode of the serial port engine includes a full-speed working mode and a high-speed working mode, and the speed of the high-speed working mode is eight times that of the full-speed working mode; When the parsing module detects that the negotiation signal has a high level value, the control data exchange state machine switches to the high-speed working mode. When the parsing module detects that the negotiation signal has a low level value, the control data exchange state machine switches to the full-speed working mode.

[0013] Specifically, when the project is running, after a clock reset signal is given in timing, speed negotiation is first performed to determine the working mode of the serial port engine; after completing the speed negotiation, test data and test transactions are sent through the test end.

[0014] Specifically, the file output by the data exchange state machine to the BFM includes payload handshake transceiver logic, which decomposes the payload into transaction-level signals, and transaction-level transceiver logic for connecting to the serial data transceiver.

[0015] The beneficial effects brought by the technical solution provided by the embodiment of the present application include at least: 1. Remove some PHY logic, reduce a link in the verification structure, and directly connect DUT through UTMI interface, which reduces design complexity, shortens the verification process and improves verification speed.

[0016] 2. Changing the verification method from software simulation to collaborative simulation, placing DUT and BFM on hardware test and running, and changing from serial operation on PC test to parallel operation on the hardware side, greatly improves the processing speed of DUT. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 It is a schematic diagram of the structure of the verification environment of UTMI in the related art; Figure 2 It is a structural diagram of a UTMI-based short-process software and hardware collaborative verification system provided in an embodiment of the present application; Figure 3This is a detailed schematic diagram of the short-process hardware and software collaborative verification system based on UTMI; Figure 4 It is a schematic diagram of the situation where the system structure of the present application is applied with external signals; Figure 5 A structural block diagram of a computer device provided by an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION

[0018] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0019] The term "multiple" as used herein refers to two or more than two. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the related objects are in an "or" relationship.

[0020] Figure 1 This is a schematic diagram of the structure of the UTMI verification environment in related technologies. From the perspective of structural layout, it includes the following parts: (1) The host-side TB test terminal includes a transaction generator that sends simulated test data in the form of data packets to the host-side BFM (bus functional model).

[0021] (2) The BFM on the HOST side parses the data sent by the TB, splits it into commands and data, and sends it to the serial data transceiver.

[0022] (3) Serial data transceiver, which receives BFM commands and data, interprets them into transaction-level behaviors, and calls various logics to send the received and transmitted data to the corresponding PHY converter.

[0023] (4) PHY converter, converts the data allocated by the serial data transceiver into UTMI protocol signals and gives them to (5) HOSTPHY model.

[0024] (5) HOST PHY model converts UTMI transactions into high-speed serial data and adds NRZI encoding, which is also an important reason for the complexity of the overall verification environment.

[0025] (6) DEVICE PHY model, converts serial data into parallel data, decodes and analyzes it into UTMI transactions and sends it to the DUT part.

[0026] In the verification of UTMI of system-level SOC, in addition to the complex logic of the transaction level, the implementation of PHY involves technologies such as high-speed signal processing and encoding and decoding, which requires a long time for coding and debugging. Specifically, the UTMI signal is converted into a serial signal through PHY, and then transmitted to other devices through media such as external data lines. Therefore, the implementation part includes TB responsible for sending test data, HOST BFM responsible for analyzing test data and converting it into UTMI protocol timing, and PHY model responsible for converting UTMI protocol test timing into PHY high-speed signal. In addition, because the data passes through redundant multi-layer logic, the clock overhead of a transaction verification is large, the process is too long, and in the case of software simulation verification, it is impossible to effectively avoid the post-simulation problem that some logic only appears on the chip.

[0027] In response to the above problems, this application proposes a short process solution for the UTMI protocol, which directly feeds back transaction-level information by analyzing the UTMI protocol signal of the DUT, eliminates the complex signal conversion of the PHY part, and the data part directly interacts through the reverse signal of the UTMI handshake signal, and the DUT and verification logic are placed in the hardware.

[0028] Figure 2 It is a structural diagram of a short-process software and hardware collaborative verification system based on UTMI provided in an embodiment of the present application. The system embeds a bus function model BFM, a data exchange state machine, a serial port engine, and a speed negotiation module in the HOST module. Figure 2 In the specific structure, the BFM at the HOST end receives the test data sent by the TB end, splits and extracts the BFM transaction data, the output of the BFM is connected to the data exchange state machine, the BFM transaction data is received through the data exchange state machine and parsed and configured, and the parsed and configured UTMI data is sent to the serial port engine.

[0029] The device under test (DUT) receives UTMI input data and feeds back UTMI output data through the serial port engine, and exchanges data with the data exchange state machine. The speed negotiation module connects to the device under test through the docking UTMI interface, generates a speed negotiation signal based on the UTMI protocol signal of the simulated PHY layer behavior output by the device under test, and feeds it back to the data exchange state machine. The data exchange state machine switches the driving working mode of the serial port engine according to the negotiation signal. When the data exchange state machine receives the BFM transaction data and performs parsing and configuration, it monitors the speed negotiation signal output by the speed negotiation module, performs initial speed negotiation based on the signal level value, and exchanges data with the device under test through the serial port engine.

[0030] Considering some scenarios, such as the UTMI interface verification of SOC, the overall verification structure is on-chip and there is no external transmission process, so the logic of the PHY part is redundant in the verification of the protocol. Therefore, when verifying the design, the verification structure is changed to directly output the UTMI protocol signal to the DUT, skipping the process of converting to the PHY signal and converting the PHY signal back to the UTMI signal. This can shorten the verification process, reduce feedback time, and reduce design complexity.

[0031] like Figure 3 As shown, in some embodiments, the data exchange state machine includes a parsing module, an enumeration module, an output module and an input module. The enumeration module, the output module and the input module are respectively used to drive the data exchange state machine to enter the enumeration state SETUP, the sending state OUT, and the receiving state IN. The parsing module is used to parse the input transaction token and send corresponding state switching instructions to the enumeration module, the output module and the input module to control the state of the data exchange state machine. In other words, the data exchange state machine switches three states based on the BFM transaction data to complete the data exchange process.

[0032] The following is a detailed description of the three different states and the test transactions executed: When the data exchange state machine executes a normal data exchange transaction, it switches to the sending state by outputting a transaction command after parsing the transaction token state, and outputs UTMI data to the device under test through the serial port engine. When the device under test feeds back input UTMI data, the data exchange state machine switches to the data receiving state by inputting a transaction command, and forwards the data to the BFM.

[0033] Exemplary correspondence Figure 3 In a basic IN transaction, the serial port engine sends an IN transaction command through ⑥, reads the data in the DUT through ⑧, and the data is directly returned to the BFM through the "a" channel and uploaded to the TB side. In a basic OUT transaction, the serial port engine sends an OUT transaction command through the ⑦ channel, and sends the data sent by the BFM in the "b" channel to the DUT through the ⑨ port.

[0034] The IN / OUT / SETUP phase corresponds to the receive / send / enumeration transactions. The first of these three transactions to be completed is the enumeration transaction, which is completed by multiple IN / OUTs. The content includes reading the internal description data of the DUT and configuring the internal DUT.

[0035] When the data exchange state machine performs the enumeration output task, it enters the enumeration state through the enumeration instruction after parsing the transaction token state, and then switches to the sending state through the output transaction command to output the UTMI data containing the enumeration transaction to the device under test. When the device under test determines the enumeration transaction and is ready to receive configuration data, the data exchange state machine reads the local initialization configuration data based on the enumeration instruction and generates enumeration data. Then the data exchange state machine switches to the sending state and outputs the enumeration data to the device under test according to the timing requirements.

[0036] See also Figure 3 For example, in the OUT transaction based on setup, it starts with step ① and enters the enumeration state. The next bus behavior is ⑦, output command, and output from port ⑨. After that, when the DUT samples the command, it knows that this behavior is an OUT transaction in the enumeration, and the DUT is ready to receive the configuration information. The enumeration module first reads the local configuration information (that is, initializes the mem file) through ② and outputs it through ③, and then sends it to the DUT through port ⑨. After receiving it, the DUT configures it locally. After reading the configuration several times above, the enumeration is completed. After the enumeration is completed, reading and writing can be performed, and the transaction becomes an IN / OUT transaction.

[0037] When the data exchange state machine performs the enumeration input task, it enters the enumeration state through the enumeration instruction after parsing the transaction token state, and then switches to the sending state through the output transaction command. When the device under test obtains and samples and determines the required enumeration transaction and prepares the feedback UTMI data packet, the data exchange state machine switches to the data receiving state based on the input transaction command, receives the UTMI data packet and extracts the enumeration data, and performs logical judgment on the enumeration data contained in the enumeration state.

[0038] See also Figure 3 In the IN transaction based on setup, the enumeration state is entered from step ①, and the next bus behavior is ⑦, outputting the command, which is output from port ⑨. After that, after the DUT samples the command, it knows that this behavior is an IN transaction in the enumeration, prepares the data specified by this data packet, and performs ⑥ to receive the data in the DUT. The DUT data is output by ⑧, and returns to the enumeration state by ④, and is configured locally by the judgment logic in the enumeration state through ⑤.

[0039] The speed negotiation module is connected to the device under test and the analysis module respectively; the operation priority of the device under test is higher than that of the HOST module. When the speed negotiation module receives the UTMI protocol signal (UTMI_linestate) output by the device under test, it feeds back the mode signal (UTMI_op_mode) after speed negotiation, and sends the negotiation signal (hs_mode) to the analysis module. Of course, this process includes the speed negotiation process, because the driver working mode of the serial port engine includes full-speed (fs) working mode and high-speed (hs) working mode, and the speed of the high-speed working mode is eight times that of the full-speed working mode. Therefore, during the negotiation process, DUT_init will send UTMI_xcverselect and UTMItermselect selection signals to the DUT for negotiation and confirmation between the two parties.

[0040] When the parsing module detects that the negotiation signal has a high level value, the control data exchange state machine switches to the high-speed working mode. When the parsing module detects that the negotiation signal has a low level value, the control data exchange state machine switches to the full-speed working mode.

[0041] Figure 4 A schematic diagram of the application of external signals to the system structure of the present application is listed. The system as a whole is located in the UTMI logic module. On the left side of the module is a typical UTMI signal interface driver, which can directly connect to the UTMI interface and link the DUT device. On the right side is the payload handshake interface of the TB test device that connects to the test data.

[0042] Based on the above system, the present application also provides a short-process software and hardware collaborative verification method based on UTMI, including the following steps: (1) Use Verilog language to develop a serial port engine SIE based on UTMI, which includes the docking signal of UTMI signal for docking DUT; the transaction-level interface docking with BFM for docking TB test transactions. The speed negotiation module includes signals for driving the negotiation mode and receiving signals for simulating PHY-level behavior. The BFM file includes the payload handshake transceiver logic, which decomposes the payload into transaction-level signals, such as the state machine logic of PID, DATA, and CRC, and the transaction-level transceiver logic docking with SIE.

[0043] (2) Instantiate sie, DUT_init and BFM files under the top-level HOST of rtl, and generate and combine the test cmd, data and other data required in the verification environment into a payload, and connect it to the HOST interface, such as Figure 3 .

[0044] (3) When the project is running, after the clock reset and other system signals are given, DUT_init takes precedence over all modules and completes the speed negotiation of DUT, which determines that SIE runs in high-speed or full-speed mode.

[0045] (4) After completing the speed negotiation, TB can start sending test data. The first thing to be completed is the enumeration transaction. In several IN / OUT-based data exchanges, the configuration of the DUT and the reading of the DUT-specific description information are completed.

[0046] (5) After the enumeration is completed, TB can send transactions and various protocol behaviors involved in various transactions, including IN / OUT transactions and transmission methods of various lengths. This design covers various behaviors based on the UTMI protocol.

[0047] In summary, the beneficial effects brought about by this application include the following: 1. Remove some PHY logic, reduce a link in the verification structure, and directly connect DUT through UTMI interface, which reduces design complexity, shortens the verification process and improves verification speed.

[0048] 2. Changing the verification method from software simulation to collaborative simulation, placing DUT and BFM on hardware test and running, and changing from serial operation on PC test to parallel operation on the hardware side, greatly improves the processing speed of DUT.

[0049] The UTMI-based short-process software and hardware collaborative verification device provided in the embodiment of the present application can be applied to the UTMI-based short-process software and hardware collaborative verification method provided in the above embodiment. For relevant details, refer to the above method embodiment. The implementation principle and technical effect are similar and will not be repeated here.

[0050] It should be noted that the UTMI-based short-process software and hardware collaborative verification device provided in the embodiment of the present application is only illustrated by the division of the above-mentioned functional modules / functional units. In actual applications, the above-mentioned functions can be assigned to different functional modules / functional units as needed, that is, the internal structure of the UTMI-based short-process software and hardware collaborative verification device is divided into different functional modules / functional units to complete all or part of the functions described above. In addition, the implementation method of the UTMI-based short-process software and hardware collaborative verification method provided in the above method embodiment and the implementation method of the UTMI-based short-process software and hardware collaborative verification device provided in this embodiment belong to the same concept. The specific implementation process of the UTMI-based short-process software and hardware collaborative verification device provided in this embodiment is detailed in the above method embodiment, which will not be repeated here.

[0051] Figure 5The block diagram of the structure of a computer device provided by an exemplary embodiment of the present application is shown. It is a computer device such as a desktop computer, a laptop computer, a PDA, and a cloud server. The computer device may include, but is not limited to, a processor and a memory. The processor and the memory may be connected via a bus or other means. The processor may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, graphics processors (GPU), embedded neural network processors (NPU) or other dedicated deep learning coprocessors, discrete gates or transistor logic devices, discrete hardware components and other chips, or a combination of the above-mentioned chips.

[0052] The processor may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0053] As a non-transient computer-readable storage medium, the memory can be used to store non-transient software programs, non-transient computer executable programs and modules, such as program instructions / modules corresponding to the methods in the above-mentioned embodiments of the present application. The processor executes various functional applications and data processing of the processor by running the non-transient software programs, instructions and modules stored in the memory, that is, the method in the above-mentioned method implementation is realized. The memory may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created by the processor, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely arranged relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network and a combination thereof.

[0054] In some embodiments, the computer device may further optionally include: a peripheral device interface and at least one peripheral device. The processor, the memory and the peripheral device interface may be connected via a bus or a signal line. Each peripheral device may be connected to the peripheral device interface via a bus, a signal line or a circuit board. Specifically, the peripheral device includes: at least one of a radio frequency circuit, a display screen and a keyboard.

[0055] The peripheral device interface can be used to connect at least one peripheral device related to I / O (Input / Output) to the processor and the memory. In some embodiments, the processor, the memory, and the peripheral device interface are integrated on the same chip or circuit board; in some other embodiments, any one or two of the processor, the memory, and the peripheral device interface can be implemented on a separate chip or circuit board, which is not limited in this embodiment.

[0056] The display screen is used to display the UI (User Interface). The UI may include graphics, text, icons, videos, and any combination thereof. When the display screen is a touch screen, the display screen also has the ability to collect touch signals on the surface or above the surface of the display screen. The touch signal can be input to the processor as a control signal for processing. At this time, the display screen can also be used to provide virtual buttons and / or virtual keyboards, also known as soft buttons and / or soft keyboards. In some embodiments, the display screen can be one, which is set on the front panel of the computer device; in other embodiments, the display screen can be at least two, which are respectively set on different surfaces of the computer device or are folded; in other embodiments, the display screen can be a flexible display screen, which is set on the curved surface or folded surface of the computer device. Even the display screen can be set into a non-rectangular irregular shape, that is, a special-shaped screen. The display screen can be made of materials such as LCD (Liquid Crystal Display), OLED (Organic Light-Emitting Diode), etc.

[0057] The power supply is used to power various components in the computer device. The power supply can be AC, DC, a disposable battery, or a rechargeable battery. When the power supply includes a rechargeable battery, the rechargeable battery can be a wired rechargeable battery or a wireless rechargeable battery. A wired rechargeable battery is a battery that is charged through a wired line, and a wireless rechargeable battery is a battery that is charged through a wireless coil. The rechargeable battery can also be used to support fast charging technology.

[0058] Those skilled in the art will appreciate that the structure shown in this embodiment does not constitute a limitation on the computer device, and may include more or fewer components than shown in the figure, or combine certain components, or adopt a different component arrangement.

[0059] The embodiment of the present application also discloses a computer-readable storage medium. Specifically, the computer-readable storage medium is used to store a computer program, and when the computer program is executed by the processor, the method in the above-mentioned method implementation is implemented. Those skilled in the art can understand that the implementation of all or part of the process in the above-mentioned implementation method of the present application can be completed by instructing the relevant hardware through a computer program, and the program can be stored in a computer-readable storage medium, and when the program is executed, it can include the process of the implementation of the above-mentioned methods. Among them, the storage medium can be a disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), a flash memory (Flash Memory), a hard disk (Hard Disk Drive, abbreviated: HDD) or a solid-state drive (SSD), etc.; the storage medium can also include a combination of the above-mentioned types of memory.

[0060] This specific embodiment is merely an explanation of the present invention and is not a limitation of the present invention. After reading this specification, those skilled in the art may make non-creative modifications to the present embodiment as needed. However, as long as they are within the scope of the claims of the present invention, they are protected by the patent law.

Claims

1. A short-process software and hardware collaborative verification system based on UTMI, characterized in that: The system embeds a bus function model BFM, a data exchange state machine, a serial port engine, and a speed negotiation module in the HOST module; The BFM receives the test data, splits and extracts the BFM transaction data, and the output of the BFM is connected to the data exchange state machine; The data exchange state machine receives the BFM transaction data and performs parsing and configuration, and sends the parsed and configured UTMI data to the serial port engine; The device under test receives UTMI input data and feeds back UTMI output data through the serial port engine, and performs data interaction with the data exchange state machine; The speed negotiation module is connected to the device under test by docking with the UTMI interface, generates a speed negotiation signal according to the UTMI protocol signal simulating the PHY layer behavior output by the device under test, and feeds it back to the data exchange state machine. The data exchange state machine switches the driving working mode of the serial port engine according to the negotiation signal.

2. The UTMI-based short-process software and hardware collaborative verification system according to claim 1, characterized in that: When the data exchange state machine receives the BFM transaction data and performs parsing and configuration, it monitors the speed negotiation signal output by the speed negotiation module, performs initial speed negotiation according to the signal level value, and exchanges data with the device under test through the serial port engine.

3. The UTMI-based short-process software and hardware collaborative verification system according to claim 2, characterized in that: The data exchange state machine comprises a parsing module, an enumeration module, an output module and an input module; the enumeration module, the output module and the input module are respectively used to drive the data exchange state machine to enter the enumeration state, the sending state and the receiving state; the parsing module is used to parse the transaction token, send corresponding state switching instructions to the enumeration module, the output module and the input module, and control the state of the data exchange state machine; The data exchange state machine switches three states based on the BFM transaction data to complete the data exchange process.

4. The UTMI-based short-process software and hardware collaborative verification system according to claim 3, characterized in that: When the data exchange state machine executes a normal data interaction transaction, it switches to the sending state by outputting a transaction command after parsing the transaction token state, and outputs UTMI data to the device under test through the serial port engine; when the device under test feeds back input UTMI data, the data exchange state machine switches to the data receiving state by inputting a transaction command, and forwards the data to the BFM.

5. The UTMI-based short-process software and hardware collaborative verification system according to claim 3, characterized in that: When the data exchange state machine performs the enumeration output task, it enters the enumeration state through the enumeration instruction after parsing the transaction token state, and then switches to the sending state through the output transaction command to output the UTMI data containing the enumeration transaction to the device under test; When the device under test determines the enumeration transaction and is ready to receive configuration data, the data exchange state machine reads the local initialization configuration data based on the enumeration instruction and generates enumeration data; Then the data exchange state machine switches to the sending state and outputs the enumeration data to the device under test according to the timing requirements.

6. The UTMI-based short-process software and hardware collaborative verification system according to claim 5, characterized in that: When the data exchange state machine performs the enumeration input task, it enters the enumeration state through the enumeration instruction after parsing the transaction token state, and then switches to the sending state through the output transaction command; When the device under test obtains and samples and determines the required enumeration transaction and prepares the UTMI data packet for feedback, the data exchange state machine switches to the data receiving state based on the input transaction command, receives the UTMI data packet and extracts the enumeration data, and performs logical judgment on the enumeration data contained in the enumeration state.

7. The UTMI-based short-process software and hardware collaborative verification system according to claim 3, characterized in that: The speed negotiation module is connected to the device under test and the analysis module respectively; the operation priority of the device under test is higher than that of the HOST module. When the speed negotiation module receives the UTMI protocol signal output by the device under test, it feeds back a mode signal after speed negotiation and sends a negotiation signal to the analysis module.

8. The UTMI-based short-process software and hardware collaborative verification system according to claim 7, characterized in that: The driving working mode of the serial port engine includes a full-speed working mode and a high-speed working mode, and the speed of the high-speed working mode is eight times that of the full-speed working mode; When the parsing module detects that the negotiation signal has a high level value, the control data exchange state machine switches to the high-speed working mode. When the parsing module detects that the negotiation signal has a low level value, the control data exchange state machine switches to the full-speed working mode.

9. The UTMI-based short-process software and hardware collaborative verification system according to any one of claims 1 to 8, characterized in that: When the project is running, after the clock reset signal is given in the timing, the speed negotiation is first performed to determine the working mode of the serial port engine; after the speed negotiation is completed, the test data and test transactions are sent through the test end.

10. The UTMI-based short-process software and hardware collaborative verification system according to claim 9, characterized in that: The file output by the data exchange state machine to the BFM includes payload handshake transceiver logic, which decomposes the payload into transaction-level signals, and transaction-level transceiver logic for interfacing with the serial data transceiver.

Images