CN114580325B - Tarmac log analysis method in chip RTL verification stage - Google Patents

Tarmac log analysis method in chip RTL verification stage Download PDF

Info

Publication number
CN114580325B
CN114580325B CN202111671408.8A CN202111671408A CN114580325B CN 114580325 B CN114580325 B CN 114580325B CN 202111671408 A CN202111671408 A CN 202111671408A CN 114580325 B CN114580325 B CN 114580325B
Authority
CN
China
Prior art keywords
log
list
writing
instruction
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111671408.8A
Other languages
Chinese (zh)
Other versions
CN114580325A (en
Inventor
员清观
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Infotm Microelectronics Co ltd
Original Assignee
Shanghai Infotm Microelectronics Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Infotm Microelectronics Co ltd filed Critical Shanghai Infotm Microelectronics Co ltd
Priority to CN202111671408.8A priority Critical patent/CN114580325B/en
Publication of CN114580325A publication Critical patent/CN114580325A/en
Application granted granted Critical
Publication of CN114580325B publication Critical patent/CN114580325B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/327—Logic synthesis; Behaviour synthesis, e.g. mapping logic, HDL to netlist, high-level language to RTL or netlist
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
    • G06F16/1815—Journaling file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design
    • G06F30/32—Circuit design at the digital level
    • G06F30/33—Design verification, e.g. functional simulation or model checking
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The invention discloses a method for analyzing a Tarmac log in a chip RTL verification stage, which comprises the following steps: reading log information from the Tarmac log file, processing and converting, and writing the result into a conversion log list; analyzing each entry in the conversion log list to generate a call tree data structure; analyzing the call tree data structure and writing the call tree into the file; a new Tarmac log parsing tool that can provide the following benefits to facilitate improved RTL simulation verification efficiency: analyzing and outputting a complete function call tree, and providing a shortcut tool for analyzing problems from the software perspective; and counting the cost of each function call, namely conveniently supporting the performance optimization of the function level so as to reduce the simulation time.

Description

Tarmac log analysis method in chip RTL verification stage
Technical Field
The invention relates to the technical field of chips, in particular to a Tarmac log analysis method in a chip RTL verification stage.
Background
In the design work, chip front end designers need to invest a long time to perform RTL (register transfer level) function simulation after completing various algorithms/protocols and the like by using a hardware description language Verilog HDL. As the complexity of chips continues to rise, the difficulty of verification becomes greater in addition to the complexity of the design. Most chip design manufacturers now, the verification work is mainly divided 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 development process, and the working time of the RTL simulation verification occupies a very large proportion in the whole chip period, and the industrial investigation shows about 70%. Along with the continuous improvement of the complexity and the integration level of the chip, the simulation verification time is continuously improved, so that the importance of improving the simulation verification work efficiency is self-evident.
RTL simulation verification takes so long, on one hand, the simulation itself needs to occupy massive computing resources, and the environment running for one day may not be enough to simulate running of hundred ms embedded software; on the other hand, diagnosis after the simulation finds out a problem is often troublesome, which also increases the complexity of the simulation verification process. The simulation verification efficiency is improved, the running time of software is reduced, and the problem diagnosis efficiency is improved by a method.
In this context, not only are the simulation tools offered by EDA manufacturers very generic, but the functionality is also becoming more and more sophisticated. As EDA tools continue to evolve, the variability between different products is realThe subject matter herein will be described in the context of a Synopsys development environment for use by this company. Synopsys providesThe debugging tool is used for assisting the customer in completing the efficient analysis of problems occurring in the simulation process. The embedded software-driven SoC verification is realized by providing synchronous multi-window views of hardware and software design behaviors. It combines the visibility of the embedded processor, RTL code, C code and assembly code at instruction level accuracy to achieve a comprehensive SoC debug solution.
The process of comprehensively diagnosing problems through hardware waveforms and software code using the Verdi tool is to load the fsdb data file generated by the simulation process and then open the eclipse software interface. When a certain moment is selected in the nWave interface of Verdi, the eclipse interface can be automatically synchronized to the moment, and the corresponding software execution site at the moment is displayed. The client can check all registers, memories, variables, corresponding codes and the like, and can also set breakpoints and single step debugging. And greatly helps to improve the problem diagnosis efficiency.
However, the Verdi tool has the following drawbacks: 1. it is inconvenient to extract function level runtime information to assist in optimizing software execution time; 2. the software can be analyzed only by locating problems through waveform analysis, and the waveform analysis of some problems is difficult, and the locating efficiency from the software direction is higher.
Disclosure of Invention
In view of the two defects existing in the current chip technology field, the invention provides a Tarmac log analysis method in a chip RTL verification stage, which can generate a function call tree and count the execution time of each function based on the Tarmac log, so as to promote the improvement of RTL simulation verification efficiency.
In order to achieve the above purpose, the embodiment of the present invention adopts the following technical scheme:
a method for analysis of a Tarmac log at a chip RTL verification stage, the method comprising the steps of:
reading log information from the Tarmac log file, processing and converting, and writing the result into a conversion log list;
analyzing each entry in the conversion log list to generate a call tree data structure;
parsing the call tree data structure and writing the call tree to the file.
According to one aspect of the present invention, the reading log information from the tar log file and performing processing conversion, and writing the result into the conversion log list includes: 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 ending the processing if the end of the file is reached;
if the current value is Rx_REG log, updating the current values of R0 to R12;
if the result is the IRQ event LOG, generating a BL instruction LOG and an LR_REG LOG, and writing a converted_LOG_List List;
if the BLX_REG 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 LOG is other than useless LOG, writing a converted_LOG_List List;
if it is a dead log, it is discarded.
According to one aspect of the invention, if the IRQ event LOG is generated, the BL instruction LOG and the lr_reg LOG are generated and written into the converted_log_list List, including:
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 the LR register value contained in the IRQ event LOG, and writing the LOG into a converted_LOG_List List.
According to one aspect of the present invention, if the blx_reg instruction LOG is generated, the BL instruction LOG is generated, and the LOG is written into the converted_log_list List, including: the skip register ID is obtained from the LOG, a BL instruction LOG is generated according to the current value of the skip register ID, and the LOG is written into a converted_LOG_List List.
According to one aspect of the present invention, the steps of reading log information from the tar log file and performing processing conversion, and writing the result into the conversion log list include the following steps: after each step is completed, the step is skipped to a step of reading a log from the Tarmac log file.
In accordance with one aspect of the invention, the parse conversion log list each entry generates a call tree data structure comprising: traversing the filtered and Converted List of Converted LOG List, and 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 ending the processing if the end of the file is reached;
if the current function call depth is the BL instruction LOG, writing the BL instruction LOG into the 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 acquired LR return register value into a Curstar_List, and writing the corresponding index of the current BL instruction LOG in the Calltree_LOG_ns_List into the Curstar_nsindex_List;
if the instruction is EX instruction log, reading the latest element of Curstar_List, which corresponds to the return value of the function call stack top, and if the current instruction address is not equal to the return value of the stack top, indicating the return from the lower function call.
In accordance with one aspect of the invention, if the current instruction address is not equal to the top of stack return value, indicating a return from a lower function call comprises the steps of: reading the latest element of Curstar_nsindex_List to obtain a corresponding BL instruction LOG time index, calculating the actual execution time of a function according to the current EX instruction LOG time and the time saved in the Calltree_LOG_ns_List, and writing back the actual execution time of the function to the Calltree_LOG_ns_List; deleting the latest element of the Curstar_List List; the latest element of the Curstar_nsindex_List List is deleted.
In accordance with one aspect of the present invention, the parsing the conversion log list each entry generates a call tree data structure further comprising the steps of: after each step is completed, the process jumps to the step of reading a LOG from the Converted LOG List.
In accordance with one aspect of the invention, parsing the call tree data structure and writing the call tree to the file includes: traversing three function call tree lists, and processing and generating call tree files; the method specifically comprises the following steps:
obtaining a function call depth from a Calltere_LOG_depth_List List;
acquiring function execution time from a Calltere_LOG_ns_List List;
acquiring function detailed information from a Calltere_LOG_func_List List;
generating a new log line writing file by combining the information: each level of function call depth displays a Tab indentation, plus the function execution time and the formatted output of the function detail information.
The implementation of the invention has the advantages that: analyzing the Tarmac log line by line, and storing the corresponding LR return register value of the Tarmac log into a stack when the Tarmac log encounters a function call log, wherein after multi-layer function call, the LR return register value corresponding to each layer call is stored in the stack; if the resolved next instruction address is equal to the LR register value at the top of the current stack, then a corresponding function is 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 to facilitate increasing RTL simulation verification efficiency:
1. analyzing and outputting a complete function call tree, and providing a shortcut tool for analyzing problems from the software perspective;
2. and counting the cost of each function call, namely conveniently supporting the performance optimization of the function level so as to reduce the simulation time.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed 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 other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic flow chart of step S1 according to the present invention;
FIG. 2 is a schematic flow chart of step S2 according to the present invention;
fig. 3 is a schematic flow chart of step S3 according to the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The analysis of Verdi on software is based on the information of the Tarmac log file generated in the simulation process, and the Tarmac log contains all the register read-write, memory read-write, various exception information and the like generated in the software execution process, so that each step of action of the CPU execution instruction is thoroughly described. The invention also achieves the design objective by parsing the Tarmac log. Analyzing the Tarmac log line by line, and storing the corresponding LR return register value of the Tarmac log into a stack when the Tarmac log encounters a function call log, wherein after multi-layer function call, the LR return register value corresponding to each layer call is stored in the stack; if the resolved next instruction address is equal to the LR register value at the top of the current stack, then a corresponding function is 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 defined first:
1. the Tarmac log is named as follows:
1) BL instruction log-type IS "IT/IS" log, include the direct function call instruction, this corresponds to scene of the ordinary function call;
2) The BLX_REG instruction log-type IS 'IT/IS' log, comprises an indirect function call instruction, jump address assignment IS stored in a certain register of R0-R12, the jump address assignment corresponds to a scene using a function pointer in software, the jump target register value can be converted into a BL instruction log corresponding to common function call after being obtained, and then a function call tree IS convenient to analyze;
3) The IRQ event log-the log with the subtype of E being CoreEvent_IRQ, needs to be converted into a BL instruction log and an LR_REG log in application, and then the function call tree is convenient to analyze;
4) EX instruction Log-Log of type "IT/IS", generic term of non-function call instruction;
5) Lr_reg log-log with subtype "R14 link register;
6) Rx_REG log-type is the log of the general purpose registers with the subtype R' being R0 to R12;
7) Useless logs-all logs except 1-6 above, do not affect the implementation of the text;
2. list definition used in the following steps S2 and S3:
1) Calltere_LOG_func_List-contains and only contains a List of all BL instruction LOGs in the Tarmac LOG;
2) Calltree_LOG_ns_List-a List of function execution times corresponding to each BL instruction LOG in the Calltree_LOG_func_List;
3) The calltree_log_depth_list is a List of function call depths corresponding to each BL instruction LOG in the calltree_log_func_list and is used for controlling each row of retraction in a function call tree;
4) In the process of analyzing the log, a current function call stack List which dynamically changes, wherein the value of each element is an LR return register of a function in a current call tree, a stack bottom element corresponds to root function call, and a stack top element corresponds to current page node function call;
5) Curdstack_nsindex_List-the index of the corresponding entry of the jump function corresponding to each LR return register in Curdstack_List in the Calltree_LOG_ns_List List is used for calculating the function execution time.
As shown in fig. 1, 2 and 3, a method for analyzing a tar mac log in an RTL verification stage of a chip, the method includes the following steps:
step S1: reading log information from the Tarmac log file, processing and converting, and writing the result into a conversion log list;
and reading and processing each piece of log information row by row from the Tarmac log file, filtering useless logs, and converting special logs. The processing result is written into a converted_log_list conversion List together.
S11, reading a log from the Tarmac log file, and ending the processing if the end of the file is reached;
s12, if the log is the Rx_REG log, updating the current values of R0 to R12, and jumping to the step S11;
s13, if the IRQ event log is obtained;
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 List;
s13.3, jumping to a step S11;
s14, if the command log is BLX_REG command log;
s14.1, obtaining a skip register ID from the LOG, generating a BL instruction LOG according to the current value of the skip register ID, and writing the LOG into a converted_LOG_List List;
s14.2, jumping to a step S11;
s15, writing a converted_LOG_List List into other non-useless LOGs, and jumping to the step S11;
step S16, if the log is useless, discarding and jumping to step S11.
Step S2: analyzing each entry in the conversion log list to generate a call tree data structure;
traversing the filtered and Converted List of Converted LOG List, processing and generating three function call tree lists.
S21, reading a log from the Tarmac log file, and ending the processing if the end of the file is reached;
s22, if the BL command log is the BL command log;
step S22.1, step S22.2, writing the BL instruction LOG into a 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 call depth into the Calltree_LOG_depth_List;
s22.4, jumping to S21;
s23, if the log is the LR_REG log;
s23.1, writing the obtained LR return register value into a Curstar_List;
step S23.2, writing the corresponding index of the current BL instruction LOG in the Calltree_LOG_ns_List List into the Curstar_nsindex_List;
s23.3, jumping to the step S21;
s24, if the EX instruction log is obtained, reading the latest element of the Curstar_List, wherein the latest 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 stack top return value, indicating that the return is from the lower function call;
step S24.2.1 reads the latest element of Curstar_nsindex_List to obtain the corresponding BL instruction LOG time index, calculates the actual execution time of the function according to the current EX instruction LOG time and the time saved in CallTree_LOG_ns_List, and writes back the actual execution time of the function to CallTree_LOG_ns_List;
step S24.2.2 deletes the Curstar_List List latest element;
step S24.2.3 deletes the Curstar_nsindex_List List latest element;
step S24.2.4 jumps to step S21.
Step S3: parsing the call tree data structure and writing the call tree to the file.
And traversing three function call tree lists, and processing and generating call tree files.
S31, obtaining the function call depth from the Calltere_LOG_depth_List List
S32, obtaining function execution time from the Calltere_LOG_ns_List List
S33, obtaining detailed function information from the Calltere_LOG_func_List List
S34, generating a new log line writing file by combining the information: each level of function call depth displays a Tab indentation, plus the function execution time and the formatted output of the function detail information
Step S35, jumping to step S31.
The algorithms and displays presented herein are not inherently related to any particular computer, virtual system, or other apparatus. Various general-purpose systems may also be used with the teachings herein. The required structure for a construction of such a system is apparent from the description above. In addition, the present invention is not directed to any particular programming language. It will be appreciated that the teachings of the present invention described herein may be implemented in a variety of programming languages, and the above description of specific languages is provided for disclosure of enablement and best mode of the present invention.
In the description provided herein, numerous specific details are set forth. However, it is understood 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 construed as reflecting the intention that: i.e., the claimed invention 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 apparatus of the embodiments may be adaptively changed and disposed in one or more apparatuses different from the embodiments. 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. Any combination of all features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or units of any method or apparatus so disclosed, may be used in combination, except insofar as at least some of such features and/or processes or units 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 but not others included in other embodiments, 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 can 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 use of the words first, second, third, etc. do not denote any order. These words may be interpreted as names.
The foregoing is merely illustrative of the present invention, and the present invention is not limited thereto, and any changes or substitutions easily contemplated by those skilled in the art within the technical scope of the present invention should be included in the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims (4)

