CN112699626B - Scheduling detection method and device, equipment and computer readable storage medium - Google Patents

Abstract

The present application relates to a scheduling detection method and apparatus, device, and computer-readable storage medium. In one embodiment of the present application, the scheduling detection method may include: monitoring the scheduling module in the device under test; when a scheduling request entering the scheduling module is detected, caching the information in the scheduling request; when the scheduling feedback sent by the scheduling module is detected, releasing the information of the corresponding scheduling request from the cache; and verifying the scheduling behavior of the device under test based on the scheduling feedback and/or the information in the scheduling request. The embodiment of the present application can efficiently complete the system-level or subsystem-level verification of the chip.

Description

Scheduling detection method, device, equipment, and computer-readable storage medium

Technical Field

The present application relates to the field of communication technology, and in particular to a scheduling detection method and apparatus, device, and computer-readable storage medium.

Background technique

Usually, simulation is used to verify the operation effect of the chip system level or its subsystem level. At present, system-level simulation and subsystem-level simulation are mainly realized by performing module-level simulation on multiple circuit modules in the chip system or subsystem. In module-level simulation, it is mainly realized by comparing the simulation module (RM) with the scheduling result of the chip at the timing level. In this timing-level comparison, the simulation module needs to monitor the internal signal of the chip to ensure the accuracy of the comparison. When performing netlist simulation verification such as comprehensive netlist and PR netlist, the internal signal of the chip is presented in the form of a netlist, which is difficult to sample and locate accurately, which brings great difficulties to the timing-level comparison. In addition, since the clock of each circuit module in the chip is different and its delay is dynamically changing, when performing netlist simulation for each electronic module in the chip, it is necessary to debug the code of the simulation module for each circuit module when sampling the internal signal of the chip, which takes a lot of debugging time and leads to low efficiency. This is especially true after the addition of the Standard Delay Format (SDF) delay.

Summary of the invention

In view of the above-mentioned technical problems in the related art, the present application provides a scheduling detection method and apparatus, a device, and a computer-readable storage medium to efficiently complete system-level or subsystem-level verification of a chip.

To achieve the above-mentioned object, the first aspect of the present application provides a scheduling detection method, comprising:

Monitoring the scheduling module in the device under test;

When a scheduling request entering the scheduling module is detected, information in the scheduling request is cached;

When monitoring the scheduling feedback sent by the scheduling module, releasing the information of the corresponding scheduling request from the cache;

The scheduling behavior of the device under test is verified according to the scheduling feedback and/or information in the scheduling request.

From the above, it is realized that the interface signal of the device under test can be detected by monitoring the chip, that is, the scheduling request and scheduling feedback of the scheduling module in the device under test, thereby efficiently completing the detection of the subsystem-level scheduling behavior or system-level scheduling behavior of the chip, which can be achieved without multiple debugging, effectively saving time and improving efficiency.

In at least some embodiments, the scheduling request includes the port number to which the message belongs and the priority level to which the message belongs; and caching the information in the scheduling request includes: caching the information in the scheduling request using the combined information of the port to which the message belongs and the priority level to which the message belongs in the scheduling request as an index.

From the above, efficient access to information in scheduling requests is achieved.

In at least some embodiments, verifying the scheduling behavior of the device under test includes: verifying whether the scheduling behavior of the device under test complies with predetermined scheduling rules. If so, it indicates that the scheduling behavior of the device under test is normal; if not, it indicates that the scheduling behavior of the device under test is abnormal; wherein, the scheduling rules include one or more of the following: signal timing of information in a scheduling request, signal timing of information in a scheduling feedback, consistency of on-path information of a scheduling feedback with a corresponding scheduling request, consistency of the number of scheduling feedbacks with the number of cells of a corresponding scheduling request, and a preemptive frame function.

From the above, it is achieved that various system-level or subsystem-level scheduling behaviors in the device under test can be verified by monitoring the scheduling request and scheduling feedback of the scheduling module in the chip, that is, the device under test.

