Chip design verification method and related device

Abstract

The embodiment of the invention provides a chip design verification method and a related device. The chip design verification method comprises the steps of obtaining a to-be-tested chip design and executing the to-be-tested chip design; in the process of executing the to-be-tested chip design, when it is detected that a current transaction processed by the to-be-tested chip design generates blocking delay due to input blocking conditions, if it is determined that the blocking delay exceeds the upper limit of the preset blocking period number, the blocking delay caused by the input blocking conditions is relieved, and the current transaction continues to be processed; in the process of continuing to process the current transaction, if it is detected that the current transaction generates transaction processing delay due to a non-input blocking condition and it is determined that the transaction processing delay exceeds a preset delay upper limit, an error indication is returned; wherein the transaction processing delay is the time difference between the moment when the starting signal of the current transaction is valid and the moment when the completion signal is valid. Through transaction processing delay detection, omission of scenes with problems in the chip can be avoided, and comprehensiveness of problem detection is enhanced.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and specifically to a chip design verification method and related devices. Background Art

[0002] In the process of large-scale digital integrated circuit research and development, the cost of tape-out is extremely high, so it is very important to ensure the performance of chip functions.

[0003] Among them, defects that affect chip performance include, for example, deadlock, livelock, and starvation. These defects are all related to chip transaction processing delays. However, the accuracy of verifying these defects that affect chip performance needs to be improved. Therefore, how to single out defects with specific characteristics to achieve accurate assessment of chip functionality has become a pressing issue for those skilled in the art. Summary of the Invention

[0004] In view of this, an embodiment of the present application provides a chip design verification method and related devices to achieve accurate evaluation of chip functions.

[0005] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0006] In a first aspect, an embodiment of the present application provides a chip design verification method, comprising:

[0007] Obtaining a chip design to be tested and executing the chip design to be tested;

[0008] During execution of the chip design under test, when it is detected that a current transaction processed by the chip design under test generates a blocking delay due to an input blocking condition, if it is determined that the blocking delay exceeds a preset upper limit of blocking cycles, the blocking delay generated by the input blocking condition is released, and the current transaction is continued to be processed;

[0009] During the process of continuing to process the current transaction, if it is detected that the current transaction generates a transaction processing delay due to a non-input blocking condition, it is determined whether the transaction processing delay exceeds a preset delay upper limit. If so, an error indication is returned; wherein the transaction processing delay is the time difference between the time when the start signal of the current transaction is valid and the time when the completion signal is valid.

[0010] In a second aspect, an embodiment of the present application provides a chip design verification device, comprising:

[0011] A chip design execution module for obtaining a chip design for testing and executing the chip design for testing;

[0012] a constraint unit, configured to, when detecting that a current transaction processed by the chip design under test generates a blocking delay due to an input blocking condition during execution of the chip design under test, release the blocking delay generated by the input blocking condition and continue processing the current transaction if it is determined that the blocking delay exceeds an upper limit of a preset blocking cycle number;

[0013] A delay checker is configured to, while continuing to process the current transaction, determine whether the transaction processing delay exceeds a preset delay limit if it is detected that the current transaction generates a transaction processing delay due to a non-input blocking condition, and if so, return an error indication; wherein the transaction processing delay is the time difference between the time when the start signal of the current transaction is valid and the time when the completion signal is valid.

[0014] An embodiment of the present application also provides a computer device, including a processor and a memory, wherein the memory stores computer instructions, and the processor executes the computer instructions to implement the chip design verification method as described above.

[0015] An embodiment of the present application also provides a computer program, which is executed to implement the chip design verification method as described above.

[0016] The chip design verification method provided by an embodiment of the present application includes: obtaining a chip design to be tested and executing the chip design to be tested; in the process of executing the chip design to be tested, when it is detected that a current transaction processed by the chip design to be tested generates a blocking delay due to an input blocking condition, if it is determined that the blocking delay exceeds a preset upper limit of blocking cycles, then the blocking delay caused by the input blocking condition is released, and the current transaction is continued to be processed; in the process of continuing to process the current transaction, if it is detected that the current transaction generates a transaction processing delay due to a non-input blocking condition, then it is determined whether the transaction processing delay exceeds a preset delay upper limit, and if so, an error indication is returned; wherein the transaction processing delay is the time difference between the moment when the start signal of the current transaction is valid and the moment when the completion signal is valid.

[0017] In this way, by detecting the processing progress of the current transaction processed by the chip design under test during the execution of the chip design under test, on the one hand, non-input blocking conditions that cause problems in the chip design under test and extend the transaction processing delay time of the current transaction processed by the chip design under test can be detected, such as deadlock, livelock, and starvation that cause problems in the chip design under test. On the other hand, since normal conditions that may cause the processing time of the current transaction to be too long (i.e., conditions where the processing time is too long and not caused by problems or defects in the chip design under test) are usually related to the input blocking conditions of the chip design under test, the blocking delay caused by the input blocking condition is detected separately, and when it is determined that the blocking delay exceeds the preset blocking cycle limit, the blocking delay caused by the input blocking condition is promptly released to avoid false alarms, thereby improving the detection accuracy of the chip design under test. Since transaction processing delays caused by non-input blocking conditions are usually a necessary condition for problems or defects in the chip design under test, after releasing the blocking delay caused by the input blocking condition, by detecting transaction processing delays caused by non-input blocking conditions, it is possible to avoid missing scenarios where problems occur in the chip, thereby enhancing the comprehensiveness of problem detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] 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 merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without any creative work.

[0019] Figure 1 A schematic diagram of the structure of a verification platform;

[0020] Figure 2 A schematic diagram of a process flow of a chip design verification method provided in an embodiment of the present application;

[0021] Figure 3 Another schematic diagram of a chip design verification method according to an embodiment of the present application;

[0022] Figure 4 A schematic diagram of the structure of a chip design verification device provided in an embodiment of the present application;

[0023] Figure 5 A schematic diagram of the structure of a delay checker provided in an embodiment of the present application;

[0024] Figure 6 A schematic diagram of the structure of a credit constraint unit provided in an embodiment of the present application;

[0025] Figure 7A schematic diagram of the structure of the credit flow control constraint unit provided in an embodiment of the present application;

[0026] Figure 8 A schematic diagram of the structure of a readiness constraint unit provided in an embodiment of the present application;

[0027] Figure 9 A schematic diagram of the structure of the confirmation constraint unit provided in an embodiment of the present application;

[0028] Figure 10 Another structural diagram of the chip design verification device provided in an embodiment of the present application;

[0029] Figure 11 A schematic diagram of the structure of a request constraint unit provided in an embodiment of the present application;

[0030] Figure 12 A schematic diagram of the structure of the clock request constraint unit provided in an embodiment of the present application. DETAILED DESCRIPTION

[0031] 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.

[0032] In the development of large-scale digital integrated circuits, tape-out significantly increases chip production costs, making it crucial to ensure chip functionality. Among potential chip issues or defects, deadlock, livelock, and starvation are key issues to avoid.

[0033] Once deadlock or livelock occurs in a chip, the impact is devastating and often unavoidable. Starvation often indicates illogical resource allocation or arbitration logic, or the introduction of unnecessary dependencies. Either scenario can significantly negatively impact chip functionality and performance. Therefore, deadlock, livelock, and starvation verification are crucial during chip verification.

[0034] During the chip design process, digital chip verification is used to ensure the correctness of chip functionality in order to avoid deadlock, livelock, and starvation issues or defects. Digital chip verification methods can be categorized into dynamic simulation and formal verification. Dynamic simulation is a stimulus-based simulation technology. Technicians construct specific stimuli using a hardware verification language, drive them to the input interface of the object under test, and then monitor the correctness of the output at the output interface. The coverage of dynamic simulation depends entirely on the construction of the stimuli. If the input stimuli are incomplete or missing, some scenarios will not be covered, resulting in certain vulnerabilities not being verified.

