Bus protocol verification method, device, equipment, storage medium and program product

Abstract

The application provides a bus protocol verification method, device, equipment, storage medium and program product. The bus protocol verification method comprises the following steps: configuring a protocol verification program based on protocol content of a to-be-detected bus protocol and port attributes of a to-be-detected port; performing signal transmission between the protocol verification program and the to-be-detected port, and traversing transmission signals of the to-be-detected port; determining whether the transmission signals conform to first constraint content of the to-be-detected bus protocol; the first constraint content is used for verifying parameter values of the transmission signals; and determining whether the transmission signals conform to second constraint content of the to-be-detected bus protocol; the second constraint content is used for verifying relationships between different signals in the transmission signals. The application has the advantages of configurability, strong reusability, convenient maintenance and high universality.

Description

Technical Field

[0001] This application belongs to the field of computer technology, specifically relating to a bus protocol verification method, apparatus, device, storage medium, and program product. Background Technology

[0002] Bus protocol verification is an essential step in chip design. However, bus protocol verification is a labor-intensive and inefficient process, while limited R&D cycles and human resources place high demands on both verification efficiency and quality. Therefore, there is an urgent need for a bus protocol verification method that balances accuracy and efficiency. Summary of the Invention

[0003] This application proposes a bus protocol verification method, apparatus, device, storage medium, and program product, which are configurable, highly reusable, easy to maintain, and highly versatile.

[0004] The first aspect of this application proposes a bus protocol verification method, including:

[0005] Configure a protocol verification program based on the protocol content of the bus protocol to be tested and the port attributes of the port to be tested;

[0006] Signal transmission is performed between the protocol verification program and the port to be detected, and the transmission signals of the port to be detected are traversed.

[0007] Determine whether the transmitted signal conforms to the first constraint of the bus protocol to be detected; the first constraint is used to verify the parameter values ​​of the transmitted signal.

[0008] Determine whether the transmitted signal conforms to the second constraint of the bus protocol to be detected, the second constraint being used to verify the relationship between different signals in the transmitted signal.

[0009] In some embodiments of this application, configuring the protocol verification program based on the protocol content of the bus protocol to be detected and the port attributes of the port to be detected includes:

[0010] Based on the port attributes of the port to be detected, configure the connection mode between the protocol verification program and the port to be detected;

[0011] Based on the protocol content of the bus protocol to be tested and the connection mode, the attribute parameters of the protocol verification program are configured. The attribute parameters are used to constrain the signal transmission between the protocol verification program and the port to be tested.

[0012] In some embodiments of this application, determining whether the transmitted signal conforms to the second constraint of the bus protocol to be detected includes:

[0013] Based on the second constraint, a first verification information related to the transmission channel is extracted from the transmission signal using a preset reference model.

[0014] Determine whether the first information to be verified conforms to the second constraint of the bus protocol to be detected;

[0015] Determine whether the second information to be verified in the transmitted signal, excluding the first information to be verified, conforms to the second constraint.

[0016] In some embodiments of this application, the step of extracting first verification information related to the transmission channel from the transmission signal using a preset reference model based on the second constraint includes:

[0017] Using a preset reference model, information related to the transmission channel is filtered out from the transmitted signal;

[0018] Based on the second constraint and the filtered information related to the transmission channel, the first information to be verified is obtained.

[0019] In some embodiments of this application, obtaining the first information to be verified based on the second constraint content and the filtered information related to the transmission channel includes:

[0020] Based on the filtered information related to the transmission channel, the first association relationship between requests of the same type and the second association relationship between requests of different types are determined respectively;

[0021] Based on the first association, the second association, and the second constraint content, the first information to be verified is obtained.

[0022] In some embodiments of this application, obtaining the first information to be verified based on the first association relationship, the second association relationship, and the second constraint content includes at least one of the following steps:

[0023] If the initiation time of a burst transmission request on the read channel is different from the initiation time of a burst transmission request on the write channel, record the request address of the burst transmission request on the read channel and the request address of the burst transmission request on the write channel.

[0024] Record the type of each advance transmission request with the same request identifier;

[0025] Record the response information on the read channel, as well as the read request information corresponding to the response information;

[0026] If the request issued by the address write channel precedes the data write channel, record whether the data identifier of the data write channel conforms to the relevant provisions of the bus protocol to be detected;

[0027] After the address write channel sends a request, it records whether a corresponding read channel needs to send a response.

[0028] In some embodiments of this application, determining whether the second information to be verified in the transmitted signal, excluding the first information to be verified, conforms to the second constraint includes at least one of the following steps:

[0029] If the initiated request requires at least two clock cycles to transmit, determine whether the next address read request will be transmitted in a later clock cycle;

[0030] In the event that a synchronization command request has been transmitted ahead of schedule, is a new synchronization command request initiated?

[0031] When the request type is an exclusive access request, is the channel signal of the write request consistent with the channel signal of the read request?

[0032] If a request sent by the data write channel precedes a request sent by the address write channel, determine whether the request sent by the address write channel matches the listening type corresponding to the request sent by the data write channel.

[0033] For a request to monitor a transaction, determine whether the corresponding response information conforms to the specific constraints in the bus protocol to be detected.

[0034] In some embodiments of this application, determining whether the transmitted signal conforms to the first constraint of the bus protocol to be detected includes:

[0035] Determine the request information contained in the transmitted signal;

[0036] Within the clock cycle in which the request information is initiated, it is determined whether the request information conforms to the first constraint of the bus protocol to be detected.

[0037] A second aspect of this application provides a bus protocol verification apparatus, comprising:

[0038] The configuration module is used to configure the protocol verification program based on the protocol content of the bus protocol to be detected and the port attributes of the port to be detected.