In at least some embodiments, verifying the scheduling behavior of the device under test includes: each time a low-priority scheduling feedback is monitored, querying the cache based on the physical port number of the scheduling feedback whether there is information about a high-priority scheduling request with the same physical port number; if so, it indicates that the preemptive frame scheduling behavior of the device under test is abnormal; if not, it indicates that the preemptive frame scheduling behavior of the device under test is normal.

As described above, it is realized that the scheduling behavior of the preemption frame function of the device under test can be detected by monitoring the scheduling request and scheduling feedback of the scheduling module in the chip, that is, the device under test.

In at least some embodiments, verifying the scheduling behavior of the device under test includes: verifying whether the number of scheduling feedbacks corresponding to a scheduling request matches the number of cells in the information of the scheduling request; if they match, it means that the scheduling behavior of the device under test is normal; if they do not match, it means that the scheduling behavior of the device under test is abnormal.

From the above, it is realized that the consistency of the number of cells can be detected by monitoring the scheduling request and scheduling feedback of the scheduling module in the monitoring chip, that is, the device under test.

In at least some embodiments, verifying the scheduling behavior of the device under test includes: verifying whether the signal rising edge and signal falling edge of the information in the scheduling request and/or scheduling feedback are aligned with the clock binary frequency of the device under test, if so, it means that the scheduling behavior of the device under test is normal, if not, it means that the scheduling behavior of the device under test is abnormal.

From the above, it is realized that the signal timing can be detected by monitoring the scheduling request and scheduling feedback of the scheduling module in the monitoring chip, that is, the device under test.

In at least some embodiments, the scheduling detection method further includes: generating corresponding error information when verifying that the scheduling behavior of the device under test is abnormal.

From the above, the corresponding generation of error information in the event of an exception is achieved, so as to facilitate reporting and viewing by technical personnel.

The first aspect of the present application provides a scheduling detection device, comprising: a monitoring module, a cache module, a release module and a verification module; wherein:

A monitoring module configured to monitor a scheduling module in the device under test;

a cache module, configured to cache information in the scheduling request when monitoring the scheduling request entering the scheduling module;

A release module, configured to release information of a corresponding scheduling request from a cache when monitoring the scheduling feedback sent by the scheduling module;

The verification module is configured to verify the scheduling behavior of the device under test according to the scheduling feedback and/or information in the corresponding scheduling request.

A third aspect of the present application provides a computing device, comprising: a communication interface, and at least one processor; wherein the at least one processor is used to execute program instructions, and when the program instructions are executed by the at least one processor, the computing device implements the method described in the first aspect above.

A fourth aspect of the present application provides a computer-readable storage medium having program instructions stored thereon, wherein when the program instructions are executed by a computer, the computer implements the method described in the first aspect above.

BRIEF DESCRIPTION OF THE DRAWINGS

The following further illustrates the various features of the present application and the connections between the various features with reference to the accompanying drawings. The accompanying drawings are all exemplary, and some features are not shown in actual proportion. Some drawings may omit features that are conventional in the field involved in the present application and are not necessary for the present application, or additional features that are not necessary for the present application may be shown. The combination of the various features shown in the accompanying drawings is not intended to limit the present application. In addition, throughout this specification, the same figure numerals refer to the same content. The specific description of the drawings is as follows:

FIG1 is a schematic diagram of a flow chart of a scheduling detection method provided in an embodiment of the present application;

FIG2 is a schematic diagram of the structure of a scheduling detection device provided in an embodiment of the present application;

FIG3 is a schematic diagram of the deployment of a scheduling detection device provided in an embodiment of the present application;

FIG4 is a structural schematic diagram of a computing device provided in an embodiment of the present application.

Detailed ways

The words "first, second, third, etc." or module A, module B, module C and other similar terms in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of the objects. It is understandable that the specific order or sequence can be interchanged where permitted so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

In the following description, the numbers representing the steps, such as S110, S120, etc., do not necessarily mean that the steps must be executed in this manner. If permitted, the order of the previous and next steps can be interchanged, or they can be executed simultaneously.

