Network-on-chip NoC verification method and device, electronic equipment, storage medium and program product

Abstract

The present disclosure relates to the field of chip verification, and provides a network-on-chip (NoC) verification method, device, electronic equipment, storage medium and program product. The method comprises: generating a common excitation sequence of multiple bus protocols according to a common part of a verification process corresponding to each bus protocol; generating an exclusive excitation sequence of each bus protocol according to an exclusive part of a verification process corresponding to each bus protocol and the common excitation sequence, wherein the exclusive excitation sequence comprises the content of the common excitation sequence; determining a corresponding excitation sequence set of each host according to the exclusive excitation sequence of the bus protocol of each host; and verifying the NoC based on the excitation sequence set. The NoC verification method provided by the present disclosure can save the time cost and labor cost of developing and maintaining the excitation sequence, and improve the verification efficiency.

Description

Technical Field

[0001] This disclosure relates to the field of chip verification, and more particularly to a method, apparatus, electronic device, storage medium, and program product for verifying a network-on-a-chip (NoC). Background Technology

[0002] Verifying the network-on-chip (NoC) within a large-scale system-on-chip (SoC) is one of the most challenging tasks in the current chip verification field. SoCs integrate dozens or even hundreds of master and slave devices, each slave device comprising multiple address regions. Therefore, verification may require accessing hundreds or thousands of address regions, leading to increasingly higher demands for complexity, coverage, and efficiency.

[0003] Traditional NoC verification is divided into multiple verification stages. After the previous verification stage passes, a dedicated stimulus sequence is developed for the next verification stage, and the stimulus sequence is used to complete the verification of the next stage. This progressive development approach has an excessively long development cycle, requires the development of too many types of stimulus sequences, and involves a large amount of duplicate code between different stimulus sequences. This results in high time and manpower costs for developing and maintaining stimulus sequences, reducing verification efficiency. Summary of the Invention

[0004] In view of this, this disclosure proposes a method, apparatus, electronic device, storage medium, and program product for verifying on-chip network NoCs. The on-chip network NoC verification method of this disclosure can save time and manpower costs in developing and maintaining stimulus sequences, and improve verification efficiency.

[0005] According to one aspect of this disclosure, a verification method for a network-on-a-chip (NoC) is provided, wherein the NoC connects to multiple hosts. The method includes: generating a common stimulus sequence for the multiple bus protocols based on a common portion of the verification process corresponding to each bus protocol; generating a unique stimulus sequence for each bus protocol based on a unique portion of the verification process corresponding to each bus protocol and the common stimulus sequence, wherein the unique stimulus sequence includes the content of the common stimulus sequence; determining a set of stimulus sequences for each host based on the unique stimulus sequence of the bus protocol for each host; and verifying the NoC based on the set of stimulus sequences.

[0006] In one possible implementation, verifying the NoC based on the set of stimulus sequences further includes: scheduling the set of stimulus sequences corresponding to each host based on a scheduling sequence to verify the NoC.

[0007] In one possible implementation, scheduling the stimulus sequence set corresponding to each host to verify the NoC includes: defining a first process in the environment component, the first process being used to execute received progress events; defining a second process in the verification component, the second process being used to configure the environment component; after the second process completes the configuration of the environment component, the main process of the environment component passes the next event to be executed to the first process; when the first process executes the received progress event, scheduling the stimulus sequence set corresponding to at least one host associated with the progress event to verify the NoC; after the first process completes the execution of each event, the main process notifies the second process to configure the environment component.

[0008] In one possible implementation, the scheduling sequence indicates that the scheduling mode is either a serial scheduling mode or a parallel scheduling mode.

[0009] In one possible implementation, the main process notifying the second process to configure the environment component includes: the main process passing a notification event to the verification component; scheduling the stimulus sequence set corresponding to each host to verify the NoC further includes: when the next event to be executed is not the simulation end event, the main process enters a blocked state and waits for a response event from the verification component; the main process of the environment component passing the next event to be executed to the first process includes: after receiving the response event, the main process exits the blocked state and passes the next event to be executed to the first process.

[0010] In one possible implementation, the second process configures the environment component by: after detecting that the verification component has received the notification event, the second process determines whether the next event to be executed is a simulation end event based on the notification event, configures the environment component according to the determination result, and after the configuration is completed, passes a response event to the environment component.

[0011] In one possible implementation, configuring the environment component based on the judgment result includes: reading the execution result of the completed progress event from the environment component; and providing the environment component with the data used for the next event to be executed when the next event to be executed is not the simulation end event.

[0012] In one possible implementation, the operation process of the stimulus sequence set corresponding to the host includes: in the initialization phase, acquiring the attribute information of the host; in the verification phase, starting a third process, a fourth process, and a fifth process, wherein the third process is used to send a request to the slave device according to the attribute information, the fourth process is used to receive a response from the slave device, and the fifth process is used to trigger a signal indicating the exit of the third process.

[0013] In one possible implementation, sending a request to the slave device based on the attribute information includes: determining whether the third process meets a first termination condition; generating a request transaction packet based on the attribute information when the third process does not meet the first termination condition; performing a validity check on the request transaction packet using a first checking function; and sending the request transaction packet when the request transaction packet is valid.

[0014] In one possible implementation, the first checking function is associated with the set of excitation sequences, and the first checking function is different for different sets of excitation sequences.

[0015] In one possible implementation, the attribute information includes a loop count threshold. When the loop count of the third process equals the loop count threshold, the first termination condition is determined to be satisfied. In the case of scheduling multiple sets of stimulus sequences corresponding to multiple hosts, the first termination condition is determined to be satisfied when the set of stimulus sequences corresponding to a host is the currently only running set of stimulus sequences. When a signal indicating that the third process should be exited is received, the first termination condition is determined to be satisfied.

[0016] In one possible implementation, receiving a response from the slave device includes: determining whether the fourth process meets the second termination condition; when the fourth process does not meet the second termination condition, calling a response acquisition function to acquire the response transaction packet when the slave device returns a response transaction packet; and using a second checking function to verify the response transaction packet.

[0017] In one possible implementation, the second checking function is associated with the set of excitation sequences, and the second checking function is different for different sets of excitation sequences.

[0018] In one possible implementation, the second termination condition is determined to be satisfied when the third process has ended and the number of request transaction packets sent is equal to the number of response transaction packets received.

[0019] In one possible implementation, the attribute information includes a time threshold and a sent request threshold, triggering a signal indicating exit from the third process, including: triggering a signal indicating exit from the third process when the verification time of the stimulus sequence set corresponding to the host reaches the time threshold; and / or triggering a signal indicating exit from the third process when the number of sent request transaction packets reaches the sent request threshold.

[0020] According to another aspect of this disclosure, a verification apparatus for a network-on-chip (NoC) is provided, wherein the NoC connects to multiple hosts. The apparatus includes: a first generation module, configured to generate a common stimulus sequence for the multiple bus protocols based on a common part of the verification process corresponding to the multiple bus protocols; a second generation module, configured to generate a unique stimulus sequence for each bus protocol based on a unique part of the verification process corresponding to each bus protocol and the common stimulus sequence, wherein the unique stimulus sequence includes the content of the common stimulus sequence; a determination module, configured to determine a set of stimulus sequences corresponding to each host based on the unique stimulus sequence of the bus protocol of each host among the multiple hosts; and a verification module, configured to verify the NoC based on the set of stimulus sequences.

[0021] In one possible implementation, verifying the NoC based on the set of stimulus sequences includes: scheduling the set of stimulus sequences corresponding to each host based on a scheduling sequence to verify the NoC.

[0022] In one possible implementation, scheduling the stimulus sequence set corresponding to each host to verify the NoC includes: defining a first process in the environment component, the first process being used to execute received progress events; defining a second process in the verification component, the second process being used to configure the environment component; after the second process completes the configuration of the environment component, the main process of the environment component passes the next event to be executed to the first process; when the first process executes the received progress event, scheduling the stimulus sequence set corresponding to at least one host associated with the progress event to verify the NoC; after the first process completes the execution of each event, the main process notifies the second process to configure the environment component.