1. A method for analysis of a Tarmac log in a chip RTL verification stage, the method comprising the steps of:
reading log information from the Tarmac log file, processing and converting, and writing the result into a conversion log list; the step of reading the log information from the Tarmac log file, processing and converting, and writing the result into a conversion log list comprises the following steps: traversing an original Tarmac LOG file, filtering and converting to generate a converted_LOG_List List, reading a LOG from the Tarmac LOG file, ending processing if the end of the file is reached, updating the current values of R0-R12 if the LOG is an Rx_REG LOG, generating a BL instruction LOG and an LR_REG LOG if the LOG is an IRQ event LOG, writing the BL instruction LOG into the converted_LOG_List List, generating the BL instruction LOG if the LOG is a BLX_REG instruction LOG, writing the LOG into the converted_LOG_List List, and writing the LOG into the converted_LOG_List List if the LOG is other non-useless LOGs, and discarding if the LOG is useless;
analyzing each entry in the conversion log list to generate a call tree data structure; each entry in the parse conversion log list generates a call tree data structure comprising: traversing the filtered and Converted List of the Converted LOG List, processing and generating three function call tree lists, reading a LOG from the Converted List of the LOG List, if the end of the file is reached, ending the processing, if the end of the file is reached, writing the BL instruction LOG into the Callltree LOG List, writing the time period of the BL instruction LOG into the Callltree LOG ns List, writing the current function call depth into the Callltree LOG depth List, if the end of the file is reached, writing the acquired LR return register value into the Currstack List, and writing the corresponding index of the current BL instruction LOG into the Currstack NSindex List in the Callltree LOG ns List; if the current instruction address is not equal to the stack top return value, indicating that the current instruction address is returned from a lower function call, reading the current index List latest element to obtain a 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 saved in the CallTree_LOG_ns_List, and writing back the CallTree_LOG_ns_List; deleting the latest element of the Curstar_List List, deleting the latest element of the Curstar_nsindex_List List, and jumping to a step of reading a LOG from the converted_LOG_List List after each step is executed;
analyzing the call tree data structure and writing the call tree into the file; the parsing the call tree data structure and writing the call tree to the file includes: traversing three function call tree lists, processing and generating call tree files, and acquiring function call depth from the calltree_log_depth_list List; acquiring function execution time from a Calltere_LOG_ns_List List; acquiring function detailed information from a Calltere_LOG_func_List List; generating a new log line writing file by combining the information: each level of function call depth displays a Tab indentation, plus the function execution time and the formatted output of the function detail information.
2. The method of claim 1, wherein generating a BL instruction LOG and an lr_reg LOG and writing a converted_log_list List if the IRQ event LOG is generated, comprises:
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 the LR register value contained in the IRQ event LOG, and writing the LOG into a converted_LOG_List List.
3. The method of claim 2, wherein generating the BL command LOG and writing the LOG to the Converted LOG List if the blx_reg command LOG is the chip RTL verification stage tar mac LOG, comprises: the skip register ID is obtained from the LOG, a BL instruction LOG is generated according to the current value of the skip register ID, and the LOG is written into a converted_LOG_List List.
4. The method for analyzing the journal of the RTL verification stage of the chip according to claim 2, wherein the steps of reading journal information from the journal file of the journal and performing process conversion, and writing the result into the conversion journal list include the steps of: after each step is completed, the step is skipped to a step of reading a log from the Tarmac log file.
CN202111671408.8A 2021-12-31 2021-12-31 Tarmac log analysis method in chip RTL verification stage Active CN114580325B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111671408.8A CN114580325B (en) 2021-12-31 2021-12-31 Tarmac log analysis method in chip RTL verification stage

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111671408.8A CN114580325B (en) 2021-12-31 2021-12-31 Tarmac log analysis method in chip RTL verification stage