The term "comprising" as used in the description and claims should not be interpreted as being limited to what is listed thereafter; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the features, integers, steps or components mentioned, but does not exclude the presence or addition of one or more other features, integers, steps or components and groups thereof. Therefore, the expression "a device comprising means A and B" should not be limited to a device consisting of components A and B only.

References to "one embodiment" or "an embodiment" in this specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least one embodiment of the present application. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing in various places in this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. In addition, in one or more embodiments, the particular features, structures, or characteristics can be combined in any appropriate manner, as would be apparent to one of ordinary skill in the art from this disclosure.

Through in-depth research on chip system-level or subsystem-level verification, the inventors found that the focus of chip subsystem-level or system-level verification is not on the specific scheduling order, specific scheduling time and other details of each circuit module inside the chip, but on whether the scheduling behavior of the chip subsystem-level or system-level (i.e., the macro-scheduling behavior of the chip) complies with the corresponding scheduling rules. Therefore, in order to solve the technical problems of long debugging time and low efficiency in chip subsystem-level or system-level verification, the embodiments of the present application provide the following scheduling detection method and device, equipment, and computer-readable storage medium, which detects the interface signal of the device under test by monitoring the scheduling request and scheduling feedback of the scheduling module in the chip (i.e., the device under test (DUT) hereinafter), and then efficiently completes the detection of the subsystem-level scheduling behavior or system-level scheduling behavior of the chip, which can be achieved without multiple debugging, which can effectively save time and improve efficiency.

FIG1 shows an exemplary process of a scheduling detection method 100 according to an embodiment of the present application. Referring to FIG1 , the scheduling detection method according to an embodiment of the present application may include the following steps:

Step S110: monitoring the scheduling module in the device under test.

Step S120, when a scheduling request entering the scheduling module is monitored, information in the scheduling request is cached.

Step S130, when the scheduling feedback sent by the scheduling module is monitored, the information of the corresponding scheduling request is released from the cache.

Step S140: verify the scheduling behavior of the device under test according to the information in the scheduling feedback and/or the scheduling request.

Through the above steps, it is possible to detect the interface signal of the device under test by monitoring the scheduling request and scheduling feedback of the scheduling module in the chip (i.e., the device under test), thereby efficiently completing the detection of the subsystem-level scheduling behavior or system-level scheduling behavior of the chip, which can be achieved without multiple debugging, effectively saving time and improving efficiency.

FIG2 shows an exemplary structure of a scheduling detection device 200 provided in an embodiment of the present application. Referring to FIG2 , the scheduling detection device 200 may include: a monitoring module 210, a cache module 220, a release module 230, and a verification module 240.

A monitoring module 210 configured to monitor a scheduling module in the device under test;

The cache module 220 is configured to cache information in the scheduling request when monitoring the scheduling request entering the scheduling module;

A release module 230, configured to release information of a corresponding scheduling request from a cache when monitoring the scheduling feedback sent by the scheduling module;

The verification module 240 is configured to verify the scheduling behavior of the device under test according to the information in the scheduling feedback and/or the scheduling request.

FIG3 shows a schematic diagram of the deployment architecture of the scheduling detection module and the scheduling module in the DUT in an embodiment of the present application.

An exemplary implementation of the embodiment of the present application is described in detail below in conjunction with FIG. 1 , FIG. 2 and FIG. 3 .

As shown in FIG. 3 below, the scheduling module of the device under test can receive a call request from its upper-level module (e.g., the inlet queue management module shown in FIG. 3) through its inlet (e.g., the inlet scheduling module), and the calling module can send scheduling feedback to its lower-level module (e.g., the outlet queue management module shown in FIG. 3) through its outlet (e.g., the outlet scheduling module shown in FIG. 3), thereby, the DUT can schedule its various electronic modules to realize the relevant functions of the DUT (e.g., when the DUT is applied to a switch, its relevant functions can be but are not limited to message conversion, forwarding, etc.). In practical applications, the inlet (e.g., the inlet scheduling module in FIG. 3) and the outlet (e.g., the outlet scheduling module in FIG. 3) of the scheduling module can be but are not limited to software-defined interfaces.