[0023] In one possible implementation, the scheduling sequence indicates that the scheduling mode is either a serial scheduling mode or a parallel scheduling mode.

[0024] In one possible implementation, the main process notifying the second process to configure the environment component includes: the main process passing a notification event to the verification component; scheduling the stimulus sequence set corresponding to each host to verify the NoC further includes: when the next event to be executed is not the simulation end event, the main process enters a blocked state and waits for a response event from the verification component; the main process of the environment component passing the next event to be executed to the first process includes: after receiving the response event, the main process exits the blocked state and passes the next event to be executed to the first process.

[0025] In one possible implementation, the second process configures the environment component by: after detecting that the verification component has received the notification event, the second process determines whether the next event to be executed is a simulation end event based on the notification event, configures the environment component according to the determination result, and after the configuration is completed, passes a response event to the environment component.

[0026] In one possible implementation, configuring the environment component based on the judgment result includes: reading the execution result of the completed progress event from the environment component; and providing the environment component with the data used for the next event to be executed when the next event to be executed is not the simulation end event.

[0027] In one possible implementation, the operation process of the stimulus sequence set corresponding to the host includes: in the initialization phase, acquiring the attribute information of the host; in the verification phase, starting a third process, a fourth process, and a fifth process, wherein the third process is used to send a request to the slave device according to the attribute information, the fourth process is used to receive a response from the slave device, and the fifth process is used to trigger a signal indicating the exit of the third process.

[0028] In one possible implementation, sending a request to the slave device based on the attribute information includes: determining whether the third process meets a first termination condition; generating a request transaction packet based on the attribute information when the third process does not meet the first termination condition; performing a validity check on the request transaction packet using a first checking function; and sending the request transaction packet when the request transaction packet is valid.

[0029] In one possible implementation, the first checking function is associated with the set of excitation sequences, and the first checking function is different for different sets of excitation sequences.

[0030] In one possible implementation, the attribute information includes a loop count threshold. When the loop count of the third process equals the loop count threshold, the first termination condition is determined to be satisfied. In the case of scheduling multiple sets of stimulus sequences corresponding to multiple hosts, the first termination condition is determined to be satisfied when the set of stimulus sequences corresponding to a host is the currently only running set of stimulus sequences. When a signal indicating that the third process should be exited is received, the first termination condition is determined to be satisfied.

[0031] In one possible implementation, receiving a response from the slave device includes: determining whether the fourth process meets the second termination condition; when the fourth process does not meet the second termination condition, calling a response acquisition function to acquire the response transaction packet when the slave device returns a response transaction packet; and using a second checking function to verify the response transaction packet.

[0032] In one possible implementation, the second checking function is associated with the set of excitation sequences, and the second checking function is different for different sets of excitation sequences.

[0033] In one possible implementation, the second termination condition is determined to be satisfied when the third process has ended and the number of request transaction packets sent is equal to the number of response transaction packets received.

[0034] In one possible implementation, the attribute information includes a time threshold and a sent request threshold, triggering a signal indicating exit from the third process, including: triggering a signal indicating exit from the third process when the verification time of the stimulus sequence set corresponding to the host reaches the time threshold; and / or triggering a signal indicating exit from the third process when the number of sent request transaction packets reaches the sent request threshold.

[0035] According to another aspect of this disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above-described method.

[0036] According to another aspect of this disclosure, a non-volatile computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the above-described method.

[0037] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0038] According to the on-chip network NoC verification method of this disclosure, a common stimulus sequence for multiple bus protocols is generated based on the common part of the verification process corresponding to multiple bus protocols; a unique stimulus sequence for each bus protocol is generated based on the unique part of the verification process corresponding to each bus protocol and the common stimulus sequence, wherein the unique stimulus sequence includes the content of the common stimulus sequence; a set of stimulus sequences corresponding to each host is determined based on the unique stimulus sequence of the bus protocol of each host; and the NoC is verified based on the set of stimulus sequences.

[0039] In this way, the construction of verification stimulus sequences or sets of verification stimulus sequences can be completed simply by developing a unified general stimulus sequence and a unique stimulus sequence for each bus protocol. Therefore, the solution disclosed herein can save time and manpower costs in developing stimulus sequences. When code modifications are required, involving modifications to common parts corresponding to multiple bus protocols, only the general stimulus sequence needs to be modified once, without repeated modifications; if a new bus protocol is added, only a unique stimulus sequence corresponding to that bus protocol needs to be developed separately, saving time and manpower costs in maintaining stimulus sequences. In summary, the on-chip network (NoC) verification method of this disclosure can save time and manpower costs in developing and maintaining stimulus sequences, and improve verification efficiency.

[0040] Other features and aspects of this disclosure will become clear from the following detailed description of exemplary embodiments with reference to the accompanying drawings. Attached Figure Description

[0041] The accompanying drawings, which are included in and form part of this specification, illustrate exemplary embodiments, features, and aspects of this disclosure together with the specification and serve to explain the principles of this disclosure.

[0042] Figure 1 This illustrates an exemplary application scenario of the verification method for a network-on-chip (NoC) according to embodiments of the present disclosure.

[0043] Figure 2 A schematic diagram illustrating the flow of a verification method for a Network on Chip (NoC) according to an embodiment of this disclosure is shown.

[0044] Figure 3 A schematic diagram illustrating the workflow of the main process, the first process, and the second process of the environment component according to an embodiment of the present disclosure is shown.

[0045] Figure 4 This diagram illustrates the flow of a third process sending a request to a slave device based on attribute information, according to an embodiment of the present disclosure.

[0046] Figure 5 A schematic diagram illustrating the flow of a fourth process receiving a response from a slave device according to an embodiment of this disclosure is shown.

[0047] Figure 6 A schematic diagram showing the structure of a verification device for a Network-on-Chip (NoC) according to an embodiment of the present disclosure is provided.

[0048] Figure 7 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0049] Various exemplary embodiments, features, and aspects of this disclosure will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0050] As used herein, the terms “comprising,” “including,” “having,” or variations thereof are open-ended and include one or more of the stated features, integrals, elements, steps, components, or functions, but do not exclude the presence or addition of one or more other features, integrals, elements, steps, components, functions, or groups thereof.

[0051] When an element is referred to as “connected,” “coupled,” “responding,” or a variation thereof relative to another element, it may be directly connected, coupled, or responding to another element, or there may be an intermediate element present.

[0052] Although the terms first, second, third, etc., may be used herein to describe various elements / operations, these elements / operations should not be limited by these terms. These terms are only used to distinguish one element / operation from another. Therefore, without departing from the teachings of the inventive concept, a first element / operation in some embodiments may be referred to as a second element / operation in other embodiments.

[0053] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0054] Furthermore, to better illustrate this disclosure, numerous specific details are set forth in the following detailed description. Those skilled in the art will understand that this disclosure can be practiced without certain specific details. In some instances, methods, means, components, and circuits well known to those skilled in the art have not been described in detail in order to highlight the main points of this disclosure.

[0055] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant regions.

[0056] The NoC's verification approach involves attaching the Verification Intellectual Property (VIP) of both the host and slave devices to the NoC. The NoC's functionality is verified by having one or more host VIPs access different address spaces of one or more slave VIPs. Successful access indicates the NoC is functioning correctly; failure indicates a malfunction.

[0057] Traditional NoC verification schemes consist of multiple verification phases. After setting up the verification environment and attaching the VIP, the conventional approach is to develop and debug the stimulus sequence step by step according to the different verification phases. Taking the Advanced eXtensible Interface (AXI) protocol as an example, the verification process is as follows:

[0058] 1. In the first stage, we develop the minimum granularity stimulus sequence (mini sequence) and debug and iterate on the mini sequence. The main purpose of the mini sequence is to access the set of starting addresses of the address space accessible by the host.