[0035] For example, a dynamic verification method uses dynamic simulation technology to check whether there are deadlocks, livelocks, starvation, etc. in the chip design (the chip design under test). Dynamic simulation technology can be divided into three important parts: stimulus construction, check module construction, and coverage analysis. Among them, stimulus construction refers to the verification engineer using hardware verification language to construct test stimuli to drive the input interface of the design. The check module is a check device in the verification platform, which is used to check whether the output of the design meets expectations. Coverage analysis is a mechanism to ensure the completeness of verification. Coverage is divided into code coverage and functional coverage. Code coverage can be further divided into line coverage, branch coverage, condition coverage, flip coverage, etc. Code coverage analysis is to ensure that all code in the design has been tested.

[0036] Functional coverage refers to the covergroups and coverpoints compiled by verification engineers to record whether test points are truly covered. Common coverage points include typical values, boundary values, outliers, and cross coverage. Functional coverage is intended to ensure that all test points are truly tested. These test points are finite points extracted by verification engineers from the designed test space. The test space is infinite, and verification engineers cannot exhaust all possibilities through dynamic simulation. Therefore, they must select a finite number of points from the infinite test space to represent the entire test space.

[0037] The simulation technology of the dynamic verification method lacks completeness when verifying problems or defects such as deadlock, livelock, and starvation, and the probability of discovery is low. The scenarios in which deadlock, livelock, and starvation occur are often complex and only occur when multiple complex or extreme conditions are combined. Such scenarios are difficult to detect during test point decomposition. Once they are not identified during the test point decomposition stage, the corresponding stimulus will not be constructed, and the corresponding functional coverage group will not be created, resulting in a low recognition rate. These problems or defects have an extremely serious impact on the chip and may cause the chip to be re-striped out.

[0038] Furthermore, stimulus-based EDA dynamic simulation can be categorized as directed stimulus or random stimulus. Directed stimulus requires anticipating the test scenario before testing in order to construct it. However, since the relevant test scenario has already been considered, the corresponding problem will inevitably be discovered. However, failure to anticipate a specific test scenario in advance may result in the problem remaining undetected. Random stimulus incorporates randomization elements when generating the stimulus. For example, the packet type, length, address, data, and the intervals between packets can all be randomized. The probability of a randomized stimulus covering complex scenarios such as deadlock, livelock, or starvation is often extremely low, and may not even fall within the random range of the random stimulus. Therefore, dynamic simulation technology used to verify problems or defects such as deadlock, livelock, and starvation is prone to missing detection.

[0039] Formal verification uses rigorous mathematical analysis to determine the correctness of a circuit. It can mathematically and completely prove whether the circuit implementation scheme actually realizes the functions described in the circuit design. Therefore, it has good completeness. Therefore, using formal verification to verify problems or defects such as deadlock, livelock, and starvation can make the verification of problems or defects more complete.

[0040] Formal verification can be divided into different application branches, with formal property verification being a key application branch. Formal property verification involves modeling the properties of the circuit being verified using a hardware assertion language or scripting language, and then using formal verification tools to prove these asserted properties. For example, "If a FIFO (First In First Out) buffer is full, no more data can be pushed into it," "If a FIFO is empty, no more data can be popped out," and "After receiving a valid request, the circuit must respond within 10 clock cycles."

[0041] In formal property verification, it's typically necessary to first write an assume property to constrain the input signals of the object under test and an assert property to check the output and internal signals of the object under test. Formal verification tools start with the initial state and explore the state space while satisfying the constraints. Typically, formal verification tools can prove multiple assert properties in parallel. Possible outcomes for assert properties include proven, falsified, and inconclusive / bounded. A proven assertion property means the formal verification tool exhaustively enumerated all possible scenarios within the constraints and found no counterexample. A falsified assertion property means the tool found at least one counterexample within the constraints and can provide the waveform of the counterexample. An inconclusive / bounded assertion property means the tool has calculated to a certain depth without finding a counterexample and reaching a final conclusion. Problems or defects such as deadlock, livelock, and starvation often require very complex and specific scenarios, often located at the corners of the entire verification space. Therefore, formal property verification can avoid missing these corner cases in the verification scenario.

[0042] A chip verification method verifies whether deadlock or livelock occurs in a chip by detecting a specific state in a detection circuit. For example, within a preset clock cycle, it determines whether a specific state recurs. If so, a report indicates the presence of deadlock or livelock. Specifically, the structure of a verification device using the chip verification method is as follows: Figure 1 As shown, an integrated circuit 11 (chip design under test) to be tested is provided within a verification platform 01, and data of the integrated circuit 11 is monitored by a hardware monitor 2. The hardware monitor 2 includes a status register 22 and status detection logic 23 for obtaining the operating status of the integrated circuit 11. Assertion checking logic 24 performs assertion checking on the integrated circuit 11. Finally, a formal verification tool 3 outputs the check results for the integrated circuit 11.

[0043] However, this chip verification method is prone to false positives. This is because the technical solution does not take into account the input constraints (i.e., input blocking conditions). The input constraints will cause the chip design under test to be in a certain state or to jump between certain states when processing the current transaction. Although this situation will cause the processing time of the current transaction, it is normal, that is, it is not a defect or problem in the chip (chip design under test). Even if reasonable constraints are added, it is normal for the chip to jump back and forth between several specific states in certain circumstances. These conditions are neither deadlocks nor livelocks, and are normal phenomena. However, the technical solution will still report an error in this case.

[0044] This technical solution cannot distinguish whether repeated state transitions of the object under test are normal or abnormal. Deadlock and livelock necessarily indicate the recurrence of certain states, but the recurrence of certain states does not necessarily indicate deadlock or livelock. The recurrence of states is a necessary but not sufficient condition for livelock. Therefore, detecting recurrence of states to determine whether there are problems or defects such as livelock or deadlock may result in false positives.

[0045] Furthermore, starvation can also prevent transactions from being processed in a timely manner, impacting chip performance and functionality. Starvation has similar effects to deadlock and livelock, both preventing certain transactions from being processed in a timely manner. However, this technical solution cannot detect starvation.

[0046] To solve the above problems, the embodiment of the present application provides a chip design verification method, which monitors the processing delay of the current transaction in the chip design (chip design to be tested) and eliminates the influence of the blocking delay caused by the input blocking condition, thereby accurately verifying the problems in the chip design. As an optional implementation, Figure 2 FIG. 1 shows a flow chart of a chip design verification method provided in an embodiment of the present application. Figure 2 As shown, the chip design verification method provided in the embodiment of the present application includes the following steps.

[0047] Step S10: Obtaining a chip design to be tested and executing the chip design to be tested. The chip design to be tested is the chip circuit to be verified, and the chip design to be tested is implemented in the form of a hardware description language (HDL), including but not limited to Verilog HDL, VHDL, etc.

[0048] Step S20: During the execution of the chip design to be tested, when it is detected that a blocking delay occurs in the current transaction processed by the chip design to be tested due to an input blocking condition, if it is determined that the blocking delay exceeds the upper limit of the preset blocking cycle number, the blocking delay caused by the input blocking condition is released, and the current transaction continues to be processed.

[0049] It should be noted that input blocking refers to the phenomenon in the chip under test design whereby the current transaction cannot be processed in a timely manner due to waiting for certain input signals (such as the credit signal or the ready signal, which are flow control-related signals), thereby causing the circuit or related module to enter a waiting state. The input signal that causes input blocking can be called an input blocking condition (or input constraint), such as the credit signal or the ready signal.

[0050] Input blocking describes a situation where a system becomes blocked while waiting for a required input signal. In this situation, the system cannot continue to operate until the required input signal is provided. Therefore, by detecting the blocking delay caused by input blocking conditions while the chip under test is processing the current transaction, such as the blocking delay caused by flow control signals such as Credit or Ready, this can be detected and resolved in advance, optimizing system performance.