In step S110, the inlet and outlet of the scheduling module can be monitored simultaneously, that is, the inlet scheduling module and the outlet scheduling module of the scheduling module in the DUT can be monitored simultaneously. Each time a scheduling request is monitored to enter the scheduling module, the following step S120 can be continued, and each time a scheduling feedback is monitored to be sent by the scheduling module, the following step S130 can be continued. Since both the scheduling request and the scheduling feedback carry relevant information of the interface signal of the device under test (for example, the message received by the device under test, the port of the message sent by the device under test, the priority, etc.), therefore, the embodiment of the present application can realize the detection of the interface signal of the device under test by monitoring the scheduling module, thereby realizing efficient detection of the scheduling behavior of the system level or subsystem level of the device under test.

In some embodiments, taking FIG. 3 as an example, the scheduling request in this document may be, but is not limited to, a port queue scheduling request, and the information in the scheduling request may include, but is not limited to, the following information:

Queue scheduling requests from the egress queue management module (EQM) (e.g., each message queue can send up to 2 scheduling requests);

The port number to which the message belongs, i.e., the port number of the port extender (PE) to which the message belongs, corresponds to the destination port number of the message scheduling described below, which includes a physical port number and an extended port number. The extended port number may be a preemptible media access control (Preamble MAC, PMAC) port number or an express media access control (Express MAC, EMAC) port number;

The priority level of the message;

The number of cells contained in the message;

Number of unused bytes in the message tail cell;

Message timestamp information, such as the time when the scheduling request was received;

Packet discarding enable can be returned when the scheduling result is fed back;

An error flag in the message sending the scheduling request to the egress scheduling module (ESCH).

In practical applications, a scheduling of the scheduling module is usually identified by information such as the port to which the message belongs and the priority to which the message belongs in the corresponding scheduling request, and the scheduling request and the scheduling feedback are also associated through this information. Therefore, in some embodiments, in step S120, the information in the scheduling request can be cached using the combined information of the port number to which the message belongs and the priority to which the message belongs in the scheduling request (for example, the scheduling queue number calculated from the port to which the message belongs and the priority to which the message belongs) as an index, so as to verify the preemption frame function in step S130.

For example, as shown in FIG. 3 below, multiple first-in-first-out (FIFO) queues may be pre-created according to the message scheduling destination port and its priority, and each FIFO queue is identified by a combination of message scheduling destination port number and message priority (e.g., a scheduling queue number calculated from the message scheduling destination port number and the message priority). In step S120, the information in the scheduling request may be sent to the corresponding FIFO queue for caching based on the port number to which the message belongs and the message priority to which the message belongs in the scheduling request.

In some embodiments, still taking FIG. 3 as an example, the scheduling feedback sent by the scheduling module (for example, via ESCH in the scheduling module) may be but is not limited to port queue scheduling feedback, and the port queue scheduling feedback may be divided into low priority and high priority.

In some embodiments, the information in the scheduling feedback may include but is not limited to the following information:

Indication of the validity of the queue scheduling result;

Scheduling result port number, that is, the scheduling result PE port number;

Scheduling result priority;

Cell sof (first cell flag) of the scheduling result;

The cell eof (end cell flag) of the scheduling result;

The number of cells contained in the message;

Number of unused bytes in the message tail cell;

The aging time scale corresponding to the scheduling result cell;

Discard registration corresponding to the scheduling result cell;

The discard flag corresponding to the scheduling result cell;

Real-time time-stamp information sent to EQM.

In step S130, the corresponding FIFO queue may be queried according to the scheduling result port number and the scheduling result priority in the scheduling feedback, and the information of the corresponding scheduling request may be released therefrom.

In the system-level scheduling or subsystem scheduling of the DUT, the scheduling queue number of the scheduling request is required to be consistent with the scheduling queue number of the scheduling feedback. Here, the scheduling queue number can be calculated based on the port number and priority. For example, the scheduling queue number = port*8+prio, port represents the port number, and prio represents the priority. In some embodiments, the information in the scheduling request can be cached according to the scheduling queue number, and the scheduling queue number can be calculated using the scheduling result port number and the scheduling result priority in the scheduling feedback in step S130, and then the information of the corresponding scheduling request is released based on the scheduling queue number.

In step S140, the information in the scheduling feedback and/or the information in the scheduling request can be used to verify whether the scheduling behavior of the device under test complies with the predetermined scheduling rules. If it complies, it means that the scheduling behavior of the device under test is normal, and if it does not comply, it means that the scheduling behavior of the device under test is abnormal. Thus, the purpose of detecting whether the scheduling of the device under test is correct can be achieved by verifying whether it complies with the scheduling rules.

Specifically, step S140 can verify the following scheduling rules, but is not limited to: the signal timing of the information in the scheduling request, the signal timing of the information in the scheduling feedback, the consistency of the scheduling feedback and the accompanying information of the corresponding scheduling request, the consistency of the number of scheduling feedback and the number of cells of the corresponding scheduling request, and the preemption frame function. Thus, based on the inlet and outlet messages of the scheduling modules such as scheduling requests and scheduling feedback, the system-level or subsystem-level scheduling behavior (i.e., the macro-scheduling behavior of the device under test) can be detected. If any one or more scheduling rules are not met, a corresponding error message is generated. If all the above scheduling rules are met, the scheduling behavior of the device under test can be correct.

In practical applications, the requirements for signal timing are generally agreed upon in advance (for example, the length of the signal timing is not less than two clocks or one clock, etc.), and the signals of each circuit module in the DUT must meet the agreement. Similarly, the scheduling request and scheduling feedback also need to meet the requirements of the signal timing. In some embodiments, in step S140, it is verified whether the rising edge and falling edge of the signal of the information in the scheduling request and/or scheduling feedback are aligned with the clock frequency division of the device under test. If so, it means that the scheduling behavior of the device under test is normal, otherwise it means that the scheduling behavior of the device under test is abnormal. Specifically, verifying the signal timing of the information in the scheduling request includes verifying whether the rising edge and falling edge of the signal of each information in the scheduling request information are aligned with the clock frequency division of the device under test, and verifying the signal timing of the information in the scheduling feedback includes verifying whether the rising edge and falling edge of the signal of each information in the scheduling feedback are aligned with the clock frequency division of the device under test. Specifically, verifying the signal timing of a message in the scheduling request can include whether the rising edge of the signal is aligned with the clock frequency division of the device under test (soc) = 0, and whether the falling edge of the signal is aligned with soc = 1. Similarly, verifying the signal timing of a piece of information in the scheduling feedback may include monitoring whether a rising edge of a signal of the piece of information in the scheduling feedback is aligned with soc=0 of the device under test, and whether a falling edge is aligned with soc=1 of the device under test.

The on-path information is generally used to recover the message, therefore, it is necessary to ensure that the on-path information in the dispatch feedback is consistent with the on-path information in the dispatch request. In some embodiments, step S140 can ensure that the next-level module of the dispatch module will not make mistakes when recovering the message by verifying whether the on-path information in the dispatch feedback is consistent with the on-path information in the corresponding dispatch request. Specifically, the on-path information may include message timestamp information, message discard enable, and the number of unused bytes in the message tail cell. Verifying the consistency of the on-path information in step S140 may include: determining whether the message timestamp information, message discard enable, and the number of unused bytes in the message tail cell in the dispatch feedback are the same as the corresponding information in the corresponding dispatch request.

Typically, each scheduling feedback corresponds to a cell, and each scheduling request may correspond to multiple cells. In some embodiments, in step S140, verifying the consistency of the number of cells includes verifying whether the number of scheduling feedbacks corresponding to a scheduling request matches the number of cells in the information of the scheduling request, that is, determining whether the number of scheduling feedbacks of a scheduling request is equal to its number of cells. If the number of scheduling feedbacks of a scheduling request matches the number of cells in the information of the scheduling request, it means that the scheduling behavior of the device under test meets the requirements for consistency of the number of cells, and the scheduling behavior is normal; if the number of scheduling feedbacks of a scheduling request does not match the number of cells in the information of the scheduling request, it means that the scheduling behavior of the device under test does not meet the requirements for consistency of the number of cells, and the scheduling behavior is abnormal.