[0059] 2. In the second stage, the boundary sequence is developed and debugged and iterated. The main purpose of the boundary sequence is to access the set of start and end addresses of the host's accessible address space.

[0060] 3. In the third stage, we will develop a single random sequence and debug and iterate on it. The main purpose of the single random sequence is to randomly access a segment of addresses within the address space accessible to the host.

[0061] 4. In the fourth stage, we will develop high-pressure excitation sequences for four scenarios and debug and iterate on the four stress sequences. The four scenarios include single host accessing single slave, single host accessing multiple slaves, multiple hosts accessing single slave, and multiple hosts accessing multiple slaves.

[0062] 5. The fifth stage involves developing an illegal sequence and debugging and iterating on it. The main purpose of the illegal sequence is to access the set of all address spaces that are inaccessible to the host.

[0063] Traditional verification methods only develop a dedicated stimulus sequence for the next verification stage after the previous stage has passed verification, and then use the stimulus sequence to complete the verification of the next stage. This progressive development approach has the following drawbacks:

[0064] 1. The development cycle is too long, there are too many types of incentive sequences to develop, and even basic sequence modifications need to take into account multiple incentive sequences.

[0065] 2. Some stimulus sequences differ only in whether the stimulus transmission is parallel, leading to the maintenance of a large amount of duplicate code.

[0066] 3. When the host uses a bus with other protocols, the corresponding five stages and eight stimulus sequences need to be redeveloped and debugged, making it impossible to adapt quickly.

[0067] 4. The learning cost is high, and the incentive sequence needs to include random constraints, which increases the complexity of the incentive sequence.

[0068] In view of this, this disclosure proposes a method, apparatus, electronic device, storage medium, and program product for verifying on-chip network NoCs. The on-chip network NoC verification method of this disclosure can save time and manpower costs in developing and maintaining stimulus sequences, and improve verification efficiency.

[0069] Figure 1 This illustrates an exemplary application scenario of the verification method for a network-on-chip (NoC) according to embodiments of the present disclosure.

[0070] like Figure 1 As shown, the design under test 10 is an on-chip network of a system-on-a-chip (SoC) 100, connecting the host M1-host M3 and slave S1-S3 of the SoC 100. Each slave includes at least one address space. Slave S1 includes address spaces add1, add2, and add3; slave S2 includes address spaces add4 and add5; and slave S3 includes address space add6.

[0071] Each host's access permissions to the address space can be pre-configured. For example, host M1 can access address spaces add1, add2, add4, and add5, but cannot access address spaces add3 and add6. Host M2 can access address spaces add1, add3, add4, and add5, but cannot access address spaces add2 and add6. Host M3 can access address space add6, but cannot access address spaces add1 through add5.

[0072] The processor executes the on-chip network NoC verification method of this disclosure embodiment, which can drive the host to send a request transaction packet. The request transaction packet may be a read / write request to access the address space on the slave device. The request transaction packet is transmitted to the slave device through the design under test 10. The slave device responds to the request transaction packet and returns a response transaction packet to the host that sent the request transaction packet through the design under test 10. If the host successfully receives the response transaction packet and determines that the response is normal based on the response transaction packet, the design under test 10 is considered to be functioning normally. Otherwise, the design under test 10 is considered to be malfunctioning.

[0073] Figure 2 A schematic diagram illustrating the flow of a verification method for a Network on Chip (NoC) according to an embodiment of this disclosure is shown.

[0074] like Figure 2 As shown, in one possible implementation, the NoC connects multiple hosts, and the method includes:

[0075] Step S21: Generate a common stimulus sequence for multiple bus protocols based on the common part of the verification process corresponding to multiple bus protocols;

[0076] Step S22: Based on the unique part of the verification process corresponding to each of the multiple bus protocols and the general stimulus sequence, generate a unique stimulus sequence for each bus protocol. The unique stimulus sequence includes the content of the general stimulus sequence.

[0077] Step S23: Determine the set of excitation sequences corresponding to each host based on the unique excitation sequence of the bus protocol for each host among the multiple hosts; and

[0078] Step S24: Verify NoC based on the set of excitation sequences.

[0079] Verification may involve various bus protocols, such as AXI, Advanced High-performance Bus (AHB), and Advanced Peripheral Bus (APB). Different bus protocols share common verification processes, such as the host's outstanding depth management and host request ID management. Each bus protocol also has unique verification processes, such as the rules governing the flag values ​​carried in the slave's response (which values ​​indicate a normal response and which indicate a failed response).

[0080] In step S21, a common stimulus sequence for multiple bus protocols can be generated based on the common parts of the verification processes corresponding to multiple bus protocols. In step S22, a unique stimulus sequence for each bus protocol can be generated based on the unique parts of the verification process corresponding to each bus protocol and the common stimulus sequence. The unique stimulus sequence includes the content of the common stimulus sequence. That is, when using a class as the sequence implementation method, the common stimulus sequence can be the parent class, and the unique stimulus sequence can be the subclass that inherits from the parent class.

[0081] In step S23, a set of stimulus sequences corresponding to each host can be determined based on the unique stimulus sequence of each host's bus protocol. In one instance, the set of stimulus sequences can be obtained by instantiating the unique stimulus sequence; therefore, the set of stimulus sequences is referred to as a stimulus sequence instance below. For example, for host M1 using the AXI protocol, the unique stimulus sequence of the AXI protocol can be instantiated to obtain the stimulus sequence instance corresponding to host M1. For host M2 using the AHB bus protocol, the unique stimulus sequence of the AHB protocol can be instantiated to obtain the stimulus sequence instance corresponding to host M2. For host M3 using the APB bus protocol, the unique stimulus sequence of the APB protocol can be instantiated to obtain the stimulus sequence instance corresponding to host M3.

[0082] In step S24, NoC can be verified based on the set of excitation sequences.

[0083] For example, a request transaction packet can be issued and a response transaction packet can be received based on the set of stimulus sequences, and the verification result can be determined based on the reception of the response transaction packet.

[0084] According to the on-chip network NoC verification method of this disclosure, a common stimulus sequence for multiple bus protocols is generated based on the common part of the verification process corresponding to multiple bus protocols; a unique stimulus sequence for each bus protocol is generated based on the unique part of the verification process corresponding to each bus protocol and the common stimulus sequence, wherein the unique stimulus sequence includes the content of the common stimulus sequence; a set of stimulus sequences corresponding to each host is determined based on the unique stimulus sequence of the bus protocol of each host; and the NoC is verified based on the set of stimulus sequences.

[0085] In this way, the construction of verification stimulus sequences or sets of verification stimulus sequences can be completed simply by developing a unified general stimulus sequence and a unique stimulus sequence for each bus protocol. Therefore, the solution disclosed herein can save time and manpower costs in developing stimulus sequences. When code modifications are required, involving modifications to common parts corresponding to multiple bus protocols, only the general stimulus sequence needs to be modified once, without repeated modifications; if a new bus protocol is added, only a unique stimulus sequence corresponding to that bus protocol needs to be developed separately, saving time and manpower costs in maintaining stimulus sequences. In summary, the on-chip network (NoC) verification method of this disclosure can save time and manpower costs in developing and maintaining stimulus sequences, and improve verification efficiency.

[0086] In one possible implementation, verifying NoC based on a set of excitation sequences includes:

[0087] The NoC is validated by scheduling the stimulus sequence instances (also referred to as stimulus sequence sets) corresponding to each host based on the scheduling sequence. It should be understood that the stimulus sequence or stimulus sequence set mentioned in this paper can be implemented as an instance of a class, or it can be implemented in other forms.

[0088] The scheduling sequence implements control functions during the verification process, responsible for scheduling the stimulus sequence sets corresponding to each host. In one example, verifying the NoC based on the stimulus sequence set includes: scheduling the stimulus sequence sets corresponding to each host to verify the NoC. In this case, only the scheduling sequence needs to be developed in advance, and the verification can be completed by combining the scheduling sequence and the stimulus sequence sets corresponding to each host, reducing scheduling complexity.