Publications (2)

Publication Number Publication Date
CN114580325A CN114580325A (en) 2022-06-03
CN114580325B true CN114580325B (en) 2023-07-25

Family

ID=81771387

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111671408.8A Active CN114580325B (en) 2021-12-31 2021-12-31 Tarmac log analysis method in chip RTL verification stage

Country Status (1)

Country Link
CN (1) CN114580325B (en)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105787093A (en) * 2016-03-17 2016-07-20 清华大学 Log file system construction method based on LSM-Tree structure
US10176078B1 (en) * 2015-08-28 2019-01-08 Cadence Design Systems, Inc. Debugging process
CN109522209A (en) * 2018-09-29 2019-03-26 中国平安人寿保险股份有限公司 Log stack information analysis method and device, computer installation and storage medium

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106294156B (en) * 2016-08-11 2018-12-07 北京邮电大学 A kind of static code fault detection analysis method and device
CN106790718A (en) * 2017-03-16 2017-05-31 北京搜狐新媒体信息技术有限公司 Service call link analysis method and system
CN107367686B (en) * 2017-06-19 2019-11-22 西北工业大学 A kind of generation method of RTL hardware Trojan horse test vector
CN110147313B (en) * 2019-04-10 2023-11-10 口碑(上海)信息技术有限公司 Log output method and device
FR3102259B1 (en) * 2019-10-17 2023-01-20 Amadeus Sas MONITORING A DISTRIBUTED APPLICATION SERVER ENVIRONMENT

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10176078B1 (en) * 2015-08-28 2019-01-08 Cadence Design Systems, Inc. Debugging process
CN105787093A (en) * 2016-03-17 2016-07-20 清华大学 Log file system construction method based on LSM-Tree structure
CN109522209A (en) * 2018-09-29 2019-03-26 中国平安人寿保险股份有限公司 Log stack information analysis method and device, computer installation and storage medium