Here, the number of scheduling feedbacks for a scheduling request can be counted while monitoring the scheduling feedbacks. Specifically, the counting starts when a scheduling feedback with cell sof being 1 is monitored, and the counting ends when a scheduling feedback with a scheduling queue number consistent with the scheduling feedback and cell eof being 1 is monitored. The value obtained by the counting is the number of scheduling feedbacks for the same scheduling request.

In at least some embodiments, the verification of the preemption frame function may include: each time a low-priority scheduling feedback is monitored, querying the cache based on the physical port number of the scheduling feedback whether there is information about a high-priority scheduling request with the same physical port number. If there is, it means that the message queue of the high-priority port queue scheduling request is not scheduled according to the preemption rule, that is, the scheduling of the device under test violates the preemption rule, and the preemption frame scheduling behavior of the device under test is abnormal; if there is no, it means that the scheduling of the message queue of the high-priority port queue scheduling request meets the preemption rule, that is, the scheduling of the device under test meets the preemption rule, and the preemption frame scheduling behavior of the device under test is normal.

The following uses an example to explain the verification of the preemption frame function in detail.

Taking Figure 3 as an example, if the export scheduling module is the KD6630 export scheduling module, it needs to support the 802.1Qbu/802.3br frame preemption function. The logical ports for message scheduling can be divided into EMAC ports (high priority) and PMAC ports (low priority). Each combination of EMAC port and PMAC port corresponds to the same physical port. Assuming that a physical port is identified as n, then its corresponding EMAC logical port can be identified as 2n+1, and its corresponding PMAC logical port can be identified as 2n. Accordingly, the scheduling request is a port queue scheduling request, and the scheduling feedback is a port queue scheduling feedback.

As shown in FIG3 , multiple FIFO queues can be pre-established according to the destination port of the message scheduling and its physical port and priority, and each FIFO queue corresponds to a combination of the port number (including the physical port identifier and the logical port identifier) and the priority of the destination port of the message scheduling. In step S120, after a port queue scheduling request (a high priority port queue scheduling request or a low priority port queue scheduling request) is detected, the information therein is stored in the corresponding FIFO queue based on the port number and priority of the message. In step S130, each time a port queue scheduling feedback is detected, if the port number of the message to which the scheduling feedback belongs indicates that the destination port of the message scheduling is the PMAC logical port 2n of the physical port n, then it is queried whether the FIFO queue whose physical port is n and whose logical port is the EMAC logical port 2n+1 is empty. If the FIFO queue is not empty, it means that there is still information of the high priority port queue scheduling request (i.e., the scheduling request whose physical port is n and whose logical port is the EMAC logical port 2n+1) in the cache, and it can be determined that the scheduling of the device under test violates the preemption rule that the EMAC can preempt the PMAC scheduling time slot of the same physical port. If the FIFO queue whose physical port is n and whose logical port is EMAC logical port 2n+1 is empty, it means that there is no information of high-priority port queue scheduling request (i.e., scheduling request whose physical port is n and whose logical port is EMAC logical port 2n+1) in the cache, and this scheduling complies with the preemption rule that EMAC can preempt the PMAC scheduling time slot of the same physical port.

In the embodiment of the present application, after step S140, the scheduling detection method 100 may further include: step S150, when verifying that the scheduling behavior of the device under test is abnormal, generating corresponding error information. Accordingly, the above-mentioned scheduling detection device 200 may further include: a prompt module 250, which can be configured to generate corresponding error information when the verification module 240 verifies that the scheduling behavior of the device under test is abnormal. In the embodiment of the present application, the abnormal situation of the scheduling behavior of the device under test can be recorded in real time through the error information, which is convenient for users (for example, chip debuggers) to check the abnormal situation of the device under test and correct the circuit design of the device under test in time.

