A protocol processing method, device, electronic device and readable storage medium

Abstract

Embodiments of the present invention provide a protocol processing method, device, electronic device and readable storage medium, which relate to the field of computer technology. In the method, a requirement characterization file of a target system-on-chip is obtained. Transactions supported by the original protocol are taken as candidate transactions, and transactions matching the requirement characterization file are selected from the candidate transactions according to the requirement characterization file as target transactions. A first description file for each target transaction is obtained. A target protocol file is generated for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after trimming. In this way, generation of a protocol file for the target system-on-chip is achieved. At the same time, by generating a target protocol file according to the target transaction selected in the requirement characterization file of the target system-on-chip, the target protocol file finally obtained can be more adapted to the requirements of the target system-on-chip.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of computer technology, and in particular to a protocol processing method, device, electronic device and readable storage medium. Background Art

[0002] At present, with the continuous development of computer technology, the application of System on Chip (SoC) is becoming more and more widespread. System on chip is an integrated circuit that compresses all the components required by the system onto the same chip. System on chip can also be called system-level chip. System on chip can realize Network-on-Chip (NoC), which is a communication network structure used to connect various functional modules, processor cores, storage units and other important components on the chip.

[0003] In the related art, it is necessary to configure the protocol used for the on-chip network. Accordingly, how to generate a protocol file for the on-chip network has become a technical problem that needs to be solved urgently. Summary of the invention

[0004] The embodiments of the present invention provide a protocol processing method, device, electronic device and readable storage medium, which can be used to generate a protocol file for an on-chip network.

[0005] In order to solve the above problem, an embodiment of the present invention discloses a protocol processing method, which includes:

[0006] Obtain the target system-on-chip requirement characterization file;

[0007] The transactions supported by the original protocol are taken as candidate transactions, and according to the requirement characterization file, a transaction matching the requirement characterization file is selected from the candidate transactions as a target transaction;

[0008] Obtaining a first description file of each of the target transactions;

[0009] A target protocol file is generated for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after being trimmed.

[0010] On the other hand, an embodiment of the present invention discloses a protocol processing device, the device comprising:

[0011] A first acquisition module is used to acquire a requirement characterization file of a target system on chip;

[0012] A first selection module is used to take transactions supported by the original protocol as candidate transactions, and select transactions matching the requirement characterization file from the candidate transactions according to the requirement characterization file as target transactions;

[0013] A second acquisition module, used for acquiring a first description file of each target transaction;

[0014] A generation module is used to generate a target protocol file for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after being trimmed.

[0015] On the other hand, an embodiment of the present invention discloses an electronic device, comprising: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions enable the processor to execute the aforementioned method.

[0016] The embodiment of the present invention further discloses a readable storage medium on which executable instructions are stored. When executed by one or more processors, the processors execute the method as described above.

[0017] The embodiment of the present invention includes the following advantages: In the protocol processing method provided by the embodiment of the present invention, a requirement characterization file of the target system-on-chip is obtained. Transactions supported by the original protocol are taken as candidate transactions, and according to the requirement characterization file, transactions matching the requirement characterization file are selected from the candidate transactions as target transactions. A first description file is obtained for each target transaction. A target protocol file is generated for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after trimming. In this way, a target transaction is selected according to the requirement characterization file of the target system-on-chip, and a target protocol file is generated based on the target transaction, thereby realizing generation of a protocol file for the target system-on-chip. At the same time, by generating a target protocol file according to the target transaction selected in the requirement characterization file of the target system-on-chip, the target protocol file finally obtained can be more adapted to the requirements of the target system-on-chip. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0019] Figure 1 is a flowchart of a protocol processing method provided by an embodiment of the present invention;

[0020] Figure 2 is a block diagram of a protocol processing device provided by an embodiment of the present invention;

[0021] Figure 3It is a structural schematic diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0022] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0023] Reference Figure 1 , shows a flowchart of a protocol processing method provided by an embodiment of the present invention, such as Figure 1 As shown, the method may specifically include the following steps:

[0024] Step 101: Obtain a requirement characterization file of a target system-on-chip.

[0025] Step 102: Take the transactions supported by the original protocol as candidate transactions, and select, according to the requirement characterization file, a transaction matching the requirement characterization file from the candidate transactions as a target transaction.

[0026] Step 103: Obtain the first description file of each target transaction.

[0027] Step 104: Generate a target protocol file for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after being trimmed.

[0028] In an embodiment of the present invention, the target system-on-chip may be any system-on-chip that needs to use the tailored original protocol, and the requirement characterization file is collected when the target system-on-chip is running, and the requirement characterization file is used to characterize the processing requirements of the target system-on-chip. The pre-collected requirement characterization file can be loaded from a preset storage location to obtain the requirement characterization file. Specifically, the requirement characterization file may include relevant information about the instructions processed in the target system-on-chip. Among them, the relevant information of the instruction can be obtained from the log (Log) of the target system-on-chip. The original protocol may be a protocol that needs to be tailored. For example, the original protocol may be a cache consistency protocol, for example, the original protocol may be a coherent hub interface (CHI) protocol, wherein the CHI protocol is a protocol for building a high-performance, low-power multi-processor system. It provides an efficient, low-latency method to connect multiple processors, accelerators, memory, and other system components to achieve shared memory access and cache consistency. The CHI protocol provides a highly optimized coherent interconnect design. It is an evolution of the Advanced eXtensible Interface Coherence Extensions (ACE) protocol and is part of the Advanced Microcontroller Bus Architecture (AMBA) bus. It is designed to solve cache consistency issues in multi-core processor systems. Alternatively, the original protocol can also be other cache consistency protocols, such as the Modified Exclusive Shared Invalid (MESI) protocol, the Modified Owned Exclusive Shared Invalid (MOESI) protocol, the ACE protocol, etc.

[0029] In actual scenarios, a large number of supported transactions are defined in the original protocol, where a transaction refers to an operation sequence. A transaction may include a series of operations to be performed. For example, taking the original protocol as the CHI protocol, the operations may be read (load), write (store), replace (replacement) and synchronization (synchronization), etc. The transactions provided by the CHI protocol ensure the consistency and integrity of data in the cache system. For a transaction, the transaction may correspond to transaction parameters. For example, the transaction parameters may include: message type, cache state, state transition event, state transition condition and state transition action. Among them, the cache state, state transition event, state transition condition and state transition action may be referred to as state, event, condition and action respectively. The cache state, state transition event, state transition condition and state transition action define the processing flow of the transaction, where the message type indicates the type of request and response message involved in the transaction, the cache state indicates the state involved in the transaction, the state transition event indicates the event that triggers the state transition, the state transition condition indicates the condition that needs to be satisfied to transition from one state to another, and the state transition condition clarifies the transition rules of the cache line between different states. The state transition action represents the action to be performed when a state transition occurs. The action can be an operation or an output.

[0030] State transition events can be triggered by instructions. For example, instructions can be read and write requests or read and write responses. Assuming that a processor core or other system component needs to write data, it will send a write request, which will be sent to the cache controller or memory controller to trigger an event. After the write request is processed, the recipient of the request will send a write response, which will trigger an event. For example, the write response can trigger a "data write completed" event. Different transactions can be used to process different instructions. In response to the instruction, the transaction corresponding to the instruction can be added to the queue and the transaction in the queue can be executed.