[0089] The scheduling sequence can include verification parameters such as the host's scheduling mode and progress events. Verification parameters can be passed to the scheduling sequence via command line. The scheduling sequence can schedule the corresponding stimulus sequence instances for each host to verify the NoC based on the verification parameters. This unified control of the verification process through parameter passing eliminates the need to develop separate stimulus sequences for different stages and protocols of testing.

[0090] In one possible implementation, the scheduling sequence indicates that the host's scheduling mode is either serial scheduling mode or parallel scheduling mode.

[0091] by Figure 1 For example, assume that hosts M1, M2, and M3 all need to be scheduled.

[0092] The serial scheduling mode requires that only one host is transmitting stimulus at any given time (corresponding to the mini sequence, boundary sequence, and single random sequence in traditional verification schemes). When the scheduling sequence indicates that the host's scheduling mode is serial, the scheduling sequence can first schedule the stimulus sequence instance corresponding to host M1. After the stimulus sequence instance corresponding to host M1 finishes running, the stimulus sequence instance corresponding to host M2 will be scheduled. After the stimulus sequence instance corresponding to host M2 finishes running, the stimulus sequence instance corresponding to host M3 will be scheduled.

[0093] There are two parallel scheduling modes. One is the parallel scheduling mode without random delay, which requires all hosts to transmit stimuli simultaneously. When the scheduling sequence indicates that the host's scheduling mode is the parallel scheduling mode without random delay, the scheduling sequence can simultaneously schedule the stimuli sequence instances corresponding to host M1, host M2, and host M3.

[0094] Another parallel scheduling mode is the parallel scheduling mode with random delay, which requires at least one host to transmit stimulus at the same time. When the scheduling sequence indicates that the host's scheduling mode is the parallel scheduling mode with random delay, the scheduling sequence can randomly generate the delays corresponding to host M1, host M2, and host M3. Taking the trigger time of step S24 as the starting point, after passing the delay corresponding to host M1, the stimulus sequence instance corresponding to host M1 is scheduled; taking the trigger time of step S24 as the starting point, after passing the delay corresponding to host M2, the stimulus sequence instance corresponding to host M2 is scheduled; taking the trigger time of step S24 as the starting point, after passing the delay corresponding to host M3, the stimulus sequence instance corresponding to host M3 is scheduled.

[0095] The scheduling mode can be dynamically adjusted by passing parameters via the command line to adapt to the verification requirements of different verification stages.

[0096] In one possible implementation, the scheduling sequence indicates multiple progress events, each associated with at least one host.

[0097] In some embodiments, scheduling the stimulus sequence set corresponding to each host to verify the NoC includes:

[0098] Define a first process in the environment component; the first process is used to execute the received progress events.

[0099] The verification component defines a second process, which is used to configure environment components;

[0100] After the second process completes the configuration of the environment components, the main process of the environment components passes the next event to be executed to the first process; when the first process executes the received progress event, it schedules at least one set of stimulus sequences corresponding to the host associated with the progress event to verify the NoC; after the first process executes each event, the main process notifies the second process to configure the environment components.

[0101] Step S24 is executed by the processor's verification module, which includes an environment component and a verification component.

[0102] The verification module can define a first process in the environment component based on the scheduling sequence. This first process is used to execute received events. The verification module can also define a second process in the verification component based on the scheduling sequence. This second process is used to configure the environment component. The environment component requires different configurations for different events. After each progress event is executed, the environment component must be reconfigured before executing the next progress event. The environment component also needs to be reconfigured after the last progress event is executed. However, there are no restrictions on the order of executing the next event (i.e., the simulation end event) and configuring the environment component.

[0103] Therefore, after the second process completes the configuration of the environment components based on the scheduling sequence instructions, the main process of the environment components, based on the scheduling sequence instructions, passes the next event to be executed to the first process. When the first process executes the received progress event based on the scheduling sequence instructions, it schedules at least one stimulus sequence instance corresponding to the host associated with the progress event to verify the NoC. After the first process finishes executing the retrieved event, it can notify the main process that the retrieved event has been completed. Then, the main process notifies the second process to configure the environment components.

[0104] For example, suppose progress event 1 is associated with hosts M1 and M2, and progress event 2 is associated with hosts M1 and M3. After receiving progress event 1, the first process can schedule the stimulus sequence instances corresponding to hosts M1 and M2 to verify the NoC. After progress event 1 is completed, the first process notifies the main process that progress event 1 has been completed. The main process notifies the second process to configure the environment components. After configuration, the main process sends progress event 2 to the first process. After receiving progress event 2, the first process can schedule the stimulus sequence instances corresponding to hosts M1 and M3 to verify the NoC.

[0105] Defining a first process in the environment component to execute events, which does not interfere with the main process of the environment component, improves the accuracy of verification. Defining a second process in the verification component to detect whether the verification component has received a notification event, which also does not interfere with the main process of the verification component, improves the accuracy of verification.

[0106] In one possible implementation, the main process of the environment component passes the next event to be executed to the first process, including:

[0107] The main process stores multiple progress events into the event queue and stores the simulation end event at the tail of the event queue;

[0108] The main process retrieves the event at the head of the event queue and passes the retrieved event to the first process.

[0109] For example, the main process can store multiple progress events into an event queue, which can be a first-in, first-out (FIFO) storage queue. The simulation end event (SIM_DONE event) can be stored at the tail of the event queue. The main process can retrieve an event (the next event to be executed) from the head of the event queue and pass it to the first process.

[0110] After retrieving an event from the head of the event queue, the next event in the queue automatically becomes the new head. In this way, all progress events can be retrieved sequentially and passed to the first process. When the simulation end event is finally retrieved, it can be determined that the simulation is about to end, allowing the execution of the stimulus sequence instance to be terminated promptly.

[0111] In one possible implementation, the main process notifies the second process of the configuration environment component by: the main process passing the notification event to the verification component;

[0112] Scheduling the stimulus sequence set corresponding to each host to verify NoC also includes: when the next event to be executed is not the simulation end event, the main process enters a blocked state and waits for a response event from the verification component;

[0113] The main process of the environment component passes the next event to be executed to the first process, including: after receiving the response event, the main process exits the blocked state and passes the next event to be executed to the first process.

[0114] For example, once the main process determines that an event has been completed, it can pass a notification event to the verification component. The verification component then completes the configuration of the environment component based on the notification event. After the environment component is configured, the verification component passes a response event to the environment component. The main process can then determine that the environment component configuration is complete upon receiving the response event.

[0115] Once the environment component determines that an event has been completed, it can retrieve the next event to be executed from the head of the event queue. The retrieved event could be a progress event or a simulation end event. If the retrieved event is a progress event rather than a simulation end event, it must wait for the environment component to complete its configuration before execution. A blocked state is a working state in chip verification; when a module / process is in a blocked state, its work is paused, and it resumes normal operation after exiting the blocked state. Therefore, the main process can enter a blocked state and wait for a response event from the verification component. After receiving the response event, the main process exits the blocked state and passes the retrieved event to the first process. If the retrieved event is a simulation end event, it is not necessary to wait for the environment component to complete its configuration; the retrieved simulation end event can be directly passed to the first process.

[0116] By exchanging notification and response events between the verification component and the environment component, the environment component can be prevented from executing the next progress event prematurely, thus avoiding execution errors.

[0117] In one possible implementation, the second process configuration environment components include:

[0118] After the second process detects that the verification component has received a notification event, it determines whether the next event to be executed is the simulation end event based on the notification event. Based on the determination result, it configures the environment component and, after the configuration is completed, passes the response event to the environment component.

[0119] In one example, the notification component can carry information about the progress event indicating that the first process has completed execution. Upon receiving the notification event, the verification component can determine the next event to be executed based on the progress event information carried by the notification component, determine whether the next event is a simulation end event, and configure the environment component accordingly. After configuration, the second process can pass a response event to the environment component.