[0051] From the above content, it can be seen that it is normal that input blocking may cause the chip design under test to jump back and forth between several specific states, which in turn leads to error reports. Therefore, when the processing time is long or the processing cannot continue during the processing of the current transaction, first of all, it is necessary to release the scenario of excessive blocking delay caused by the input blocking condition so that the current transaction can continue to be executed. Then, in the process of continuing to process the current transaction, the transaction processing delay caused by non-input blocking conditions is detected, thereby avoiding the normal situation of input blocking caused by input blocking conditions from being erroneously reported, that is, avoiding the problem of false positives in the returned error indication.

[0052] At the same time, since the blocking delay caused by the input blocking condition needs to be released before it is determined that the transaction processing delay exceeds the preset delay upper limit, the value of the preset blocking cycle upper limit is less than the preset delay upper limit.

[0053] Step S30: During the process of continuing to process the current transaction, if it is detected that the current transaction generates a transaction processing delay due to a non-input blocking condition, it is determined whether the transaction processing delay exceeds a preset delay upper limit, and if so, an error indication is returned.

[0054] The transaction processing delay is the time difference between when the start signal of the current transaction is valid and when the completion signal of the current transaction is valid.

[0055] It should be noted that when there are problems or defects such as deadlock, livelock or starvation in the design of the chip under test (that is, the non-input blocking condition), the current transaction processed by the chip under test design will definitely not be processed in time, thereby causing the transaction processing delay of the current transaction to continue to increase.

[0056] Due to the blocking delay caused by the input blocking condition in step S20, the processing time of the current transaction may also be too long. And the input blocking condition is a controllable condition in the design of the chip to be tested. The blocking delay in step S20 does not mean that there is a problem or defect in the design of the chip to be tested. Therefore, when the current transaction has a blocking delay and the blocking delay is long, when it is determined that the blocking delay has reached a certain limit (i.e., the upper limit of the preset blocking cycle number), the blocking delay caused by the input blocking condition can be removed to avoid the current transaction from being processed too long, thereby ensuring that the current transaction can continue to be processed. Thus, when the current transaction cannot be processed in time, the blocking delay caused by the input blocking condition is eliminated, ensuring that within the design of the chip to be tested, the factor that causes the processing time of the current transaction to be long is only the transaction processing delay caused by non-input blocking conditions such as deadlock, livelock or starvation problems or defects.

[0057] In this way, by detecting the processing progress of the current transaction processed by the chip design under test during the execution of the chip design under test, on the one hand, non-input blocking conditions that cause problems in the chip design under test and extend the transaction processing delay time of the current transaction processed by the chip design under test can be detected, such as deadlock, livelock, and starvation that cause problems in the chip design under test. On the other hand, since normal conditions that may cause the processing time of the current transaction to be too long (i.e., conditions where the processing time is too long and not caused by problems or defects in the chip design under test) are usually related to the input blocking conditions of the chip design under test, the blocking delay caused by the input blocking condition is detected separately, and when it is determined that the blocking delay exceeds the preset blocking cycle limit, the blocking delay caused by the input blocking condition is promptly released to avoid false alarms, thereby improving the detection accuracy of the chip design under test. Since transaction processing delays caused by non-input blocking conditions are usually a necessary condition for problems or defects in the chip design under test, after releasing the blocking delay caused by the input blocking condition, by detecting transaction processing delays caused by non-input blocking conditions, it is possible to avoid missing scenarios where problems occur in the chip, thereby enhancing the comprehensiveness of problem detection.

[0058] Further, such as Figure 3 As shown, in an optional implementation, step S30 includes:

[0059] Step S31: Split the current transaction into multiple secondary transactions, and extract a checkpoint of each secondary transaction.

[0060] Step S32: For each secondary transaction, detect whether the secondary transaction processing delay exceeds a preset delay limit. If the secondary transaction processing delay exceeds the preset delay limit, determine that the transaction processing delay of the current transaction exceeds the preset delay limit, and return an error indication. The secondary transaction processing delay is the time difference between the valid start signals of two adjacent secondary transaction checkpoints.

[0061] By dividing the processing of the current transaction in the chip design under test into different stages and then checking the secondary transaction processing delay in each stage, the efficiency of formal property verification can be improved.

[0062] Furthermore, in an optional implementation, the step S20 includes: counting the delay periods caused by the input blocking condition to obtain the input delay; comparing the value of the input delay with the preset upper limit of the number of blocking periods; when the value of the input delay is greater than or equal to the preset upper limit of the number of blocking periods, releasing the blocking delay caused by the input blocking condition.

[0063] It should be noted that when detecting the transaction processing delay of the current transaction of the chip design under test, it is impossible to distinguish the root causes of different delays from the transaction processing delay. Therefore, for the blocking delay caused by input blocking conditions, it is necessary to specifically detect the blocking delay caused by a specific input blocking condition.

[0064] In one embodiment, step S30 may include: detecting whether the current transaction is running; calculating the transaction processing delay of the current transaction; comparing the transaction processing delay with the preset delay upper limit, and outputting a timeout flag based on the comparison result, so as to output a corresponding assertion based on the timeout flag.

[0065] The transaction processing delay can be obtained by counting using a delay counter. The transaction processing delay is compared with the preset delay upper limit to check whether the transaction processing delay obtained by the delay counter exceeds the preset delay upper limit. The comparison result is a timeout flag. The timeout flag asserts the delay assertion attribute. Exemplarily, the comparison process and the delay assertion attribute are implemented using the SVA language.

[0066] Further, in an optional implementation, the input blocking includes at least one of credit signal blocking, ready signal blocking or confirmation signal blocking.

[0067] It should be noted that the credit signal blocking is related to Credit-based Flow Control. The Credit flow control is a flow control mechanism widely used in network communications and data processing. This mechanism controls the sending and receiving of data by maintaining a "Credit" value to ensure the stability and reliability of the network or system. In the Credit-based flow control mechanism, after the receiving end receives a data packet and forwards it, it will send a Credit to the sending end. The data sender will have a counter to count the number of Credits. The counter will usually decrease by one after sending a data packet and increase by one after receiving a Credit. The necessary condition for the sender to send a data packet is to have sufficient Credit. If the receiving end is unable to return Credit for some reason, signal blocking may occur.

[0068] The blocking of the ready signal is related to Valid / Ready flow control. Valid / Ready flow control is a common flow control protocol used in digital circuit design. The Valid signal is sent by the data sender, indicating that the data on the current data channel is valid and can be read by the receiver. The Ready signal is sent by the data receiver, indicating that the receiver is ready to receive new data. Data transmission only occurs when both the Valid and Ready signals are valid. The Ready signal can be valid before or after the Valid signal, but the actual data transmission depends on whether both signals are valid at the same time.

[0069] Acknowledgement signal blocking is related to the Req / Ack handshake. In electronic information systems, the Req / Ack handshake is a crucial communication protocol used to ensure the reliability and correctness of data transmission between two or more systems. In this protocol, one system (the sender) sends a request (Req) signal to another system (the receiver) and requires an acknowledgment (Ack) signal. Once the acknowledgment signal is received, the sender or receiver can proceed with subsequent operations. If one party fails to receive the acknowledgment signal, signal blocking occurs, preventing the transaction from proceeding.

[0070] Furthermore, in addition to the above three input blocking conditions, the chip under test design also includes other optional input blocking conditions. Specifically, in an optional implementation, the input blocking condition also includes: request signal blocking or clock request signal blocking.

[0071] It should be noted that the chip under test design includes at least one of the following: credit signal blocking, ready signal blocking, or confirmation signal blocking. In one specific implementation, the chip under test design may not include request signal blocking or clock request signal blocking. Request (Req) signal blocking typically refers to a control or data request signal in the system, used for handshake communication between modules. The purpose of this constraint is to ensure the correct timing relationship between the request signal and the clock, avoiding setup / hold time violations caused by path delays.

[0072] Clock request (ClkReq) signal blocking typically refers to signals related to clock gating, such as the enable signal that controls clock switching. Its purpose is to ensure that the clock gating signal is sampled at the correct time, thereby ensuring the reliability of clock switching.

[0073] Furthermore, in an optional implementation, when the input blocking condition includes signal blocking, the step of detecting, during execution of the chip design under test, that a current transaction processed by the chip design under test is blocked due to the input blocking condition includes: recording the number of credits that the receiver within the chip design under test has received requests for but not released; recording the number of clock cycles during which the receiver within the chip design under test has credits pending but not released; comparing the number of clock cycles during which the receiver has credits pending but not released to see if it exceeds a preset maximum waiting period; and if so, releasing one credit. The request or data for the current transaction is only acquired when the credit value of the chip design under test reaches the preset credit value. When the input blocking condition includes clock request signal blocking, the clock request signal of the current transaction remains high for at least a preset clock period.

[0074] Optionally, when the input blocking condition includes a ready signal being blocked, the step of detecting, during the execution of the chip design under test, that a current transaction processed by the chip design under test generates a blocking delay due to the input blocking condition includes:

[0075] Count the number of clock cycles during which the data sender experiences back pressure.

[0076] Compare the value of the back pressure cycle counter to see if it is greater than or equal to the preset maximum back pressure cycle parameter;

[0077] When the value of the back pressure cycle counter is greater than or equal to a preset maximum back pressure cycle parameter, the state of the ready signal becomes valid.

[0078] The preset maximum back-pressure cycle parameter specifies the maximum number of back-pressure clock cycles allowed, i.e., the maximum number of clock cycles during which Valid is active but Ready is inactive. When the value of the back-pressure cycle counter is greater than or equal to the preset maximum back-pressure cycle parameter, the ready signal becomes active, indicating a blocking delay.

[0079] Optionally, when the input blocking condition includes a confirmation signal blocking, the step of detecting, during the execution of the chip design under test, that a current transaction processed by the chip design under test generates a blocking delay due to the input blocking condition comprises:

[0080] Detect the status of the request / confirmation handshake connection and record whether the sender is waiting for the receiver to pull up / low the confirmation signal;

[0081] Record the number of clock cycles the sender waits for confirmation of the high / low status after raising / lowering the request;

[0082] Maintaining the expected value of the confirmation signal;

[0083] The constraint confirmation signal is equal to the value of the confirmation register;

[0084] The confirmation parameter storage module is further configured with a stability assumption attribute, a range assumption attribute and an equality assumption attribute.

[0085] The stability assumption constrains the confirmation delay variable to remain stable while waiting for Ack to go high or low. That is, the confirmation delay must remain stable in the REQINIT or DISCON states. The range assumption constrains the legal range of the confirmation delay variable.

[0086] Because the normal behavior of the confirmation signal is dynamic, and the register value usually represents the previous state of the signal, if the confirmation signal is equal to the confirmation register value, it means that the confirmation signal has not changed, which indicates the presence of blocking delay.

[0087] For further information, please refer to Figure 2 In an optional implementation, step S40 is further included between step S10 and step S20: obtaining a data transmission queue of the chip design to be tested, and reducing the bit width of the data transmission queue to execute the chip design to be tested based on the data transmission queue.

[0088] The data transmission queue is used to cache the content of the request designed for the chip under test.

[0089] It should be noted that when the FIFO data depth of the chip design under test is too large, it will increase the state space of formal verification, which will seriously affect the inference performance of the formal verification tool for assertion properties. The FIFO in the chip design under test stores data information, and the content of the stored data has no effect on the control function of the chip design under test. Therefore, in formal verification, even if the data in the FIFO is modified, it will not affect the formal verification of the chip design under test. It is only necessary to ensure that the number of FIFO data in the chip design under test remains unchanged, and only a small number of bits of the data are stored in the FIFO.

[0090] Further, such as Figure 3 As shown, in an optional implementation, the step S40 includes step S41: obtaining the design file and file list file of the chip design to be tested.

[0091] It should be noted that the design file is generally a file used to describe, record and save the design information of a system or project. The file list (filelist) is generally a structure containing a list of the design files, and is used to store a set of paths or names of the design files.

[0092] Step S42: Determine whether the file name of the design file is the same as the file name of the target design file. If yes, execute step S43; if not, execute step S41.

[0093] It should be noted that the target design file is the design file related to the current transaction, that is, the design file that needs to be processed. If the design file name is the same as the target design file name, then the design file is the design file related to the current transaction and therefore needs to be processed.

[0094] If they are the same, step S43 is executed: determining whether the parameter line instantiating the data transmission queue in the design file matches the parameter line instantiating the data transmission queue in the target design file. If so, step S44 is executed; if not, step S41 is executed. Specifically, the parameter line information includes, for example, matching module names and parameter names such as depth and width. Based on different sets of parameter information, a unique match can be made to a design file, thereby facilitating the identification of the design file.

[0095] If they match, step S44 is executed: determining whether the write data port of the data transmission queue in the design file matches the write data port of the data transmission queue in the target design file. If yes, step S45 is executed; if not, step S41 is executed.

[0096] Step S45: Concatenate the high-order data and the low-order data in the data transmission queue to obtain concatenated data, and bind the concatenated data to the write data port of the data transmission queue in the design file to obtain a second design file. The second design file includes the data transmission queue after the bit width of the data transmission queue is reduced. The size of the concatenated data is smaller than the size of the original data in the data transmission queue.

[0097] It should be noted that, since the design file has no impact on the control logic content, it is only necessary to retain part of the information in the design file to ensure that the chip design under test can determine whether the design file exists.

[0098] Specifically, in one optional implementation, the design file includes the upper 6 bits and lower 6 bits of data. The "upper" and "lower" bits represent the data within the first 6 bits and the data within the last 6 bits of the data structure of the design file. This ensures the equivalence of the control logic before and after modification while significantly reducing the complexity of the design.

[0099] The embodiment of the present application provides a chip design verification device that monitors the processing delay of the current transaction in the chip and eliminates the influence caused by input blocking conditions, thereby accurately verifying the problems in the chip. As an optional implementation, Figure 4 The structure of the chip design verification device provided by the embodiment of the present application is shown. Figure 4 As shown, the chip design verification device provided in the embodiment of the present application includes the following modules.

[0100] Chip-to-be-tested design execution module 100. The chip-to-be-tested design execution module 100 is used to obtain and execute the chip-to-be-tested design. The chip-to-be-tested design, i.e., the chip circuit to be verified, is implemented in a hardware description language (HDL). In one embodiment, the hardware description language includes Verilog HDL or VHDL.

[0101] The constraint unit 210 is used to detect that a current transaction processed by the chip design under test generates a blocking delay due to an input blocking condition during the execution of the chip design under test. If it is determined that the blocking delay exceeds a preset upper limit of blocking cycles, the blocking delay caused by the input blocking condition is released and the current transaction is continued to be processed.

[0102] The delay checker 220 is configured to determine whether the transaction processing delay exceeds a preset delay limit if it is detected that the current transaction generates a transaction processing delay due to a non-input blocking condition during the process of continuing to process the current transaction, and if so, return an error indication; wherein the transaction processing delay is the time difference between the time when the start signal of the current transaction is valid and the time when the completion signal is valid.

[0103] It should be noted that the function of the delay checker 220 is to check whether the delay between two events exceeds a preset delay upper limit. Specifically, a structure of the delay checker is as follows: Figure 5 As shown, the delay checker includes a flag register 221, a delay counter 222, comparison logic 223, a delay assertion attribute 224, and a delay parameter storage module 225 for storing a preset upper delay limit. The delay checker receives a transaction start signal or a completion signal as input and inputs it to the flag register 221. The start signal and the completion signal can be either level signals or pulse signals.