[0031] Further, for the candidate transactions defined by the original protocol, a candidate transaction for processing the instructions included in the requirement characterization file can be selected as the target transaction. There can be multiple selected target transactions. For any target transaction, the description file of the target transaction can be obtained to obtain a first description file. The description file can also be called a formal description. The first description file of the target transaction can define the message type, cache state, state transition event, state transition condition and state transition action of the target transaction. The first description file of the target transaction can be used to describe the processing flow defined by the transaction parameters of the target transaction. Correspondingly, a target protocol file can be generated for the target system-on-chip based on the first description file. In this way, the target protocol file can define the processing flow defined by the transaction parameters of each target transaction to indicate how the target system-on-chip executes the target transaction to be executed. The target protocol file can be used to describe the target protocol, which is the original protocol after trimming, and the target protocol can be regarded as a subset of the original protocol. The above process of selecting the target transaction from the candidate transactions supported by the original protocol, obtaining the first description file of each target transaction, and generating the target protocol file based on the first description file of the target transaction is the process of trimming the original protocol. The target protocol file finally obtained by trimming can be provided to the target system-on-chip, which can improve the flexibility of protocol processing compared to the method of only providing the original protocol without trimming to the system-on-chip.

[0032] In an embodiment of the present invention, a target transaction is selected according to the requirements of the target system-on-chip, and a target protocol file is generated based on the target transaction. This can remove unnecessary parts of the original protocol, and the resulting target protocol file is more adapted to the requirements of the target system-on-chip and more suitable for the application scenarios of the target system-on-chip.

[0033] In summary, in the protocol processing method provided by the embodiment of the present invention, a requirement characterization file of the target system-on-chip is obtained. Transactions supported by the original protocol are taken as candidate transactions, and according to the requirement characterization file, transactions matching the requirement characterization file are selected from the candidate transactions as target transactions. A first description file is obtained for each target transaction. A target protocol file is generated for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after trimming. In this way, a target transaction is selected according to the requirement characterization file of the target system-on-chip, and a target protocol file is generated based on the target transaction, thereby realizing generation of a protocol file for the target system-on-chip. At the same time, by generating a target protocol file according to the target transaction selected in the requirement characterization file of the target system-on-chip, the target protocol file finally obtained can be more adapted to the requirements of the target system-on-chip.

[0034] Optionally, in an embodiment of the present invention, the requirement characterization file includes an instruction sequence generated in the target system-on-chip. Accordingly, the step of selecting a transaction matching the requirement characterization file from the candidate transactions as the target transaction according to the requirement characterization file may specifically include:

[0035] Step 1021: Count instruction types of instructions in the instruction sequence as first target types, and count the number of occurrences of instructions of the first target type in the instruction sequence.

[0036] Step 1022: For any of the transactions to be selected, if the first target type matches the preset instruction type corresponding to the transaction to be selected, and the number of instruction occurrences of the first target type meets the preset number condition corresponding to the transaction to be selected, determine the transaction to be selected as the target transaction.

[0037] The instruction sequence generated in the target system-on-chip may include instructions and instruction types processed by the target system-on-chip during operation. Taking the original protocol as the CHI protocol as an example, the instructions in the instruction sequence may be instructions for operating on cache lines. Furthermore, the instruction sequence may also include the instruction generation time, and the instructions in the instruction sequence may be arranged in sequence according to the instruction generation time.

[0038] Optionally, step 1021 may specifically include:

[0039] Step 1021a, starting from the first instruction of the instruction sequence, counting the instruction type of the instructions in the preset sliding window as the first target type in the preset sliding window, and counting the number of occurrences of the instructions of the first target type in the preset sliding window.

[0040] Step 1021b: If the preset sliding window has not reached the end instruction of the instruction sequence, move the preset sliding window.

[0041] Step 1021c, re-counting the instruction type of the instructions in the preset sliding window as the first target type in the preset sliding window, and counting the number of occurrences of the instructions of the first target type in the preset sliding window until the end instruction is reached.

[0042] In an embodiment of the present invention, when statistics are collected, a sliding window method can be used for statistics. The preset sliding window can correspond to a preset duration, wherein the preset duration can be set as needed, and illustratively, the preset duration can be 3 minutes. Starting from the first instruction (i.e., the first instruction) of the instruction sequence, the instructions in a preset sliding window, i.e., the instructions generated within a preset duration, can be counted each time. Specifically, the instruction type of the instructions in the preset sliding window can be counted as the first target type in the preset sliding window. Then, the number of occurrences of the instructions of the first target type in the preset sliding window is determined as the number of occurrences of the instructions of the first target type in the preset sliding window. Exemplarily, it is assumed that the instructions in the preset sliding window include: A instruction 1, A instruction 2, B instruction 1, B instruction 2, and A instruction 3. Then it can be determined that the instruction types of the instructions in the preset sliding window include: A instruction type and B instruction type, and two first target types are obtained: A instruction type and B instruction type. Then, the number of occurrences of each instruction of instruction type A and instruction type B is determined. Specifically, for instruction type A, the number of occurrences of instructions of instruction type A is 3, and for instruction type B, the number of occurrences of instructions of instruction type B is 2. Next, if the preset sliding window has not reached the end instruction of the instruction sequence, the preset sliding window can be moved backward.

[0043] Then, continue to count the instruction types of the instructions in the preset sliding window after the move, as the first target type in the preset sliding window, and count the number of times the instructions of the first target type in the preset sliding window appear. In this way, by continuously moving and counting until the end instruction in the instruction sequence is reached. The end instruction refers to the last instruction in the instruction sequence. Each time the preset sliding window is moved, it can be directly moved backward along the time axis corresponding to the instruction sequence for a preset time length, that is, the preset sliding window after the move does not overlap with the preset sliding window before the move, or it can also be directly moved backward along the time axis corresponding to the instruction sequence for a time length less than the preset time length, that is, the preset sliding window after the move partially overlaps with the preset sliding window before the move, and the embodiment of the present invention does not limit this. In this way, by sliding processing the instruction sequence through the preset sliding window, the processing of the instruction sequence can be achieved more finely.

[0044] For the first target type and the number of occurrences of the instructions of the first target type in any preset sliding window, the first target type and the number of occurrences of the instructions of the first target type obtained by counting in the preset sliding window can be compared with the preset instruction type and the preset number of conditions corresponding to each transaction to be selected. If there is a transaction to be selected that satisfies: the first target type matches the preset instruction type corresponding to the transaction to be selected, and the number of occurrences of the instructions of the first target type meets the preset number of conditions corresponding to the transaction to be selected, then the transaction to be selected is used as the target transaction, that is, the target transaction is selected according to the instructions in the preset sliding window.

[0045] Among them, the preset instruction type corresponding to the transaction to be selected is the type of instruction processed by the transaction to be selected, and the preset number condition corresponding to the transaction to be selected is used to characterize: the condition that the number of occurrences of the instruction to be processed by the transaction to be selected must meet. If the first target type included in the instruction sequence matches the preset instruction type corresponding to the transaction to be selected, it can be determined that the instruction generated by the target on-chip system is suitable for being processed by the transaction to be selected. Further, if the number of occurrences of the first target type of instruction meets the preset number condition, it can be determined that it is suitable to process the instruction generated by the target on-chip system through the transaction to be selected.

[0046] Specifically, for any transaction to be selected, the preset instruction type corresponding to the transaction to be selected can be compared with the first target type obtained by statistics in the preset sliding window. If the first target type obtained by statistics in the preset sliding window includes the preset instruction type corresponding to the transaction to be selected, that is, the preset instruction type corresponding to the transaction to be selected exists in the first target type obtained by statistics in the preset sliding window, it is determined that the first target type matches the preset instruction type corresponding to the transaction to be selected. Otherwise, it can be determined that the first target type does not match the preset instruction type corresponding to the transaction to be selected.

[0047] Furthermore, if the first target type obtained by statistics in the preset sliding window includes the preset instruction type corresponding to the transaction to be selected, the preset number of times condition corresponding to the transaction to be selected can be further compared with the number of instruction occurrences of the first target type obtained by statistics in the preset sliding window. If the number of instruction occurrences of the matching type meets the preset number of times condition corresponding to the transaction to be selected, the transaction to be selected can be determined as the target transaction. Among them, the preset number of times condition is that the number of instruction occurrences is not less than the preset number of times threshold. Specifically, for any matching type, it can be determined whether the number of instruction occurrences of the matching type meets the number condition of the matching type in the preset number of times condition corresponding to the transaction to be selected. Among them, the matching type is the first target type obtained by statistics in the preset sliding window that matches the preset instruction type corresponding to the transaction to be selected. The matching type can be one or more.

[0048] Exemplarily, assuming that the preset instruction types corresponding to the selected transaction 1 are instruction type A and instruction type B, the preset number of times condition corresponding to the selected transaction 1 is: the number of occurrences of instructions of instruction type A is not less than 3, and the number of occurrences of instructions of instruction type B is not less than 2. The preset instruction type corresponding to the selected transaction 2 is instruction type C, and the preset number of times condition corresponding to the selected transaction 2 is: the number of occurrences of instructions of instruction type C is not less than 2. The first target types obtained by statistics in the current preset sliding window are: instruction type A and instruction type B, and the number of occurrences of instructions of the first target type includes: the number of occurrences of instructions of instruction type A is 3, and the number of occurrences of instructions of instruction type B is 2.

[0049] After comparison, since the first target type obtained by statistics in the preset sliding window contains the A instruction type and the B instruction type corresponding to the selected transaction 1, and the number of instruction occurrences of the A instruction type meets the number condition of the A instruction type in the preset number condition corresponding to the selected transaction 1 (that is, the number of instruction occurrences of the A instruction type is not less than 3), and the number of instruction occurrences of the B instruction type meets the number condition of the B instruction type in the preset number condition corresponding to the selected transaction 1 (that is, the number of instruction occurrences of the B instruction type is not less than 2). Therefore, the selected transaction 1 can be determined as the target transaction. Since the C instruction type corresponding to the selected transaction 2 does not exist in the first target type obtained by statistics in the preset sliding window, the selected transaction 2 will not be determined as the target transaction this time.

[0050] It should be noted that, in the embodiment of the present invention, the preset instruction type and preset number of conditions corresponding to each transaction to be selected can be predetermined, and a mapping relationship between the transaction to be selected and its corresponding preset instruction type and preset number of conditions can be established. In this way, when the first target type and the number of instruction occurrences of the first target type obtained by counting in the preset sliding window are compared with the preset instruction type and preset number of conditions corresponding to each transaction to be selected, the preset instruction type and preset number of conditions corresponding to each transaction to be selected can be directly found from the mapping relationship, thereby facilitating the comparison.

[0051] Exemplarily, the processing indicators of different instructions for each selected transaction can be predetermined. For any selected transaction, the proportion of the number of instructions processed by the selected transaction for different instruction types relative to the total number of instructions processed, as well as the instruction processing time of different instruction types can be predetermined. For any instruction type, if the proportion of the number of the instruction type is greater than a preset proportion threshold, and the instruction processing time of the instruction type is less than a preset time threshold, then the instruction type can be determined as the preset instruction type of the selected transaction.

[0052] At the same time, the number of instructions of the preset instruction type processed by the selected transaction within a unit time can be counted multiple times in advance, and then the average of the processing numbers counted multiple times is used as the preset number threshold, and the preset number condition corresponding to the selected transaction is set to the number of occurrences not less than the preset number threshold. Among them, the above-mentioned operation of pre-determining the preset instruction type and preset number condition corresponding to each selected transaction can be automatically realized by analyzing the script, or the preset instruction type and preset number condition corresponding to each selected transaction can be manually determined by a technician in advance, and the embodiment of the present invention does not limit this.

[0053] In the embodiment of the present invention, by counting the instruction types of instructions in the instruction sequence as the first target type, and counting the number of occurrences of the instructions of the first target type in the instruction sequence, for any transaction to be selected, when the first target type matches the preset instruction type corresponding to the transaction to be selected, and the number of occurrences of the instructions of the first target type meets the preset number of conditions corresponding to the transaction to be selected, the transaction to be selected is determined as the target transaction. In this way, by comparing the first target type and the number of occurrences of the instructions of the first target type with the preset instruction type and the preset number of conditions corresponding to the transaction to be selected, the target transaction can be selected, so the selection efficiency is high.

[0054] Optionally, in the embodiment of the present invention, the step of obtaining the first description file of each target transaction may specifically include:

[0055] Step 1031: For any of the target transactions, determine the occurrence probability of a target instruction in the instruction sequence; the instruction type of the target instruction matches the preset instruction type corresponding to the target transaction.

[0056] Step 1032: For any candidate field combination of the target transaction, if the occurrence probability of the target instruction meets the preset probability condition corresponding to the candidate field combination, determine the candidate field combination as the target field combination; different candidate field combinations represent different transaction parameter values.

[0057] Step 1033: Obtain a domain specific language DSL code for describing the target transaction and the target field combination as a first description file of the target transaction.

[0058] Specifically, for any target transaction, the instruction type in the target sliding window that is the preset instruction type corresponding to the target transaction can be determined as the target instruction. Among them, the first target type in the target sliding window matches the preset instruction type corresponding to the target transaction, and the number of occurrences of the instruction of the first target type in the target sliding window meets the preset number condition corresponding to the target transaction, that is, the target transaction is selected according to the instruction in the target sliding window, and the target sliding window is the above-mentioned preset sliding window. Then, according to the time interval between the target instructions and the number of occurrences of the target instructions, the occurrence probability of the target instruction is determined. Among them, the occurrence probability of the target instruction is used to characterize the probability of the target instruction appearing in the subsequent time, and the time interval between the target instructions is the difference between the instruction generation time of each two target instructions appearing in the instruction sequence.

[0059] The shorter the time interval, the greater the number of occurrences of the target instruction, and the greater the occurrence probability determined for the target instruction. Exemplarily, the time interval of the target instruction and the number of occurrences of the target instruction can be used as inputs of a preset prediction algorithm, and then the output of the prediction algorithm is obtained as the probability of occurrence of the target instruction. The prediction algorithm is used to output the probability of occurrence in a manner in which the time interval of the instruction and the number of occurrences are positively correlated.

[0060] Further, in an embodiment of the present invention, for any transaction supported by the original protocol, the transaction corresponds to a plurality of legal field combinations that can be selected, and a legal field combination is an alternative field combination of the transaction. The alternative field combination may include multiple fields and their field values. For example, for any parameter in the transaction parameter, any optional parameter value corresponding to the parameter corresponds to a field, and at least one field value in the field corresponding to the parameter in the alternative field combination indicates a selected value, wherein the selected value may be 1, and the unselected value may be 0. Assuming that there are two optional state transition actions in the transaction parameter: action 1 and action 2, there is an alternative field combination in which the field value of the field corresponding to action 1 is 1, and there is an alternative field combination in which the field value of the field corresponding to action 2 is 1. Accordingly, the transaction parameter value indicates the specific value of the transaction parameter, and the specific value of the transaction parameter corresponding to the transaction can be determined by the field value in the alternative field combination. For example, for any alternative field combination, the parameter value represented by the field with a field value of 1 in the alternative field combination can be determined to obtain the transaction parameter value corresponding to the transaction. Different alternative field combinations corresponding to the same transaction have different transaction parameter values. For example, the transaction parameter value represented by alternative field combination a is for the state transition action parameter, and the parameter value is action 1, while the transaction parameter value represented by alternative field combination b is for the state transition action parameter, and the parameter value is action 2.

[0061] Among them, the preset probability condition corresponding to the alternative field combination can be that the probability of occurrence is not less than the preset probability threshold, and the preset probability condition corresponding to the alternative field combination can be used to characterize: the condition that the probability of occurrence of the instruction needs to meet when processing the transaction parameter value represented by the alternative field combination. The probability of occurrence of the target instruction can be compared with the preset probability conditions of each alternative field combination of the target transaction. If the probability of occurrence of the target instruction meets the preset probability threshold corresponding to the alternative field combination, it can be determined that it is suitable to process the instruction in the target system-on-chip through the target transaction with the alternative field combination, and the alternative field combination can be determined as the target field combination.