Also Published As

Publication number Publication date
CN114580325A (en) 2022-06-03

Similar Documents

Publication Publication Date Title
WO2020233330A1 (en) Batch testing method, apparatus, and computer-readable storage medium
US8127261B2 (en) System for quickly specifying formal verification environments
US5752002A (en) Method and apparatus for performance optimization of integrated circuit designs
US20080127113A1 (en) Method and system for implementing watchpoints
US7779393B1 (en) System and method for efficient verification of memory consistency model compliance
US7409602B2 (en) Methodology for debugging RTL simulations of processor based system on chip
CN101183332A (en) Method and device for automatically generating testing datasets by program content
US20120246606A1 (en) Generation of an end point report for a timing simulation of an integrated circuit
WO2022116642A1 (en) Memory parameter extraction method, apparatus and device, and readable storage medium
CN105975664B (en) A kind of appraisal procedure of chip power-consumption Evaluation Platform
WO2024045436A1 (en) Graphical high-level synthesis circuit performance analysis method, system, apparatus, and medium
Malburg et al. Property mining using dynamic dependency graphs
CN114580325B (en) Tarmac log analysis method in chip RTL verification stage
US20140143604A1 (en) Mixed numeric and string constraint analysis
CN105760638A (en) SOC-chip simulation accelerating method
CN112861138A (en) Software security analysis method and analysis device, electronic device, and storage medium
Ciambrone et al. HEPSIM: An ESL HW/SW co-simulator/analysis tool for heterogeneous parallel embedded systems
CN112506806B (en) Method for debugging program, electronic device and storage medium
JP2663893B2 (en) Architecture simulator
US20120221512A1 (en) Dynamic database dump
CN112416727A (en) Batch processing operation checking method, device, equipment and medium
US7689400B2 (en) Reconstruction of data from simulation models
CN112000405A (en) Method, equipment and storage medium for conveniently acquiring system logs
CN113065302B (en) Method for simulating logic system design, simulator and readable storage medium
CN115629928B (en) Software and hardware cooperative verification method and system for brain-like processor

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant