NTB cross-host domain verification system, method, computer device and medium

Abstract

The present application relates to the field of computer technology and discloses a NTB cross-host domain verification system, method, computer device and medium, including a PCIe system model, an input scheduling module, a cross-domain routing module, a chip implementation module and a comparison module, wherein the PCIe system model is connected to the input scheduling module, the input scheduling module is connected to the cross-domain routing module and the chip implementation module, and the cross-domain routing module and the chip implementation module are connected to the comparison module, which can quickly and comprehensively verify the cross-host domain function of the NTB chip.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an NTB cross-host domain verification system, method, computer device, and medium. Background Art

[0002] In the field of computer system interconnection, PCIe (Peripheral Component Interconnect Express) technology has become a mainstream bus standard due to its high performance and low latency. Non-Transparent Bridges (NTBs), a special type of bridging device in PCIe systems, play a key role in enabling isolated communication between two independent PCIe domains. Unlike traditional transparent bridges, NTBs utilize functions such as address translation, address filtering, and configuration space isolation to enable two independent systems or subsystems to maintain logical independence while being physically connected via PCIe links.

[0003] In a PCIe multi-host scenario, each host is isolated from the others, requiring the use of an NTB (Network Bus Bus) for cross-domain access. However, the current PCIe protocol lacks unified specifications for the specific implementation details of the NTB, resulting in significant technical differences among NTB implementations on the market. NTBs designed by different vendors vary in address translation algorithms, configuration space management logic, and data transmission protocols, posing significant challenges to NTB verification. Existing NTB module verification is typically based on the Bus Functional Model (BT). This verification perspective only observes the address and ID conversion process, making it impossible to determine whether cross-domain memory access is truly successful, nor is it sufficient to verify the effectiveness of resource isolation. Summary of the Invention

[0004] Based on this, it is necessary to address the problem of poor verification effect of the existing NTB and propose an NTB cross-host domain verification system, method, computer device and medium.

[0005] A first aspect of the present application provides an NTB cross-host domain verification system, comprising a PCIe system model, an input scheduling module, a cross-domain routing module, a chip implementation module, and a comparison module, wherein the PCIe system model is connected to the input scheduling module, the input scheduling module is connected to the cross-domain routing module and the chip implementation module, and the cross-domain routing module and the chip implementation module are connected to the comparison module;

[0006] The PCIe system model is configured with several virtual host modules, each of which is connected to the input scheduling module, and the status of each virtual host module is initialized and set respectively, and a test message is generated randomly or according to a preset test rule, and is input into the input scheduling module;

[0007] The input scheduling module schedules receiving different test messages, and synchronously sends each test message to the cross-domain routing module and the chip implementation module in sequence;

[0008] The cross-domain routing module receives the test message sent by the input scheduling module, performs address conversion on the test message according to a preset simulation conversion method, outputs a first conversion message, and inputs the first conversion message into the sub-comparison module in the comparison module corresponding to the destination virtual host module of the first conversion message;

[0009] The chip implementation module receives the test message sent by the input scheduling module, performs address conversion on the test message according to the actual design code of the NTB chip, outputs a second conversion message, and inputs the second conversion message into the sub-comparison module in the comparison module corresponding to the destination virtual host module of the second conversion message;

[0010] The comparison module is preset with multiple sub-comparison modules configured based on different virtual host modules. The first conversion message and the second conversion message are compared in the sub-comparison module corresponding to the target virtual host module. If the comparison result does not meet the preset consistency setting, it is determined that the chip implementation module has not passed the NTB cross-host domain verification.

[0011] Furthermore, the PCIe system model performs the steps of respectively initializing the status of each virtual host module, including:

[0012] The PCIe system model receives global configuration parameters through the UVM command line parameter transfer mechanism;

[0013] Allocate a host number and a corresponding address space to each virtual host module according to the global configuration parameters;

[0014] Allocate an ID range of id_base to id_limit to each virtual host module, where id_base is the ID of the virtual host module and id_limit is the upper limit of the ID of the device connected to the virtual host module;

[0015] Allocate an address domain of addr_base to addr_limit to each virtual host module, wherein addr_base to addr_limit are addresses allocated to the virtual host module and the devices connected to the virtual host module;

[0016] The ID field and address field of each virtual host module are saved to the global configuration parameters to obtain updated global configuration parameters;

[0017] According to the updated global configuration parameters, the IDs and addresses between different virtual host modules are mapped and configured to obtain address mapping table information;

[0018] The address mapping table information is synchronously updated to the cross-domain routing module and the chip implementation module, wherein the cross-domain routing module obtains the updated address mapping table information through the table instance, and the chip implementation module obtains the updated address mapping table information through the CSR chain write table.

[0019] Furthermore, the PCIe system model executes the step of allocating a host number and a corresponding address space to each virtual host module according to the global configuration parameters, and further includes:

[0020] A hole address space is reserved, where the hole address space is used to test conversion processing of a hole address carried in the test message.

[0021] Furthermore, the test message is a REQ message, and the PCIe system model performs the step of randomly generating a test message, including:

[0022] The PCIe system model randomly selects an address under a virtual host module as the original address;

[0023] Randomly select an address under another virtual host module as the destination address;

[0024] A REQ message is generated according to the source address and the destination address.

[0025] Furthermore, the test message is a CPL message, and the PCIe system model performs the step of randomly generating a test message, including:

[0026] The PCIe system model randomly selects an ID under a virtual host module as a request ID;

[0027] Randomly select an ID under a virtual host module as a completion ID, wherein the completion ID is different from the request ID;

[0028] The CPL message is generated according to the request ID and the completion ID.

[0029] Furthermore, the step of the input scheduling module scheduling to receive different test messages and synchronously sending each test message to the cross-domain routing module and the chip implementation module in sequence includes:

[0030] The input scheduling module schedules receiving different test messages and classifies them according to the virtual host module that sends the test messages;

[0031] For test messages from the same virtual host module, different test messages are sorted according to the order in which the test messages are generated;

[0032] For test messages from different virtual host modules, a preset fair scheduling strategy is used for round-robin scheduling.

[0033] Further, the chip implementation module determines whether an idle signal is not sent to the PCIe system model for more than a preset time period, wherein the idle signal is sent by the chip implementation module to the PCIe system model after completing output of the second conversion message;

[0034] If so, a stop packet sending instruction is sent to the PCIe system model, so that the PCIe system model stops sending new test messages to the chip implementation module.

[0035] A second aspect of this embodiment provides a NTB cross-host domain verification method, which is applied to the above-mentioned input scheduling module and includes:

[0036] Scheduling and receiving different test messages, wherein the test messages are randomly generated by the PCIe system model, the PCIe system model is configured with a plurality of virtual host modules, each virtual host module is respectively connected to the input scheduling module, and the state of each virtual host module is respectively initialized and set;

[0037] Each test message is synchronously sent to the cross-domain routing module and the chip implementation module in sequence, so that the cross-domain routing module receives the test message sent by the input scheduling module, and performs address conversion on the test message according to a preset simulation conversion method, outputs a first conversion message, and inputs it into the sub-comparison module corresponding to the destination virtual host module of the first conversion message in the comparison module; and the chip implementation module receives the test message sent by the input scheduling module, and performs address conversion on the test message according to the actual design code of the NTB chip, outputs a second conversion message, and inputs it into the sub-comparison module corresponding to the destination virtual host module of the second conversion message in the comparison module; and a plurality of sub-comparison modules based on different virtual host module configurations are preset in the comparison module, and the first conversion message and the second conversion message are compared in the sub-comparison module corresponding to the destination virtual host module. If the comparison result does not meet the preset consistency setting, it is determined that the chip implementation module has failed the NTB cross-host domain verification.

[0038] A third aspect of this embodiment provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the above-mentioned NTB cross-host domain verification method.

[0039] A fourth aspect of this embodiment provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor executes the steps of the above-mentioned NTB cross-host domain verification method.

[0040] The NTB cross-host domain verification system of the present application can quickly and comprehensively verify the cross-host domain function of the NTB chip. The PCIe system model can generate a variety of test messages, covering various possible cross-domain access scenarios. Combined with the efficient scheduling mechanism of the input scheduling module, it can perform a large number of tests on the chip in a short period of time, greatly improving the verification efficiency of NTB across host domains. The design of the comparison module enables the precise location of the specific link where the chip implementation module has problems when the verification fails. Through detailed message comparison difference information, technicians can intuitively understand the deviation of the chip from the ideal analog conversion method during the address conversion process, which helps to quickly find errors or defects in the chip design code, provide support for chip optimization and improvement, and shorten the chip research and development cycle. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0042] in:

[0043] Figure 1 A structural block diagram of an NTB cross-host domain verification system in one embodiment;

[0044] Figure 2 Flowchart of a method for verifying NTB across host domains in one embodiment;

[0045] Figure 3 FIG. 1 is a structural block diagram of a computer device in one embodiment. DETAILED DESCRIPTION

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

[0047] like Figure 1 As shown, in one embodiment, a NTB cross-host domain verification system is provided, including a PCIe system model 1, an input scheduling module 2, a cross-domain routing module 3, a chip implementation module 4, and a comparison module 5, wherein the PCIe system model 1 is connected to the input scheduling module 2, the input scheduling module 2 is connected to the cross-domain routing module 3 and the chip implementation module 4, and the cross-domain routing module 3 and the chip implementation module 4 are connected to the comparison module 5;

[0048] The PCIe system model 1 is configured with a plurality of virtual host modules 11, each of which is connected to the input scheduling module 2. The state of each virtual host module 11 is initialized and set, and a test message is generated randomly or according to a preset test rule, and is input into the input scheduling module 2.

[0049] The input scheduling module 2 schedules to receive different test messages, and synchronously sends each test message to the cross-domain routing module 3 and the chip implementation module 4 in sequence;

[0050] The cross-domain routing module 3 receives the test message sent by the input scheduling module 2, performs address conversion on the test message according to a preset simulation conversion method, outputs a first conversion message, and inputs it into the sub-comparison module 51 corresponding to the destination virtual host module 11 of the first conversion message in the comparison module 5;

[0051] The chip implementation module 4 receives the test message sent by the input scheduling module 2, performs address conversion on the test message according to the actual design code of the NTB chip, outputs a second converted message, and inputs the second converted message into the sub-comparison module 51 corresponding to the destination virtual host module 11 of the second converted message in the comparison module 5;

[0052] The comparison module 5 is preset with multiple sub-comparison modules 51 configured based on different virtual host modules 11. The first conversion message and the second conversion message are compared in the sub-comparison module 51 corresponding to the target virtual host module 11. If the comparison result does not meet the preset consistency setting, it is determined that the chip implementation module 4 has not passed the NTB cross-host domain verification.

[0053] In this embodiment, the PCIe system model 1 includes multiple virtual host modules 11. Each virtual host module 11 establishes a connection with the input scheduling module 2. During the system initialization phase, the module 2 configures an independent address space and host number for each virtual host module 11 according to preset initialization rules, simulating the operating environment of different hosts in a real PCIe system.

[0054] During implementation, the virtual host module 11 generates test messages randomly or according to pre-set test rules. For example, when simulating a cross-domain data read scenario, the virtual host module 11 generates a request message (REQ message) compliant with the PCIe protocol specification. The source address is randomly selected from the address space of the virtual host module 11, and the destination address is selected from the address space of another virtual host module 11, thereby simulating a real cross-host domain access request. Furthermore, for specific testing requirements, the virtual host module 11 can generate test messages containing special requirements according to pre-set rules to fully test the NTB's cross-domain access functionality.

[0055] Input Scheduling Module 2 uses a first-in-first-out (FIFO) or priority scheduling algorithm to manage the different test messages it receives. When virtual host module 11 generates a test message, it sends it to Input Scheduling Module 2. Input Scheduling Module 2 then checks the message queues in sequence and synchronously sends each test message to cross-domain routing module 3 and chip implementation module 4. For example, if the system receives test messages from multiple virtual host modules 11 simultaneously, Input Scheduling Module 2 will ensure that each message is delivered promptly and completely to subsequent processing modules based on the order or priority of the messages received, avoiding message loss or out-of-order processing.

[0056] After receiving the test message sent by the input scheduling module 2, the cross-domain routing module 3 performs an address conversion operation according to a preset simulation conversion method. A pre-configured address mapping table is stored inside the module, and the address mapping table records the corresponding relationship between the address conversions of different virtual host modules 11. For example, when a test message with a destination address of virtual host module A is received, the cross-domain routing module 3 will look up the corresponding conversion rule in the address mapping table, convert the original address of the message into an address format recognizable by virtual host module A, and generate a first conversion message. Subsequently, the cross-domain routing module 3 inputs the host number of the destination virtual host module 11 of the first conversion message into the corresponding sub-comparison module 51 in the comparison module 5. This processing method simulates the address conversion process of the NTB device under ideal conditions to compare with the actual processing results of the subsequent chip. Specifically, the cross-domain routing module 3 makes processing judgments based on the type, address, ID and other information of the input test message; after confirming that message conversion is required, it traverses the address mapping table, uses the original domain information in the test message to find the destination domain information, and uses the destination address and / or ID to replace the address and / or ID of the converted message, and outputs it to the comparison module 5.

[0057] After receiving the test message sent by the input scheduling module 2, the chip implementation module 4 processes it according to the actual design code of the NTB chip. By calling the NTB chip's driver or simulation model, the chip implementation module 4 simulates the address conversion logic of the NTB chip in its actual operating environment. Because NTB chips from different manufacturers differ in design code and implementation details, the chip implementation module 4 needs to be adapted according to the specific chip model. For example, for a certain model of NTB chip, its address conversion may involve multiple register read and write operations and complex arithmetic operations. The chip implementation module 4 will strictly follow the chip's design documentation, execute the corresponding code logic, perform address conversion on the test message, and generate a second converted message. Then, based on the host number of the destination virtual host module 11 of the second converted message, it is input into the corresponding sub-comparison module 51 in the comparison module 5.

[0058] There are multiple sub-comparison modules 51 preset inside the comparison module 5, and each sub-comparison module 51 corresponds to a virtual host module 11. In the actual verification process, after the first conversion message and the second conversion message based on the same test message are input into the sub-comparison module 51 corresponding to the destination virtual host module 11, the sub-comparison module 51 will compare each field of the two conversion messages bit by bit. The comparison content includes but is not limited to key parameters such as address information, data content, and control identifiers. If the two messages are completely consistent in all comparison fields, it is determined that the NTB cross-host domain processing function of the chip implementation module 4 in this test scenario meets expectations; if there is any inconsistency in any field, that is, it is determined that the comparison result does not meet the preset consistency setting, indicating that the chip implementation module 4 has problems in the address conversion or other related functions of the NTB cross-host domain and has failed the verification. At this time, the sub-comparison module 51 will record detailed comparison difference information and generate a verification failure report for technical personnel to troubleshoot and analyze the problem, such as checking whether the implementation of the cross-domain routing module 3 is consistent with the chip implementation module 4; checking whether the code implementation of the chip implementation module 4 is consistent with the preset test plan; checking whether the abnormal test message content causes the output of the cross-domain routing module 3 and the chip implementation module 4 to be inconsistent.

[0059] Through the NTB cross-host domain verification system of this embodiment, the cross-host domain function of the NTB chip can be quickly and comprehensively verified. The PCIe system model 1 can generate a variety of test messages, covering various possible cross-domain access scenarios. Combined with the efficient scheduling mechanism of the input scheduling module 2, it can perform a large number of tests on the chip in a short period of time, greatly improving the verification efficiency of the NTB cross-host domain. The design of the comparison module 5 enables the precise location of the specific link where the chip implementation module 4 has problems when the verification fails. Through detailed message comparison difference information, technicians can intuitively understand the deviation of the chip from the ideal analog conversion method during the address conversion process, which helps to quickly find errors or defects in the chip design code, provide support for chip optimization and improvement, and shorten the chip R&D cycle.