[0039] An interface module is used to transmit signals between the protocol verification program and the port to be detected, and to traverse the transmission signals of the port to be detected.

[0040] The first detection module is used to determine whether the transmitted signal conforms to the first constraint content of the bus protocol to be detected; the first constraint content is used to verify the parameter values ​​of the transmitted signal.

[0041] The second detection module is used to determine whether the transmitted signal conforms to the second constraint content of the bus protocol to be detected, and the second constraint content is used to verify the relationship between different signals in the transmitted signal.

[0042] An embodiment of the third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the method described in the first aspect above.

[0043] An embodiment of the fourth aspect of this application provides a computer program product including a computer program that is executed by a processor to implement the method described in the first aspect.

[0044] An embodiment of the fifth aspect of this application provides a computer program product including a computer program that is executed by a processor to implement the method described in the first aspect.

[0045] The technical solutions provided in this application embodiment have at least the following technical effects or advantages:

[0046] In the bus protocol verification method provided in this application embodiment, a protocol verification program is first configured based on the bus protocol to be detected and the port to be detected. Then, through the configured protocol verification program, the transmission signals of the port to be detected are traversed, and the parameter values ​​of the transmission signals and the relationships between different signals in the transmission signals can be verified to determine whether the transmission signals of the port to be detected conform to the bus protocol to be detected. Thus, configuring the protocol verification program according to the bus protocol to be detected and the port to be detected has strong configurability, enabling the method to be applied to the verification of multiple bus protocols for various types of ports to be detected, thus enhancing reusability. Furthermore, the protocol verification program can be used to verify multiple bus protocols for multiple ports to be detected. When errors occur during debugging, only the corresponding attributes at the error location need to be modified, making the maintenance of this bus protocol verification method simpler and more convenient. In addition, this method can be used for both formal verification and simulation verification of bus protocols, effectively improving its versatility.

[0047] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0048] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings.

[0049] In the attached diagram:

[0050] Figure 1 This application shows a schematic diagram of the framework structure of a bus protocol verification device provided in one embodiment. Figure 1 ;

[0051] Figure 2 A flowchart illustrating a bus protocol verification method provided in an embodiment of this application is shown;

[0052] Figure 3 This application shows a schematic diagram of the framework structure of a bus protocol verification device provided in one embodiment. Figure 2 ;

[0053] Figure 4 A schematic diagram of the specific process of step S4 in one embodiment of this application is shown;

[0054] Figure 5 This application shows a schematic diagram of the framework structure of a bus protocol verification device provided in one embodiment. Figure 3 ;

[0055] Figure 6 This illustration shows a schematic diagram of the structure of an electronic device according to an embodiment of this application;

[0056] Figure 7 A schematic diagram of a storage medium provided in one embodiment of this application is shown. Detailed Implementation

[0057] Exemplary embodiments of this application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of this application and to fully convey the scope of this application to those skilled in the art.

[0058] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0059] The following section explains some of the technical terms used in the embodiments of this application.

[0060] In this embodiment, the bus can be understood as a common channel for transmitting information between the CPU (processor, short for Central Processing Unit), memory, input devices and output devices in a computer system. Various components of the host are connected through the bus, and external devices are connected to the bus through corresponding interface circuits.

[0061] A bus protocol can be understood as a specification for transmitting data via a bus. The content of a bus protocol defines the relationships that need to be satisfied between interface devices, components, signals, buses, and channels. In other words, to achieve signal transmission, the host, interface devices, components, and bus channels must each meet various necessary conditions required by the bus protocol. Different bus protocols can be designed based on different buses. Specifically, bus protocols can include, but are not limited to, the AXI (Advanced eXtensible Interface) protocol and the ACE (AXI Coherency Extensions) protocol.

[0062] Bus protocol verification refers to the process of checking whether the signal transmission between protocol entities meets the characteristics or conditions specified in the protocol, based on the protocol content. Bus protocol verification is an essential step in chip design.

[0063] Bus protocol verification methods include simulation verification and formal verification. Simulation verification is performed within a program-based logic simulation environment, and functional verification of the chip is largely achieved through simulation verification during chip verification. However, when there are protocol request forwarding modules for numerous bus interfaces, simulation verification requires writing similar bus protocol constraints and verification processes for each bus interface. This not only increases the workload but also significantly slows down logic simulation, resulting in a substantial reduction in verification speed. Furthermore, simulation verification is used for specific bus interfaces, leading to low reusability. Multiple similar codebases may also exist, increasing the difficulty for the computer to read the files. Additionally, when errors occur in the code, the large number of files may necessitate fixing the same problem in multiple places.

[0064] Formal verification primarily checks whether a design program logically satisfies certain properties or whether different design programs are logically equivalent. However, most current formal verification applications only verify static behavior and cannot verify dynamic behavior. Furthermore, as the design program becomes more complex, the content that needs to be verified increases dramatically, resulting in a significant workload for verification.

[0065] This embodiment can perform bus protocol verification based on the bus protocol verification VIP (verification intellectual property). The bus protocol verification VIP can be understood as a hardware module that can be integrated into the chip design verification environment to verify whether the bus protocol in the chip conforms to the specification.

[0066] The embodiments of this application are described in detail below.