[0120] The verification component configures the environment component according to the progress event indicating completion of the notification event, so that the configured environment component can execute the next event and avoid execution errors caused by verification environment mismatch.

[0121] In one possible implementation, the method also includes:

[0122] The second process stops detecting once the simulation end event has been completed.

[0123] The second process continues to detect before the simulation end event has been completed.

[0124] For example, the second process can loop through and check whether the verification component has received a notification event. A notification event indicates a completed progress event. If the completed progress event is a simulation end event, it means there are no unexecuted events in the event queue. Therefore, the loop terminates when the simulation end event has been completed. That is, the second process stops checking when the simulation end event has been completed; it continues checking when the simulation end event has not been completed.

[0125] This method reduces unnecessary testing and lowers verification costs.

[0126] In one possible implementation, the environment components are configured based on the judgment result, including:

[0127] Read the execution result of the completed progress event from the environment component;

[0128] When the next event to be executed is not the simulation end event, provide the environment components with the data used by the next event to be executed.

[0129] Executing a progress event requires data, and an execution result is generated upon completion. Executing a simulation end event does not require data. If the next event to be executed is a simulation end event, configuring the environment component only requires reading the execution result of the completed progress event from the environment component. If the next event to be executed is not a simulation end event, in addition to reading the execution result of the completed progress event from the environment component, the data used by the next event to be executed must also be provided to the environment component. That is, regardless of whether the next event to be executed is a simulation end event, the execution result of the completed progress event is read from the environment component. If the next event to be executed is not a simulation end event, the data used by the next event to be executed is further provided to the environment component.

[0130] In this way, the environment components can be configured in different ways for different types of the next event to be executed, avoiding unnecessary configuration of the environment components.

[0131] Figure 3 A schematic diagram illustrating the workflow of the main process, the first process, and the second process of the environment component according to an embodiment of the present disclosure is shown.

[0132] like Figure 3As shown, in step S31, the main process of the environment component stores multiple progress events and simulation end events into an event queue, with the simulation end event located at the tail of the event queue. In step S32, the main process of the environment component retrieves the first event to be executed from the head of the event queue and passes the retrieved event to the first process. In step S33, the first process executes the received event. In step S34, after the main process of the environment component determines that the previously retrieved event has been executed, it passes the notification event to the verification component. In step S35, the main process of the environment component retrieves the event located at the head of the event queue. In step S36, if the retrieved event is not a simulation end event, the main process of the environment component enters a blocked state and waits for a response event from the verification component. In step S37, the second process detects that the verification component has received a notification event and calls the configuration task to configure the environment component. After configuration is completed, in step S38, the second process passes the response component to the environment component. In step S39, after receiving the response event, the main process of the environment component exits the blocked state and passes the retrieved event to the first process, then repeats step S34. In step S40, when the retrieved event is a simulation end event, the main process of the environment component passes the simulation end event to the first process. After receiving the event, the first process repeats step S33.

[0133] The following is combined Figure 3 The described verification process illustrates an example of transmission progress events, notification events, and response events according to embodiments of this disclosure.

[0134] First, store progress event 1, progress event 2, and simulation end event into the event queue. At this point, progress event 1 is at the head of the event queue and is the first event to be executed, while the simulation end event is at the tail of the event queue.

[0135] At the environment component level, the main process first retrieves progress event 1 from the head of the event queue and passes it to the first process, which then executes progress event 1. At this point, progress event 2 becomes the head of the event queue and is the next event to be executed. After the main process determines that progress event 1 has been completed, it passes a notification event to the verification component (the notification event carries the identifier of progress event 1) and retrieves progress event 2 from the head of the event queue. Progress event 2 is not the simulation end event, so the main process enters a blocked state and waits for a response event from the verification component. At this point, the simulation end event becomes the head of the event queue.

[0136] At the verification component, the second process detects that the verification component has received a notification event. Based on the identifier carried in the notification event, it determines that the most recently completed event was progress event 1, and that the next event to be executed is progress event 2. It then invokes a configuration task to configure the environment component. The configuration process includes reading the execution result of progress event 1 from the environment component and providing the environment component with the data used by progress event 2. After configuration is complete, a response event is passed to the environment component.

[0137] At the environment component level, after receiving the response event, the main process exits the blocked state and passes progress event 2 to the first process. The first process executes progress event 2. After the main process determines that progress event 2 has been completed, it passes a notification event to the verification component (the notification event carries the identifier of progress event 2), retrieves the simulation end event located at the head of the event queue, and the main process directly passes the simulation end event to the first process.

[0138] At the verification component, the second process detects that the verification component has received a notification event. Based on the identifier carried by the notification event, it determines that the most recently completed event is progress event 2, and determines that the next event to be executed is the simulation end event. It then calls the configuration task to configure the environment component. The configuration process includes reading the execution result of progress event 2 from the environment component.

[0139] After the first process executes the simulation end event, it can terminate the still running stimulus sequence instance.

[0140] In one possible implementation, the execution process of the stimulus sequence set corresponding to the host includes:

[0141] During the initialization phase, the host's attribute information is obtained;

[0142] During the verification phase, the third, fourth, and fifth processes are initiated. The third process is used to send requests to the slave device based on the attribute information, the fourth process is used to receive responses from the slave device, and the fifth process is used to trigger a signal indicating the exit of the third process.

[0143] The execution process of the stimulus sequence instance is mainly divided into an initialization phase and a verification phase. Both phases are completed by the verification module. The initialization phase completes the data preparation work for the verification phase, mainly obtaining the host's attribute information.

[0144] Taking the execution process of the excitation sequence instance corresponding to host M1 as an example, during the initialization phase, one or more of the following attribute information are mainly obtained:

[0145] Configuration parameters required when using random addresses can be passed via command-line arguments.

[0146] The slave devices that host M1 is allowed to access, the address space that host M1 is allowed to access, the slave devices that host M1 is not allowed to access, and the address space that host M1 is not allowed to access can be obtained from the resource manager.

[0147] The ID queue for host M1 is generated based on the headwind depth and the headwind type passed via command line. In one example, there are six headwind types: Type 1 means the host can only send one request packet at a time, and must receive the response packet corresponding to the previously sent request packet before sending the next request packet. Type 2 means the host can send A request packets at a time, where A equals half the headwind depth. Type 3 means the host can only send one write request packet and B read request packets at a time, where B equals the headwind depth. Type 4 means the host can send B write request packets and only one read request packet at a time. Type 5 means the host can send B read request packets and B write request packets at a time. Type 6 means the number of read and write request packets the host can send at a time is random. The generated ID queue may or may not contain duplicate IDs. A single ID queue can be generated, where IDs can be used by both read and write request transaction packets. Alternatively, two ID queues can be generated, with IDs in one queue used only by read request transaction packets and IDs in the other queue used only by write request transaction packets. The generation method of the ID queue can be adjusted according to the application scenario requirements; this disclosure does not limit the specific generation method of the ID queue.

[0148] The number of iterations adapted by host M1 can be determined based on the default number of iterations passed through the command line, as well as the host's bus type and advance depth. For example, if host M1's bus protocol is AHB / APB, it has no advance capability. To balance simulation time, the actual number of iterations can be controlled at 1 / 4 of the default number of iterations (or 1 / 6, 1 / 5, etc.). If host M1's bus protocol is AXI, it has advance capability but a smaller advance depth. The actual number of iterations can be controlled between 4 times the advance depth and 1 / 2 of the default number of iterations (or between 5 times the advance depth and 1 / 2 of the default number of iterations, or between 4 times the advance depth and 2 / 3 of the default number of iterations, etc.).

[0149] It should be understood that the host's attribute information may include more or less content, and the embodiments of this disclosure do not limit the content of the host's attribute information or the specific method of obtaining it.

[0150] After the initialization phase, the verification phase begins. During verification, the verification module initiates the third, fourth, and fifth processes. The third process, upon startup, generates request transaction packets based on attribute information and sends them to the slave devices. Upon receiving the request transaction packet, the slave device performs the corresponding operation based on the packet type (e.g., read / write) and returns a response transaction packet to the corresponding stimulus sequence instance on the master device. The fourth process, upon startup, is responsible for receiving response transaction packets from the slave devices. The fifth process is used to trigger a signal indicating the exit of the third process. After the third process exits, the verification phase ends.

