Verification method and related apparatus
By setting a counter for the request, the problem of poor scalability and readability caused by clock cycle timing in chip verification is solved, achieving the effect of simplifying maintenance and improving code readability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- PHYTIUM TECH CO LTD
- Filing Date
- 2022-09-28
- Publication Date
- 2026-07-28
AI Technical Summary
In existing chip verification technologies, the clock cycle-based stamping method results in poor scalability and readability of the verification environment, and is time-consuming and labor-intensive to maintain.
By setting corresponding counters for requests, the timing of requests is maintained, avoiding complex timing-related code, and using counters to control the target functional modules to perform actions according to the timing.
It improves the scalability of the verification environment and the readability of the code, simplifies the maintenance process, and avoids complex timing-related code.
Smart Images
Figure CN115563913B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of chip verification technology, specifically to a verification method and related apparatus. Background Technology
[0002] Chip verification is an essential part of the chip design phase. In the early stages of chip verification, a verification environment can be designed and built based on the chip's specifications and characteristics. Functional modules within the verification environment are used to implement different functions to verify the chip. These modules can send various requests to each other to achieve data exchange.
[0003] In the verification solutions provided by related technologies, the functional modules in the verification environment maintain the timing of requests based on the clock cycle pacing method. This method suffers from poor scalability, poor readability of verification code, and time-consuming and labor-intensive maintenance. Summary of the Invention
[0004] In view of this, the embodiments of this application aim to provide a verification method and related apparatus to improve the scalability of the verification scheme and the readability of the verification code.
[0005] In a first aspect, a verification method is provided, the method being applied to a target functional module in a verification environment, the target functional module having an interactive relationship with other functional modules in the verification environment, the method comprising: detecting a request sent by the other functional modules; in response to detecting a first request sent by the other functional modules, storing the first request in the storage structure of the target functional module and starting a counter corresponding to the first request, wherein the first request is used to trigger the target functional module to perform one or more actions according to a first timing sequence; and controlling the target functional module to perform the one or more actions according to the first timing sequence based on the counter corresponding to the first request.
[0006] Optionally, controlling the target function module to execute the one or more actions according to the first timing sequence based on the counter corresponding to the first request includes: checking the counter corresponding to the first request in each clock cycle to determine whether the execution time of the target action among the one or more actions has been reached; if the execution time of the target action has been reached, controlling the target function module to execute the target action.
[0007] Optionally, the method further includes refreshing the counter corresponding to the request in the storage structure in each clock cycle.
[0008] Optionally, the verification environment is a UVM verification environment.
[0009] Secondly, a verification device is provided for verifying a target functional module in a verification environment, the target functional module having an interactive relationship with other functional modules in the verification environment. The device includes: a detection unit configured to detect requests sent by the other functional modules; a storage unit configured to, in response to detecting a first request sent by the other functional modules, store the first request in the storage structure of the target functional module and start a counter corresponding to the first request, wherein the first request is used to trigger the target functional module to perform one or more actions according to a first timing sequence; and a control unit configured to, according to the counter corresponding to the first request, control the target functional module to perform the one or more actions according to the first timing sequence.
[0010] Optionally, the control unit is further configured to: check the counter corresponding to the first request in each clock cycle to determine whether the execution time of the target action in the one or more actions has been reached; if the execution time of the target action has been reached, control the target function module to execute the target action.
[0011] Optionally, the apparatus further includes a refresh unit configured to refresh the counter corresponding to the request in the memory structure in each clock cycle.
[0012] Optionally, the verification environment is a UVM verification environment.
[0013] Thirdly, a method is provided that includes a memory and a processor, wherein the memory stores executable code and the processor is configured to execute the executable code to implement the method as described in the first aspect.
[0014] Fourthly, a computer program product is provided, the computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method as described in the first aspect.
[0015] Fifthly, a computer-readable medium is provided that stores program code that, when run on a computer, causes the computer to perform the method as described in the first aspect.
[0016] Related technologies maintain the timing of requests by using clock cycle-based timing. This approach requires timing circuits and code to handle the clock cycle progression of requests, resulting in poor scalability and readability. Unlike related technologies, this application maintains the timing of requests by setting corresponding counters for each request, avoiding complex timing-related code and offering strong scalability. Attached Figure Description
[0017] Figure 1 This is a schematic diagram of a verification environment provided in an embodiment of this application.
[0018] Figure 2 This is a schematic diagram of a handshake interaction process provided in an embodiment of this application.
[0019] Figure 3 This is a flowchart illustrating a verification method provided in an embodiment of this application.
[0020] Figure 4 This is a flowchart illustrating another verification method provided in an embodiment of this application.
[0021] Figure 5 This is a schematic diagram of a verification device provided in an embodiment of this application.
[0022] Figure 6 This is a schematic diagram of another verification device provided in an embodiment of this application. Detailed Implementation
[0023] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.
[0024] Chip verification is an essential part of the chip design phase. As chip size increases, the time required for chip verification grows, and chip verification accounts for a larger proportion of the entire design cycle. To improve the speed of chip verification, various automated verification languages and methods have emerged.
[0025] In the early stages of chip verification, a verification environment can be designed and built based on the chip's specifications and characteristics. For example, a verification environment can be built using System Verilog hardware design and verification language. Common verification environments include Universal Verification Methodology (UVM) verification environments, Verification Methodology Manual (VMM) verification environments, and Open Verification Methodology (OVM) verification environments, etc.
[0026] Setting up the verification environment includes designing the various functional modules within it and designing the data interaction between these modules. These functional modules in the verification environment are used to implement different functions to verify the chip. Figure 1 This is a schematic diagram of the structure of a verification environment provided in an embodiment of this application, such as... Figure 1As shown, functional modules can include, for example, a driver, a reference model, a scoreboard, a monitor, and a device under test (DUT). These functional modules can exchange various requests to achieve data interaction. Figure 1 In this process, there is data interaction between the driver module, the reference model, and the verified module. For example, the driver module can input test stimuli to the reference model and the verified module.
[0027] In some embodiments, the module being verified may be a load store unit (LSU) of a processor. The LSU is an important component of the processor, located between the processor and memory, and is used to perform data loading and storage. The functional module interacting with the LSU may be, for example, a cache functional model, such as a Level 2 cache reference model (L2C-RFM). The interaction between the two functional modules includes load requests (LD requests) and / or store requests (ST requests) under both non-cacheable and cacheable attributes.
[0028] When processing interaction requests from various functional modules in the verification environment, the relevant technologies are based on clock timing, using sequential circuits and code to process the clock cycle of the requests progressively.
[0029] Taking the most common handshake interaction as an example, assume the requester is A and the receiver is B, where the requester and receiver can be any functional module in the verification environment. Requester A sends a handshake request signal to receiver B, requiring receiver B to respond with either a handshake agreement signal or a handshake rejection signal after four clock cycles. If receiver B agrees, requester A sends the necessary information to receiver B; if receiver B rejects, requester A waits for a period before sending the request to receiver B again.
[0030] Taking the LSU and L2C-RFM mentioned above as an example, data interaction between the LSU and L2C-RFM involves data return over multiple clock cycles. If the LSU issues a non-cacheable ST request, the L2C-RFM will check if it can receive it. If it can, it will return a receive signal to the LSU; otherwise, it will not return anything. If the L2C-RFM receives a data storage instruction, it will place the request in the L2C-RFM's storage structure. Then, in the next clock cycle (cyc1), it will return an ACK signal. In cyc2, it will return the instruction's ID information. In cyc3, it will receive the specific location of the data storage and the data to be stored. Then, every 30-60 clock cycles, it will write the data to the specific location and return a completion message. Similarly, the processing of data loading requests is similar to that described above and will not be elaborated upon here.
[0031] As can be seen, data interaction is conducted using clock-based timing, meaning the relevant technology employs clock cycle code to implement the cyclical progression of requests. However, this approach suffers from poor scalability and readability, and is also time-consuming and labor-intensive to maintain. For example, the handshake interaction process for a single requester was described earlier. When multiple requesters are involved, multiple clock cycle codes are required, meaning each request needs clock cycle code to implement the cyclical progression of requests. Even for similar requests, some code may be identical; adding more requests requires rewriting the same code repeatedly, making it extremely cumbersome and resulting in poor scalability and readability.
[0032] Based on this, this application provides a verification method and a verification device to realize data interaction between functional modules in a more flexible manner, thereby improving the scalability of the verification environment and the readability of the code.
[0033] Figure 2 This is a flowchart illustrating a verification method provided in an embodiment of this application. Figure 2 The method shown is applied to a target functional module in a verification environment, such as a UVM verification environment. The target functional module can be any functional module in the verification environment; in some embodiments, it can be an interface signal-driven analog module in the verification environment. The target functional module interacts with other functional modules in the verification environment. For example, the target functional module can be a driver module, which interacts with the module under test and the reference model in the verification environment; or, for example, the target functional module can be L2C-RFM, which interacts with the LSU under test and the monitor module in the verification environment. In other words, the target module can be any functional module in the verification environment that interacts with other functional modules. The following section combines... Figure 2 The verification scheme provided in the embodiments of this application will be introduced.
[0034] In step S210, requests sent by other functional modules are detected.
[0035] The system detects requests sent by other functional modules in the verification environment to the target functional module. These other functional modules are those in the verification environment that have an interactive relationship with the target functional module.
[0036] In some embodiments, a request checking function can be used to detect requests sent by other functional modules to a target functional module. The request checking function can identify multiple types of requests, which may include multiple types of requests sent by the same functional module to the target functional module, or multiple types of requests sent by different functional modules to the target functional module.
[0037] As the types of requests sent by other functional modules increase, the functional checking function can be extended to identify more types of requests. For example, new functions can be added to the request checking function, extending the functional checking function without affecting existing functions.
[0038] In step S220, in response to detecting a first request sent by another functional module, the first request is stored in the storage structure of the target functional module, and the counter corresponding to the first request is started.
[0039] The first request is a request sent by other functional modules that is detected by the target functional module. Taking the target functional module as L2C-RFM and other functional modules as LSU as an example, LSU can send multiple LD requests or / ST requests to L2C-RFM in parallel. When L2C-RFM detects a request sent by LSU, this request is the first request.
[0040] After detecting a first request sent by another functional module, the first request is stored in the target functional module's storage structure. The target functional module's storage structure can be a data structure capable of storing the first request. The target functional module can store different types of first requests.
[0041] In some embodiments, the first request can be stored based on the number of requests the storage structure can receive. Taking the handshake interaction mentioned earlier as an example... Figure 3 To introduce it. For example... Figure 3 As shown, there are multiple requesters, A, C, and D, and a receiver, B. Each requester can send one request per clock cycle, while receiver B can only receive two requests simultaneously. When requesters A, C, and D send requests at the same time and receiver B is idle, if receiver B's processing priority is A, C, and D, then requests from requesters A and C will enter receiver B's storage structure, while requester D's request will be rejected. Requester D will wait until B has free space before sending its request again.
[0042] When the target functional module needs to receive more first requests, the storage structure can be expanded. For example, if it needs to receive more numbers and / or types of first requests, the number of data structures used to store requests in the storage structure can be expanded to store more first requests.
[0043] A counter corresponding to the first request is started simultaneously with storing the first request. In other words, for each first request stored in the storage structure of the target functional module, there is a corresponding counter.
[0044] A counter can be used to count clock pulses. The counter corresponding to a request in the target functional module's memory structure can be refreshed every clock cycle. For example, a status refresh function can be created to update the time of the counter corresponding to each request in the memory structure.
[0045] The first request is used to trigger the target functional module to execute one or more actions based on a counter according to a first timing sequence. The first timing sequence is the time sequence of the target functional module executing one or more actions corresponding to the first request. Taking the target functional module as L2C-RFM and other functional modules as LSU as an example, the first timing sequence is the time order in which L2C-RFM executes multiple actions corresponding to the LSU sending a storage request. Specifically, the first timing sequence is as follows: when L2C-RFM detects that the first request sent by the LSU is a storage request, if L2C-RFM receives a data storage instruction, it will return an ACK signal in clock cycle cyc1, return the instruction's ID-related information in cyc2, receive the specific location of the data storage and the data to be stored in cyc3, and then write the data to the specific location at intervals of 30-60 clock cycles.
[0046] In step S230, based on the counter corresponding to the first request, the target function module is controlled to execute one or more actions according to the first timing sequence.
[0047] For example, the LSU's storage request is stored in the storage structure of the target functional module L2C-RFM, and the counter corresponding to the storage request is started. When the counter is 1 (the first clock cycle), L2C-RFM returns an ack signal; when the counter is 2 (the second clock cycle), L2C-RFM returns the instruction's ID-related information; when the counter is 3 (the third clock cycle), L2C-RFM receives the specific location of the data to be stored and the data to be stored; then, when the counter is between 33 and 63, the data is written to the specific location.
[0048] In some embodiments, the counters for all requests in the storage structure of the target functional module can be checked, and when a request reaches the corresponding time point, the target functional module can be controlled to perform the corresponding action to output the corresponding information or release the request.
[0049] In some cases, if the initial timing changes, for example, if an action requires a longer or shorter time to execute, the target functional module can be controlled to perform the corresponding action over a longer or shorter counting time. For example, when the L2C-RFM needs to write data to a specific location after 20 clock cycles, the L2C-RFM can be controlled to perform the data writing action when the counter is at 23.
[0050] In some cases, if the information that the target functional module needs to return changes when performing certain actions during the execution of the corresponding actions of the first request, or if the target functional module needs to add some information to return when performing certain actions, the function can be modified directly at the corresponding time or time period.
[0051] As can be seen, the verification method provided in this application embodiment can store the request from the requester, configure a corresponding clock counter for the request, and control the target functional module to execute one or more actions corresponding to the request according to the timing requirements based on the time provided by the clock counter. Unlike related technologies, this application embodiment maintains the timing of the request by setting a corresponding counter for the request, avoiding complex timing-related code and having strong scalability.
[0052] In some embodiments, the counter corresponding to each first request in the storage structure of the target functional module can be checked every clock cycle to determine whether the time for executing the action corresponding to each request has arrived. That is, the counters of each request in the storage structure are checked on a clock cycle basis to determine whether the execution time of the target action corresponding to the request has arrived. Here, the target action is the action that the target functional module is about to execute.
[0053] When the first request corresponds to only one action, that action is the target action. The counter for the first request is checked, and when the execution time for that action has been reached, the target function module is controlled to execute the target action, and the first request is released. When the first request corresponds to multiple actions, the counter for the first request is checked, and when the execution time for the currently scheduled target action has been reached, the target function module is controlled to execute the target action. Once all actions corresponding to the first request have been executed, the first request can be released.
[0054] The following is combined with Figure 4 A verification method provided in an embodiment of this application will be described. Figure 4The transaction processing flow of the target functional module in each cycle is shown.
[0055] In step S410, check if there is a request.
[0056] Check if any other functional modules in the verification environment send requests to the target functional module. If a request is detected, add the request to the data storage structure of the target functional module; if no request is detected, proceed to step S420.
[0057] In step S420, check if there are any pending requests in the data structure.
[0058] If the pending request is the handshake signal mentioned earlier, then check if there is a handshake signal to be returned in the data structure. If there is a pending request, then return it according to the remaining cases. Process the corresponding request according to different counts; you can either receive data or send data. Afterward, check if there are any pending requests to receive; if so, then receive the data.
[0059] In step S430, all counters in the data structure are updated.
[0060] Figure 4 This application describes a simple implementation, and its embodiments demonstrate good scalability when the situation becomes more complex. For example, if the target functional module needs to accept more requests, process more types of information, or maintain a longer clock cycle for the requests, the verification method provided in this application can be effectively extended to accommodate various changes. Specifically, when there are more requests and multiple requests not in the same cycle, the number of storage structures can be expanded to store more requests; when the types of information to be processed increase, different information can be fed back when performing corresponding actions based on the counters corresponding to the requests; when the clock cycle for the requests needs to be maintained for a longer period, the count end time of each request in the data structure can be adjusted to be higher.
[0061] The verification method provided in this application can be applied to the simulation of interface signal driving and the construction of functional modules in the UVM verification environment. When the registered transfer level (RTL) code being verified is upgraded, the UVM verification environment can quickly adapt.
[0062] As can be seen, this application decomposes the multi-cycle function of the target functional module into the function of each cycle, and then combines the functions of each cycle into a single-cycle function. In order to maintain the order of the cycles, a counter is added for simulation. That is, a request that requires multiple cycles to return data is decomposed into returning the corresponding part of the data for each cycle, and then the return of the requested data is completed within multiple single cycles according to the request counter.
[0063] Currently, most verification environments execute their functional modules in parallel using multiple request paths. Each request path maintains its own timing, and the duration of each request path is generally greater than one cycle. In some cases, there are interrelationships between request paths. Taking the most common storage and read requests as an example, a read request depends on a storage request. Before the storage request is released, the read request cannot read the data stored by the storage request. In other words, for the same data, the read request follows the storage request, meaning there is a temporal relationship between the two requests. Therefore, if a logical problem occurs in the control of one path at a certain moment, other request paths are likely to experience cascading control problems, ultimately disrupting the normal behavior of the verification program. The verification scheme provided in this application decouples the temporal interference between requests. It returns data for each request according to the counter corresponding to the request. In other words, it transforms multiple request paths into a single request path for processing by the target functional module, thereby avoiding cascading control problems.
[0064] The above text combined Figures 1 to 4 The method embodiments of this application are described in detail below, in conjunction with... Figures 5 to 6 The present application provides a detailed description of the apparatus embodiments. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be found in the foregoing method embodiments.
[0065] Figure 5 This is a schematic diagram of a verification device provided in an embodiment of this application. Figure 5 The verification device 500 shown is used to verify a target functional module in a verification environment, which interacts with other functional modules in the verification environment. The device 500 includes a detection unit 510, a storage unit 520, and a control unit 530, which are described below.
[0066] The detection unit 510 is configured to detect requests sent by the other functional modules;
[0067] Storage unit 520 is configured to, in response to detecting a first request sent by the other functional module, store the first request in the storage structure of the target functional module and start a counter corresponding to the first request, wherein the first request is used to trigger the target functional module to perform one or more actions according to a first timing sequence;
[0068] Control unit 530 is configured to control the target functional module to perform one or more actions in accordance with the first timing sequence based on the counter corresponding to the first request.
[0069] Optionally, the control unit 530 is further configured to: check the counter corresponding to the first request in each clock cycle to determine whether the execution time of the target action in the one or more actions has been reached; if the execution time of the target action has been reached, control the target function module to execute the target action.
[0070] Optionally, the apparatus further includes a refresh unit 540 configured to refresh the counter corresponding to the request in the memory structure in each clock cycle.
[0071] Optionally, the verification environment is a UVM verification environment.
[0072] Figure 6 This is a structural example diagram of another verification device provided in an embodiment of this application. Figure 6 The illustrated apparatus 600 may include a memory 610 and a processor 620. The memory 610 may be used to store executable code. The processor 620 may be used to execute the executable code stored in the memory 610 to implement the steps in the various methods described above. In some embodiments, the apparatus 620 may further include a network interface 630 through which the processor 620 exchanges data with external devices.
[0073] It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.
[0074] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.
[0075] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0076] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0077] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0078] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0079] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs) or semiconductor media (e.g., solid-state disks, SSDs), etc.
[0080] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A verification method, characterized in that, The method is applied to a target functional module in a verification environment, which interacts with other functional modules in the verification environment. The method includes: Detect requests sent by the other functional modules; In response to detecting a first request sent by the other functional modules, the first request is stored in the storage structure of the target functional module, and a counter corresponding to the first request is started. The first request is used to trigger the target functional module to perform one or more actions according to a first timing sequence, where the first timing sequence is the time sequence when the target functional module performs one or more actions corresponding to the first request. Based on the counter corresponding to the first request, control the target functional module to execute one or more actions according to the first timing sequence; Wherein, controlling the target functional module to execute one or more actions according to the first timing sequence based on the counter corresponding to the first request includes: In each clock cycle, check the counter corresponding to the first request to determine whether the execution time of the target action among the one or more actions has arrived; If the execution time of the target action is reached, control the target function module to execute the target action.
2. The method according to claim 1, characterized in that, The method further includes: The counter corresponding to the request in the memory structure is refreshed in each clock cycle.
3. The method according to claim 1, characterized in that, The verification environment is a UVM verification environment.
4. A verification device, characterized in that, The device is used to verify a target functional module in a verification environment, the target functional module having an interactive relationship with other functional modules in the verification environment. The device includes: The detection unit is configured to detect requests sent by the other functional modules; The storage unit is configured to, in response to detecting a first request sent by the other functional modules, store the first request in the storage structure of the target functional module and start a counter corresponding to the first request, wherein the first request is used to trigger the target functional module to perform one or more actions according to a first timing sequence, the first timing sequence being the time sequence when the target functional module performs one or more actions corresponding to the first request; The control unit is configured to control the target functional module to perform one or more actions in accordance with the first timing sequence based on the counter corresponding to the first request; The control unit is further configured as follows: In each clock cycle, check the counter corresponding to the first request to determine whether the execution time of the target action among the one or more actions has arrived; If the execution time of the target action is reached, control the target function module to execute the target action.
5. The apparatus according to claim 4, characterized in that, The device further includes: The refresh unit is configured to refresh the counter corresponding to the request in the memory structure in each clock cycle.
6. The apparatus according to claim 4, characterized in that, The verification environment is a UVM verification environment.
7. A verification device, characterized in that, The method includes a memory and a processor, wherein the memory stores executable code and the processor is configured to execute the executable code to implement the method as described in any one of claims 1-3.
8. A computer-readable storage medium, characterized in that, It stores code for performing the method as described in any one of claims 1-3.