Implementation Method of Automated Verification Platform Based on SRIO GEN4 Protocol
By using an automated verification platform based on the SRIO GEN4 protocol, the problem of limited applicability in existing technologies has been solved, and rapid functional convergence and protocol consistency checks have been achieved, thereby improving verification efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- WELL CORE MICROELECTRONICS TECH (TIANJIN) CO LTD
- Filing Date
- 2022-12-30
- Publication Date
- 2026-07-24
AI Technical Summary
Existing automated verification platforms have limited applicability, unclear product requirements, and cannot meet the needs of rapid iteration and functional convergence.
This automated verification platform, based on the SRIO GEN4 protocol, generates matching verification environments according to customer needs, supports Switch, Bridge, and Endpoint modes, automatically configures the verification environment, and uses the UVM verification methodology to create i/o agents and reference models for protocol consistency checks.
It achieves rapid function convergence, reduces user maintenance time and costs, and ensures protocol consistency and verification efficiency.
Smart Images

Figure CN116185841B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of software development, and in particular relates to an implementation method of an automated verification platform based on the SRIO GEN4 protocol. Background Technology
[0002] In existing technologies, the scope of application of automated verification platforms is limited, product requirements are unclear, and they cannot meet the needs of rapid product iteration and functional convergence. Summary of the Invention
[0003] In view of this, the present invention aims to propose an automated verification platform implementation method based on the SRIO GEN4 protocol, which can generate an SRIO device verification environment based on the UVM methodology based on software scripts according to customer needs, including standard protocol verification stimuli, register model, reference model and scoreboard.
[0004] To achieve the above objectives, the technical solution of the present invention is implemented as follows:
[0005] An automated verification platform implementation method based on the SRIO GEN4 protocol generates a matching verification environment based on the characteristic parameters of the customer's verification object script.
[0006] If the DUT function is in Switch mode, complete the routing configuration according to the design requirements and complete the function convergence.
[0007] If configured in Bridge mode, the incentive expectation for completing the conversion protocol will be fulfilled according to design requirements;
[0008] If configured in Endpoint mode, the environment will be generated automatically.
[0009] Furthermore, the parameters required by the user's design object are obtained, the path attribute parameters are configured, and the parameters are filled into the script parameter positions. At the same time, the customer provides the register table of the design chip for the specific implementation of the design object. This table is used by the automation platform to create RAL components and to complete the register function and attribute verification according to the table content.
[0010] Users create srio i / o_agents that match the design requirements and quantity based on the verification device attributes and port quantity requirements, using the UVM verification methodology.
[0011] Based on the device attributes required for user authentication, the script creates a reference model based on the Switch / endpoint / bridge model;
[0012] For doorbell / message / datastream messages without a protocol address, data and descriptors are bound together through queues and data descriptors, allowing users to obtain data from the data source by describing the content.
[0013] Import the register list using Python so that verification personnel can verify the register attributes and functions.
[0014] Furthermore, when configured in SW mode, a customized routing reference model is required based on customer needs to send incentive packets to the expected routing queue, while providing protocol-defined routing lookup rules for flat lookup and hierarchical lookup.
[0015] Furthermore, if configured as an Endpoint or bridge model, the RM will record the storage message address. If there is no address field, the protocol message will be stored using a virtual pointer defined by a special field. The storage location is a dynamically associative array, and the user can customize the mapping mechanism according to the application requirements.
[0016] Furthermore, during the Doorbell verification model implementation process, the Doorbell header information is encapsulated and placed into the Doorbell queue. Users can obtain source data by reading the data information in this queue and perform protocol consistency checks.
[0017] Furthermore, this solution discloses an electronic device, including a processor and a memory communicatively connected to the processor and used to store executable instructions of the processor, wherein the processor is used to execute an automated verification platform implementation method based on the SRIO GEN4 protocol.
[0018] Furthermore, this solution discloses a server, including at least one processor and a memory communicatively connected to the processor, the memory storing instructions executable by the at least one processor, the instructions being executed by the processor to cause the at least one processor to execute an automated verification platform implementation method based on the SRIO GEN4 protocol.
[0019] Furthermore, this solution discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, implements an automated verification platform implementation method based on the SRIO GEN4 protocol.
[0020] Compared with existing technologies, the automated verification platform implementation method based on the SRIO GEN4 protocol described in this invention has the following advantages:
[0021] (1) The automated verification platform implementation method based on the SRIO GEN4 protocol described in this invention generates a matching verification environment based on the characteristic parameter script of the customer verification object. If the DUT function is in Switch mode, only the routing configuration needs to be completed according to the design requirements to complete the function convergence; if it is configured in Bridge mode, the incentive expectation of the conversion protocol needs to be completed according to the design requirements; when configured in Endpoint mode, the environment is automatically generated without any time investment.
[0022] (2) The automated verification platform implementation method based on the SRIO GEN4 protocol described in this invention, in which the BFM controller part completes MPW verification, can ensure protocol consistency. The time cost for user maintenance of this automated verification platform depends on the complexity of the user routing design and the complexity and implementation method of the bridge mode reference model. Attached Figure Description
[0023] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:
[0024] Figure 1 This is a schematic diagram illustrating the implementation mechanism of the automated verification platform described in an embodiment of the present invention;
[0025] Figure 2 This is a schematic diagram of the structure of the i / o_agent content described in an embodiment of the present invention;
[0026] Figure 3 This is a first schematic diagram illustrating the process of implementing an automated verification platform based on the SRIO GEN4 protocol according to an embodiment of the present invention.
[0027] Figure 4 This is a schematic diagram illustrating the implementation process of the automated verification platform based on the SRIO GEN4 protocol according to an embodiment of the present invention.
[0028] Figure 5 This is a schematic diagram of the platform implementation process described in an embodiment of the present invention;
[0029] Figure 6 This is a second schematic diagram illustrating the implementation process of the automated verification platform based on the SRIO GEN4 protocol according to an embodiment of the present invention.
[0030] Figure 7 This is a third schematic diagram illustrating the process of implementing an automated verification platform based on the SRIO GEN4 protocol according to an embodiment of the present invention.
[0031] Figure 8This is the fourth schematic diagram of the implementation process of the automated verification platform based on the SRIO GEN4 protocol according to an embodiment of the present invention. Detailed Implementation
[0032] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.
[0033] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0034] The software script needs to obtain parameters required by the user's design object, including the SRIO protocol version, link width, number of ports, port attributes, and configuration path attribute parameters, and populate them into the script parameter positions. Simultaneously, the customer provides a register table for the designed chip, which is used by the automation platform to create the RAL component and verify the register functions and attributes according to the table's contents.
[0035] The Driver library contains SRI standard protocol stimuli and regular AMB bus configuration stimuli; the Reference model library is a model library based on device attributes, including Switch, Bridge, and Endpoint attribute devices; the Coverage library is a functional coverage component library used to create functional coverage components for verifying the configuration, transport layer, and physical layer protocol consistency of verification objects in the automated platform; the Ral library is based on the client register list and creates RAL model components in the UVM methodology, providing register attribute-related verification; the checker library matches the reference model to complete device attribute-related checks, such as performing message consistency checks on Switch attribute devices and protocol checks on Bridge messages after bridge protocol conversion. The automated verification platform implementation mechanism is as follows: Figure 1 As shown;
[0036] The script can generate the number of SRIO i_agents, cfg agent, SRIOmodel, Scoreboard, multiple sets of SRIO o_agents, register model RAL model, etc., to match customer configuration requirements.
[0037] Cfg_agent is a bus based on the UVM verification methodology and commonly used AMBA configuration types. It can include one or more configurations such as apb, ahb, axi3, and axi4 buses. It can realize front-door access to register addresses, and the configuration stimulus protocol consistency has been silicon verified and conforms to the AMBA bus standard protocol.
[0038] Based on the verification device attributes and port quantity requirements, the user creates a `srio i / o_agent` that matches the design requirements attributes and quantity, implemented using the UVM verification methodology. The `i / o_agent` contains the following structure. Figure 2 As shown;
[0039] All BFMs have undergone MPW silicon verification and standard GEN4 device interfacing tests, meeting the highest GEN4 protocol requirements. When selected as switching mode, the BFM does not create a resp_gen processing module; however, when configured as endpoint or bridge mode, it can handle received SRIO protocol request messages such as IO / Message / maintenance packets / custom messages, while simultaneously sending up to 128 outstanding unacknowledged requests. The BFM's internal trans layer provides various flexible parameter configurations for configuring port flow control, stimulus timing, response time, and abnormal responses; the trans RX layer monitor is used to collect received SRIO protocol messages to achieve the expected performance of the RM. The phy layer provides physical standard protocol stimulus, including specific IDLE sequences, protocol definition control characters, and link training.
[0040] Based on the device attributes required for user authentication, the script creates a reference model based on the Switch / endpoint / bridge model.
[0041] When configured in SW mode, a customized routing reference model is required based on customer needs. This model sends incentive packets to the expected routing queue and provides protocol-defined routing lookup rules, including flat and hierarchical lookups. If configured in Endpoint or bridge mode, the RM records the stored packet address. If no address field is available, the protocol packet is stored using a virtual pointer defined by a special field. The storage location is a dynamically associative array, and the user customizes the mapping mechanism according to application requirements. Specifically... Figure 3 As shown;
[0042] The Scoreboard component will also be created in different forms according to different user needs to ensure the correctness of the transport layer function design.
[0043] In Switch mode, the messages from the SRIO model are compared with the messages collected by o_agent to perform an end-to-end check, ensuring message correctness. The platform implementation process is as follows: Figure 4 As shown;
[0044] In endpoint / bridge mode, the packet header and payload are checked and processed separately. Meanwhile, in the base test, the UVM component and user-added components can access the data storage space. Devices with this attribute implement SRIO protocol packet conversion to heterogeneous protocols or bus implementations. The check is based on the consistency check of valid data and valid header information. For packets with address dependencies, a mapping module is used to map SRIO packets to heterogeneous protocol packets, specifically as follows... Figure 5 As shown;
[0045] For doorbell / message / datastream messages without a protocol address, data and descriptors are bound together using queues and data descriptors. Users retrieve data from the data source based on the descriptor content.
[0046] The Doorbell verification model implementation is shown in the figure. It requires encapsulating the Doorbell header information and placing it in a Doorbell queue. Users retrieve source data by reading data from this queue and perform protocol consistency checks. Specifically... Figure 6 As shown;
[0047] The message contains data content, with a maximum payload of 4kB. The verification platform uses a combination of letter / mbox / destid header information as an index for the message data storage space and uses a flag signal to record the number of times the same message is stored. In devices with this type of message attribute, message storage only occurs when the response status value is 0, indicating normal reception. When the status value is 7, only the message header information is recorded, and no data is stored. Users can retrieve the corresponding source data information through the data index, specifically as follows... Figure 7 As shown;
[0048] Data stream protocol messages do not contain address information, have a maximum data payload of 64KB, and require processing based on the packet header information. The verification environment uses a combination of streamid / deviceid information as an index for data storage, and a flag signal indicates the number of times messages with the same header information are stored. Users can retrieve the corresponding source data information through the data index, specifically as follows... Figure 8 As shown;
[0049] The Register Model (RAL model) is a model of the registers within the customer's Device Under Test (DUT). The register list is imported via Python, allowing verification personnel to verify the register attributes and functions. The list format is supported as Excel, and the verification environment provides front-door access incentives.
[0050] The coverage component is a functional coverage collection component. The functions collected in the verification environment cover the transport layer protocol packet header fields and packet length; physical layer transmit / receive control characters.
[0051] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
[0052] In the several embodiments provided in this application, it should be understood that the disclosed methods and systems can be implemented in other ways. For example, the division of units described above is merely a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. The aforementioned units may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of the present invention according to actual needs.
[0053] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention, and they should all be covered within the scope of the claims and specification of the present invention.
[0054] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. An automated verification platform implementation method based on the SRIO GEN4 protocol, characterized in that: Generate a matching verification environment based on the client's verification object characteristic parameters script; If the DUT function is in Switch mode, complete the routing configuration according to the design requirements and complete the function convergence. If configured in Bridge mode, the incentive expectation for completing the conversion protocol will be fulfilled according to design requirements; If configured in Endpoint mode, the environment will be generated automatically; Specifically as follows: Obtain the parameters required by the user's design object, configure the path attribute parameters and fill them into the script parameter positions. At the same time, the customer provides the register table of the design chip for the specific implementation of the design object. The automated platform creates the RAL component and completes the register function and attribute verification according to the table content. The required parameters include SRIO protocol version, link width, number of ports, port attributes, configuration path attribute parameters, which are then filled into the script parameter positions. The script generates the number of SRIO i_agents, Cfg_agent, SRIO model, Scoreboard, multiple sets of SRIO o_agents, and register model RAL model to match the customer's configuration requirements. Among them, Cfg_agent is an AMBA configuration type bus implemented based on the UVM verification methodology. The Driver library contains SRIO standard protocol stimuli and AMBA bus configuration stimuli; the Reference model library is a model library based on device attributes, including three types of attribute devices: Switch, Bridge, and Endpoint; the Coverage library is a functional coverage component library, used to create functional coverage components for verifying the configuration, transport layer, and physical layer protocol consistency of verification objects in the automation platform; the Ral library is based on the client register list and creates RAL model components in the UVM methodology, providing register attribute-related verification; the checker library matches the Reference model library to complete device attribute-related checks, including message consistency checks for Switch attribute devices and protocol checks after bridging protocol conversion for Bridge messages; users create SRIO i_agent and SRIO o_agent based on the UVM verification methodology to match the design requirements attributes and quantities according to the verification device attributes and port quantity requirements; Based on the device attributes required for user authentication, the script creates a reference model based on Switch, Endpoint, and Bridge modes. For Doorbell, message, and datastream messages without protocol addresses, data and descriptors are bound together through queues and data descriptors, allowing users to obtain data from the data source by describing the content. Import the register list using Python so that verification personnel can verify the register attributes and functions; When configured in Switch mode, a customized routing reference model is required based on design requirements. The incentive packets are sent to the expected routing queue, and protocol-defined routing lookup rules are provided for flat lookup and hierarchical lookup. If configured as Endpoint or Bridge mode, the RM record is used to store the message address. If there is no address field protocol, the message is stored through a virtual pointer defined by a special field. The storage location is a dynamically associative array, and the user can customize the mapping mechanism according to the application requirements. During the implementation of the Doorbell verification model, the Doorbell header information is encapsulated and placed into the Doorbell queue. Users obtain source data by reading the Doorbell queue data information and perform protocol consistency checks.
2. An electronic device, comprising a processor and a memory communicatively connected to the processor and used for storing processor-executable instructions, characterized in that: The processor is used to execute the automated verification platform implementation method based on the SRIO GEN4 protocol as described in claim 1.
3. A server, characterized in that: It includes at least one processor and a memory communicatively connected to the processor, the memory storing instructions executable by the at least one processor, the instructions being executed by the processor to cause the at least one processor to perform the automated verification platform implementation method based on the SRIO GEN4 protocol as described in claim 1.
4. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by the processor, it implements the automated verification platform implementation method based on the SRIO GEN4 protocol as described in claim 1.