[0151] Different processes are used to complete different tasks in the verification phase, thus avoiding overloading a single process.

[0152] In one possible implementation, a request is sent to the slave device based on attribute information, including:

[0153] Determine whether the third process meets the first termination condition;

[0154] When the third process does not meet the first termination condition, a request transaction packet is generated based on the attribute information;

[0155] Use the first check function to perform a validity check on the request transaction packet;

[0156] Send a request transaction packet if the request transaction packet is valid.

[0157] As mentioned above, attribute information includes the address space that the host is allowed to access and the address space that it is not allowed to access. In one example, sending a request to the slave device based on the attribute information includes:

[0158] Based on the allowed and disallowed address spaces of the host, a request transaction packet is generated. Taking host M1 as an example, according to a preset selection algorithm, one or more slave devices can be selected from the slave devices accessible to host M1 and stored in the slave queue. The slave queue is traversed, and the selection algorithm is used to select one or more address spaces from the address space of each slave device and store them in the address space queue. The address space queue is traversed, and according to a preset address segment random generation algorithm, one or more address segments are requested from each address space accessible to host M1. The length of the address segment can be randomly selected from 64B / 128B / 256B / 512B / 1024B / 2048B. The address segment and read / write operation are packaged into a structure and stored in the structure queue. The structure queue is traversed, and a request transaction packet is generated based on each structure.

[0159] The preset selection algorithm can achieve random selection, or it can achieve conditional selection, such as selecting from a specific position in the queue. This disclosure does not limit the specific selection mechanism of the selection algorithm.

[0160] Furthermore, the request transaction packet can be randomized with constraints, such as by extracting a portion of the address range carried in the request transaction packet, using the starting address of the extracted portion as the starting address of the transaction packet, and using the length of the extracted portion as the transmission length of the transaction packet.

[0161] Furthermore, when generating request transaction packets from a structure, IDs are typically assigned to the packets based on the host's maximum advance depth. However, actual testing may only require a portion of the advance depth (e.g., using only half the advance depth). Directly using the ID assigned to the request transaction packet during generation from the structure could cause the request transaction packet to exceed the concurrency limits of the current test scenario (determined by the advance type), thus defeating the test objective. Therefore, after generating the request transaction packet from the structure, the ID of the request transaction packet can be reset to ensure that the sent request transaction packet conforms to the dynamic constraints on advance capability in the current test scenario. This allows for precise control of the concurrent behavior of the request transaction packet, improving test accuracy, reducing learning costs, and decreasing the complexity of the stimulus sequence.

[0162] The first check function can be used to perform a validity check on the request transaction packet. The purpose of the validity check is to confirm whether the request transaction packet is valid (if valid, it can be sent). If the request transaction packet is valid, the request transaction packet is sent to the slave device.

[0163] In one possible implementation, the first check function is associated with a set of excitation sequences, and the first check function differs for different sets of excitation sequences.

[0164] For example, the first check function is an empty function in the general excitation sequence, which is reserved as a processing interface for various bus protocols. The specific implementation of the first check function is overridden in the excitation sequence instance.

[0165] This method avoids sending invalid request packets to the slave device, thus improving the accuracy of verification.

[0166] The process of generating the request transaction packet, checking its validity, and sending it when it is valid can be executed as a whole, looped multiple times. First, it can be determined whether the third process meets the first termination condition. If it does not, the process is executed again; if it does, it exits.

[0167] This method avoids reducing verification efficiency due to the third process running for too long.

[0168] The first termination condition can be triggered in multiple ways, and it can be determined at multiple nodes whether the third process meets the first termination condition.

[0169] In one possible implementation, the attribute information includes a loop count threshold.

[0170] When the number of iterations in the third process equals the iteration count threshold, the first termination condition is determined to be satisfied.

[0171] When scheduling multiple stimulus sequence sets corresponding to multiple hosts, the first termination condition is determined to be satisfied when the stimulus sequence set corresponding to a host is the only stimulus sequence set currently running.

[0172] Upon receiving a signal instructing the termination of the third process, it is determined that the first termination condition has been met.

[0173] For example, the attribute information includes a loop count threshold. After each request transaction packet is issued, the actual loop count of the third process is incremented by one. At this point, the actual loop count of the third process can be compared with the loop count threshold. If the actual loop count of the third process equals the loop count threshold, the test count requirement is considered met, and the test can end. That is, when the actual loop count of the third process equals the loop count threshold, the first termination condition is determined to be met.

[0174] For example, the scheduling sequence might schedule multiple stimulus sequence instances corresponding to multiple hosts, with the aim of testing whether the NoC supports communication from multiple hosts to a single slave or multiple slaves. If the actual loop count of the third process is less than the loop count threshold, it can be determined whether the stimulus sequence instance corresponding to the current host is the only running stimulus sequence instance. If the stimulus sequence instance corresponding to the current host is the only running stimulus sequence instance, it does not match the test requirements, and the test can be terminated. That is, when the actual loop count of the third process equals the loop count threshold, the first termination condition is determined to be met.

[0175] For example, receiving a signal indicating the termination of the third process directly also confirms that the first termination condition has been met. This signal indicating termination of the third process can be generated by the fifth process when a preset condition is met. An example of the fifth process generating a signal indicating termination of the third process is given later.

[0176] The third process can be terminated promptly by triggering the first termination condition in multiple ways.

[0177] If the current host does not have advance transmission capability, after each request transaction packet is sent, a notification event can be sent to the fourth process first. After waiting for the fourth process to return a response event, the actual number of loops in the third process and the number of loops threshold can be compared.

[0178] Figure 4 This diagram illustrates the flow of a third process sending a request to a slave device based on attribute information, according to an embodiment of the present disclosure.

[0179] like Figure 4As shown, taking the execution process of the stimulus sequence instance corresponding to host M1 as an example, if the scheduling sequence schedules multiple stimulus sequence instances corresponding to hosts, the third process first determines in step S51 whether the stimulus sequence instance corresponding to host M1 is the only currently running stimulus sequence instance. If the stimulus sequence instance corresponding to host M1 is the only currently running stimulus sequence instance, the first termination condition is met, and the third process exits. If the stimulus sequence instance corresponding to host M1 is not the only currently running stimulus sequence instance, the third process executes step S52, generating a request transaction packet based on the address space that the host is allowed to access and the address space that is not allowed to access. The third process executes step S53, using the first checking function to perform a validity check on the request transaction packet. If the request transaction packet is valid, the third process executes step S54 to send the request transaction packet. If the request transaction packet is invalid, the third process repeats step S51. After step S54 is completed, the third process executes step S55 to determine whether the actual number of loops of the third process is equal to the number of loops threshold. If the actual number of loops of the third process is equal to the number of loops threshold, the first termination condition is met, and the third process exits. If the actual number of iterations of the third process is less than the iteration threshold, the third process repeats step S51. If a signal indicating exit from the third process is received at any time, the first termination condition is met, and the third process exits.

[0180] In one possible implementation, receiving a response from the slave device includes:

[0181] Determine whether the fourth process meets the second termination condition;

[0182] When the fourth process does not meet the second termination condition, the response acquisition function is called to acquire the response transaction packet when the slave returns the response transaction packet.

[0183] Use the second check function to verify the response transaction packet.

[0184] For example, the fourth process can call the response retrieval function get_response to retrieve the response transaction packet when the slave returns the response transaction packet.

[0185] The fourth process can use the second check function to verify the response transaction packet. The purpose of the verification is to confirm whether the response transaction packet is correct, reclaim the ID of the response transaction packet, etc., and the verification result can be used to determine whether the response transaction packet is normal.

[0186] In one possible implementation, the second check function is associated with a set of excitation sequences, and the second check function differs for different sets of excitation sequences.

