CN114580325A - Method for analyzing Tarmac log in chip RTL verification stage - Google Patents

Abstract

The invention discloses a method for analyzing a Tarmac log in an RTL (real time language) verification stage of a chip, which comprises the following steps of: reading log information from the Tarmac log file, performing processing conversion, and writing a result into a conversion log list; analyzing each item in the conversion log list to generate a call tree data structure; analyzing a calling tree data structure and writing the calling tree into a file; a new Tarmac Log resolution tool that facilitates increasing RTL simulation verification efficiency by providing the following: the complete function call tree is analyzed and output, and a rapid tool for analyzing problems from the software perspective is provided; and (4) counting the cost of each function call, and conveniently supporting the performance optimization of a function level to reduce the simulation time.

Description

Method for analyzing Tarmac log in chip RTL verification stage

Technical Field

The invention relates to the technical field of chips, in particular to a method for analyzing a Tarmac log in an RTL (real time language) verification stage of a chip.

Background

In the design work, a chip front-end designer invests a long period of time to perform RTL (register transfer level) function simulation after finishing the realization of various algorithms/protocols and the like by using a hardware description language Verilog HDL. As the complexity of chips continues to increase, in addition to the complexity of designs, the difficulty of verification becomes greater. At present, most chip design manufacturers mainly divide verification work into two parts: RTL simulation verification and FPGA function verification. Only the former is of interest herein.

RTL simulation verification is an important bottleneck in the chip design and development process, the working time of the chip occupies a very large proportion in the whole chip period, and the industry research shows that the working time is about 70%. Along with the continuous improvement of the complexity and the integration of the chip, the simulation verification time is continuously and correspondingly improved, so the importance of improving the working efficiency of the simulation verification is self-evident.

RTL simulation verification consumes so much time, on one hand, simulation itself needs to occupy massive computing resources, and environment running can not simulate running of hundreds of ms-level embedded software in one day; on the other hand, diagnosis after a problem is found by simulation is often troublesome, which also increases the complexity of the simulation verification process. The simulation verification efficiency is improved, the software is optimized to reduce the running time, and the problem diagnosis efficiency is improved by the method.

Against this background, the simulation tools provided by EDA manufacturers are not only very generic, but also increasingly sophisticated in functionality. With the evolution of EDA tools, there is little practical variability between different products, and the subject matter is set forth herein in the Synopsys development environment used by the company. Synopsys provides

The debugging tool is used for assisting a customer to finish efficient analysis of problems in the simulation process. The method realizes the SoC verification driven by embedded software by providing a synchronous multi-window view of hardware and software design behaviors. It combines the visibility of embedded processor, RTL code, C code and assembly code of instruction level precision to realize comprehensive SoC debugging solution.

The process of using the Verdi tool to comprehensively diagnose problems through hardware waveforms and software codes is to load fsdb data files generated in the simulation process and then open an eclipse software interface. When a certain moment is selected on the nWave interface of Verdi, the eclipse interface can automatically synchronize to the moment, and the corresponding software execution site at the moment is displayed. The client can view all registers, memories, variables, corresponding codes and the like, and can also set breakpoints and single-step debugging. The method is greatly helpful for improving the problem diagnosis efficiency.

However, the Verdi tool has the following disadvantages: 1. it is inconvenient to extract function-level runtime information to assist in optimizing software execution time; 2. the software can only be analyzed by positioning problems through waveform analysis, and the waveform analysis of some problems is difficult, but the positioning from the software direction is more efficient.

Disclosure of Invention

In view of the two defects in the prior art of chips, the invention provides a method for analyzing the Tarmac log in the RTL verification stage of the chip, which can generate a function call tree and count the execution time of each function based on the Tarmac log, and promote the improvement of the RTL simulation verification efficiency.

In order to achieve the above purpose, the embodiment of the invention adopts the following technical scheme:

a method for analyzing a Tarmac log in a chip RTL verification stage comprises the following steps:

reading log information from the Tarmac log file, performing processing conversion, and writing a result into a conversion log list;

analyzing each item in the conversion log list to generate a call tree data structure;

the call tree data structure is parsed and the call tree is written to a file.

According to one aspect of the invention, the reading log information from the Tarmac log file and performing processing conversion, and the writing the result into the conversion log list comprises: traversing the original Tarmac LOG file, filtering and converting to generate a Converted _ LOG _ List List; the method specifically comprises the following steps: reading a log from the Tarmac log file, and finishing the processing if the log reaches the end of the file;

if the current value is the Rx _ REG log, updating the current values of R0-R12;

if the LOG is the IRQ event LOG, generating a BL instruction LOG and a LR _ REG LOG, and writing the BL instruction LOG and the LR _ REG LOG into a Converted _ LOG _ List List;

if the instruction LOG is the BLX _ REG instruction LOG, generating a BL instruction LOG, and writing the LOG into a Converted _ LOG _ List List;

if the LOGs are other non-useless LOGs, writing the Converted _ LOG _ List List;

if it is a garbage log, it is discarded.

According to an aspect of the present invention, if the IRQ event LOG is the IRQ event LOG, generating a BL instruction LOG and an LR _ REG LOG, and writing a Converted _ LOG _ List, includes:

generating a BL instruction LOG, taking a system interrupt processing function as a jump target, and writing the LOG into a Converted _ LOG _ List List;

and generating an LR _ REG LOG according to an LR register value contained in the IRQ event LOG, and writing the LOG into a Converted _ LOG _ List List.

According to an aspect of the present invention, if the instruction is a BLX _ REG instruction LOG, generating a BL instruction LOG and writing the LOG into a Converted _ LOG _ List includes: and obtaining a jump register ID from the LOG, generating a BL instruction LOG according to the current value of the jump register ID, and writing the LOG into a Converted _ LOG _ List List.

According to one aspect of the invention, the reading log information from the Tarmac log file and the processing conversion, and the writing of the result into the conversion log list comprises the following steps: and jumping to a step of reading a log from the Tarmac log file after each step is executed.

In accordance with one aspect of the present invention, parsing each entry in the translation log list to generate a call tree data structure comprises: traversing the filtered and Converted modified LOG List, processing and generating three function call tree lists; the method specifically comprises the following steps:

reading a LOG from the Converted _ LOG _ List List, and if the LOG reaches the end of the file, ending the processing;

if the current function call depth is the BL instruction LOG, writing the BL instruction LOG into a Calltree _ LOG _ func _ List, writing the time period of the BL instruction LOG into the Calltree _ LOG _ ns _ List, and writing the current function call depth into the Calltree _ LOG _ depth _ List;

if the current BL instruction LOG is the LR _ REG LOG, writing the obtained LR return register value into a Curstart _ List, and writing a corresponding index of the current BL instruction LOG in a Calltree _ LOG _ ns _ List into the Curstart _ nsindex _ List;

if the current instruction address is not equal to the stack top return value, the current instruction address indicates that the current instruction address is returned from the lower function call.

According to one aspect of the invention, indicating a return from a lower function call if the current instruction address is not equal to the top of stack return value comprises the steps of: reading the newest element of Curstart _ nsindex _ List to obtain the corresponding BL instruction LOG time index, calculating the actual execution time of the function according to the current EX instruction LOG time and the time stored in Calltree _ LOG _ ns _ List, and writing back the actual execution time of the function to Calltree _ LOG _ ns _ List; deleting the latest element of the Curstart _ List List; delete the curstart nsindex List newest element.

According to one aspect of the invention, parsing each entry in the translation log list to generate a call tree data structure further comprises the steps of: after the execution of each step is completed, the step of reading a LOG from the Converted _ LOG _ List is jumped to.

In accordance with one aspect of the present invention, parsing the call tree data structure and writing the call tree to the file comprises: traversing the three function call tree lists, processing and generating a call tree file; the method specifically comprises the following steps:

acquiring a function call depth from a Calltree _ LOG _ depth _ List List;

acquiring function execution time from a Calltree _ LOG _ ns _ List List;

acquiring function detailed information from a Calltree _ LOG _ func _ List List;

and synthesizing the information to generate a new log line writing file: each level of function call depth displays a Tab indentation, plus the function execution time and the formatted output of function detail information.

The implementation of the invention has the advantages that: analyzing the Tarmac log line by line, saving the LR return register value corresponding to the function call log into a stack when the function call log is encountered, and saving the LR return register value corresponding to each layer of call in the stack after the function call is carried out by multiple layers; if the resolved next instruction address is equal to the LR register value at the top of the current stack, then this indicates that the corresponding function has returned. Based on this basic logic, we can parse to get a complete function call stack. A new Tarmac log parsing tool is provided that can provide the following benefits, thereby facilitating an increase in RTL simulation verification efficiency:

1. the complete function call tree is analyzed and output, and a rapid tool for analyzing problems from the software perspective is provided;

2. and (4) counting the cost of each function call, and conveniently supporting the performance optimization of a function level to reduce the simulation time.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.

FIG. 1 is a schematic flow chart of step S1 according to the present invention;

FIG. 2 is a flowchart illustrating step S2 according to the present invention;

fig. 3 is a flowchart illustrating step S3 according to the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The analysis of software by Verdi is based on the information of the Tarmac log file generated in the simulation process, the Tarmac log comprises all register read-write, memory read-write, various abnormal information and the like generated in the software execution process, and each step of the CPU execution instruction is described in detail. The invention also achieves the design goal by analyzing the Tarmac log. Analyzing the Tarmac log line by line, saving the LR return register value corresponding to the function call log into a stack when the function call log is encountered, and saving the LR return register value corresponding to each layer of call in the stack after the function call is carried out by multiple layers; if the resolved next instruction address equals the LR register value at the top of the current stack, then this indicates that the corresponding function has returned. Based on this basic logic, we can parse to get a complete function call stack.

For convenience of the following description, some concepts used in the present invention are first defined:

1. the Tarmac logs are named as follows:

1) BL instruction log-log with type "IT/IS", containing direct function call instruction, which corresponds to the scene of ordinary function call;

2) the BLX _ REG instruction log-the log with the type of 'IT/IS' comprises an indirect function call instruction, a jump address IS specified and stored in a certain register from R0 to R12, the jump address corresponds to a scene using a function pointer in software, after a jump target register value IS obtained, the jump target register value can be converted into a BL instruction log corresponding to a common function call, and then a function call tree IS conveniently analyzed;

3) the IRQ event log-the log with the E subtype is a CoreEvent _ IRQ log, a BL instruction log and an LR _ REG log need to be converted in application, and then a function call tree is conveniently analyzed;

4) EX instruction Log-Log with type "IT/IS", which IS a general name of non-function call instruction;

5) LR _ REG log-log with type "R" and subtype R14 _;

6) rx _ REG Log-Log with type "R" and subtype R0-R12 general purpose registers;

7) useless logs-all logs except the logs 1-6 above do not influence the implementation of the text;

2. the list definitions used in the following steps S2 and S3:

1) calltree _ LOG _ func _ List-contains and only contains a List of all BL instruction LOGs in the Tarmac LOG;

2) callree _ LOG _ ns _ List-a List of function execution times corresponding to each BL instruction LOG in the callree _ LOG _ func _ List;

3) a callre _ LOG _ depth _ List, a List of function call depths corresponding to each BL instruction LOG in the callre _ LOG _ func _ List, for controlling each row in the function call tree to retract;

4) in the process of resolving the logs, dynamically changing a current ongoing function call stack List, wherein the value of each element is an LR return register of a function in a current call tree, the bottom element of the stack corresponds to a root function call, and the top element of the stack corresponds to a current page node function call;

5) curstart _ nsindex _ List-the index of the corresponding entry in Calltree _ LOG _ ns _ List for the jump function corresponding to each LR return register in the Curstart _ List is used to calculate the function execution time.

As shown in fig. 1, fig. 2 and fig. 3, a method for analyzing the Tarmac log in the RTL verification stage of a chip includes the following steps:

step S1: reading log information from the Tarmac log file, performing processing conversion, and writing a result into a conversion log list;

reading and processing each piece of log information line by line from the Tarmac log file, filtering useless logs, and converting special logs in the useless logs. The processing result is also written into a Converted _ LOG _ List (conversion LOG List) conversion List.

S11, reading a log from the Tarmac log file, and finishing the processing if the log reaches the end of the file;

step S12, if the log is the Rx _ REG log, updating current values of R0-R12, and jumping to step S11;

s13, if the event log is an IRQ event log;

s13.1, generating a BL instruction LOG, taking a system interrupt processing function as a jump target, and writing the LOG into a Converted _ LOG _ List List;

s13.2, generating an LR _ REG LOG according to an LR register value contained in the IRQ event LOG, and writing the LOG into a Converted _ LOG _ List;

s13.3, jumping to the step S11;

s14, if the instruction log is a BLX _ REG instruction log;

s14.1, obtaining a jump register ID from the LOG, generating a BL instruction LOG according to the current value of the jump register ID, and writing the LOG into a Converted _ LOG _ List List;

s14.2, jumping to S11;

step S15, writing the Converted _ LOG _ List into other non-useless LOGs, and jumping to step S11;

step S16. if the log is a useless log, discarding and jumping to step S11.

Step S2: analyzing each item in the conversion log list to generate a call tree data structure;

and traversing the filtered and Converted modified LOG List, processing and generating three function call tree lists.

S21, reading a log from the Tarmac log file, and finishing the processing if the end of the file is reached;

s22, if the instruction is a BL instruction log;

step S22.1. step S22.2. write BL instruction LOG into Calltree _ LOG _ func _ List;

s22.2, writing the time period of the BL instruction LOG into a Calltree _ LOG _ ns _ List;

s22.3, writing the current function calling depth into a Calltree _ LOG _ depth _ List;

s22.4, jumping to S21;

step S23, if the log is an LR _ REG log;

s23.1, writing the obtained LR return register value into a Curstack _ List;

step S23.2, writing a corresponding index of the current BL instruction LOG in a Calltree _ LOG _ ns _ List into a Curstat _ nsindex _ List;

s23.3, jumping to S21;

s24, if the command log is an EX command log, reading the newest element of the Curstart _ List, wherein the newest element corresponds to a function call stack top return value;

s24.1, if the current instruction address is not equal to the stack top return value, directly jumping to the step S21;

s24.2, if the current instruction address is not equal to the return value of the stack top, indicating that the call is returned from the lower function;

step S24.2.1, reading the newest element of Curstack _ nsindex _ List to obtain the corresponding BL instruction LOG time index, and according to the current EX instruction LOG time and the time stored in Calltree _ LOG _ ns _ List, calculating the actual function execution time, and writing back to Calltree _ LOG _ ns _ List;

step S24.2.2 deletes the newest element of the Curstart _ List List;

step S24.2.3 deletes the newest element of the Curstart _ nsindex _ List List;

step S24.2.4 jumps to step S21.

Step S3: the call tree data structure is parsed and the call tree is written to a file.

And traversing the three function call tree lists, processing and generating a call tree file.

Step S31, obtaining function calling depth from Calltree _ LOG _ depth _ List

Step S32, obtaining function execution time from Calltree _ LOG _ ns _ List List

Step S33, acquiring function detailed information from a Calltree _ LOG _ func _ List List

Step S34, synthesizing the information to generate a new log line write-in file: each level of function call depth displays a Tab indentation, and is added with function execution time and formatted output of function detailed information

And S35, jumping to S31.

The algorithms and displays presented herein are not inherently related to any particular computer, virtual machine, or other apparatus. Various general purpose systems may also be used with the teachings herein. The required structure for constructing such a system will be apparent from the description above. Moreover, the present invention is not directed to any particular programming language. It is appreciated that a variety of programming languages may be used to implement the teachings of the present invention as described herein, and any descriptions of specific languages are provided above to disclose the best mode of the invention.

In the description provided herein, numerous specific details are set forth. It is understood, however, that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be interpreted as reflecting an intention that: that the invention as claimed requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

Those skilled in the art will appreciate that the modules in the device in an embodiment may be adaptively changed and disposed in one or more devices different from the embodiment. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or elements of any method or apparatus so disclosed, may be combined in any combination, except combinations where at least some of such features and/or processes or elements are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments herein include some features included in other embodiments, rather than other features, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. For example, in the following claims, any of the claimed embodiments may be used in any combination.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word "comprising" does not exclude the presence of elements or steps not listed in a claim. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by one and the same item of hardware. The usage of the words first, second and third, etcetera do not indicate any ordering. These words may be interpreted as names.

The above description is only an embodiment of the present invention, but the scope of the present invention is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present invention disclosed herein are intended to be covered by the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the appended claims.

Claims (9)

1. A method for analyzing a Tarmac log in a chip RTL verification stage is characterized by comprising the following steps:

reading log information from the Tarmac log file, performing processing conversion, and writing a result into a conversion log list;

analyzing each item in the conversion log list to generate a call tree data structure;

the call tree data structure is parsed and the call tree is written to a file.

2. The method for analyzing the Tarmac log in the RTL verification stage of the chip according to claim 1, wherein the reading of the log information from the Tarmac log file and the processing conversion, and the writing of the result into the conversion log list comprises: traversing the original Tarmac LOG file, filtering and converting to generate a Converted _ LOG _ List List; the method specifically comprises the following steps: reading a log from the Tarmac log file, and finishing the processing if the log reaches the end of the file;