[0060] In a specific embodiment, the PCIe system model 1 performs the steps of respectively initializing the status of each virtual host module 11, including:

[0061] The PCIe system model 1 receives global configuration parameters through the UVM command line parameter transfer mechanism;

[0062] Allocate a host number and a corresponding address space to each virtual host module 11 according to the global configuration parameters;

[0063] Allocate an ID range of id_base to id_limit to each virtual host module 11, wherein id_base is the ID of the virtual host module 11, and id_limit is the upper limit of the ID of the device connected to the virtual host module 11;

[0064] Allocate an address range of addr_base to addr_limit to each virtual host module 11, wherein addr_base to addr_limit are addresses allocated to the virtual host module 11 and the devices connected to the virtual host module 11;

[0065] The ID field and the address field of each virtual host module 11 are saved in the global configuration parameters to obtain updated global configuration parameters;

[0066] According to the updated global configuration parameters, the IDs and addresses between different virtual host modules 11 are mapped and configured to obtain address mapping table information;

[0067] The address mapping table information is synchronously updated to the cross-domain routing module 3 and the chip implementation module 4, wherein the cross-domain routing module 3 obtains the updated address mapping table information through the table instance, and the chip implementation module 4 obtains the updated address mapping table information through the CSR chain write table.

[0068] In this embodiment, PCIe system model 1 utilizes general UVM command line parameter delivery mechanism to receive global configuration parameters. Through UVM, various configuration information required for system operation, such as global configuration parameters such as number of hosts and address space size, can be input from the outside.

[0069] Based on the received global configuration parameters, PCIe system model 1 creates several virtual host modules and assigns each virtual host module 11 a unique host number, dividing the corresponding address space. For example, if the parameters specify three virtual host modules, they are assigned numbers A, B, and C, respectively, and are allocated address spaces of, for example, 1MB, 2MB, and 3MB, respectively, according to preset rules (e.g., proportional or specified size), simulating the resource allocation of different hosts in a real PCIe system.

[0070] For each virtual host module 11, an ID domain is determined, specifying id_base and id_limit. id_base serves as the virtual host module's own ID, used to distinguish between different hosts; id_limit sets the upper limit of the device IDs that can be connected to it. For example, if virtual host module A has id_base set to 10 and id_limit set to 30, this means its ID is 10 and the maximum ID of the device it can connect to is 30. Virtual host module B has id_base set to 40 and id_limit set to 60.

[0071] Each virtual host module 11 is assigned an address range from addr_base to addr_limit. This address range covers the addresses available to the virtual host module 11 itself and its connected devices. For example, if the address range of virtual host module A is set to h100-h200, the host and its connected devices will use addresses within this range for data transmission and identification during communication; the address range of virtual host module B is set to h400-h600.

[0072] The ID field and address field information of each virtual host module 11 is saved in the global configuration parameters and updated. The updated global configuration parameters include the detailed and complete configuration information of each virtual host module.

[0073] Based on the updated global configuration parameters, PCIe system model 1 configures mappings between the IDs and addresses of different virtual host modules 11. Using pre-defined rules, the correspondence between different host IDs and addresses is established, generating address mapping information. For example, a certain address segment of virtual host module A is specified to correspond to a specific ID of virtual host module B, and a certain address segment of virtual host module B is specified to correspond to a specific ID of virtual host module A, clarifying the address translation logic for cross-domain access.

[0074] The generated address mapping table information is synchronously updated to the cross-domain routing module 3 and the chip implementation module 4. The cross-domain routing module 3 obtains the updated address mapping table information through the table instance, that is, it creates a special data structure (table instance) to store and manage the address mapping relationship, so as to quickly find and convert addresses when processing messages. The chip implementation module 4 obtains information through the CSR (control / status register) chain write table. By operating the relevant registers, the address mapping table information is written to the internal storage structure of the chip, so that it can perform operations such as address conversion based on this information.

[0075] Furthermore, global configuration parameters can be modified in real time during the verification system's operation, such as reallocating the address space of the virtual host module 11 and adjusting the ID domain range, simulating the dynamic changes in system configuration in actual applications. It should be noted that before dynamically modifying the address mapping table, it is necessary to first confirm that the messages related to the intended modification in the current system have successfully completed the address mapping table lookup process. Once the prerequisites are confirmed, the table entries in the cross-domain routing module 3 and the chip implementation module 4 are synchronously updated. After the address mapping table is updated, the modified test message is sent to ensure that the test message is consistent and there is no packet loss. If it is not possible to ensure that the modified message has been successfully forwarded, it is necessary to anticipate the possibility of routing discarded messages. To avoid verification environment errors, the first-in-first-out queue (FIFO) used for comparison in the comparison module 5 must be cleared to eliminate the potential for message comparison errors caused by packet loss, thereby ensuring the stability and accuracy of the verification environment.

[0076] In a specific embodiment, the PCIe system model 1 performs the step of allocating a host number and a corresponding address space to each virtual host module 11 according to the global configuration parameters, further comprising:

[0077] A hole address space is reserved, where the hole address space is used to test conversion processing of a hole address carried in the test message.

[0078] In this embodiment, after allocating a base address space to each virtual host module 11, the PCIe system model 1 reserves a certain amount of hole address space within this address space. This reserved hole address space can be a discontinuous address segment. By reserving hole address space, it is possible to simulate abnormal address situations that may occur in actual applications, allowing the verification system to comprehensively test the conversion processing of hole addresses in test messages, helping to identify potential problems that may exist when the NTB chip handles non-standard addresses.