[0067] To address the shortcomings of existing bus protocol verification methods, this application proposes a new method. This method first configures a protocol verification program based on the bus protocol and port to be tested. Then, using this configured program, it iterates through the transmission signals of the port to be tested, verifying the parameter values ​​of the transmission signals and the relationships between different signals to determine whether the output signal of the port conforms to the bus protocol. This method, which configures the protocol verification program according to the bus protocol and port to be tested, has strong configurability, enabling it to be applied to multiple bus protocol verifications for various ports, thus enhancing reusability. Furthermore, a single program file can be used to verify multiple bus protocols for multiple ports, significantly reducing the verification workload. When errors occur during debugging, only the corresponding attributes at the error location need to be modified, making the bus protocol verification method easier and more convenient to maintain. In addition, this method can be used for both formal verification and simulation verification of bus protocols, effectively improving its versatility.

[0068] It should be noted that the bus protocol to be tested in this embodiment may include, but is not limited to, the AXI protocol and ACE protocol mentioned above, as long as the protocol verification program can be configured according to the protocol to be tested and the port to be tested.

[0069] This method is based on a configurable protocol verification program, which can also be understood as a protocol verification device or the aforementioned bus protocol verification VIP. The process of configuring the protocol verification program can be understood as the instantiation and configuration process of the protocol verification program. The protocol verification program can connect to the port to be tested and send data to or receive data sent by the port to be tested, in order to help verify whether the data sent or received by the port to be tested conforms to the relevant constraints of the bus protocol to be tested.

[0070] Please refer to Figure 1 This is a schematic diagram of the framework structure of the bus protocol verification device provided in the embodiments of this application, as shown below. Figure 1As shown, the bus protocol verification device may include a configuration module, an interface module, a first detection module, and a second detection module. The configuration module is used to instantiate and configure the bus protocol verification device; the interface module is used to connect to the port to be tested and transmit signals, and traverse the transmitted signals of the port to be tested; the first detection module is used to determine whether the parameter values ​​of the transmitted signals conform to the content of the bus protocol to be tested; and the second detection module is used to determine whether the relationship between different signals in the transmitted signals conforms to the content of the bus protocol to be tested. Thus, the bus protocol verification method can be implemented through the bus protocol verification device, which not only has configurability and strong reusability, but also significantly reduces the verification workload, makes maintenance more convenient, and has higher versatility.

[0071] Please see below. Figure 2 This is a flowchart illustrating the bus protocol verification method provided in an embodiment of this application. Figure 2 As shown, the method may include the following steps:

[0072] Step S1: Configure the protocol verification program based on the protocol content of the bus protocol to be detected and the port attributes of the port to be detected.

[0073] In this embodiment, port attributes may include, but are not limited to, identity attributes, identification attributes, and transmission channel attributes. The identity attribute can be understood as the identity attribute of the port to be detected when transmitting signals. For example, it may be a master, a master device or master disk that sends a request to the bus protocol verification device; or a slave, a slave device or slave disk that receives a request sent by the bus protocol verification device.

[0074] Identification attributes may include, but are not limited to, the transmission task sequence number and signal bit width when the port under test transmits signals. The master device can indicate the execution order by setting the transmission task sequence number. Specifically, transmission tasks with the same sequence number from the same master device can only be executed sequentially; transmission tasks with different sequence numbers from the same master device, or transmission tasks from different master devices, do not have an execution order requirement. That is, the role of identification attributes is to specify the order of certain special transmission tasks. When there is a clear order, the same task identifier can be used.

[0075] Signal transmission based on the AXI or ACE protocol can be divided into the R channel (Read data channel), W channel (Write data channel), AR channel (Read Address channel), AW channel (Write Address channel), and B channel (Write Response channel) from the perspective of data and address control.

[0076] The ACE protocol also includes AC, CR, and CD channels. The AC channel is the input channel of the cache master, which provides the address and related control information for the listening transaction. The CR channel is the output channel of the cache master, providing a response to the listening transaction; the listening response indicates whether the data transmission associated with the CD channel is expected. The CD channel is an optional output channel used to transmit the listened data from the master. Typically, transmission is performed through the CD channel when the monitored master has a copy of the data available for return. These transmission channel attributes can be understood as certain characteristics exhibited by the channel-related information when the port under test transmits signals, such as the maximum number of supported barriers (similar to semaphores and condition variables, used to control the execution of parallel programs), the number of outstanding (advanced) transmissions, and the number of transmissions initiated by the W channel before the AW channel.

[0077] In some implementations, step S1 may include the following processing: configuring the connection mode between the protocol verification program and the port to be detected based on the port attributes of the port to be detected; configuring the attribute parameters of the protocol verification program based on the protocol content and connection mode of the bus protocol to be detected. Thus, by configuring the protocol verification program according to the port attributes of the port to be detected and the protocol content of the bus protocol to be detected, the configured protocol verification program can be adapted to the port to be detected, and can traverse the transmission signals of the port to be detected to obtain sufficient detection information.

[0078] The connection mode between the protocol verification program and the port to be tested can be configured according to the identity attributes of the port to be tested. Specifically, if the port to be tested is a master device, the bus protocol verification device is a slave device; if the port to be tested is a slave device, the bus protocol verification device is a master device. Regardless of whether the port to be tested is a master device or a slave device, after the bus protocol verification device connects to the port to be tested and obtains sufficient transmission signals, when performing protocol verification on the transmission signals of the port to be tested, the bus protocol verification device can act as a checker (comparator) to verify whether the transmission signals conform to the relevant constraints of the bus protocol to be tested, thereby realizing its protocol verification function.

[0079] The attribute parameters of the protocol verification program here are used to constrain the signal transmission between the protocol verification program and the port to be tested. Specifically, they can be set according to the port attributes of the port to be tested, and must comply with the relevant constraints of the bus protocol to be tested. This embodiment does not impose specific limitations on this. For example, the attribute parameters of the protocol verification program may include, but are not limited to, the transmission task sequence number and signal bit width of the bus protocol verification device, the maximum number of supported barriers, the number of outstanding barriers, and the number of transmissions initiated by channel W before channel AW.

[0080] Step S2: Signal transmission is performed between the protocol verification program and the port to be tested, and the transmission signals of the port to be tested are traversed.

[0081] The signal transmission between the protocol verification program and the port under test can be based on the connection mode between the bus protocol verification device and the port under test. The port under test can send a request to the bus protocol verification device, and the bus protocol verification device can send a response to the port under test; conversely, the port under test can also receive a request from the bus protocol verification device and send a response to the bus protocol verification device. Traversing the transmitted signals of the port under test can be understood as reading, checking, and processing all input and output signals of the port under test.

[0082] Step S3: Determine whether the transmitted signal conforms to the first constraint of the bus protocol to be tested.

[0083] The first constraint is used to verify the parameter values ​​of the transmitted signal. The verification of the parameter values ​​can be understood as static behavior verification, which can be directly judged based on the request information sent by the port to be tested.

[0084] Specifically, step S3 may include the following processing: determining the request information contained in the transmission signal; and determining whether the request information conforms to the first constraint of the bus protocol to be detected within the clock cycle in which the request information is initiated.

[0085] The request information can be sent by the port to be tested or by the bus protocol verification device. This embodiment does not specifically limit the specific type and content of the request information, as long as it is request information transmitted between the port to be tested and the bus protocol verification device. The clock period for initiating the request information can also be called the request initiation clock. During this time period, the parameter values ​​of the request information usually do not change, allowing for accurate verification of the parameter values.

[0086] In practical applications, since the parameter values ​​of the transmitted signal are often obtained from the request information, the request information contained in the transmitted signal can be obtained first, and the verification can be performed in a timely manner within the clock cycle initiating the request information to determine whether the parameter values ​​of the request information conform to the relevant constraints of the detection protocol.

[0087] Specifically, the step of determining whether the transmitted signal conforms to the first constraint of the bus protocol to be tested can be performed by the first detection module of the bus protocol verification device, and may include at least one of the following verification contents:

[0088] 1) Check whether the signal value in the request information conforms to the relevant constraints of the bus protocol under test. It can check whether the signal value in the request information is a reserved value in the bus protocol under test, such as whether the reserved value of burst transmission is 2'b11 specified in the bus protocol under test.

[0089] 2) When the current request type is axsnoop (a request sent from the listening address channel), determine whether the parameter values ​​on other channels conflict with the parameter values ​​on the listening address channel of the current transmission request. For example, when axsnoop is not 0, the axbar signal (a signal on the address channel) cannot be 1. The axbar signal can be a low bit

[01] or a high bit

[10] to distinguish between memory barrier and sync barrier. When axsnoop is not 0, axbar cannot be a high bit

[10] , that is, it cannot be a sync barrier.

[0090] 3) If the current request type is a wrap transfer request, determine whether the length of the wrap transfer request complies with the relevant constraints of the bus protocol under test. A wrap transfer is called a wrap transfer when the address reaches a boundary and then jumps back to the lowest point to start again. The AXI and ACE protocols stipulate that the length of the wrap transfer request can only be 2, 4, 8, or 16, and the starting address of the transfer needs to be aligned with the size of each wrap transfer.

[0091] 4) If the current request type is a read request or a write request, determine whether the address of the requested transmission conforms to the relevant constraints of the bus protocol under test. For example, the AXI and ACE protocols stipulate that the address space is 4Kb when the slave device transmits signals, so the transmission address of the read request or write request during verification cannot cross 4Kb.

[0092] 5) If the current request type is an exclusive access request, determine whether the transfer size and address comply with the relevant constraints of the bus protocol under test. For example, the AXI and ACE protocols specify that the transfer size for exclusive access requests is 1 / 2 / 4 / 8 / 16 / 32 / 64 / 128 bytes, and the address is aligned according to the transfer size with a bit width of less than 16.

[0093] 6) If the current request type is a virtual message transmission type, determine whether the information transmitted by the address read channel conflicts with the message type. For example, the AXI and ACE protocols can specify the message type and transmission address of the transmitted information, so the message type recorded in the transmission signal cannot conflict with the message type of the current request.

[0094] 7) Determine if the currently requesting channel has established a communication connection. Based on the AXI and ACE protocols, each independent channel's signals include a data signal, a valid signal (sender high), and a ready signal (receiver high), used to provide a two-way handshake mechanism. The information source uses the valid signal to indicate when a valid address is available and whether data or control information is available on the channel. The destination uses the ready signal to indicate when information can be received. This embodiment can detect whether the channel's data signal remains stable when the channel's valid signal is high and the ready signal is low, to verify whether the currently requesting channel has established a communication connection.

[0095] For the above verification content, if all verifications pass, it can be determined that the port under test conforms to the first constraint of the bus protocol under test. If at least one verification fails, it indicates that the port under test does not conform to the first constraint of the bus protocol under test. The relevant attributes of the port under test can be adjusted, and then the transmission signals of the port under test can be iterated again to re-verify whether the transmission signals conform to the first constraint of the bus protocol under test, until the acquired transmission signals conform to the first constraint of the bus protocol under test. Alternatively, only the relevant information that failed the previous verification can be acquired for re-verification until the acquired information conforms to the first constraint of the bus protocol under test. In this way, when debugging errors occur, the correction can be completed by modifying the attribute corresponding to the error location, thereby further improving the verification efficiency of this bus protocol verification method.

[0096] Step S4: Determine whether the transmitted signal conforms to the second constraint of the bus protocol to be detected.

[0097] The second constraint is used to verify the relationship between different signals in the transmitted signal. These different signals can include signals of the same type sent at different times, or signals of different types sent in parallel, as long as they are not completely identical. The relationship between different signals can include the relationship between request and response information, i.e., whether the transmitted signal conforms to the second constraint of the bus protocol under test, and can include dynamic behavior verification.

[0098] In some implementations, such as Figure 3 As shown, the second detection module may include a preset reference model and a detection unit, then as follows: Figure 4As shown, step S4 above may include the following processing: based on the second constraint content, extracting the first verification information related to the transmission channel from the transmission signal using a preset reference model; determining, through the detection unit, whether the first verification information conforms to the second constraint content of the bus protocol to be detected, and determining whether the second verification information in the transmission signal other than the first verification information conforms to the second constraint content.

[0099] The preset reference model, based on the second constraint, extracts information related to the transmission channel from the input data. This extracted information can be referred to as the first information to be verified, while the request information for which no information extraction has been performed is referred to as the second information to be verified. The preset reference model can specify the feature fields that need to be extracted based on the second constraint of the bus protocol under test, in order to extract the first information to be verified related to the transmission channel from the transmitted signal.

[0100] Information related to the transmission channel may include, but is not limited to: AR request information, AW request information, W request information, and AC request information. Specifically, AR request information may include information related to the AR channel from exclusive access request information and barrier request information; AW request information may include information related to the AW channel from barrier request information, as well as information about the AW channel when the AW channel request precedes the W channel; W request information may include information about the W channel when the W channel request precedes the AW channel; and AC request information may include information from the AC channel.

[0101] In practical applications, the amount of signal transmitted through ports is relatively large, but not all information needs to be verified. To reduce the verification workload, the information that needs to be verified can be extracted into fields. During verification, the extracted field information can be directly compared to see if it conforms to the relevant provisions of the bus protocol under test. For the AXI and ACE protocols, most of the information that needs to be verified is related to the transmission channel. Therefore, in this embodiment, a first verification information related to the transmission channel can be extracted from the transmitted signal using a preset reference model. Then, the detection unit of the second detection module can be used to compare whether the first verification information conforms to the relevant provisions of the bus protocol under test. In this way, the workload of bus protocol verification can be significantly reduced.

[0102] In some implementations, the step of extracting the first information to be verified related to the transmission channel from the transmission signal based on the second constraint content and using a preset reference model may include the following processing: using the preset reference model to filter out information related to the transmission channel from the transmission signal; and obtaining the first information to be verified based on the second constraint content and the filtered information related to the transmission channel.

[0103] In this embodiment, the amount of transmitted signal at the port to be tested may be relatively large, and there may be a lot of information related to the transmission channel in the transmitted signal. If each piece of information is traversed sequentially during verification, the workload will be very large and the efficiency will be relatively low. This embodiment uses a preset reference model to first filter out the information related to the transmission channel in the transmitted signal. Then, based on the second constraint content, the filtered information related to the transmission channel is reorganized. Fields related to the second constraint content can be extracted to obtain the first information to be verified that can be judged by a comparator. This allows for a quick determination of whether each piece of information conforms to the relevant constraints of the bus protocol to be tested, thereby improving the overall verification efficiency.

[0104] Furthermore, the step of obtaining the first information to be verified based on the second constraint content and the filtered information related to the transmission channel may include the following steps: determining the first association relationship between requests of the same type and the second association relationship between requests of different types based on the filtered information related to the transmission channel; obtaining the first information to be verified based on the first association relationship, the second association relationship, and the second constraint content.

[0105] The first and second association relationships can be, but are not limited to, the relationship between the time the two requests are sent, the relationship between the transmission channels used by the two requests, and the relationship between the sent request and response information.

[0106] In this embodiment, the second constraint content of the bus protocol is used to verify the relationship between different signals in the transmission signal. Therefore, the information related to the filtered transmission channel can be processed to determine the groups of transmission signals that are related to each other. Then, based on the specific provisions in the second constraint content, the fields or features related to the second constraint content in the groups of transmission signals that are related to each other can be determined to form the first verification information that facilitates protocol verification.

[0107] Specifically, the steps for obtaining the first information to be verified based on the first association relationship, the second association relationship, and the second constraint content may include at least one of the following:

[0108] 1) When the initiation time of a burst transfer request on the read channel differs from that on the write channel, record the request address of both the read and write channels. For example, when the barrier requests on the read and write channels are not initiated simultaneously, the axid (address channel identifier) ​​of the first initiated barrier request can be recorded. This is used to check whether the channel address of another channel that initiates a barrier request is the previously recorded axid. If it is, it indicates that the information to be verified conforms to the relevant constraints of the bus protocol under test; if the channel address is not the previously recorded axid, it indicates that the information to be verified does not conform to the relevant constraints of the bus protocol under test.

[0109] 2) Record the types of advance requests with the same request identifier. The request identifier can be understood as the identifier in the identifier attribute mentioned above. In the AXI and ACE protocols, theoretically, different advance requests cannot have the same request identifier, but when there is a clear order, the same request identifier can be used. For example, a barrier request and a virtual request can have the same request identifier, where a virtual request can be understood as a request sent or received by a virtual machine. With the same request identifier, the following advance requests are not allowed: a barrier request advancing a non-barrier request, a virtual request advancing a non-virtual request, etc.

[0110] 3) Record the response information on the read channel, as well as the corresponding read request information. In the AXI and ACE protocols, specific rules can be defined for read requests and their response information. These rules can be used for verification during bus protocol validation. For example, when the read channel returns a response signal, the number of returns should match the corresponding read request. Specifically, for a transmission signal where arsnoop is 1, the number of returns is 1. For other requests, the number of returns should match the arlen (burst transmission length) signal value in the request, where arlen indicates the number of data transmissions contained in a single burst. The returned response signal may include multiple clock cycles, meaning that if the transmission requires multiple clock cycles to complete, and if it corresponds to a virtual request, the return value for the second clock cycle must be the same as the return value for the first clock cycle.