if the current value is the Rx _ REG log, updating the current values of R0-R12;

if the LOG is the IRQ event LOG, generating a BL instruction LOG and a LR _ REG LOG, and writing the BL instruction LOG and the LR _ REG LOG into a Converted _ LOG _ List List;

if the command is the BLX _ REG command LOG, generating a BL command LOG, and writing the LOG into a Converted _ LOG _ List List;

if the LOGs are other non-useless LOGs, writing the Converted _ LOG _ List List;

if it is a garbage log, it is discarded.

3. The method for analyzing the Tarmac LOG in the RTL verification stage of the chip of claim 2, wherein if the IRQ event LOG is generated, a BL instruction LOG and a LR _ REG LOG are generated and written into a Converted _ LOG _ List, and the method comprises the following steps:

generating a BL instruction LOG, taking a system interrupt processing function as a jump target, and writing the LOG into a Converted _ LOG _ List List;

and generating an LR _ REG LOG according to an LR register value contained in the IRQ event LOG, and writing the LOG into a Converted _ LOG _ List List.

4. The method for analyzing the Tarmac LOG in the RTL verification stage of the chip of claim 2, wherein if the instruction LOG is a BLX _ REG instruction LOG, generating a BL instruction LOG and writing the LOG into a Converted _ LOG _ List List comprises: and obtaining a jump register ID from the LOG, generating a BL instruction LOG according to the current value of the jump register ID, and writing the LOG into a Converted _ LOG _ List List.

5. The method for analyzing the Tarmac log in the RTL verification stage of the chip as claimed in claim 2, wherein the step of reading the log information from the Tarmac log file and performing the processing conversion, and writing the result into the conversion log list comprises the following steps: after each step is executed, jumping to a step of reading a log from the Tarmac log file.

6. The method for analyzing the Tarmac log during the RTL verification phase of the chip of claim 1, wherein parsing each entry in the translation log list to generate a call tree data structure comprises: traversing the filtered and Converted modified LOG List, processing and generating three function call tree lists; the method specifically comprises the following steps:

reading a LOG from the Converted _ LOG _ List List, and if the LOG reaches the end of the file, ending the processing;

if the current function call depth is the BL instruction LOG, writing the BL instruction LOG into a Calltree _ LOG _ func _ List, writing the time period of the BL instruction LOG into the Calltree _ LOG _ ns _ List, and writing the current function call depth into the Calltree _ LOG _ depth _ List;

if the current BL instruction LOG is the LR _ REG LOG, writing the obtained LR return register value into a Curstart _ List, and writing a corresponding index of the current BL instruction LOG in a Calltree _ LOG _ ns _ List into the Curstart _ nsindex _ List;

if the current instruction address is not equal to the stack top return value, the current instruction address indicates that the current instruction address is returned from the lower function call.

7. The method for analyzing the Tarmac log during the RTL verification stage of the chip of claim 6, wherein the step of indicating a return from a lower function call if the current instruction address is not equal to the top-of-stack return value comprises the steps of: reading the newest element of Curstart _ nsindex _ List to obtain the corresponding BL instruction LOG time index, calculating the actual execution time of the function according to the current EX instruction LOG time and the time stored in Calltree _ LOG _ ns _ List, and writing back the actual execution time of the function to Calltree _ LOG _ ns _ List; deleting the newest element in the Curstart _ List List; delete the curstart nsindex List newest element.

8. The method for analyzing the Tarmac log during the RTL verification stage of the chip of claim 7, wherein parsing each entry in the translation log list to generate the call tree data structure further comprises the steps of: after the execution of each step is completed, the step of reading a LOG from the Converted _ LOG _ List is jumped to.

9. The method for analyzing the Tarmac log during the RTL verification stage of the chip of claim 8, wherein parsing the call tree data structure and writing the call tree to the file comprises: traversing the three function call tree lists, processing and generating a call tree file; the method specifically comprises the following steps:

acquiring a function calling depth from a Calltree _ LOG _ depth _ List List;

acquiring function execution time from a Calltree _ LOG _ ns _ List List;

acquiring function detailed information from a Calltree _ LOG _ func _ List List;

and synthesizing the information to generate a new log line writing file: each level of function call depth displays a Tab indentation, plus the function execution time and the formatted output of function detail information.

Images