[0104] Flag register 221 is used to indicate whether the current transaction is currently running. Specifically, flag register 221 records the state in which a transaction has begun processing but has not yet completed, i.e., the state between when the start signal is valid and when the completion signal is valid. Specifically, when the signal for the current transaction is reset, flag register 221 is set to invalid. At each clock cycle, if the completion signal is valid, flag register 221 is set to invalid; otherwise, if the start signal is valid, flag register 221 is set to valid.

[0105] The delay counter 222 is used to calculate transaction processing delays. Specifically, it counts the number of delay cycles between the start signal being valid and the completion signal being valid. Specifically, the signal for the current transaction is reset to 0. It is cleared to 0 at each clock cycle if the completion signal is valid. If the value of the flag register 221 is valid, the delay cycle in the delay counter 222 is incremented by 1.

[0106] The comparison logic 223 is used to compare the transaction processing delay with the preset delay limit to check whether the value of the delay counter 222 exceeds the preset delay limit. The comparison result is a timeout flag. The timeout flag is sent to the delay assertion attribute 224 for assertion. The delay assertion attribute 224 is used to output a corresponding assertion based on the timeout flag obtained from the comparison logic 223 and send it to subsequent modules.

[0107] In one embodiment, Figure 4As shown, the chip design execution module 100, delay checker 220 and constraint unit 210 are located on the verification platform 200, and the chip design verification device also includes.

[0108] The formal verification tool 300 is used to perform formal verification on the chip design execution module 100 to obtain a verification result.

[0109] In this way, by detecting the processing progress of the current transaction processed by the chip design under test during the execution of the chip design under test, on the one hand, non-input blocking conditions that cause problems in the chip design under test and extend the transaction processing delay time of the current transaction processed by the chip design under test can be detected, such as deadlock, livelock, and starvation that cause problems in the chip design under test. On the other hand, since normal conditions that may cause the processing time of the current transaction to be too long (i.e., conditions where the processing time is too long and not caused by problems or defects in the chip design under test) are usually related to the input blocking conditions of the chip design under test, the blocking delay caused by the input blocking condition is detected separately, and when it is determined that the blocking delay exceeds the preset blocking cycle limit, the blocking delay caused by the input blocking condition is promptly released to avoid false alarms, thereby improving the detection accuracy of the chip design under test. Since transaction processing delays caused by non-input blocking conditions are usually a necessary condition for problems or defects in the chip design under test, after releasing the blocking delay caused by the input blocking condition, by detecting transaction processing delays caused by non-input blocking conditions, it is possible to avoid missing scenarios where problems occur in the chip, thereby enhancing the comprehensiveness of problem detection.

[0110] Furthermore, in addition to end-to-end checks during transaction delay detection, to improve verification efficiency, formal verification tools can simultaneously check and verify multiple assertions in parallel. This allows the processing of a single transaction to be divided into different stages, and the phased checkpoints of the sub-transactions in each stage to improve verification efficiency. In an optional implementation, the delay checker 220 is configured to split the current transaction into multiple sub-transactions and extract the checkpoints of each sub-transaction.

[0111] The delay checker 220 is configured to detect, for each secondary transaction, whether the secondary transaction processing delay of the secondary transaction exceeds a preset delay upper limit; if the secondary transaction processing delay exceeds the preset delay upper limit, determine that the transaction processing delay of the current transaction exceeds the preset delay upper limit, and return an error indication; wherein the secondary transaction processing delay is the time difference between the validity of the start signal and the validity of the completion signal between two adjacent secondary transaction checkpoints.

[0112] Specifically, in a chip design under test, the input blocking condition may include at least one of: credit signal blocking, ready signal blocking, or confirmation signal blocking.

[0113] For example, confirmation signal blocking can be described as: the transaction receiver at the output end does not reply to the clock confirmation (ClkAck); credit signal blocking can be described as: the transaction receiver at the output end does not reply to Credit, forming back pressure;

[0114] The non-input blocking conditions may include: unfair two-level arbitration, resulting in starvation of a request source; deadlock or livelock of the state machine of the receiving port control unit or the sending port control unit, and inability to jump to the active state in time.

[0115] For these input blocking conditions and non-input blocking conditions, the following stage checkpoints can be set appropriately: check whether the clock request is valid to whether the receiving port state is active to check whether the receiving port state machine has deadlock / livelock problems; check whether the request is received to whether the sending port state is active to check whether the sending port state machine has deadlock / livelock problems; check whether the request is received to whether the corresponding virtual channel credit is sufficient to check the flow control mechanism and whether there is deadlock problem; check whether the FIFO is not empty, the sending port is active, and the corresponding virtual channel credit is sufficient to FIFO Pop to check whether the arbitration logic has starvation problems.

[0116] Furthermore, in an optional implementation, when the input blocking condition includes at least one of a credit signal blocking, a ready signal blocking, or a confirmation signal blocking, the constraint unit 210 includes multiple types, each of which processes a type of signal blocking. Specifically, the constraint unit 210 includes at least one of a credit constraint unit, a ready constraint unit, and a confirmation constraint unit.

[0117] The inputs of the credit constraint unit are the valid signal and the credit valid signal. The valid signal indicates that the sender has sent a valid transaction or data, which means that a credit has been consumed; the credit valid signal indicates that a credit has been restored. The structure of the credit constraint unit is as follows: Figure 6 As shown, it includes: a waiting credit counter 2111 (pending_credit_counter), a waiting cycle counter 2112 (pending_cycle_counter), a first comparison module 2113, a credit parameter storage module 2114 for storing a preset maximum waiting cycle, and a cycle release module 2115.

[0118] Specifically, the waiting credit counter 2111 is used to record the number of credits that the receiver in the chip design under test has received requests for but has not released. That is, the number of credits that are yet to be released to the sender. The behavior of the waiting credit counter 2111 is that it is 0 when reset, and in each clock cycle: if the Valid signal is valid and the CreditVld signal is invalid, then add one; if the Valid signal is invalid and the CreditVld signal is valid, then subtract one. The waiting cycle counter 2112 is used to record the number of clock cycles in which the receiver in the chip design under test has credits to be released but has not released the credits. The behavior of the waiting cycle counter 2112 is that it is 0 when reset, and in each clock cycle: if the credit is released, that is, the CreditVld signal is valid, then clear to zero; otherwise; if the waiting credit counter 2111 is not 0, then add one.

[0119] The preset maximum waiting cycle (MAX_PENDING_CYCLE) specifies the maximum number of cycles in which a credit is pending but not released. Comparison logic is used to compare the value of the waiting cycle counter 2112 to see if it exceeds the preset maximum waiting cycle. Cycle release module 2115 is used to release a credit when the value of the waiting cycle counter 2112 exceeds the preset maximum waiting cycle.

[0120] Furthermore, in the chip under test design, if the credit flow control is constrained, the input credit of the credit flow control is constrained independently by channel / virtual channel, and its structure is as follows: Figure 7 As shown. The chip under test design needs to perform credit flow control independently by channel / virtual channel, which means: the credit of each channel is independently calculated / counted; the sender will specify the channel number when sending a transaction or data to specify which channel’s credit is consumed; the receiver will also specify the channel number when releasing the credit to specify which channel’s credit is restored. At this time, the input of the credit constraint unit includes: request valid (ReqVld) signal, request virtual channel number (ReqVC), credit valid (CreditVld), credit virtual channel number (CreditVC). ReqVld indicates that the sender has issued a transaction or data, that is, consumed a credit; ReqVC indicates the virtual channel number (Virtual Channel, VC) corresponding to the transaction or data, that is, indicates which virtual channel’s credit is consumed; CreditVld indicates that a credit is restored, and CreditVC indicates which virtual channel the restored credit corresponds to.