[0062] For each candidate field combination of any transaction, a corresponding preset probability condition can be determined in advance for each candidate field combination, and a mapping relationship between each candidate field combination of each transaction and the preset probability condition can be established. In this way, when comparing the occurrence probability of the target instruction with the preset probability condition corresponding to the candidate field combination, the preset probability condition corresponding to each candidate field combination can be directly found from the mapping relationship, thereby facilitating the comparison.

[0063] Exemplarily, for any candidate field combination of the transaction to be selected, multiple statistical operations can be performed in advance, and the statistical operation can be: the number of instructions of the preset type of instructions actually processed by the transaction to be selected with the candidate field combination within the preset time length during the statistical operation, wherein the preset type of instruction is the instruction of the preset instruction type corresponding to the transaction to be selected, and the number of instructions is the number of occurrences of the preset type of instruction within the preset time length. In this way, the number of instructions of multiple preset types of instructions can be obtained. Then, based on the number of instructions counted, the preset probability threshold of occurrence is set. Exemplarily, the more the number of instructions, the higher the preset probability threshold can be set, and the ratio of each instruction number to the total number of instructions processed by all the candidate field combinations of the transaction to be selected can be calculated, and the average of the multiple ratios is used as the preset probability threshold of the candidate field combination. Alternatively, for any statistical operation, the number of occurrences of the preset type of instructions counted by the statistical operation and the time interval between the preset type of instructions counted are used as the input of the preset prediction algorithm, wherein the time interval between the preset type of instructions is the difference between the instruction generation time of each two preset type instructions counted in this statistical operation. Then, the output of the prediction algorithm is obtained as the occurrence probability of the preset type instruction. For the statistical operation performed, multiple occurrence probabilities can be obtained. The mean of these multiple occurrence probabilities can be used as the preset probability threshold of the candidate field combination. The preset probability condition of the candidate field combination is set to the occurrence probability not less than the preset probability threshold.

[0064] In one implementation, for any target transaction, a domain specific language (DSL) code snippet corresponding to the target transaction and the target field combination can be searched from the first preset database as the first description file of the target transaction. The first preset database can be pre-established, and the first preset database includes a DSL code set corresponding to each candidate transaction. In this way, management is convenient and manageability is high. The DSL code set corresponding to a candidate transaction includes a DSL code snippet corresponding to each candidate field combination of the candidate transaction, that is, the first preset database includes multiple DSL code snippets, one DSL code snippet corresponds to a candidate transaction and an candidate field combination of the candidate transaction, and the DSL code snippet is used to describe the candidate transaction and the candidate field combination. Exemplarily, the DSL code snippet can be used to describe the behavior and state transition of the candidate transaction, and define the message type of the candidate transaction in detail. The code snippet in the first preset database can be pre-written. Exemplarily, the content in the complete CHI protocol specification can be analyzed in advance. A flow chart and a state chart are created for each transaction in the CHI protocol to visualize the behavior and state transition of the transaction, thereby facilitating the writing of code snippets.

[0065] In another implementation, for any target transaction, the transaction parameter value represented by the target field combination of the target transaction can be written into a preset DSL code template to obtain a DSL code snippet for describing the target transaction and the target field combination. The DSL code template includes a definition statement for defining each parameter in the transaction parameter, and the parameter value of each parameter in the transaction parameter can be written into the definition statement of the parameter to obtain a DSL code snippet for describing the target transaction and the target field combination.

[0066] For example, suppose there is a transaction for reading data to a local cache. The cache states of the transaction include: waiting for data (WaitingForData), data received (DataReceived), and completed (Complete). The state transition events include: read request arrival (ReadRequest), read response arrival (ReadResponse). The message types of the transaction include: ReadRequest {Address addr;}, ReadResponse {Data data;}. The state transition conditions include: transition condition 1 and transition condition 2, wherein transition condition 1 is when the read request arrives, the state transitions from waiting for data to data received, and transition condition 2 is when the read response arrives, the state transitions from data received to completed. The state transition actions include: executing the action of sending a read request (send(ReadRequest, addr)) when the state transitions from waiting for data to data received, and executing the action of receiving data and updating the cache (updateCache(data)) when the state transitions from data received to completed. The DSL code snippet of the transaction may include:

[0067] StateI. WaitingForData, DataReceived, Complete;

[0068] This line of code is used to define the cache state involved in the transaction.

[0069] Furthermore, it may also include:

[0070] message ReadRequest { Address addr;};

[0071] message ReadResponse { Data data;};

[0072] The above code line is used to define the message type of the transaction.

[0073] Furthermore, it may also include:

[0074] transition(WaitingForData) on (ReadRequest) do {

[0075] send(ReadRequest, addr);

[0076] } to (DataReceived);

[0077] The above code line is used to indicate that when a read request arrives, WaitingForData is converted to DataReceived, and the action of sending the read request is executed.

[0078] Furthermore, it may also include:

[0079] transition(DataReceived) on (ReadResponse) do {

[0080] updateCache(data);

[0081] } to (Complete);

[0082] The above code line is used to indicate that when a read response arrives, DataReceived is converted to Complete, and the action of receiving data and updating the cache is executed.

[0083] Furthermore, it may also include:

[0084] initial state WaitingForData;

[0085] The above code line is used to define the initial state of the read transaction as WaitingForData. Of course, the above example is only for illustrative purposes. For example, in actual application scenarios, transactions may also include other states, such as exclusive (UniqueClean, UC) state, modified exclusive (Unique Dirty, UD) state, shared clean (Shared Clean, SC) state, modified shared (Shared Dirty, SD) state, etc., and the embodiments of the present invention do not limit this.

[0086] Furthermore, in an embodiment of the present invention, the first description files of all target transactions can be used as a transaction model, and the transaction model can be regarded as a collection of the first description files of all target transactions. The transaction model is a formal description of all target transactions, and obtaining the transaction model is equivalent to achieving formal modeling. The first description file is a DSL code segment, and the transaction model can be understood as a DSL code segment, in which mathematical or logical forms are used to define the target transaction, for example, to define the execution process, state transition events, state transition conditions, and state transition actions of the target transaction. By using DSL code as a description file, subsequent maintenance and updating can be facilitated, and the maintainability is high. At the same time, the accuracy of the created transaction model can be ensured, and at the same time, it can be convenient for subsequent processing through a preset protocol verification tool.

[0087] In an embodiment of the present invention, for any candidate field combination of a target transaction, when the probability of occurrence of a target instruction meets the preset probability condition corresponding to the candidate field combination, the candidate field combination is determined as the target field combination; different candidate field combinations represent different transaction parameter values. A DSL code snippet for describing the target transaction and the target field combination is obtained as the first description file of the target transaction. In this way, by comparing the probability of occurrence of the target instruction with the preset probability condition corresponding to the candidate field combination, the target field combination can be selected, thereby facilitating the acquisition of a DSL code snippet for describing the target transaction and the target field combination as the first description file, thereby ensuring processing efficiency.

[0088] In the embodiment of the present invention, when different field combinations are selected for the same transaction, different cache strategies will be implemented. It should be noted that the field combination may also include a cache level for indicating the application, so as to implement customized cache strategies for different cache levels. Among them, the cache strategy cache indicates how to manage data, for example, how to allocate, replace and maintain consistency of data. When performing cache allocation, direct mapping, full associativity or group associativity can be used. In the direct mapping method, each data block can only be stored in a specific cache line, in the full associativity method, any cache line can store any data, and in the group associativity method, each data block can be stored in a specific set of cache lines. When performing replacement, simple replacement (evict) or writeback (writeback) can be used. Through different replacement methods, cache replacement can be performed more effectively, cache resources can be used more effectively, and cache misses can be reduced. When the selected target field combination indicates that a simple replacement is used when replacing, the replacement process can be simplified. When the selected target field combination indicates that a writeback is used when replacing, unnecessary data transmission and status updates can be reduced, thereby improving the overall performance of the system. For example, in the simple replacement mode, when processing a replacement instruction, if the cache line does not contain modified data, the cache only needs to send an evict request to the directory system, and the directory system will update the status and reply with a completion response (Completion response with Invalidate, comp_I). In the write-back mode, if the cache line contains modified data, the modified data will be written back to the main memory, and the cache line will enter the invalid (Invalid, I) state after the write-back is completed, which has no effect on the status of other caches in the system on chip.