[0079] In a specific embodiment, the test message is a REQ message, and the PCIe system model 1 performs the step of randomly generating a test message, including:

[0080] The PCIe system model 1 randomly selects an address under a virtual host module 11 as the original address;

[0081] Randomly select an address under another virtual host module 11 as the destination address;

[0082] A REQ message is generated according to the source address and the destination address.

[0083] In this embodiment, a REQ message is a message format used to initiate a request in a PCIe system. It typically contains key information such as the source address, destination address, request type, and data length. When generating a REQ message, the randomly selected source and destination addresses are entered into the corresponding fields in the message. Other necessary fields, such as the request type (which may be a read request, a write request, etc.) and data length, may also be generated based on preset rules or randomly, ultimately forming a complete REQ message.

[0084] In a specific embodiment, the test message is a CPL message, and the PCIe system model 1 performs the step of randomly generating a test message, including:

[0085] The PCIe system model 1 randomly selects an ID under a virtual host module 11 as a request ID;

[0086] Randomly select an ID under the virtual host module 11 as a completion ID, wherein the completion ID is different from the request ID;

[0087] The CPL message is generated according to the request ID and the completion ID.

[0088] In this embodiment, the CPL message (Completion Message) is a standard message format used in PCIe systems to respond to requests. It typically contains key information such as a request ID, completion ID, response status, and data content. During the generation process, the selected request ID and completion ID are entered into the corresponding fields in the message. Other necessary fields can also be generated according to preset rules or randomly. For example, the response status (success, failure, etc.) can be set based on the simulated response situation, and data content can be generated or filled in as needed, ultimately forming a complete CPL message.

[0089] In a specific embodiment, two virtual host modules 11 can send messages to each other for verification. For example, for virtual host module A and virtual host module B, the id_base of virtual host module A is set to 10, the id_limit is set to 30, and the address domain is set to h100~h200; the id_base of virtual host module B is set to 40, the id_limit is set to 60, and the address domain is set to h400~h600. Virtual host module A generates message TLP-A, the source address of the message is h102, the destination address is h403, and the ID is 12; virtual host module B generates message TLP-B, the source address of the message is h502, the destination address is h177, and the ID is 55. By sending TLP-A and TLP-B to the input scheduling module 2 respectively, and then converting, processing and comparing them through the subsequent cross-domain routing module 3, chip implementation module 4 and comparison module 5, the verification of NTB cross-domain access is achieved.

[0090] In a specific embodiment, the input scheduling module 2 schedules receiving different test messages and synchronously sends each test message to the cross-domain routing module 3 and the chip implementation module 4 in sequence, including the following steps:

[0091] The input scheduling module 2 schedules receiving different test messages and classifies them according to the virtual host module 11 that sends the test messages;

[0092] For test messages from the same virtual host module 11, different test messages are sorted according to the order in which the test messages are generated;

[0093] For the test messages from different virtual host modules 11, a preset fair scheduling strategy is adopted to perform round-robin scheduling.

[0094] In this embodiment, by sorting messages from the same virtual host module 11, test messages are ensured to be processed in the order in which they were generated. A fair scheduling strategy is also employed to schedule messages from different virtual host modules 11 in turn, achieving fair resource allocation among these virtual host modules 11. This prevents messages from one virtual host module 11 from being processed for extended periods due to a large number of messages from other modules. This ensures that each virtual host module 11 receives a reasonable opportunity to be processed within the system, improving the efficiency and fairness of the entire verification system.

[0095] In a specific embodiment, the chip implementation module 4 determines whether an idle signal is not sent to the PCIe system model 1 for more than a preset time period, wherein the idle signal is sent by the chip implementation module 4 to the PCIe system model 1 after completing the output of the second conversion message;

[0096] If so, a stop packet sending instruction is sent to the PCIe system model 1 to make the PCIe system model 1 stop sending new test messages to the chip implementation module 4.

[0097] In this embodiment, after completing the output operation of the second converted message, the chip implementation module 4 sends an idle signal to the PCIe system model 1. The idle signal is used to inform the PCIe system model 1 that the current chip implementation module 4 has completed a message processing task and is in a state where it can receive new test messages.

[0098] Chip implementation module 4 has an internal timing mechanism that records the time interval from the last idle signal transmission to the current moment. Chip implementation module 4 continuously compares this time interval with a preset duration. The preset duration is a time threshold set in advance based on the chip's performance and verification requirements.

[0099] If Chip Implementation Module 4 determines that the time interval between the last idle signal transmission and the current moment has exceeded the preset duration, it indicates that Chip Implementation Module 4 may be busy for a long time due to some reasons (such as insufficient processing power or anomalies) and cannot process new test messages in a timely manner. In this case, Chip Implementation Module 4 will send a stop packet transmission instruction to PCIe System Model 1, instructing it to suspend sending new test messages to Chip Implementation Module 4.

[0100] After receiving the stop packet transmission instruction, the PCIe system model 1 will stop sending new test messages to the chip implementation module 4 and wait until the chip implementation module 4 recovers its normal processing capacity before continuing to send. This can prevent the chip implementation module 4 from being overloaded with test messages.

[0101] Reference Figure 2 In one embodiment, a NTB cross-host domain verification method is provided. The NTB cross-host domain verification method is applied to the input scheduling module 2 in the aforementioned embodiment, including:

[0102] S1: Scheduling and receiving different test messages, wherein the test messages are randomly generated by the PCIe system model 1, the PCIe system model 1 is configured with a plurality of virtual host modules 11, each virtual host module 11 is respectively connected to the input scheduling module 2, and the status of each virtual host module 11 is respectively initialized;

[0103] S2: Each test message is synchronously sent to the cross-domain routing module 3 and the chip implementation module 4 in sequence, so that the cross-domain routing module 3 receives the test message sent by the input scheduling module 2, and performs address conversion on the test message according to the preset simulation conversion method, outputs a first conversion message, and inputs it into the sub-comparison module 51 corresponding to the destination virtual host module 11 of the first conversion message in the comparison module 5; and the chip implementation module 4 receives the test message sent by the input scheduling module 2, and performs address conversion on the test message according to the preset simulation conversion method, outputs a first conversion message, and inputs it into the sub-comparison module 51 corresponding to the destination virtual host module 11 of the first conversion message in the comparison module 5; and The test message is address-translated, and a second conversion message is output, which is input into the sub-comparison module 51 corresponding to the destination virtual host module 11 of the second conversion message in the comparison module 5; and a plurality of sub-comparison modules 51 configured based on different virtual host modules 11 are preset in the comparison module 5, and the first conversion message and the second conversion message are compared in the sub-comparison module 51 corresponding to the destination virtual host module 11. If the comparison result does not meet the preset consistency setting, it is determined that the chip implementation module 4 has failed the NTB cross-host domain verification.

[0104] In a specific embodiment, the PCIe system model performs the step of respectively initializing the status of each virtual host module, including:

[0105] The PCIe system model receives global configuration parameters through the UVM command line parameter transfer mechanism;

[0106] Allocate a host number and a corresponding address space to each virtual host module according to the global configuration parameters;

[0107] Allocate an ID range of id_base to id_limit to each virtual host module, where id_base is the ID of the virtual host module and id_limit is the upper limit of the ID of the device connected to the virtual host module;

[0108] Allocate an address domain of addr_base to addr_limit to each virtual host module, wherein addr_base to addr_limit are addresses allocated to the virtual host module and the devices connected to the virtual host module;

[0109] The ID field and address field of each virtual host module are saved to the global configuration parameters to obtain updated global configuration parameters;

[0110] According to the updated global configuration parameters, the IDs and addresses between different virtual host modules are mapped and configured to obtain address mapping table information;

[0111] The address mapping table information is synchronously updated to the cross-domain routing module and the chip implementation module, wherein the cross-domain routing module obtains the updated address mapping table information through the table instance, and the chip implementation module obtains the updated address mapping table information through the CSR chain write table.

[0112] In a specific embodiment, the PCIe system model performs the step of allocating a host number and a corresponding address space to each virtual host module according to the global configuration parameters, further comprising:

[0113] A hole address space is reserved, where the hole address space is used to test conversion processing of a hole address carried in the test message.

[0114] In a specific embodiment, the test message is a REQ message, and the PCIe system model performs the step of randomly generating a test message, including:

[0115] The PCIe system model randomly selects an address under a virtual host module as the original address;

[0116] Randomly select an address under another virtual host module as the destination address;

[0117] A REQ message is generated according to the source address and the destination address.

[0118] In a specific embodiment, the test message is a CPL message, and the PCIe system model performs the step of randomly generating a test message, including:

[0119] The PCIe system model randomly selects an ID under a virtual host module as a request ID;

[0120] Randomly select an ID under a virtual host module as a completion ID, wherein the completion ID is different from the request ID;

[0121] The CPL message is generated according to the request ID and the completion ID.

[0122] In a specific embodiment, the step of the input scheduling module scheduling receiving different test messages and synchronously sending each test message to the cross-domain routing module and the chip implementation module in sequence includes:

[0123] The input scheduling module schedules receiving different test messages and classifies them according to the virtual host module that sends the test messages;

[0124] For test messages from the same virtual host module, different test messages are sorted according to the order in which the test messages are generated;

[0125] For test messages from different virtual host modules, a preset fair scheduling strategy is used for round-robin scheduling.

[0126] In a specific embodiment, the chip implementation module determines whether an idle signal is not sent to the PCIe system model for more than a preset time period, wherein the idle signal is sent by the chip implementation module to the PCIe system model after completing output of the second conversion message;

[0127] If so, a stop packet sending instruction is sent to the PCIe system model, so that the PCIe system model stops sending new test messages to the chip implementation module.

[0128] Through the NTB cross-host domain verification method of this embodiment, the cross-host domain function of the NTB chip can be quickly and comprehensively verified. The PCIe system model 1 can generate a variety of test messages, covering various possible cross-domain access scenarios. Combined with the efficient scheduling mechanism of the input scheduling module 2, it can perform a large number of tests on the chip in a short period of time, greatly improving the verification efficiency of the NTB cross-host domain. The design of the comparison module 5 enables the precise location of the specific link where the chip implementation module 4 has problems when the verification fails. Through detailed message comparison difference information, technicians can intuitively understand the deviation of the chip from the ideal analog conversion method during the address conversion process, which helps to quickly find errors or defects in the chip design code, provide strong support for chip optimization and improvement, and shorten the chip R&D cycle.