Here, the error information can be used to describe the scheduling behavior in which the error occurred and its error type. That is, the error information can be used to describe what kind of error occurred in the scheduling of the device under test at which time. For example, the error information can include the port number to which the message belongs, the priority to which the message belongs, and the message timestamp information. The user can know which scheduling of the device under test has an error through this information. In addition, the error information can also include information for indicating the specific error type. For example, assuming that errors in the multiple scheduling rules mentioned in the above step S130 occur in the scheduling of the device under test, the error information can include an error code corresponding to each verification error in the multiple scheduling rules. In this way, without multiple software debugging, the user (for example, the debugger) can fully understand whether there are errors and what errors exist in the macro scheduling behavior of the system level or subsystem level of the DUT by viewing the error information, which is convenient, fast, time-saving and labor-saving.

In some embodiments, in step S150, after the error information is generated, the error information can be written into a predetermined file. Thus, not only can the error information be saved in real time, but also the error information in the predetermined file can be displayed in response to the operation of the user (e.g., a debugger) on the predetermined file, so that the user can check the error information at any time. Of course, any other similar method can also be used to save the error information.

4 is a schematic structural diagram of a computing device 400 provided in an embodiment of the present application. The computing device 400 includes: a processor 410 , a memory 420 , a communication interface 430 , and a bus 440 .

It should be understood that the communication interface 430 in the computing device 400 shown in FIG. 4 may be used to communicate with other devices.

The processor 410 may be connected to a memory 420. The memory 420 may be used to store the program code and data. Therefore, the memory 420 may be a storage unit inside the processor 410, or an external storage unit independent of the processor 410, or a component including a storage unit inside the processor 410 and an external storage unit independent of the processor 410.

Optionally, the computing device 400 may further include a bus 440. The memory 420 and the communication interface 430 may be connected to the processor 410 via the bus 440. The bus 440 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus 440 may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, FIG. 4 is represented by only one line, but it does not mean that there is only one bus or one type of bus.

It should be understood that in the embodiment of the present application, the processor 410 may adopt a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. Alternatively, the processor 410 may adopt one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiment of the present application.

The memory 420 may include a read-only memory and a random access memory, and provides instructions and data to the processor 410. A portion of the processor 410 may also include a nonvolatile random access memory. For example, the processor 410 may also store information on the device type.

When the computing device 400 is running, the processor 410 executes the computer execution instructions in the memory 420 to perform the operation steps of the above-mentioned scheduling detection method.

It should be understood that the computing device 400 according to the embodiment of the present application can correspond to the corresponding subject in the method according to each embodiment of the present application, and the above-mentioned and other operations and/or functions of each module in the computing device 400 are respectively for realizing the corresponding process of each method of the present embodiment, which will not be repeated here for the sake of brevity.

Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

An embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it is used to execute a scheduling detection method, which includes at least one of the schemes described in the above embodiments.

The computer storage medium of the embodiment of the present application can adopt any combination of one or more computer-readable media. Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable storage media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any combination of the above. More specific examples (non-exhaustive lists) of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the above. In this document, computer-readable storage media can be any tangible medium containing or storing programs, which can be used by instruction execution systems, devices or devices or used in combination with them.

Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

The program code embodied on the computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for performing the operation of the present application can be written in one or more programming languages or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (e.g., using an Internet service provider to connect through the Internet).

Note that the above are only preferred embodiments of the present application and the technical principles used. Those skilled in the art will understand that the present application is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present application. Therefore, although the present application is described in more detail through the above embodiments, the present application is not limited to the above embodiments, and may also include more other equivalent embodiments without departing from the concept of the present application, all of which belong to the scope of protection of the present application.

Claims (9)

1. A scheduling detection method, characterized in that the device under test includes a scheduling module, an inlet queue management module and an outlet queue management module, the scheduling module includes an inlet scheduling module and an outlet scheduling module, and the method includes: Monitoring the scheduling module in the device under test; When a scheduling request of an ingress scheduling module entering the scheduling module from an ingress queue management module is monitored, information in the scheduling request is cached; When monitoring the scheduling feedback sent by the egress scheduling module of the scheduling module to the egress queue management module, releasing the information of the corresponding scheduling request from the cache; Verifying the scheduling behavior of the device under test according to the scheduling feedback and/or information in the scheduling request; The verifying the scheduling behavior of the device under test includes: verifying whether the scheduling behavior of the device under test complies with a predetermined scheduling rule, if so, it indicates that the scheduling behavior of the device under test is normal, if not, it indicates that the scheduling behavior of the device under test is abnormal; Among them, the scheduling rules include one or more of the following: signal timing of information in the scheduling request, signal timing of information in the scheduling feedback, consistency of the on-path information of the scheduling feedback and the corresponding scheduling request, consistency of the number of scheduling feedback and the number of cells of the corresponding scheduling request, and preemption frame function. 2. The scheduling detection method according to claim 1, characterized in that: The scheduling request includes the port number to which the message belongs and the priority level to which the message belongs; The caching of the information in the scheduling request includes: caching the information in the scheduling request using the combination information of the port to which the message belongs and the priority to which the message belongs in the scheduling request as an index. 3. The scheduling detection method according to claim 1 is characterized in that verifying the preemption frame function includes: each time a low-priority scheduling feedback is monitored, querying the cache based on the physical port number of the scheduling feedback whether there is information about a high-priority scheduling request with the same physical port number; if so, it indicates that the preemption frame scheduling behavior of the device under test is abnormal; if not, it indicates that the preemption frame scheduling behavior of the device under test is normal. 4. The scheduling detection method according to claim 1 is characterized in that verifying the consistency of the scheduling feedback quantity with the number of cells of the corresponding scheduling request includes: verifying whether the number of scheduling feedback corresponding to a scheduling request matches the number of cells in the information of the scheduling request; if they match, it means that the scheduling behavior of the device under test is normal; if they do not match, it means that the scheduling behavior of the device under test is abnormal. 5. The scheduling detection method according to claim 1 is characterized in that verifying the signal timing of the information in the scheduling request and the signal timing of the information in the scheduling feedback includes: verifying whether the rising edge and the falling edge of the signal of the information in the scheduling request and/or the scheduling feedback are aligned with the clock binary frequency of the device under test, if so, it means that the scheduling behavior of the device under test is normal, if not, it means that the scheduling behavior of the device under test is abnormal. 6. The scheduling detection method according to claim 1 is characterized in that it also includes: generating corresponding error information when verifying that the scheduling behavior of the device under test is abnormal. 7. A scheduling detection device, characterized in that it includes: a monitoring module, a cache module, a release module and a verification module; wherein, A monitoring module configured to monitor a scheduling module in a device under test; the device under test includes a scheduling module, an inlet queue management module and an outlet queue management module, and the scheduling module includes an inlet scheduling module and an outlet scheduling module; a cache module configured to cache information in the scheduling request when monitoring a scheduling request of an ingress scheduling module entering the scheduling module from an ingress queue management module; A release module, configured to release information of a corresponding scheduling request from a cache when monitoring a scheduling feedback sent by an egress scheduling module of the scheduling module to an egress queue management module; A verification module is configured to verify the scheduling behavior of the device under test based on the information in the scheduling feedback and/or the corresponding scheduling request, including: verifying whether the scheduling behavior of the device under test complies with a predetermined scheduling rule. If so, it indicates that the scheduling behavior of the device under test is normal; if not, it indicates that the scheduling behavior of the device under test is abnormal; wherein the scheduling rule includes one or more of the following: the signal timing of the information in the scheduling request, the signal timing of the information in the scheduling feedback, the consistency of the on-path information of the scheduling feedback and the corresponding scheduling request, the consistency of the number of scheduling feedback and the number of cells of the corresponding scheduling request, and the preemption frame function. 8. A computing device, comprising: Communication interface, processor, memory; The memory is used to store program instructions, and when the program instructions are executed by the processor, the computing device implements the scheduling detection method described in any one of claims 1 to 6. 9. A computer-readable storage medium having program instructions stored thereon, wherein when the program instructions are executed by a computer, the computer implements the scheduling detection method according to any one of claims 1 to 6.