[0187] For example, the second check function is an empty function in the general excitation sequence, which is reserved as a processing interface for various bus protocols. The specific implementation of the second check function is overridden in the excitation sequence instance.

[0188] In this way, the fourth thread is able to receive response transaction packets from the slave device, and the fourth thread can verify the response transaction packets. The NoC function can be determined based on the verification result of the fourth thread.

[0189] If the current host does not have advance transmission capability, it can call the response acquisition function after receiving the notification event from the third process, and return the response event to the third process after obtaining the response transaction packet.

[0190] For example, the process of obtaining the response transaction packet and performing a validity check on the response transaction packet can be executed as a whole, looped multiple times. First, it can be determined whether the fourth process meets the second termination condition. If the fourth process does not meet the second termination condition, it can be executed again. If the fourth process meets the second termination condition, then the fourth process exits.

[0191] In this way, the verification efficiency can be reduced by the fourth thread running for too long.

[0192] In one possible implementation, the second termination condition is determined to be satisfied when the third process has ended and the number of request transaction packets sent is equal to the number of response transaction packets received.

[0193] For example, if the third process has ended and the number of request transaction packets sent equals the number of response transaction packets received, then it is considered that there are no more response transaction packets to be received, and the fourth thread can exit. Therefore, when the third process has ended and the number of request transaction packets sent equals the number of response transaction packets received, the second termination condition is determined to be met.

[0194] This method allows the fourth process to be terminated promptly.

[0195] Figure 5 A schematic diagram illustrating the flow of a fourth process receiving a response from a slave device according to an embodiment of this disclosure is shown.

[0196] like Figure 5As shown, in step S61, the fourth process calls the response acquisition function to acquire the response transaction packet when the slave device returns it. In step S62, the fourth process uses the second checking function to verify the response transaction packet. In step S63, the fourth process determines whether the number of sent request transaction packets is equal to the number of received response transaction packets. If the third process has ended (exited) and the number of sent request transaction packets is equal to the number of received response transaction packets, the second termination condition is met, and the fourth process exits. If the third process has not ended (exited) or the number of sent request transaction packets is not equal to the number of received response transaction packets, the fourth process repeats step S61.

[0197] In one possible implementation, the attribute information includes a time threshold and a sent request threshold, and the signal that triggers the exit from the third process includes:

[0198] When the verification time of the stimulus sequence set corresponding to the host reaches the time threshold, a signal indicating the exit of the third process is triggered; and / or

[0199] When the number of sent request transaction packets reaches the sent request threshold, a signal indicating the exit of the third process is triggered.

[0200] For example, the attribute information may also include a time threshold, and the fifth process may trigger a signal indicating the exit of the third process, which may include: triggering a signal indicating the exit of the third process when the actual simulation time of the stimulus sequence instance corresponding to the host reaches the time threshold.

[0201] For example, the attribute information may also include a sent request threshold, and the fifth process may trigger a signal indicating the exit of the third process, which may include: when the number of sent request transaction packets reaches the sent request threshold, a signal indicating the exit of the third process is triggered.

[0202] The verification method can be made more flexible by triggering signals to indicate the exit of the third process in multiple ways.

[0203] Those skilled in the art will understand that in practical applications, more or fewer processes can be started during the simulation phase. For example, the work of the fifth process can also be completed by the third process, in which case only the third and fourth processes need to be started. This disclosure does not limit the number of processes started during the simulation phase or the scope of responsibility of each thread.

[0204] In this embodiment, the content and execution of the general stimulus sequence are independent of specific protocols, resulting in a reasonable process and clear planning. Furthermore, it reserves first and second check functions for compatibility with different bus protocols, used to perform bus protocol-related calculations and judgments before sending request transaction packets and after receiving response transaction packets. This approach reduces the development and maintenance costs of the stimulus sequence and improves verification efficiency.

[0205] This disclosure also proposes a verification device for a network-on-chip (NoC). Figure 6 A schematic diagram showing the structure of a verification device for a Network-on-Chip (NoC) according to an embodiment of the present disclosure is provided.

[0206] In one possible implementation, NoC connects multiple hosts, such as Figure 6 As shown, the device includes:

[0207] The first generation module 71 is used to generate a general stimulus sequence for multiple bus protocols based on the common part of the verification process corresponding to multiple bus protocols.

[0208] The second generation module 72 is used to generate a unique stimulus sequence for each bus protocol based on the unique part of the verification process corresponding to each bus protocol and the general stimulus sequence. The unique stimulus sequence includes the content of the general stimulus sequence.

[0209] Module 73 is configured to determine the set of excitation sequences corresponding to each host based on the unique excitation sequence of the bus protocol for each host among multiple hosts; and

[0210] Verification module 74 is used to verify NoC based on the set of excitation sequences.

[0211] In one possible implementation, verifying the NoC based on the set of stimulus sequences includes: scheduling the set of stimulus sequences corresponding to each host based on a scheduling sequence to verify the NoC.

[0212] In one possible implementation, scheduling the stimulus sequence set corresponding to each host to verify the NoC includes: defining a first process in the environment component, the first process being used to execute received progress events; defining a second process in the verification component, the second process being used to configure the environment component; after the second process completes the configuration of the environment component, the main process of the environment component passes the next event to be executed to the first process; when the first process executes the received progress event, scheduling the stimulus sequence set corresponding to at least one host associated with the progress event to verify the NoC; after the first process completes the execution of each event, the main process notifies the second process to configure the environment component.

[0213] In one possible implementation, the scheduling sequence indicates that the scheduling mode is either a serial scheduling mode or a parallel scheduling mode.

[0214] In one possible implementation, the main process notifying the second process to configure the environment component includes: the main process passing a notification event to the verification component; scheduling the stimulus sequence set corresponding to each host to verify the NoC further includes: when the next event to be executed is not the simulation end event, the main process enters a blocked state and waits for a response event from the verification component; the main process of the environment component passing the next event to be executed to the first process includes: after receiving the response event, the main process exits the blocked state and passes the next event to be executed to the first process.

[0215] In one possible implementation, the second process configures the environment component by: after detecting that the verification component has received the notification event, the second process determines whether the next event to be executed is a simulation end event based on the notification event, configures the environment component according to the determination result, and after the configuration is completed, passes a response event to the environment component.

[0216] In one possible implementation, configuring the environment component based on the judgment result includes: reading the execution result of the completed progress event from the environment component; and providing the environment component with the data used for the next event to be executed when the next event to be executed is not the simulation end event.

[0217] In one possible implementation, the operation process of the stimulus sequence set corresponding to the host includes: in the initialization phase, acquiring the attribute information of the host; in the verification phase, starting a third process, a fourth process, and a fifth process, wherein the third process is used to send a request to the slave device according to the attribute information, the fourth process is used to receive a response from the slave device, and the fifth process is used to trigger a signal indicating the exit of the third process.

[0218] In one possible implementation, sending a request to the slave device based on the attribute information includes: determining whether the third process meets a first termination condition; generating a request transaction packet based on the attribute information when the third process does not meet the first termination condition; performing a validity check on the request transaction packet using a first checking function; and sending the request transaction packet when the request transaction packet is valid.

[0219] In one possible implementation, the first checking function is associated with the set of excitation sequences, and the first checking function is different for different sets of excitation sequences.

[0220] In one possible implementation, the attribute information includes a loop count threshold. When the loop count of the third process equals the loop count threshold, the first termination condition is determined to be satisfied. In the case of scheduling multiple sets of stimulus sequences corresponding to multiple hosts, the first termination condition is determined to be satisfied when the set of stimulus sequences corresponding to a host is the currently only running set of stimulus sequences. When a signal indicating that the third process should be exited is received, the first termination condition is determined to be satisfied.

[0221] In one possible implementation, receiving a response from the slave device includes: determining whether the fourth process meets the second termination condition; when the fourth process does not meet the second termination condition, calling a response acquisition function to acquire the response transaction packet when the slave device returns a response transaction packet; and using a second checking function to verify the response transaction packet.