[0111] For request and response information on the read channel, the PassDirty and IsShared signals are also involved. The PassDirty signal indicates whether the master device is writing data to main memory. If the PassDirty signal is 1, it means the master device needs to write data to main memory initially, and the current cache line should be in a written or modified (Dirty state) state. If the PassDirty signal is 0, it means the master device does not need to write data to main memory initially, and the current cache line can be in an unwritten or unmodified state. The IsShared signal indicates whether the master device's cache line is in a shared state. If the IsShared signal is 1, it means the current cache line must be in a shared state; if the IsShared signal is 0, it means the current cache line may not be in a shared state. The PassDirty and IsShared signals in certain types of read requests and their response information can be specified in the AXI and ACE protocols. For example, for some requests, it can be required that the returned PassDirty and IsShared signals remain unchanged, and the return value not be mixed with the OKAY and EXOKAY signals; for non-exclusive access requests, the EXOKAY signal cannot be returned. The OKAY signal indicates that the transmission of requests other than exclusive access requests has been completed; the EXOKAY signal indicates that the transmission of exclusive access requests has been completed, and if it fails, OKAY is returned.

[0112] 4) When a request from the address write channel precedes that from the data write channel, record whether the data identifier of the data write channel conforms to the relevant provisions of the bus protocol under test. The data identifier (wstrb) of the data write channel, also known as the valid identifier, indicates the address write channel corresponding to the signal transmitted by the data write channel, and the maximum number of bits of data transmitted in a specified time unit. In the AXI and ACE protocols, the data write channel, its corresponding address write channel, and the maximum number of bits of data transmitted in a specified time unit can be specified. During bus protocol verification, verification can be performed according to these relevant provisions.

[0113] 5) After the address write channel sends a request, record whether a response from the corresponding read channel is required. In the AXI and ACE protocols, the transmission signals and their response signals on the address write channel can be specified. For example, for the transmission signals on the address write channel, if the address write channel request needs to wait for the corresponding data write channel request to complete, the return value (b bresp) of the response signal can be 1; if the address write channel request does not need to wait for the corresponding data write channel request to complete, the return value (b bresp) of the response signal can be 0.

[0114] After obtaining the aforementioned first information to be verified, to determine whether the first information to be verified conforms to the second constraint, it is possible to directly compare whether each recorded item of the first information to be verified conforms to the relevant provisions of the bus protocol to be tested. Alternatively, the second constraint can be preloaded into a preset reference model according to the recording format of the first information to be verified. After obtaining the aforementioned first information to be verified, each item of the first information to be verified can be compared one by one for rapid protocol verification. The specific content corresponding to the obtained first information to be verified may include at least one of the following verification contents:

[0115] 1) If the initiation time of a burst transmission request on the read channel is different from the initiation time of a burst transmission request on the write channel, record the request address of the burst transmission request on the read channel and the request address of the burst transmission request on the write channel.

[0116] 2) Record the type of each advance transmission request with the same request identifier;

[0117] 3) Record the response information on the read channel, as well as the corresponding read request information;

[0118] 4) If the request issued by the address write channel precedes the data write channel, record whether the data identifier of the data write channel conforms to the relevant provisions of the bus protocol to be tested;

[0119] 5) After the address write channel sends a request, record whether the corresponding read channel needs to send a response message.

[0120] In addition to verifying whether the first information to be verified conforms to the relevant provisions of the bus protocol to be tested, this embodiment also verifies whether the second information to be verified in the transmitted signal, other than the first information to be verified, conforms to the relevant provisions of the bus protocol to be tested. Specifically, the corresponding feature fields can be extracted based on the verification points of the bus protocol to be tested, and then the extracted feature fields can be compared with the relevant provisions of the bus protocol to be tested by the second detection module of the bus protocol verification device.

[0121] Specifically, the step of determining whether the second information to be verified in the transmitted signal, excluding the first information to be verified, conforms to the second constraint may further include at least one of the following verification criteria:

[0122] 1) If an initiated request requires at least two clock cycles to complete, determine whether the next address read request should be a second clock cycle transmission. In the AXI and ACE protocols, this rule can be applied to requests requiring multiple clock cycles to ensure signal transmission completion. This can be verified during bus protocol validation. For example, if the returned response signal involves multiple clock cycles, and the initiated transmission requires a second clock cycle to complete the request, the next initiated ar request should also require this second clock cycle transmission.

[0123] 2) In the case of a synchronization command request leading transmission, are new synchronization command requests initiated? In the AXI and ACE protocols, leading transmission can also be specified; for example, when a sync request leads transmission, no new sync requests can be initiated. This can be verified during bus protocol verification.

[0124] 3) In the case of an exclusive access request, is the channel signal of the write request consistent with the channel signal of the read request? In the AXI and ACE protocols, the transmission of exclusive access requests can be specified; for example, the channel signal of an exclusive access write request must be consistent with the corresponding read request. Therefore, during bus protocol verification, the consistency between the exclusive access write request and the corresponding read request channel signal can be verified accordingly.

[0125] 4) When a request from the data write channel precedes a request from the address write channel, determine whether the request from the address write channel matches the snoop type corresponding to the request from the data write channel. In the ACE protocol, snooping channels can also be specified. For example, if a request from channel w precedes a request from channel aw, the delayed aw request must match the snoop type corresponding to the initiated w channel request. Therefore, during bus protocol verification, it can be verified whether the delayed aw request matches the snoop type corresponding to the initiated w channel request.