[0129] Figure 3 FIG1 shows an internal structure diagram of a computer device in an embodiment. The computer device can be a terminal or a server. Figure 3 As shown, the computer device includes a processor, a memory, and a network interface connected via a system bus. The memory includes a non-volatile storage medium and an internal memory. The non-volatile storage medium of the computer device stores an operating system and may also store a computer program. When the computer program is executed by the processor, the processor can implement the NTB cross-host domain verification method. The internal memory may also store a computer program. When the computer program is executed by the processor, the processor can implement the NTB cross-host domain verification method. Those skilled in the art will understand that Figure 3 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0130] In one embodiment, a computer device is provided, comprising a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the following steps:

[0131] Scheduling and receiving different test messages, wherein the test messages are randomly generated by the PCIe system model, the PCIe system model is configured with a plurality of virtual host modules, each virtual host module is respectively connected to the input scheduling module, and the state of each virtual host module is respectively initialized and set;

[0132] Each test message is synchronously sent to the cross-domain routing module and the chip implementation module in sequence, so that the cross-domain routing module receives the test message sent by the input scheduling module, and performs address conversion on the test message according to a preset simulation conversion method, outputs a first conversion message, and inputs it into the sub-comparison module corresponding to the destination virtual host module of the first conversion message in the comparison module; and the chip implementation module receives the test message sent by the input scheduling module, and performs address conversion on the test message according to the actual design code of the NTB chip, outputs a second conversion message, and inputs it into the sub-comparison module corresponding to the destination virtual host module of the second conversion message in the comparison module; and a plurality of sub-comparison modules based on different virtual host module configurations are preset in the comparison module, and the first conversion message and the second conversion message are compared in the sub-comparison module corresponding to the destination virtual host module. If the comparison result does not meet the preset consistency setting, it is determined that the chip implementation module has failed the NTB cross-host domain verification.

[0133] This embodiment can quickly and comprehensively verify the cross-host domain function of the NTB chip. The PCIe system model 1 can generate a variety of test messages, covering various possible cross-domain access scenarios. Combined with the efficient scheduling mechanism of the input scheduling module 2, it can perform a large number of tests on the chip in a short period of time, greatly improving the verification efficiency of the NTB cross-host domain. The design of the comparison module 5 enables the precise location of the specific link where the problem exists in the chip implementation module 4 when the verification fails. Through the detailed message comparison difference information, technicians can intuitively understand the deviation of the chip from the ideal analog conversion method during the address conversion process, which helps to quickly find errors or defects in the chip design code, provide strong support for the optimization and improvement of the chip, and shorten the chip R&D cycle.

[0134] In one embodiment, a computer-readable storage medium is provided, storing a computer program. When the computer program is executed by a processor, the processor performs the following steps:

[0135] Scheduling and receiving different test messages, wherein the test messages are randomly generated by the PCIe system model, the PCIe system model is configured with a plurality of virtual host modules, each virtual host module is respectively connected to the input scheduling module, and the state of each virtual host module is respectively initialized and set;

[0136] Each test message is synchronously sent to the cross-domain routing module and the chip implementation module in sequence, so that the cross-domain routing module receives the test message sent by the input scheduling module, and performs address conversion on the test message according to a preset simulation conversion method, outputs a first conversion message, and inputs it into the sub-comparison module corresponding to the destination virtual host module of the first conversion message in the comparison module; and the chip implementation module receives the test message sent by the input scheduling module, and performs address conversion on the test message according to the actual design code of the NTB chip, outputs a second conversion message, and inputs it into the sub-comparison module corresponding to the destination virtual host module of the second conversion message in the comparison module; and a plurality of sub-comparison modules based on different virtual host module configurations are preset in the comparison module, and the first conversion message and the second conversion message are compared in the sub-comparison module corresponding to the destination virtual host module. If the comparison result does not meet the preset consistency setting, it is determined that the chip implementation module has failed the NTB cross-host domain verification.

[0137] This embodiment can quickly and comprehensively verify the cross-host domain functionality of the NTB chip. The PCIe system model 1 can generate a variety of test messages, covering various possible cross-domain access scenarios. Combined with the efficient scheduling mechanism of the input scheduling module 2, it can perform a large number of tests on the chip in a short period of time, greatly improving the verification efficiency of the NTB cross-host domain. The design of the comparison module 5 enables the precise location of the specific link where the chip implementation module 4 has problems when the verification fails. Through detailed message comparison difference information, technicians can intuitively understand the deviation of the chip from the ideal analog conversion method during the address conversion process, which helps to quickly find errors or defects in the chip design code, provide support for chip optimization and improvement, and shorten the chip R&D cycle.

[0138] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The program can be stored in a non-volatile computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0139] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0140] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present invention, all of which fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.

Claims

1. An NTB cross-host domain verification system, characterized in that: It includes a PCIe system model, an input scheduling module, a cross-domain routing module, a chip implementation module, and a comparison module, wherein the PCIe system model is connected to the input scheduling module, the input scheduling module is connected to the cross-domain routing module and the chip implementation module, and the cross-domain routing module and the chip implementation module are connected to the comparison module; The PCIe system model is configured with several virtual host modules, each of which is connected to the input scheduling module, and the status of each virtual host module is initialized and set respectively, and a test message is generated randomly or according to a preset test rule, and is input into the input scheduling module; The input scheduling module schedules receiving different test messages, and synchronously sends each test message to the cross-domain routing module and the chip implementation module in sequence; The cross-domain routing module receives the test message sent by the input scheduling module, performs address conversion on the test message according to a preset simulation conversion method, outputs a first conversion message, and inputs the first conversion message into the sub-comparison module in the comparison module corresponding to the destination virtual host module of the first conversion message; The chip implementation module receives the test message sent by the input scheduling module, performs address conversion on the test message according to the actual design code of the NTB chip, outputs a second conversion message, and inputs the second conversion message into the sub-comparison module in the comparison module corresponding to the destination virtual host module of the second conversion message; The comparison module is preset with multiple sub-comparison modules configured based on different virtual host modules. The first conversion message and the second conversion message are compared in the sub-comparison module corresponding to the target virtual host module. If the comparison result does not meet the preset consistency setting, it is determined that the chip implementation module has not passed the NTB cross-host domain verification.

2. The NTB cross-host domain verification system according to claim 1, characterized in that: The PCIe system model performs the steps of respectively initializing and setting the status of each virtual host module, including: The PCIe system model receives global configuration parameters through the UVM command line parameter transfer mechanism; Allocate a host number and a corresponding address space to each virtual host module according to the global configuration parameters; Allocate an ID range of id_base to id_limit to each virtual host module, where id_base is the ID of the virtual host module and id_limit is the upper limit of the ID of the device connected to the virtual host module; Allocate an address domain of addr_base to addr_limit to each virtual host module, wherein addr_base to addr_limit are addresses allocated to the virtual host module and the devices connected to the virtual host module; The ID field and address field of each virtual host module are saved to the global configuration parameters to obtain updated global configuration parameters; According to the updated global configuration parameters, the IDs and addresses between different virtual host modules are mapped and configured to obtain address mapping table information; The address mapping table information is synchronously updated to the cross-domain routing module and the chip implementation module, wherein the cross-domain routing module obtains the updated address mapping table information through the table instance, and the chip implementation module obtains the updated address mapping table information through the CSR chain write table.

3. The NTB cross-host domain verification system according to claim 2, characterized in that: The PCIe system model executes the step of allocating a host number and a corresponding address space to each virtual host module according to the global configuration parameters, further comprising: A hole address space is reserved, where the hole address space is used to test conversion processing of a hole address carried in the test message.

4. The NTB cross-host domain verification system according to claim 2, characterized in that: The test message is a REQ message, and the PCIe system model performs a step of randomly generating a test message, including: The PCIe system model randomly selects an address under a virtual host module as the original address; Randomly select an address under another virtual host module as the destination address; A REQ message is generated according to the source address and the destination address.

5. The NTB cross-host domain verification system according to claim 2, characterized in that: The test message is a CPL message, and the PCIe system model performs a step of randomly generating a test message, including: The PCIe system model randomly selects an ID under a virtual host module as a request ID; Randomly select an ID under a virtual host module as a completion ID, wherein the completion ID is different from the request ID; The CPL message is generated according to the request ID and the completion ID.

6. The NTB cross-host domain verification system according to claim 1, characterized in that: The step of the input scheduling module scheduling and receiving different test messages and synchronously sending each test message to the cross-domain routing module and the chip implementation module in sequence includes: The input scheduling module schedules receiving different test messages and classifies them according to the virtual host module that sends the test messages; For test messages from the same virtual host module, different test messages are sorted according to the order in which the test messages are generated; For test messages from different virtual host modules, a preset fair scheduling strategy is used for round-robin scheduling.

7. The NTB cross-host domain verification system according to claim 1, characterized in that: The chip implementation module determines whether an idle signal is not sent to the PCIe system model for more than a preset time, wherein the idle signal is sent by the chip implementation module to the PCIe system model after completing the output of the second conversion message; If so, a stop packet sending instruction is sent to the PCIe system model, so that the PCIe system model stops sending new test messages to the chip implementation module.

8. A NTB cross-host domain verification method, characterized in that: The NTB cross-host domain verification method is applied to the input scheduling module according to any one of claims 1 to 7, comprising: Scheduling and receiving different test messages, wherein the test messages are randomly generated by the PCIe system model, the PCIe system model is configured with a plurality of virtual host modules, each virtual host module is respectively connected to the input scheduling module, and the state of each virtual host module is respectively initialized and set; Each test message is synchronously sent to the cross-domain routing module and the chip implementation module in sequence, so that the cross-domain routing module receives the test message sent by the input scheduling module, and performs address conversion on the test message according to a preset simulation conversion method, outputs a first conversion message, and inputs it into the sub-comparison module corresponding to the destination virtual host module of the first conversion message in the comparison module; and the chip implementation module receives the test message sent by the input scheduling module, and performs address conversion on the test message according to the actual design code of the NTB chip, outputs a second conversion message, and inputs it into the sub-comparison module corresponding to the destination virtual host module of the second conversion message in the comparison module; and a plurality of sub-comparison modules based on different virtual host module configurations are preset in the comparison module, and the first conversion message and the second conversion message are compared in the sub-comparison module corresponding to the destination virtual host module. If the comparison result does not meet the preset consistency setting, it is determined that the chip implementation module has failed the NTB cross-host domain verification.

9. A computer device, characterized in that: The device includes a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the NTB cross-host domain verification method according to claim 8.

10. A computer-readable storage medium, characterized in that A computer program is stored, and when the computer program is executed by a processor, the processor is caused to perform the steps of the NTB cross-host domain verification method according to claim 8.

Images