[0222] In one possible implementation, the second checking function is associated with the set of excitation sequences, and the second checking function is different for different sets of excitation sequences.

[0223] In one possible implementation, the second termination condition is determined to be satisfied when the third process has ended and the number of request transaction packets sent is equal to the number of response transaction packets received.

[0224] In one possible implementation, the attribute information includes a time threshold and a sent request threshold, triggering a signal indicating exit from the third process, including: triggering a signal indicating exit from the third process when the verification time of the stimulus sequence set corresponding to the host reaches the time threshold; and / or triggering a signal indicating exit from the third process when the number of sent request transaction packets reaches the sent request threshold.

[0225] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0226] This disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above method.

[0227] This disclosure also provides a non-volatile computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the above-described method.

[0228] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0229] Figure 7 A block diagram of an electronic device according to an embodiment of the present disclosure is shown. For example, the electronic device may be provided as a server or a terminal device. (Refer to...) Figure 7 The electronic device 1900 includes a processing component 1922, which further includes one or more processors, and memory resources represented by memory 1932 for storing instructions, such as application programs, that can be executed by the processing component 1922. The application programs stored in memory 1932 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 1922 is configured to execute instructions to perform the methods described above.

[0230] Electronic device 1900 may also include a power supply component 1926 configured to perform power management of electronic device 1900, a wired or wireless network interface 1950 configured to connect electronic device 1900 to a network, and an input / output interface 1958 (I / O interface). Electronic device 1900 can operate on an operating system, such as Windows Server, stored in memory 1932. TM Mac OS X TM Unix TM Linux TM FreeBSD TM Or similar.

[0231] In an exemplary embodiment, a non-volatile computer-readable storage medium is also provided, such as a memory 1932 including computer program instructions that can be executed by a processing component 1922 of an electronic device 1900 to perform the above-described method.

[0232] Computer-readable storage media can be tangible devices capable of holding and storing programs / instructions used by instruction execution devices. Computer-readable storage media can be, for example—but not limited to—electrical storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or recessed protrusions storing instructions thereon, and any suitable combination of the foregoing. The computer-readable storage media used herein are not to be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0233] The computer program (or computer-readable program instructions) described herein can be downloaded from a computer-readable storage medium to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage medium in the respective computing / processing device.

[0234] The computer program (or computer program instructions) used to perform the operations of this disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions to implement various aspects of this disclosure.

[0235] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0236] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0237] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0238] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0239] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for verifying on-chip network NoC, characterized in that, The NoC connects multiple hosts, and the method includes: Based on the common parts of the verification processes corresponding to multiple bus protocols, a general stimulus sequence for the multiple bus protocols is generated; Based on the unique part of the verification process corresponding to each of the multiple bus protocols and the general stimulus sequence, a unique stimulus sequence is generated for each bus protocol, wherein the unique stimulus sequence includes the content of the general stimulus sequence. Based on the unique excitation sequence of the bus protocol for each of the plurality of hosts, determine the set of excitation sequences corresponding to each host; and The NoC is verified based on the set of excitation sequences.

2. The method according to claim 1, characterized in that, Verification of the NoC based on the set of stimulus sequences includes: The NoC is verified by scheduling the set of stimulus sequences corresponding to each host according to the scheduling sequence.

3. The method according to claim 2, characterized in that, The scheduling of the stimulus sequence set corresponding to each host to verify the NoC includes: Define a first process in the environment component, which is used to execute the received progress events; The verification component defines a second process, which is used to configure the environment component; After the second process completes the configuration of the environment component, the main process of the environment component passes the next event to be executed to the first process; when the first process executes the received progress event, it schedules the set of stimulus sequences corresponding to at least one host associated with the progress event to verify the NoC; after the first process executes each event, the main process notifies the second process to configure the environment component.

4. The method according to claim 2, characterized in that, The scheduling sequence indicates that the scheduling mode is either serial scheduling mode or parallel scheduling mode.

5. The method according to claim 3, characterized in that, The main process notifying the second process to configure the environment component includes: the main process passing a notification event to the verification component; The method of scheduling the set of stimulus sequences corresponding to each host to verify the NoC also includes: when the next event to be executed is not the simulation end event, the main process enters a blocked state and waits for a response event from the verification component; The main process of the environment component passes the next event to be executed to the first process, including: after receiving the response event, the main process exits the blocked state and passes the next event to be executed to the first process.

6. The method according to claim 5, characterized in that, The second process configures the environment components including: After the second process detects that the verification component has received the notification event, it determines whether the next event to be executed is the simulation end event based on the notification event, configures the environment component according to the determination result, and after the configuration is completed, passes the response event to the environment component.

7. The method according to claim 6, characterized in that, Configure the environment components according to the judgment result, including: Read the execution result of the completed progress event from the environment component; When the next event to be executed is not the simulation end event, provide the environment components with the data used for the next event to be executed.

8. The method according to claim 3, characterized in that, The execution process of the stimulus sequence set corresponding to the host includes: During the initialization phase, the host's attribute information is obtained; During the verification phase, a third process, a fourth process, and a fifth process are initiated. The third process is used to send a request to the slave device based on the attribute information. The fourth process is used to receive a response from the slave device. The fifth process is used to trigger a signal indicating that the third process should be exited.

9. The method according to claim 8, characterized in that, Sending a request to the slave device based on the attribute information includes: Determine whether the third process satisfies the first termination condition; When the third process does not meet the first termination condition, a request transaction packet is generated based on the attribute information; The first checking function is used to perform a validity check on the request transaction packet; If the request transaction packet is valid, the request transaction packet is sent.

10. The method according to claim 9, characterized in that, The first checking function is associated with the set of excitation sequences, and the first checking function is different for different sets of excitation sequences.

11. The method according to claim 9, characterized in that, The attribute information includes a threshold for the number of loops. When the number of iterations in the third process equals the iteration count threshold, it is determined that the first termination condition is met. When scheduling multiple sets of stimulus sequences corresponding to multiple hosts, and the set of stimulus sequences corresponding to a host is the only set of stimulus sequences currently running, it is determined that the first termination condition is met. Upon receiving a signal instructing the user to exit the third process, it is determined that the first termination condition has been met.

12. The method according to claim 8, characterized in that, Receive a response from the slave device, including: Determine whether the fourth process satisfies the second termination condition; When the fourth process does not meet the second termination condition, the response acquisition function is called to acquire the response transaction packet when the slave returns the response transaction packet; The response transaction packet is validated using a second checking function.

13. The method according to claim 12, characterized in that, The second checking function is associated with the set of excitation sequences, and the second checking function is different for different sets of excitation sequences.

14. The method according to claim 13, characterized in that, The second termination condition is determined to be satisfied when the third process has ended and the number of request transaction packets sent is equal to the number of response transaction packets received.

15. The method according to claim 8, characterized in that, The attribute information includes a time threshold and a sent request threshold, and the signal that triggers the exit from the third process includes: When the verification time of the stimulus sequence set corresponding to the host reaches the time threshold, a signal indicating the exit of the third process is triggered; and / or When the number of sent request transaction packets reaches the sent request threshold, a signal indicating the exit of the third process is triggered.

16. A verification device for a network-on-a-chip (NoC), characterized in that, The NoC connects to multiple hosts, and the device includes: The first generation module is used to generate a general stimulus sequence for the multiple bus protocols based on the common part of the verification process corresponding to the multiple bus protocols. The second generation module is used to generate a unique stimulus sequence for each bus protocol based on the unique part of the verification process corresponding to each bus protocol and the general stimulus sequence. The unique stimulus sequence includes the content of the general stimulus sequence. The determining module is configured to determine the set of excitation sequences corresponding to each host based on the unique excitation sequence of the bus protocol of each of the plurality of hosts; and The verification module is used to verify the NoC based on the set of excitation sequences.

17. An electronic device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 15.

18. A non-volatile computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 15.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 15.

Images