[0126] 5) For requests from listening transactions, determine whether the corresponding response information conforms to the specific constraints in the bus protocol under test. The ACE protocol may also include specifications for response signals to the listening channels. Specifically, the listening channels include, but are not limited to, the ac channel, cr channel, and cd channel. The ac channel is the input to the cache master device, which can provide the address and related control information for the listening transaction. The cr channel returns the response signal as the output of the cache master device, providing a response to the listening transaction; each listening transaction has its own associated response signal. The cd channel is an optional output channel used to transmit the listening data from the master device. Therefore, during bus protocol verification, the relevant specifications for the listening channels can be verified.

[0127] For example, when the CR channel returns a response signal, the return value of the CR channel should conform to the allowed value of the corresponding AC request (the request for AC channel transmission). When the CD channel returns a response signal, the ACE protocol can specify the number of data returns; and after all AC requests have received response signals from the CR channel, the number of times the CD channel returns response signals can be consistent with the number of data transmissions in the response signals returned by the CR channel. Therefore, during bus protocol verification, it can be verified whether the return value of the CR channel conforms to the allowed value of the corresponding AC request, the number of times the CD channel returns response signals, and whether the number of times the CD channel returns response signals is consistent with the number of times the CR channel returns response signals.

[0128] In other implementations, such as Figure 5 As shown, the bus protocol verification device may further include a channel information buffer, specifically, but not limited to, a FIFO (First In First Out) data buffer. Before obtaining the first information to be verified, the bus protocol verification method may further include the following processing: buffering the information related to the transmission channel in the transmitted signal according to the first-in-first-out rule. This embodiment can also set the bit width (e.g., 8 bits) and depth of the FIFO to effectively buffer the amount of data according to the transmitted signal. The depth of the FIFO, that is, how many bits of data of a specified width can be stored, can be, for example, 256 words. After such setting, the capacity of the channel information FIFO is 256 8-bit bytes.

[0129] The bus protocol verification method provided in this embodiment first configures a protocol verification program based on the bus protocol to be detected and the port to be detected. Then, through the configured protocol verification program, it traverses the transmission signals of the port to be detected and verifies the parameter values ​​of the transmission signals and the relationships between different signals in the transmission signals to determine whether the signal output by the port to be detected conforms to the bus protocol to be detected. Thus, configuring the protocol verification program according to the bus protocol to be detected and the port to be detected has strong configurability, enabling this method to be applied to the verification of multiple bus protocols for various types of ports to be detected, thus enhancing its reusability. Furthermore, multiple bus protocol verifications for multiple ports to be detected can be achieved with a single program file. When errors occur during debugging, only the corresponding attributes need to be modified at the location of the error, making the bus protocol verification method simpler and more convenient to maintain. In addition, this method can be used for both formal verification and simulation verification of bus protocols, effectively improving its versatility.

[0130] Based on the same concept as the aforementioned bus protocol verification method, this embodiment also provides a bus protocol verification device, which is used to implement the bus protocol verification method, such as... Figure 1As shown, the bus protocol verification device may include:

[0131] The configuration module is used to configure the protocol verification program based on the protocol content of the bus protocol to be detected and the port attributes of the port to be detected.

[0132] The interface module is used to transmit signals between the protocol verification program and the port to be tested, and to traverse the transmission signals of the port to be tested.

[0133] The first detection module is used to determine whether the transmitted signal conforms to the first constraint content of the bus protocol to be tested; the first constraint content is used to verify the parameter values ​​of the transmitted signal.

[0134] The second detection module is used to determine whether the transmitted signal conforms to the second constraint content of the bus protocol to be tested. The second constraint content is used to verify the relationship between different signals in the transmitted signal.

[0135] The bus protocol verification device provided in this application embodiment is based on the same inventive concept as the bus protocol verification method described above, and has at least the same beneficial effects. Furthermore, the various embodiments of the bus protocol verification method are also applicable to this bus protocol verification device, and will not be described again in this embodiment.

[0136] This application also provides an electronic device for performing the bus protocol verification method described above. Please refer to... Figure 6 This illustrates a schematic diagram of an electronic device provided by some embodiments of this application. For example... Figure 6 As shown, the electronic device 4 includes: a processor 400, a memory 401, a bus 402 and a communication interface 403. The processor 400, the communication interface 403 and the memory 401 are connected through the bus 402. The memory 401 stores a computer program that can run on the processor 400. When the processor 400 runs the computer program, it executes the bus protocol verification method provided in any of the foregoing embodiments of this application.

[0137] The memory 401 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this device network element and at least one other network element is achieved through at least one communication interface 403 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0138] Bus 402 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. Memory 401 is used to store programs. After receiving execution instructions, processor 400 executes the program. The bus protocol verification method disclosed in any of the aforementioned embodiments of this application can be applied to processor 400, or implemented by processor 400.

[0139] The processor 400 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 400 or by instructions in software form. The processor 400 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 401. The processor 400 reads the information in memory 401 and, in conjunction with its hardware, completes the steps of the above method.

[0140] The electronic device provided in this application embodiment and the bus protocol verification method provided in this application embodiment are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0141] This application also provides a computer-readable storage medium corresponding to the bus protocol verification method provided in the foregoing embodiments. Please refer to... Figure 7 The computer-readable storage medium shown is an optical disc 50, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it executes the bus protocol verification method provided in any of the aforementioned embodiments.

[0142] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0143] This application also provides a computer program product, including a computer program that is executed by a processor to implement the bus protocol verification method of any of the above embodiments.