[0121] The credit constraint unit internally contains N virtual channel credit constraint units, where N is the number of virtual channels. Furthermore, virtual channel credit constraints require simultaneous reference to the virtual channel number when considering both Valid and Credit validity. For example, the virtual channel number must be considered when maintaining waiting credit counter 2111. Taking virtual channel 0 as an example, its behavior is as follows: upon reset, it is 0. At each clock cycle: if the request valid signal is valid and the request virtual channel number is 0, and the credit valid signal is invalid or the credit virtual channel number is not 0, the waiting credit counter 2111 increments by one; if the request valid signal is invalid or the request virtual channel number is not 0, and the credit valid signal is valid and the credit virtual channel number is 0, the waiting credit counter 2111 decrements by one.

[0122] The input of the readiness constraint unit is a valid signal and a ready signal, such as Figure 8 As shown, the readiness constraint unit includes: a back pressure cycle counter 2121 , a back pressure parameter module 2122 for storing a preset maximum back pressure cycle parameter, a second comparison module 2123 and a readiness assumption attribute 2124 .

[0123] The back pressure cycle counter 2121 is used to count the number of clock cycles during which the data sender experiences back pressure. Specifically, it counts the number of clock cycles during which the Valid state is valid but the Ready state is invalid. The counter is reset to 0 and is cleared at each clock cycle if both Valid and Ready are valid. Otherwise, it increments by one if either Valid or Ready is invalid.

[0124] The second comparison module 2123 is used to compare whether the value of the back pressure cycle counter 2121 is greater than or equal to the preset maximum back pressure cycle parameter. When the value of the back pressure cycle counter 2121 is greater than or equal to the preset maximum back pressure cycle parameter, the ready assumption attribute 2124 constrains the response so that the Ready signal must be valid.

[0125] The confirmation constraint unit is as follows Figure 9 As shown, it includes: state detection logic 2131, acknowledgment latency counter 2132 (ack_latency_counter), acknowledgment register 2133, equality assumption attribute 2134, and acknowledgment parameter storage module 2135 for storing acknowledgment latency variables. The acknowledgment constraint unit inputs are request (Req) signals and acknowledgment (Ack) signals. Optionally, the acknowledgment constraint unit also includes acknowledgment parameter storage module 2135. The acknowledgment parameter storage module 2135 is also configured with stability assumption attributes, range assumption attributes, and equality assumption attributes.

[0126] The state detection logic 2131 is used to detect the state of the Req / Ack handshake connection and record whether the sender is waiting for the receiver to pull up / low the confirmation (Ack) signal. The state detection logic 2131 can be implemented using a finite state machine or a register. When the state detection logic 2131 is implemented using a state machine, the jump logic of the state detection logic 2131 is as follows: the state detection logic 2131 is initially in the idle (IDLE) state; when in the idle state: when Req is valid, the state detection logic 2131 jumps to the request initiation (REQINIT) state; otherwise, it remains in the idle state; when the state detection logic 2131 is in the request initiation state: when Ack is valid, the state detection logic 2131 jumps to the active (ACTIVE) state; otherwise, it remains in the request initiation state; when the state detection logic 2131 is in the active state: when Req is invalid, the state detection logic 2131 jumps to the disconnected (DISCON) state; otherwise, it remains in the active state; when the state detection logic 2131 is in the disconnected state: when Ack is invalid, the state detection logic 2131 jumps to the idle state; otherwise, it remains in the disconnected state.

[0127] Acknowledgement Delay Counter 2132 is used to record the number of clock cycles the sender waits for Ack to be raised / lowered after raising / lowering Req. Based on the aforementioned state detection logic, Acknowledgement Delay Counter 2132 is reset to 0 and is cleared at each clock cycle if the connection state is IDLE or ACTIVE, and incremented by one if the connection state is REQINIT or DISCON.

[0128] The confirmation register 2133 is used to maintain the expected value of the confirmation signal. The equality assumption attribute 2134 is used to constrain the confirmation signal to be equal to the value of the confirmation register. The confirmation parameter storage module 2135 is also configured with a stability assumption attribute and a range assumption attribute to constrain the confirmation delay variable.

[0129] The confirmation register 2133 maintains the desired value of Ack, and its maintenance method is to be invalid when reset. In each clock cycle: when the state machine is in REQINIT, that is, Req is valid, while waiting for Ack to be valid, and the value of the confirmation delay counter 2132 is greater than or equal to the confirmation delay variable, the confirmation register 2133 is set to the valid state; when the state machine is in DISCON, that is, Req is invalid, while waiting for Ack to be invalid, and the value of the confirmation delay counter 2132 is greater than or equal to the confirmation delay variable, the confirmation register 2133 is set to the invalid state.

[0130] Furthermore, in an optional implementation, when the state detection logic 2131 is implemented using registers, the wait_ack_assert register can be used to replace the REQINIT state of the finite state machine, and the wait_ack_deassert register can be used to replace the DISCON state of the finite state machine.

[0131] The maintenance mode of the waiting Ack valid register is that it is invalid when reset. In each clock cycle: if Req is valid and Ack is invalid, it is set to valid; otherwise; if Req is valid and Ack is valid, it is set to invalid.

[0132] The maintenance mode of the Wait Ack Invalid register is that it is invalid when reset, and in each clock cycle: if Req is invalid and Ack is valid, it is set to valid, otherwise; if Req is invalid and Ack is invalid, it is set to invalid.

[0133] Correspondingly, the behavior of the confirmation delay counter 2132 becomes: it is reset to 0, and in each clock cycle: if both Req / Ack signals are valid, or both Req / Ack are invalid, it is cleared to zero, otherwise; if either the wait Ack valid register or the wait Ack invalid register is valid, it is increased by one.

[0134] Accordingly, the stability assumption property becomes the constraint that the confirmation delay remains stable when either the Wait Ack Valid Register or the Wait Ack Invalid Register is valid.

[0135] Correspondingly, the maintenance mode of confirmation register 2133 becomes invalid when reset, and in each clock cycle: when the Waiting Ack Valid Register is valid and the value of the confirmation delay counter is greater than or equal to the confirmation delay variable, the confirmation register 2133 is set to valid; when the Waiting Ack Invalid Register is valid and the value of the confirmation delay counter is greater than or equal to the confirmation delay variable, the confirmation register 2133 is set to invalid.

[0136] In particular, in an optional implementation, the confirmation constraint unit is not included in the state detection logic 2131. Thus, the behavior of the confirmation delay counter is to reset to 0. In each clock cycle, if both the Req / Ack signal are valid or both the Req / Ack signal are invalid, the counter is cleared to 0. Otherwise, if only one of the Req / Ack signals is valid, the counter is incremented by one.

[0137] Accordingly, the stability assumption property becomes the constraint that the confirmation delay remains stable when there is and one of the Req / Acks is valid.

[0138] Correspondingly, the maintenance mode of the confirmation register 2133 becomes invalid when reset. In each clock cycle: when Req is valid and Ack is invalid, and the value of the confirmation delay counter is greater than or equal to the confirmation delay variable, the confirmation register is set to valid; when Req is invalid and Ack is valid, and the value of the confirmation delay counter is greater than or equal to the confirmation delay variable, the confirmation register becomes invalid.

[0139] In order to more clearly illustrate the implementation of the technical solution of the present invention, a verification example of a chip design to be tested is given as an example. Figure 10 As shown in Figure 2, the input port has two sets of interfaces, representing two possible transaction input sources. Each set of interfaces includes: clock request (ClkReq) and clock acknowledgement (ClkAck) for port control; request valid (ReqVld), request virtual channel number (ReqVC), and request header (ReqHeader) for transmission requests; and request credit valid (ReqCreditVld) and request credit virtual channel number (ReqCreditVC) for credit flow control.

[0140] Before sending a request, the sender must first raise the clock request (ClkReq). The receiver, once ready to receive the request, raises the clock acknowledgment (ClkAck). When both the clock request and acknowledgment are valid, the port is in the Active state, and the request can be transmitted. Requests are divided into several virtual channels for transmission and processing, with ReqVC representing the virtual channel number. The ReqHeader carries several fields specific to the request, such as the request address (ReqAddr), request command (ReqCmd), and requester ID (ReqID). Credit flow control is performed on the interface by virtual channel, with ReqCreditVC representing the virtual channel number corresponding to the credit. Credits are released by the transaction receiver to the transaction sender. Internally, each interface group has a receive port control unit, which controls and records the port connection status. This control unit implements a finite state machine. For each virtual channel in each interface group, the chip circuitry has a FIFO to buffer the request content. These FIFOs undergo two levels of arbitration, ultimately selecting a FIFO that receives output permission and sending it to the output port. The first level of arbitration selects a winning virtual channel from among different virtual channels of the same request source, while the second level of arbitration arbitrates between different request sources. The prerequisites for a FIFO to participate in arbitration are that the FIFO is not empty, the output port is active, and the virtual channel corresponding to the FIFO has sufficient credit. The control logic before the first level of arbitration is responsible for determining the arbitration conditions.

[0141] For details, please refer to Figure 10 , Figure 10 This is a specific embodiment of a chip under test design. For example, its input port has two interfaces, Interface 0 and Interface 1, representing two possible transaction input sources. Each interface includes: a clock request (ClkReq) and clock acknowledgement (ClkAck) for port control; a request valid (ReqVld), request virtual channel number (ReqVC), and request header (ReqHeader) for transmission requests; and a request credit valid (ReqCreditVld) and request credit virtual channel number (ReqCreditVC) for credit flow control.

[0142] Before sending a request, the sender must first raise the clock request (ClkReq). The receiver, once ready to receive the request, raises the clock acknowledgment (ClkAck). When both the clock request and acknowledgment are valid, the port is in the Active state, and the request can be transmitted. Requests are divided into several virtual channels for transmission and processing, with ReqVC representing the virtual channel number. The ReqHeader carries several fields specific to the request, such as the request address (ReqAddr), request command (ReqCmd), and requester ID (ReqID). The interface uses credit flow control on a per-virtual channel basis, with ReqCreditVC representing the virtual channel number corresponding to the credit. Credits are released by the transaction receiver to the transaction sender.

[0143] Inside the chip circuit, each group of interfaces is supported by a receiving port control unit, which is used to control and record the port connection status. It implements a finite state machine internally. For each virtual channel in each group of interfaces, the chip circuit is equipped with a FIFO to cache the requested content. These FIFOs will go through two levels of arbitration to select a FIFO that ultimately obtains output permission and pop it out to the output port. The first level of arbitration is to select a winning virtual channel from different virtual channels of the same request source, while the second level of arbitration is to arbitrate between different request sources. The prerequisite for the FIFO to participate in arbitration is that the FIFO is not empty, the output port is in an active state, and the virtual channel corresponding to the FIFO has sufficient credit. The control logic before the first level of arbitration is used to judge the arbitration conditions.

[0144] In addition, in an optional implementation, before binding the delay checker, each virtual channel of each request source can be checked end-to-end, that is, the delay from the transaction entering the chip circuit to the output port can be checked before the binding operation is performed.

[0145] Furthermore, in an optional implementation, the input blocking condition further includes: request signal blocking or clock request signal blocking. Accordingly, the constraint unit 210 further includes a request constraint unit or a clock request constraint unit.

[0146] It should be noted that the request constraint unit is used to constrain the request transaction related signals of the input end interface. The structure of the request constraint unit is shown in the attached figure. Figure 11 As shown, it is composed of at least one request constraint logic 2141 and a request field assumption attribute 2142. Each request constraint logic 2141 corresponds to a virtual channel of the chip under test design. The request constraint logic 2141 is used to constrain the corresponding virtual channel to send a request for the corresponding virtual channel when there is sufficient credit.

[0147] The request constraint logic 2141 is as follows Figure 11 As shown, it includes a credit counter 2143 and a request validity assumption attribute 2144. Credit counter 2143 records the number of credits available to the sender and outputs a permit signal to request validity assumption attribute 2144. Taking virtual channel 0 as an example, the behavior of credit counter 2143 is as follows: the reset value is 0, and in each clock cycle: if the sender receives credit for virtual channel 0 in a certain clock cycle and does not send a request for virtual channel 0, the credit counter 2143 is incremented by one; if the sender sends a request for virtual channel 0 in a certain clock cycle and does not receive credit for virtual channel 0, the credit counter 2143 is decremented by one.

[0148] The request validity assumption attribute 2144 constrains that when the send permission signal is invalid, that is, when there is insufficient credit, the request for the corresponding virtual channel will not be sent. The request field assumption attribute 2142 constrains the validity of specific fields in the request header, including ReqAddr (request address), ReqCmd (request command), and ReqID (requester identifier).

[0149] The clock request constraint unit is as follows: Figure 12As shown; its input is the clock request (ClkReq) signal, and its internal components include: a clock request beat register 2151, a hold clock request flag 2152, a clock request hold counter 2153, a stability assumption attribute 2154, and a clock request parameter module 2155 for storing a preset clock request hold period. The clock request constraint unit is used to constrain ClkReq from being pulled up or down too frequently, that is, after ClkReq is pulled up, it needs to be kept for a certain period of time before it can be pulled down. The clock request beat register 2151 performs register beats on the input ClkReq, and the signal after the beat is recorded as ClkReq_d1. The hold clock request flag, recorded as hold_clkreq, is used to record whether the input ClkReq should be maintained at present. The clock request hold counter is recorded as clkreq_hold_counter, and the preset clock request hold period parameter is HOLD_CYCLE.

[0150] The clock request beat register 2151 maintains the hold_clkreq register, which is invalid at reset. In each clock cycle, if ClkReq is valid and ClkReq_d1 is invalid, the register is set to valid. If clkreq_hold_counter is greater than or equal to HOLD_CYCLE, the register is set to invalid. The clock request beat register 2151 maintains the clkreq_hold_counter register, which is 0 at reset. In each clock cycle, if clkreq_hold_counter is greater than or equal to HOLD_CYCLE, the register is cleared to 0. If hold_clkreq is valid, the register is incremented by 1.

[0151] In this way, after the rising edge of ClkReq, hold_clkreq will remain valid for HOLD_CYCLE clock cycles. The stability assumption property is used to constrain that the input ClkReq must remain stable when hold_clkreq is valid.

[0152] Furthermore, in an optional implementation, the chip design to be tested also includes: a data transmission queue management module for obtaining the data transmission queue of the chip design to be tested, the data transmission queue being used to cache the content of the request for the chip design to be tested; and reducing the bit width of the data transmission queue to execute the chip design to be tested based on the data transmission queue. It should be noted that when the FIFO data depth of the chip circuit is too large, the state space of the formal verification will be increased, thereby seriously affecting the inference performance of the formal verification tool for assertion attributes. The FIFO in the chip stores data information, and the content of the stored data has no effect on the controllability of the chip. Therefore, in formal verification, even if the data of the FIFO is modified, it will not affect the formal verification of the chip. It is only necessary to ensure that the number of FIFO data in the chip remains unchanged, and only a small number of bits in the data are stored in the FIFO.

[0153] An embodiment of the present application also provides a computer device, including a processor and a memory, wherein the memory stores computer instructions, and the processor executes the computer instructions to implement the chip design verification method as described above.

[0154] An embodiment of the present application also provides a computer program, which is executed to implement the chip design verification method as described above.

[0155] Although the embodiments of the present application are disclosed above, the present application is not limited thereto. Any person skilled in the art may make various changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims.

Claims

1. A chip design verification method, characterized in that: include: Obtaining a chip design to be tested and executing the chip design to be tested; During execution of the chip design under test, when it is detected that a current transaction processed by the chip design under test generates a blocking delay due to an input blocking condition, if it is determined that the blocking delay exceeds a preset upper limit of blocking cycles, the blocking delay generated by the input blocking condition is released, and the current transaction is continued to be processed; During the process of continuing to process the current transaction, if it is detected that the current transaction generates a transaction processing delay due to a non-input blocking condition, it is determined whether the transaction processing delay exceeds a preset delay upper limit. If so, an error indication is returned; wherein the transaction processing delay is the time difference between the time when the start signal of the current transaction is valid and the time when the completion signal is valid.

2. The chip design verification method according to claim 1, wherein: In the process of continuing to process the current transaction, if it is detected that the current transaction generates a transaction processing delay due to a non-input blocking condition, the step of determining whether the transaction processing delay exceeds a preset delay upper limit includes: Splitting the current transaction into multiple secondary transactions, and extracting a checkpoint of each secondary transaction; For each of the secondary transactions, detecting whether a secondary transaction processing delay of the secondary transaction exceeds a preset delay upper limit; If the secondary transaction processing delay exceeds the preset delay upper limit, determining that the transaction processing delay of the current transaction exceeds the preset delay upper limit and returning an error indication; The secondary transaction processing delay is the time difference between the validity of the start signal and the validity of the completion signal between two adjacent secondary transaction checkpoints.

3. The chip design verification method according to claim 1, wherein: The step of detecting that the current transaction generates a transaction processing delay due to a non-input blocking condition, and then determining whether the transaction processing delay exceeds a preset delay upper limit, comprises: Detecting whether the current transaction is running; Calculating a transaction processing delay of the current transaction; The transaction processing delay is compared with the preset delay upper limit, and a timeout flag is output according to the comparison result, so as to output a corresponding assertion according to the timeout flag.

4. The chip design verification method according to claim 1, wherein: The input blocking condition includes at least one of a credit signal blocking, a ready signal blocking, or a confirmation signal blocking; The input blocking condition also includes: request signal blocking or clock request signal blocking.

5. The chip design verification method according to claim 4, wherein: When the input blocking condition includes a credit signal blocking, the step of detecting, during the execution of the chip design under test, that a current transaction processed by the chip design under test generates a blocking delay due to the input blocking condition comprises: Recording the number of credits in the chip design under test that the receiver has received requests for but has not released; Record the number of clock cycles during which the receiver in the chip under test has credits to be released but has not released any credits; comparing whether the number of clock cycles during which the receiver has credit to be released but has not released the credit exceeds a preset maximum waiting period; If the preset maximum waiting period is exceeded, a credit is released.

6. The chip design verification method according to claim 4, wherein: The input blocking condition includes a ready signal being blocked, and the step of detecting, during the execution of the chip design under test, that a current transaction processed by the chip design under test generates a blocking delay due to the input blocking condition, comprises: Count the number of clock cycles during which the data sender experiences back pressure. Compare the value of the back pressure cycle counter to see if it is greater than or equal to the preset maximum back pressure cycle parameter; When the value of the back pressure cycle counter is greater than or equal to a preset maximum back pressure cycle parameter, the state of the ready signal becomes valid.

7. The chip design verification method according to claim 4, wherein: The input blocking condition includes a confirmation signal blocking, and the step of detecting that a current transaction processed by the chip design under test generates a blocking delay due to the input blocking condition during the execution of the chip design under test comprises: Detect the status of the request / confirmation handshake connection and record whether the sender is waiting for the receiver to pull up / low the confirmation signal; Record the number of clock cycles the sender waits for confirmation of the high / low status after raising / lowering the request; Maintaining the expected value of the confirmation signal; The constraint confirmation signal is equal to the value of the confirmation register; The confirmation parameter storage module is further configured with a stability assumption attribute, a range assumption attribute and an equality assumption attribute.

8. The chip design verification method according to claim 1, wherein: After the step of obtaining the chip design to be tested, the method further includes: Obtaining a data transmission queue for the chip design under test, wherein the data transmission queue is used to cache content requested for the chip design under test; The bit width of the data transmission queue is reduced to execute the chip design under test based on the data transmission queue.

9. The chip design verification method according to claim 8, wherein: The step of obtaining the data transmission queue of the chip under test design and reducing the bit width of the data transmission queue includes: Obtaining the design files and file list files of the chip to be tested; Determining whether the file name of the design file is the same as the file name of the target design file; Determining whether a parameter row for instantiating a data transmission queue in the design file matches a parameter row for instantiating a data transmission queue in the target design file; If they match, determining whether the write data port of the data transmission queue in the design file matches the write data port of the data transmission queue in the target design file; If there is a match, the high-order data and the low-order data in the data transmission queue are spliced ​​to obtain spliced ​​data, and bound to the write data port of the data transmission queue in the design file to obtain a second design file, which includes the data transmission queue after reducing the bit width of the data transmission queue.

10. A chip design verification device, characterized in that: include: A chip design execution module for obtaining a chip design for testing and executing the chip design for testing; a constraint unit, configured to, when detecting that a current transaction processed by the chip design under test generates a blocking delay due to an input blocking condition during execution of the chip design under test, release the blocking delay generated by the input blocking condition and continue processing the current transaction if it is determined that the blocking delay exceeds an upper limit of a preset blocking cycle number; A delay checker is configured to, while continuing to process the current transaction, determine whether the transaction processing delay exceeds a preset delay limit if it is detected that the current transaction generates a transaction processing delay due to a non-input blocking condition, and if so, return an error indication; wherein the transaction processing delay is the time difference between the time when the start signal of the current transaction is valid and the time when the completion signal is valid.

11. The chip design verification device according to claim 10, wherein: The chip design execution module to be tested, the constraint unit, and the delay checker are located in a verification platform. The chip design verification device further includes: A formal verification tool is used to perform formal verification on the chip design to obtain a verification result.

12. The chip design verification device according to claim 10, wherein: The input blocking condition includes at least one of a credit signal blocking, a ready signal blocking, or a confirmation signal blocking; The constraint unit includes: at least one of a credit constraint unit, a readiness constraint unit, and a confirmation constraint unit; The input blocking condition also includes: request signal blocking or clock request signal blocking; The constraint unit further includes a request constraint unit or a clock request constraint unit.

13. The chip design verification device according to claim 12, wherein: The request constraint unit includes: At least one request constraint logic, each request constraint logic corresponding to a virtual channel of the chip under test design, the request constraint logic being configured to constrain the corresponding virtual channel to send a request for the corresponding virtual channel when credit is sufficient; Request field assumption attributes are used to enforce validity constraints on request fields.

14. The chip design verification device according to claim 13, wherein: The request constraint logic includes: A credit counter, used to record the number of credits available to the sender and output a permission-to-send signal to the request valid hypothesis attribute; The request valid assumption attribute is used to constrain the request of the corresponding virtual channel not to be sent when the permission to send signal is invalid.

15. The chip design verification device according to claim 12, wherein: The clock request constraint unit includes: Clock request beat register, used to beat the input clock request register; A clock request hold flag, used to record whether the input clock request should be held currently; a clock request hold counter, for recording the number of clock cycles during which the input clock request is held; Stability assumption attribute, used to constrain the input clock request to remain stable when the clock request flag is valid; The clock request parameter module is used to store a preset clock request holding period.

16. The chip design verification device according to claim 10, wherein: The chip design under test also includes: a data transmission queue management module, which is used to obtain the data transmission queue of the chip design under test, and the data transmission queue is used to cache the requested content of the chip design under test; and reduce the bit width of the data transmission queue to execute the chip design under test based on the data transmission queue.

17. A computer device, characterized in that: The method comprises a processor and a memory, wherein the memory stores computer instructions, and the processor executes the computer instructions to implement the chip design verification method according to any one of claims 1 to 9.

18. A computer program, characterized in that The computer program is executed to implement the chip design verification method according to any one of claims 1 to 9.

Images