[0089] Among them, the instructions included in the instruction sequence may be generated by an application in the target system-on-chip. Selecting the target transaction according to the instruction sequence can ensure that the candidate transaction that has a greater impact on the performance of the application is selected as the target transaction. Exemplarily, the target system-on-chip may be a multi-core system-on-chip, and the target system-on-chip may run a variety of applications. Different applications may correspond to different business scenarios, that is, different applications may have different requirements for cache consistency. For example, the application may include a video codec program and a database query program, etc. The video codec program application requires frequent data sharing, while the database query program pays more attention to the reading and writing speed of data.

[0090] If a static cache strategy is adopted to provide a unified cache strategy for all applications, it is impossible to adapt to the needs of different applications, which may easily lead to resource waste and performance bottlenecks. In an embodiment of the present invention, since the instruction sequence generated in the target system-on-chip will include instructions corresponding to each application in the target system-on-chip, correspondingly, the target transaction and target field combination are selected according to the instruction sequence, which is equivalent to taking into account the needs of different applications and realizing a dynamic cache strategy. Exemplarily, in the presence of a video codec program, the cache strategy formed by the selected target transaction and target field combination may include a cache strategy that allows data to be shared in multiple caches. In the presence of a database query program, the cache strategy formed by the selected target transaction and target field combination may include a cache strategy that optimizes read and write performance.

[0091] In this way, the tailored target protocol can adapt to the needs of different applications, so that each application can obtain better performance in cache consistency, improve the flexibility and efficiency of cache consistency, optimize performance, and avoid resource waste and performance bottlenecks.

[0092] Optionally, the embodiment of the present invention may further include the following steps:

[0093] Step S21: Select a target concurrent processing strategy from preset concurrent processing strategies based on the target transaction and a preset mapping relationship; the preset mapping relationship is used to characterize the mapping relationship between each of the preset concurrent processing strategies and the supported transaction.

[0094] Step S22: Obtain a second description file of the target concurrent processing strategy.

[0095] Among them, the preset concurrent processing strategy is the concurrent processing strategy supported by the original protocol. Exemplarily, the preset concurrent processing strategy may include a lock strategy, a token passing strategy, a sequential execution strategy, a blocking strategy, etc. These strategies can handle the situation where multiple transactions access the same cache line at the same time. Among them, the lock strategy implements locks at the cache line level through exclusive access and atomic operations to prevent multiple cores from modifying the same line at the same time. The token passing strategy uses tokens to control the order in which transactions access shared resources. The sequential execution strategy manages the execution order of transactions through queues to ensure that transactions are executed in address order. The blocking strategy can prevent race conditions. Race conditions refer to a concurrent environment where multiple nodes access shared data at the same time, and the execution order of these multiple nodes affects the output or system state. In the blocking strategy, when a node initiates a transaction, if another node in the system initiates a transaction that causes access to the same cache line, the system can block subsequent transactions. After the node completes the transaction, the node sends completion messages to enable the system to unblock the transaction initiated by another node, thereby ensuring the correct order of transactions. It should be noted that in the embodiment of the present invention, the preset concurrent processing strategy can also be updated, for example, a more efficient preset concurrent processing strategy can be added to reduce delay and improve throughput.

[0096] Optionally, step S21 may specifically include: step S21a, for any of the preset concurrent processing strategies, if the supported transaction corresponding to the preset concurrent processing strategy matches the target transaction, then the preset concurrent processing strategy is determined as the target concurrent processing strategy. For any preset concurrent processing strategy, the original protocol will define the transactions supported by the preset concurrent processing strategy, wherein the preset concurrent processing strategy can handle the concurrency under the cache state involved in the supported transactions. Accordingly, a mapping relationship between the preset concurrent processing strategy and the supported transactions can be established in advance based on the transactions supported by each preset concurrent processing strategy. Accordingly, after selecting the target transaction, for any preset concurrent processing strategy, the supported transaction corresponding to the preset concurrent processing strategy can be directly found from the preset mapping relationship, and then the found supported transaction is compared with the target transaction. If the supported transaction corresponding to the preset concurrent processing strategy includes all target transactions, it is determined that the supported transaction corresponding to the preset concurrent processing strategy matches the target transaction. Accordingly, the preset concurrency processing strategy can be determined as the target concurrency processing strategy. The target concurrency processing strategy can be used to characterize how the target protocol ultimately handles concurrency. In this way, by searching for the mapping relationship and comparing, the target concurrency processing strategy can be easily determined.

[0097] It should be noted that, in the embodiments of the present invention, the target concurrent processing strategy can be further selected in combination with the on-chip system complexity, the system performance target value and the system available resources. Specifically, if all target transactions are included in the supported transactions corresponding to the preset concurrent processing strategy, then when the on-chip system complexity of the target on-chip system meets the preset complexity requirements of the preset concurrent processing strategy, the system performance target value matches the preset performance value of the preset concurrent processing strategy, and the system available resources meet the preset resource requirements of the preset concurrent processing strategy, the preset concurrent processing strategy is determined as the target concurrent processing strategy. Among them, the on-chip system complexity is used to characterize the complexity of the system. The on-chip system complexity is related to the number of cores and cache levels of the system. The preset complexity requirement characterizes the maximum complexity that the preset concurrent processing strategy can adapt to. If the on-chip system complexity does not exceed the maximum complexity, it can be determined that the on-chip system complexity meets the preset complexity requirements of the preset concurrent processing strategy. The system performance target value is used to characterize the performance target of the system design. The system performance target value may include the maximum throughput and the minimum delay. Accordingly, the preset performance value characterizes the performance target value that can be achieved by the preset concurrent processing strategy. If the preset performance value is not less than the system performance target value, it can be determined that the two match. Furthermore, the system available resources are related to the system's memory and processor capabilities. The preset resource requirements characterize the minimum resources required by the preset concurrent processing strategy. If the system available resources are not less than the minimum resources, it can be determined that the system available resources meet the preset resource requirements.

[0098] Further, a description file of the target concurrent processing strategy may be obtained to obtain a second description file. The description file of the target concurrent processing strategy may be a DSL code snippet. Optionally, the step of obtaining the second description file of the target concurrent processing strategy may specifically include: step S22a, obtaining a DSL code for describing the target concurrent processing strategy as the second description file. In an embodiment of the present invention, a DSL code snippet corresponding to the target concurrent processing strategy may be searched from a second preset database as the second description file of the target concurrent processing strategy. The second preset database may be pre-established, and the second preset database includes DSL code snippets corresponding to each preset concurrent processing strategy, that is, the second preset database includes multiple DSL code snippets, one DSL code snippet corresponds to one preset concurrent processing strategy, and the DSL code snippet is used to describe the preset concurrent processing strategy. The second preset database may be the same database as the first preset database, or may be two independent databases, which is not limited in the embodiment of the present invention. In this way, using the DSL code as the description file of the target concurrent processing strategy can facilitate subsequent processing by a preset protocol verification tool.

[0099] Accordingly, the above step of generating a target protocol file for the target system-on-chip based on the first description file may specifically include: Step 1041, generating the target protocol file based on the first description file and the second description file.

[0100] Specifically, all the first description files and the second description files can be combined to obtain an initial protocol file. That is, the DSL code segment corresponding to the above-mentioned transaction model is combined with the DSL code segment corresponding to the target concurrent processing strategy, and the merged DSL code segment obtained is the initial protocol file. Among them, the initial protocol file can also be called a stable protocol model. Then, the initial protocol file is directly determined as the target protocol file, or a state machine model file is generated based on the initial protocol file, and the initial protocol file and the state machine model file are used as the target protocol file. In this way, the integrity of the target protocol file can be further improved. Among them, the state machine model file is equivalent to describing all cache states defined in the initial protocol file and the conversion method between different cache states (including events that trigger state conversion and actions performed when state conversion occurs). All cache states can include stable states and transient states. The transient state refers to the transition state when the cache line is converted between stable states. The transient state reflects the intermediate state of the cache line during the transaction process.

[0101] Exemplarily, the initial protocol file can be used as the input of the preset generation tool, and the input of the preset generation tool is obtained to obtain the state machine model file. Among them, the preset generation tool can be a protocol generation (Protocol, Generate, ProtoGen) tool, and the preset generation tool can run the initial protocol file and create a state pointer. When a state transition occurs, the state pointer is controlled to point to the converted cache state, and the action performed when the state transition occurs and the event that triggers the state transition are linked. Each cache state pointed to by the state pointer, the action performed when the state transition occurs each time, and the event that triggers the state transition are recorded. Finally, based on the recorded cache state, the action performed when the state transition occurs, and the event that triggers the state transition, a state machine model file is created. For example, the recorded cache state, the action performed when the state transition occurs, and the event that triggers the state transition are written into the preset state machine DSL code template to obtain a state machine model file. The preset generation tool can finally directly output the initial protocol file and the state machine model file to obtain the target protocol file.

[0102] In actual application scenarios, improper identification and processing of concurrent operations may lead to reduced system performance or even cause system failure. In an embodiment of the present invention, based on the target transaction and the preset mapping relationship, a target concurrent processing strategy is selected from the preset concurrent processing strategies, a second description file of the target concurrent processing strategy is obtained, and a target protocol file is generated based on the first description file and the second description file, so that the target protocol file can be processed concurrently, thereby avoiding performance degradation or system failure problems caused by concurrency to a certain extent. At the same time, by implementing the target concurrent processing strategy in the target protocol file, the function of the target protocol is more complete.

[0103] Optionally, in the embodiment of the present invention, after the step of generating a target protocol file for the target system-on-chip based on the first description file, the following steps may be performed:

[0104] Step S31, obtaining a reference protocol file generated according to the demand representation file; the generation method of the reference protocol file is different from the generation method of the target protocol file.

[0105] Step S32: Match the reference protocol file and the target protocol file according to the cache states defined by the reference protocol file and the target protocol file respectively.

[0106] Step S33: If the target protocol file matches the reference protocol file, target prompt information is output; the target prompt information is used to indicate that the target protocol file meets the preset correctness requirement.

[0107] In an embodiment of the present invention, the reference protocol file may be pre-generated according to the requirement characterization file, and accordingly, the reference protocol file may be loaded from a preset storage location. The reference protocol file and the target protocol file are used to achieve the same requirement. The reference protocol file may be used as a reference to compare the reference protocol file with the target protocol file to verify the correctness of the automatically generated target protocol file.

[0108] In one implementation scenario, the reference protocol file can be manually generated based on the requirement characterization file. Accordingly, the complexity of the requirement characterization file used this time can be lower than the preset complexity, so that the difficulty of generating the reference protocol file can be reduced and the accuracy of the reference protocol file can be ensured. Accordingly, if the target protocol file matches the reference protocol file, it can be determined that the correctness of the protocol processing method meets the standard, and the protocol processing method can be used to process other requirement characterization files. The protocol processing method can be run in an electronic device in the form of a protocol processing tool, and the process of matching the reference protocol file and the target protocol file can be regarded as a verification process for the protocol processing tool.

[0109] When matching, the number of repetitions of the first state set of the reference protocol file and the second state set of the target protocol file can be determined first, and the coverage rate can be determined based on the number of repetitions. Among them, the more the number of repetitions, the higher the coverage rate. For example, the ratio of the number of repetitions to the preset reference value can be used as the coverage rate. The first state set includes all cache states defined in the reference protocol file, and the second state set includes all cache states defined in the target protocol file. If the coverage rate exceeds the preset coverage rate threshold, it is further determined whether the conversion mode between the same cache states in the first state set and the second state set is consistent. And, the performance indicators and resource consumption indicators of the reference protocol file and the target protocol file in the simulation process are compared. The target protocol file meets the preset correctness requirements, which can refer to: the coverage rate exceeds the preset coverage rate threshold, the conversion mode between the same cache states in the first state set and the second state set is consistent, the difference between the performance indicator of the reference protocol file and the performance indicator of the target protocol file is within the preset performance indicator difference range, and the difference between the resource consumption indicator of the reference protocol file and the resource consumption indicator of the target protocol file is within the preset resource consumption indicator difference range. Accordingly, in the case of meeting the preset correctness requirements, it can be determined that the target protocol file matches the reference protocol file, and then the target prompt information is output. The target prompt information may be text information, for example, the target prompt information may be "has passed comparison verification".

[0110] In an embodiment of the present invention, a reference protocol file generated according to a demand characterization file is obtained; the generation method of the reference protocol file is different from the generation method of the target protocol file. According to the cache status defined by the reference protocol file and the target protocol file respectively, the reference protocol file and the target protocol file are matched. If the target protocol file matches the reference protocol file, the target prompt information is output; the target prompt information is used to characterize that the target protocol file meets the preset correctness requirements. In this way, it can be determined whether the target protocol file is correct through verification, and then the correctness of the protocol processing method can be verified.

[0111] It should be noted that in the embodiment of the present invention, test cases can also be generated in advance for the reference protocol file and the target protocol file, respectively. Among them, the test case may include a consistency test case, a functional test case and a boundary condition test case corresponding to the normal operation in the corresponding protocol file to ensure that the key protocol scenarios in the protocol file are covered. The reference protocol file and the target protocol file are respectively subjected to consistency testing, functional testing and boundary condition testing through their respective test cases. Among them, the consistency test is to verify whether the protocol file meets all pre-defined consistency conditions by running the consistency test case. The functional test is to test whether the protocol file implements all pre-set expected functions by executing the functional test case. The boundary condition test is to test whether the protocol file can correctly handle boundary conditions and abnormal situations through the boundary condition test case. If the target protocol file and the reference protocol file pass the consistency test, functional test and boundary condition test, the target protocol file is matched with the reference protocol file to avoid unnecessary matching operations when the protocol file fails the test.

[0112] Optionally, in the embodiment of the present invention, after the step of generating a target protocol file for the target system-on-chip based on the first description file, the following steps may be performed:

[0113] Step S41: input the target protocol file into a preset protocol verification tool.

[0114] Step S42: Obtain the output of the preset protocol verification tool to obtain a protocol verification result.

[0115] Step S43: If the protocol verification result indicates that the target protocol file has passed the verification, the target protocol file is output to the user.

[0116] The preset protocol verification tool may be a protocol model detector, for example, Murphi, ) model checker. Preset invariants are predefined in the preset protocol verification tool. Specifically, a property constraint file can be customized in advance in the preset protocol verification tool, and the property constraint file can include preset invariants. For example, the preset invariants can include a single-writer multiple-reader (SWMR) invariant and a dirty data (Dirty) unique invariant, wherein the SWMR invariant and the Dirty unique invariant correspond to the SWMR rule and the Dirty unique rule respectively, so as to ensure that the pruned protocol achieves cache consistency. The preset verification tool can be used to verify whether the target protocol file violates the preset invariant. And, the target protocol file is traversed to check whether there is a state in which execution cannot continue, that is, a deadlock. If the target protocol file does not violate the preset invariant and there is no deadlock, a protocol verification result indicating that the target protocol file has passed the verification can be generated. For example, a text-type protocol verification result can be output: "The preset invariant is not violated and there is no deadlock". Accordingly, when the protocol verification result indicates that the target protocol file has passed the verification, the target protocol file is output to the user for the user to apply the target protocol file to the target system-on-chip. Exemplarily, the target protocol file may be displayed to the user, or sent to a user terminal used by the user.

[0117] In an embodiment of the present invention, the generated target protocol file is verified by a preset protocol verification tool. The target protocol file is output to the user only when the protocol verification result indicates that the target protocol file has passed the verification. Outputting the target protocol file to the user for use can ensure that the protocol file finally provided to the target system-on-chip is a verified protocol file, ensure the reliability of the protocol file finally provided to the target system-on-chip, and further ensure the reliability and stability of the target system-on-chip.

[0118] It should be noted that in the embodiment of the present invention, transactions that meet the requirements of cache consistency in the CHI protocol can also be pre-selected as core transactions. The core transactions are selected as candidate transactions to select target transactions from the core transactions to form a transaction subset, so that the target protocol obtained after trimming retains the core functions to ensure functional completeness. In this way, it can be ensured that the transaction subset can meet the requirements of the target on-chip system while meeting the consistency requirements to a certain extent.

[0119] In one example, the target transaction may include ReadOnce, ReadShared, and WriteFull to ensure that cache consistency is maintained while ensuring the simplicity of the target protocol. Among them, ReadOnce is used for a single core to read data, ReadShared is used for multiple cores to share read data, and WriteFull is used to write data and ensure data consistency. ReadShared transactions can process load instructions. In a multi-core processor system, different caches need to maintain data consistency to ensure that each processor core can access the latest data. ReadShared transactions allow cache lines to be shared between different caches instead of being invalidated at each read. In ReadShared transactions, as long as the requestor receives the consistency data and is informed to enter a valid state, the snoop filter (SF) is allowed to fully control the result state of all caches, which is highly flexible. The response to the ReadShared transaction contains the consistency data requested and the state information indicating the requester needs to enter. Among them, the response can come from the directory system or the cache party (fwd owner) that has a copy of the data and is responsible for forwarding the request. Exemplarily, when a peer cache receives a ReadShared transaction from a directory, it can convert the cache line being read from the UD state to the SD state and retain the data at all locations, rather than invalidating the cache line being read. A WriteFull transaction can process a store instruction, which involves writing data and converting cache states, and if the cache line being written is in the UC state, it uses a no-data request cache to obtain exclusivity through a CleanUnique no-data request, and allows silent upgrades. For example, the state of the cache line being written is converted from UC to UD, and no information needs to be sent during a silent upgrade, which can reduce data transmission and save bandwidth.

[0120] The design and verification of the protocol is a very challenging task. Since the protocol specification (spec) of the original protocol is relatively complex, if the target protocol is involved by manual interpretation, the cost is high because the protocol specification is complex and difficult to understand. And limited by personal experience, errors are prone to occur in the design method through manual interpretation. In an embodiment of the present invention, a target protocol matching the requirements of the target system-on-chip is automatically generated, and a protocol is customized for the target system-on-chip. Since no manual interpretation is required, labor costs and time costs can be reduced, and errors can be reduced. At the same time, when it is necessary to generate respective target protocol files for different target systems-on-chip, the protocol processing method provided by the embodiment of the present invention is directly used, and the protocol file can be generated according to the requirement characterization files of different target systems-on-chip, that is, the protocol processing method can be reused for different target systems-on-chip, and the method has high versatility and scalability. And the target protocol file is generated by formal description for different target systems-on-chip, so that the automatically generated protocol file is easier to integrate into the verification test process, and is verified by an automated tool such as a preset protocol verification tool. Therefore, the difficulty of verification can be reduced, verification can be facilitated, and then the verification coverage can be improved, and the accuracy of the generated protocol file can be verified.

[0121] In the embodiment of the present invention, a machine learning algorithm can also be used to optimize protocol tailoring and verification. For example, the requirement characterization file of the target system-on-chip can be processed by a machine learning algorithm to determine the target transaction. Since system requirements and work complexity are constantly changing, the protocol processing method provided by the embodiment of the present invention can automatically generate the target protocol file. Therefore, it is convenient to re-determine the target protocol file for the new requirement characterization file when changes occur, so as to dynamically adjust the protocol.

[0122] Reference Figure 2 , shows a block diagram of a protocol processing device provided by an embodiment of the present invention, such as Figure 2 As shown, the device may specifically include:

[0123] A first acquisition module 201 is used to acquire a requirement characterization file of a target system on chip;

[0124] A first selection module 202 is used to select transactions supported by the original protocol as candidate transactions, and select transactions matching the requirement characterization file from the candidate transactions according to the requirement characterization file as target transactions;

[0125] A second acquisition module 203, used to acquire a first description file of each target transaction;

[0126] The generating module 204 is used to generate a target protocol file for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after being trimmed.

[0127] Optionally, the requirement characterization file includes an instruction sequence generated in the target system-on-chip; the first selection module 202 is specifically configured to:

[0128] Counting instruction types of instructions in the instruction sequence as first target types, and counting the number of occurrences of instructions of the first target type in the instruction sequence;

[0129] For any of the transactions to be selected, if the first target type matches the preset instruction type corresponding to the transaction to be selected, and the number of instruction occurrences of the first target type meets the preset number condition corresponding to the transaction to be selected, the transaction to be selected is determined as the target transaction.

[0130] Optionally, the first selection module 202 is further configured to:

[0131] Starting from the first instruction of the instruction sequence, counting instruction types of instructions in a preset sliding window as a first target type in the preset sliding window, and counting the number of occurrences of instructions of the first target type in the preset sliding window;

[0132] If the preset sliding window has not reached the end instruction of the instruction sequence, moving the preset sliding window;

[0133] The instruction types of the instructions in the preset sliding window are re-counted as the first target type in the preset sliding window, and the number of occurrences of the instructions of the first target type in the preset sliding window is counted until the end instruction is reached.

[0134] Optionally, the second acquisition module 203 is specifically configured to:

[0135] For any of the target transactions, determining the probability of occurrence of a target instruction in the instruction sequence; the instruction type of the target instruction matches a preset instruction type corresponding to the target transaction;

[0136] For any candidate field combination of the target transaction, when the occurrence probability of the target instruction meets the preset probability condition corresponding to the candidate field combination, the candidate field combination is determined as the target field combination; different candidate field combinations represent different transaction parameter values;

[0137] A domain specific language (DSL) code for describing the target transaction and the target field combination is obtained as a first description file of the target transaction.

[0138] Optionally, the device further comprises:

[0139] A second selection module is used to select a target concurrent processing strategy from preset concurrent processing strategies based on the target transaction and a preset mapping relationship; the preset mapping relationship is used to characterize the mapping relationship between each of the preset concurrent processing strategies and the supported transaction;

[0140] A third acquisition module, used to acquire a second description file of the target concurrent processing strategy;

[0141] The generating module 204 is specifically used for:

[0142] The target protocol file is generated based on the first description file and the second description file.

[0143] Optionally, the second selection module is specifically configured to: for any of the preset concurrent processing strategies, if the supported transaction corresponding to the preset concurrent processing strategy matches the target transaction, determine the preset concurrent processing strategy as the target concurrent processing strategy;

[0144] The third acquisition module is specifically used to: acquire DSL code for describing the target concurrent processing strategy as the second description file.

[0145] Optionally, the device further comprises:

[0146] A fourth acquisition module, configured to acquire a reference protocol file generated according to the requirement characterization file after the generation module 204 generates a target protocol file for the target system-on-chip based on the first description file; the generation method of the reference protocol file is different from the generation method of the target protocol file;

[0147] A matching module, used for matching the reference protocol file and the target protocol file according to the cache states defined by the reference protocol file and the target protocol file respectively;

[0148] The first output module is used to output target prompt information if the target protocol file matches the reference protocol file; the target prompt information is used to indicate that the target protocol file meets a preset correctness requirement.

[0149] Optionally, the device further comprises:

[0150] An input module, configured to input the target protocol file into a preset protocol verification tool after the generating module 204 generates a target protocol file for the target system-on-chip based on the first description file;

[0151] A fifth acquisition module, used to acquire the output of the preset protocol verification tool to obtain a protocol verification result;

[0152] The second output module is configured to output the target protocol file to a user if the protocol verification result indicates that the target protocol file has passed the verification.

[0153] In summary, in the protocol processing device provided by the embodiment of the present invention, the requirement characterization file of the target system-on-chip is obtained. The transactions supported by the original protocol are taken as the selected transactions, and according to the requirement characterization file, the transactions matching the requirement characterization file are selected from the selected transactions as the target transactions. The first description file of each target transaction is obtained. A target protocol file is generated for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after trimming. In this way, the target transaction is selected according to the requirement characterization file of the target system-on-chip, and the target protocol file is generated based on the target transaction, thereby realizing the generation of the protocol file for the target system-on-chip. At the same time, by generating the target protocol file according to the target transaction selected by the requirement characterization file of the target system-on-chip, the target protocol file finally obtained can be more adapted to the requirements of the target system-on-chip.

[0154] Reference Figure 3 , is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Figure 3 As shown, the electronic device includes: a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other through the communication bus; the memory is used to store executable instructions, and the executable instructions enable the processor to execute the protocol processing method of the above embodiment. The executable instructions can constitute a program.

[0155] An embodiment of the present invention provides a readable storage medium having executable instructions stored thereon. When executed by one or more processors, the processors are enabled to execute the protocol processing method of the foregoing embodiment.

[0156] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0157] It should be understood by those skilled in the art that the embodiments of the present invention can be provided as methods, devices, or computer program products. Therefore, the embodiments of the present invention can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes. It should be noted that all actions of acquiring signals, information or data in this application are carried out under the premise of complying with the corresponding data protection laws and policies of the country of residence and with the authorization given by the owner of the corresponding device. The embodiments of the present invention are described with reference to the flowcharts and / or block diagrams of the methods, terminal devices (systems), and computer program products according to the embodiments of the present invention. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing terminal device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device generate instructions for implementing the processes in the process Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0158] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing terminal device to operate in a predictable manner, so that the instructions stored in the computer readable memory produce a manufactured product including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0159] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable terminal device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0160] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0161] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or terminal device including the elements.

[0162] The above is a detailed introduction to a protocol processing method, a protocol processing device, an electronic device and a readable storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for a general technician in this field, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A protocol processing method, characterized in that: The method comprises: Obtaining a requirement characterization file of a target system-on-chip; the requirement characterization file includes an instruction sequence generated in the target system-on-chip; The transactions supported by the original protocol are taken as candidate transactions, and according to the requirement characterization file, a transaction matching the requirement characterization file is selected from the candidate transactions as a target transaction; For any of the target transactions, determining the probability of occurrence of a target instruction in the instruction sequence; the instruction type of the target instruction matches a preset instruction type corresponding to the target transaction; For any candidate field combination of the target transaction, if the occurrence probability of the target instruction meets the preset probability condition corresponding to the candidate field combination, determine the candidate field combination as the target field combination; Acquire a domain specific language (DSL) code for describing the target transaction and the target field combination as a first description file of the target transaction; A target protocol file is generated for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after being trimmed.

2. The method according to claim 1, characterized in that The requirement characterization file includes an instruction sequence generated in the target system-on-chip; and selecting a transaction matching the requirement characterization file from the candidate transactions as a target transaction according to the requirement characterization file, including: Counting instruction types of instructions in the instruction sequence as first target types, and counting the number of occurrences of instructions of the first target type in the instruction sequence; For any of the transactions to be selected, if the first target type matches the preset instruction type corresponding to the transaction to be selected, and the number of instruction occurrences of the first target type meets the preset number condition corresponding to the transaction to be selected, the transaction to be selected is determined as the target transaction.

3. The method according to claim 2, characterized in that The counting of instruction types of instructions in the instruction sequence as the first target type, and counting the number of occurrences of instructions of the first target type in the instruction sequence, comprises: Starting from the first instruction of the instruction sequence, counting instruction types of instructions in a preset sliding window as a first target type in the preset sliding window, and counting the number of occurrences of instructions of the first target type in the preset sliding window; If the preset sliding window has not reached the end instruction of the instruction sequence, moving the preset sliding window; The instruction types of the instructions in the preset sliding window are re-counted as the first target type in the preset sliding window, and the number of occurrences of the instructions of the first target type in the preset sliding window is counted until the end instruction is reached.

4. The method according to claim 1, characterized in that: Different combinations of the candidate fields represent different transaction parameter values.

5. The method according to any one of claims 1 to 4, characterized in that: The method further comprises: Based on the target transaction and the preset mapping relationship, a target concurrent processing strategy is selected from the preset concurrent processing strategies; the preset mapping relationship is used to characterize the mapping relationship between each of the preset concurrent processing strategies and the supported transaction; Obtaining a second description file of the target concurrent processing strategy; The generating a target protocol file for the target system-on-chip based on the first description file includes: The target protocol file is generated based on the first description file and the second description file.

6. The method according to claim 5, characterized in that The selecting a target concurrent processing strategy from preset concurrent processing strategies based on the target transaction and the preset mapping relationship comprises: for any of the preset concurrent processing strategies, if the supported transaction corresponding to the preset concurrent processing strategy matches the target transaction, determining the preset concurrent processing strategy as the target concurrent processing strategy; The obtaining of the second description file of the target concurrent processing strategy includes: obtaining a DSL code for describing the target concurrent processing strategy as the second description file.

7. The method according to any one of claims 1 to 4, characterized in that: After generating a target protocol file for the target system-on-chip based on the first description file, the method further includes: Acquire a reference protocol file generated according to the requirement representation file; the reference protocol file is generated in a manner different from the target protocol file; Matching the reference protocol file and the target protocol file according to cache states defined by the reference protocol file and the target protocol file respectively; If the target protocol file matches the reference protocol file, target prompt information is output; the target prompt information is used to indicate that the target protocol file meets the preset correctness requirement.

8. The method according to any one of claims 1 to 4, characterized in that: After generating a target protocol file for the target system-on-chip based on the first description file, the method further includes: Inputting the target protocol file into a preset protocol verification tool; Obtaining the output of the preset protocol verification tool to obtain a protocol verification result; If the protocol verification result indicates that the target protocol file has passed the verification, the target protocol file is output to the user.

9. A protocol processing device, characterized in that: The device comprises: A first acquisition module is used to acquire a requirement characterization file of a target system-on-chip; the requirement characterization file includes an instruction sequence generated in the target system-on-chip; A first selection module is used to take transactions supported by the original protocol as candidate transactions, and select transactions matching the requirement characterization file from the candidate transactions according to the requirement characterization file as target transactions; A second acquisition module is used to determine, for any of the target transactions, the occurrence probability of a target instruction in the instruction sequence; the instruction type of the target instruction matches the preset instruction type corresponding to the target transaction; for any candidate field combination of the target transaction, if the occurrence probability of the target instruction meets the preset probability condition corresponding to the candidate field combination, determine the candidate field combination as the target field combination; and obtain a domain specific language DSL code for describing the target transaction and the target field combination as a first description file of the target transaction; A generation module is used to generate a target protocol file for the target system-on-chip based on the first description file; wherein the target protocol file is used to describe the original protocol after being trimmed.

10. An electronic device, characterized in that: include: A processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface communicate with each other via the communication bus; The memory is used to store executable instructions, and the executable instructions enable the processor to execute the method according to any one of claims 1 to 8.

11. A readable storage medium, characterized in that: Executable instructions are stored thereon, which, when executed by one or more processors, cause the processors to perform the method according to any one of claims 1 to 8.

Images