[0144] The computer-readable storage medium and computer program product provided in the above embodiments of this application are based on the same inventive concept as the bus protocol verification method provided in the embodiments of this application, and have the same beneficial effects as the methods adopted, run or implemented by the application programs stored therein.

[0145] This application embodiment also provides a computer program product corresponding to the bus protocol verification method provided in the foregoing embodiments, including a computer program that is executed by a processor to implement the bus protocol verification method described above.

[0146] The computer program product provided in this application embodiment is based on the same inventive concept as the bus protocol verification method provided in this application embodiment, and has the same beneficial effects as the method implemented by the computer program being executed by the processor.

[0147] It should be noted that:

[0148] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known structures and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0149] Similarly, it should be understood that, for the sake of brevity and to aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together in a single embodiment, figure, or description thereof. However, this disclosure should not be construed as reflecting a schematic diagram in which the claimed application requires more features than expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0150] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0151] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A bus protocol verification method, characterized in that, include: Configure a protocol verification program based on the protocol content of the bus protocol to be tested and the port attributes of the port to be tested; Signal transmission is performed between the protocol verification program and the port to be detected, and the transmission signals of the port to be detected are traversed. Determine whether the transmitted signal conforms to the first constraint of the bus protocol to be detected; The first constraint is used to verify the parameter values ​​of the transmitted signal; Determining whether the transmitted signal conforms to the second constraint of the bus protocol to be tested includes: based on the second constraint, extracting first verification information related to the transmission channel from the transmitted signal using a preset reference model; determining whether the first verification information conforms to the second constraint of the bus protocol to be tested; determining whether second verification information in the transmitted signal other than the first verification information conforms to the second constraint; the second constraint is used to verify the relationship between different signals in the transmitted signal.

2. The method according to claim 1, characterized in that, The protocol verification program, configured based on the protocol content of the bus protocol to be detected and the port attributes of the port to be detected, includes: Based on the port attributes of the port to be detected, configure the connection mode between the protocol verification program and the port to be detected; Based on the protocol content of the bus protocol to be tested and the connection mode, the attribute parameters of the protocol verification program are configured. The attribute parameters are used to constrain the signal transmission between the protocol verification program and the port to be tested.

3. The method according to claim 1, characterized in that, The step of extracting first verification information related to the transmission channel from the transmitted signal based on the second constraint content and using a preset reference model includes: Using a preset reference model, information related to the transmission channel is filtered out from the transmitted signal; Based on the second constraint and the filtered information related to the transmission channel, the first information to be verified is obtained.

4. The method according to claim 3, characterized in that, The first information to be verified, obtained based on the second constraint content and the filtered information related to the transmission channel, includes: Based on the filtered information related to the transmission channel, the first association relationship between requests of the same type and the second association relationship between requests of different types are determined respectively; Based on the first association, the second association, and the second constraint content, the first information to be verified is obtained.

5. The method according to claim 4, characterized in that, Obtaining the first information to be verified based on the first association relationship, the second association relationship, and the second constraint content includes at least one of the following steps: If the initiation time of a burst transmission request on the read channel is different from the initiation time of a burst transmission request on the write channel, record the request address of the burst transmission request on the read channel and the request address of the burst transmission request on the write channel. Record the type of each advance transmission request with the same request identifier; Record the response information on the read channel, as well as the read request information corresponding to the response information; If the request issued by the address write channel precedes the data write channel, record whether the data identifier of the data write channel conforms to the relevant provisions of the bus protocol to be detected; After the address write channel sends a request, it records whether a corresponding read channel needs to send a response.

6. The method according to claim 1, characterized in that, Determining whether the second information to be verified in the transmitted signal, excluding the first information to be verified, conforms to the second constraint includes at least one of the following steps: If the initiated request requires at least two clock cycles to transmit, determine whether the next address read request will be transmitted in a later clock cycle; In the event that a synchronization command request has been transmitted ahead of schedule, is a new synchronization command request initiated? When the request type is an exclusive access request, is the channel signal of the write request consistent with the channel signal of the read request? If a request sent by the data write channel precedes a request sent by the address write channel, determine whether the request sent by the address write channel matches the listening type corresponding to the request sent by the data write channel. For a request to monitor a transaction, determine whether the corresponding response information conforms to the specific constraints in the bus protocol to be detected.

7. The method according to claim 1, characterized in that, The step of determining whether the transmitted signal conforms to the first constraint of the bus protocol to be detected includes: Determine the request information contained in the transmitted signal; Within the clock cycle in which the request information is initiated, it is determined whether the request information conforms to the first constraint of the bus protocol to be detected.

8. A bus protocol verification device, characterized in that, include: The configuration module is used to configure the protocol verification program based on the protocol content of the bus protocol to be detected and the port attributes of the port to be detected. An interface module is used to transmit signals between the protocol verification program and the port to be detected, and to traverse the transmission signals of the port to be detected. The first detection module is used to determine whether the transmitted signal conforms to the first constraint of the bus protocol to be detected. The first constraint is used to verify the parameter values ​​of the transmitted signal; The second detection module is used to determine whether the transmission signal conforms to the second constraint content of the bus protocol to be tested, including: based on the second constraint content, extracting first verification information related to the transmission channel from the transmission signal using a preset reference model; determining whether the first verification information conforms to the second constraint content of the bus protocol to be tested; determining whether second verification information in the transmission signal other than the first verification information conforms to the second constraint content; the second constraint content is used to verify the relationship between different signals in the transmission signal.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by the processor to implement the method as described in any one of claims 1-7.

11. A computer program product, comprising a computer program, characterized in that, The computer program is executed by a processor to implement the method according to any one of claims 1-7.

Images