CN112364580A

CN112364580A - Method and device for automatically inserting specific code into register transmission level design file

Info

Publication number: CN112364580A
Application number: CN202011266604.2A
Authority: CN
Inventors: 王涛; 李鹏涛; 剧诺璇
Original assignee: Shanghai Zhaoxin Integrated Circuit Co Ltd
Current assignee: Shanghai Zhaoxin Integrated Circuit Co Ltd
Priority date: 2020-11-13
Filing date: 2020-11-13
Publication date: 2021-02-12

Abstract

The invention provides a method for automatically inserting specific codes into a Register Transfer Level (RTL) design file, which comprises the following steps: reading an RTL file and obtaining storage information according to the RTL file; reading insertion information, wherein the insertion information comprises a code to be inserted and an absolute path of a module corresponding to the code to be inserted in the RTL file; obtaining a module instantiation name from the absolute path, and storing the module instantiation name into a queue; executing an insertion program to obtain a final module definition statement; and inserting the code to be inserted into the final module definition statement.

Description

Method and device for automatically inserting specific code into register transmission level design file

Technical Field

The present invention relates to the field of chip design and chip verification, and more particularly, to a method and apparatus for automatically inserting a specific Code (Code) into a Register Transfer Level (RTL) design file.

Background

Currently, large scale integrated circuits are mostly in the form of systems on a chip. Before each submodule is assembled into a system on chip, each submodule often has a need to insert specific code into a specific location.

At present, when a specific code is to be inserted into a specific module in a Register Transfer Level (RTL) design, a position of the module in the Register Transfer Level design file code needs to be located first by a manual method, and then the specific code is inserted into the module. However, this process must be manually performed by the chip designer, and the huge number of annotations in the RTL document also causes the trouble of the search process, resulting in the disadvantage of low efficiency. In addition, in a general situation, a larger chip (e.g., SoC) has a larger number of codes corresponding to the RTL file, so that the manual search for the inserted codes wastes more time for the chip designer.

Therefore, there is a need for a method and apparatus for automatically inserting specific code into a register transfer level design file to improve the above problems.

Disclosure of Invention

The following disclosure is illustrative only and is not intended to be limiting in any way. In addition to the illustrative aspects, embodiments, and features, other aspects, embodiments, and features will be apparent by reference to the drawings and the following detailed description. That is, the following disclosure is provided to introduce concepts, points, benefits and novel and non-obvious technical advantages described herein. Selected, but not all, embodiments are described in further detail below. Thus, the following disclosure is not intended to identify essential features of the claimed subject matter, nor is it intended to be used in determining the scope of the claimed subject matter.

It is therefore a primary objective of the claimed invention to provide a method and apparatus for automatically inserting specific code into a register file to improve the above-mentioned disadvantages.

The invention provides a method for automatically inserting specific codes into a Register Transfer Level (RTL) design file, which comprises the following steps: reading an RTL file and obtaining storage information according to the RTL file; reading insertion information, wherein the insertion information comprises a code to be inserted and an absolute path of a module corresponding to the code to be inserted in the RTL file; obtaining a module instantiation name from the absolute path, and storing the module instantiation name into a queue; executing an insertion program, wherein the insertion program comprises the following steps: step (a): sequentially taking out the instantiation names of the modules from the queue; step (b): searching a module instantiation statement corresponding to the module instantiation name in the RTL file to obtain a module definition name corresponding to the module instantiation statement; step (c): jumping to the starting position of a module definition statement corresponding to the module definition name according to the stored information; repeating the steps (a) to (c) until the queue has no instantiation name of the module, and obtaining a final module definition statement; and inserting the code to be inserted into the final module definition statement.

In some embodiments, the method further includes inserting the code to be inserted between a final start position of the final module definition statement and a final end position of the final module definition statement.

In some embodiments, the stored information includes: defining the line number of the statement of each module in the RTL file; the number of lines of each module instantiation statement in the RTL file; and the corresponding relation between each module instantiation name and each module definition name.

In some embodiments, after reading in the insertion information, the method further includes: filtering the comment sentences in the RTL file; and storing the annotation statement into a temporary file.

In some embodiments, after the code to be inserted is inserted into the final module definition statement, the method further includes: and restoring the comment statement in the RTL file.

In some embodiments, the insertion information further includes: a first level (hierarchy) to which the code to be inserted belongs; wherein the method further comprises: reading new insertion information, wherein the new insertion information at least comprises a new code to be inserted and a second level to which the new code to be inserted belongs; when the first level is the same as the second level, combining the code to be inserted and the new code to be inserted into a code group; and inserting the code set in the final module definition statement after the insertion program is executed.

The invention provides a device for automatically inserting specific codes into a Register Transfer Level (RTL), which comprises: a processor; and one or more computer storage media storing computer-readable instructions, wherein the processor uses the computer storage media to execute instructions that: reading an RTL file and obtaining storage information according to the RTL file; reading insertion information, wherein the insertion information comprises a code to be inserted and an absolute path of a module corresponding to the code to be inserted in the RTL file; obtaining a module instantiation name from the absolute path, and storing the module instantiation name into a queue; executing an insertion program, wherein the insertion program comprises the following steps: step (a): sequentially taking out the instantiation names of the modules from the queue; step (b): searching a module instantiation statement corresponding to the module instantiation name in the RTL file to obtain a module definition name corresponding to the module instantiation statement; step (c): jumping to the starting position of a module definition statement corresponding to the module definition name according to the stored information; repeating the steps (a) to (c) until the queue has no instantiation name of the module, and obtaining a final module definition statement; and inserting the code to be inserted into the final module definition statement.

Drawings

FIG. 1 is a block diagram of an example of a computing system capable of incorporating a processor of an embodiment of the present invention.

FIG. 2 is a flowchart illustrating a method for automatically inserting specific code into a register transfer level design file according to an embodiment of the present invention.

Fig. 3 is a flowchart illustrating a method for executing an insertion program by a processor according to an embodiment of the invention.

FIG. 4A is a diagram illustrating the contents of an RTL file for executing an inserted code according to an embodiment of the present invention.

FIG. 4B is a diagram illustrating the contents of the insert information stored in the queue according to an embodiment of the present invention.

FIG. 4C shows an embodiment of the present invention with multiple levels of inserted code.

FIG. 4D is a diagram illustrating a first implementation of using batch input to insert code into the RTL file of FIG. 4A according to an embodiment of the present invention.

FIG. 4E is a diagram illustrating a second implementation of using batch input to insert code into the RTL file of FIG. 4A according to an embodiment of the invention.

Detailed Description

The embodiment of the invention provides a method and a device for automatically inserting a specific code into a Register Transfer Level (RTL). Specific codes are inserted under the condition that the original design function is not changed, the position of the codes to be inserted is searched in a skipping mode, and the running speed of the register transmission level design file is increased. In addition, when the code to be inserted is a connecting line, a function of leading out a signal across a hierarchy (hierarchy) can be realized. The invention can prevent the whole insertion process from being influenced by the annotation statement and the original annotation statement from being influenced.

Reference will now be made in detail to the various embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of embodiments of the invention, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be recognized by one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the embodiments of the invention.

Some portions of the detailed descriptions that follow are presented in terms of procedures, logic blocks, processing, and other symbolic representations of operations on data bits within a computer memory. These descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. In the present invention, a procedure, logic block, process, etc., is conceived to be a self-consistent sequence of steps or instructions leading to a desired result. The steps are those utilizing physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a computer system. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as transactions, bits, values, elements, symbols, characters, samples, pixels, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present invention, discussions utilizing terms such as "selecting," "dispatching," "determining," "storing," "dispatching," "determining," "verifying," or the like, refer to the actions and processes of a computer system (e.g., method flowchart 200 of FIG. 2 and method flowchart 300 of FIG. 3) or similar electronic computing device or processor (e.g., system 100 of FIG. 1). The computer system or similar electronic computing device manipulates and transforms data represented as physical (electronic) quantities within the computer system memories, registers or other such information storage, transmission or display devices.

The described embodiments of the invention may be generally discussed in the context of computer-executable instructions residing on some form of computer-readable storage medium, such as program modules, being executed by one or more computers or other devices. By way of example, and not limitation, computer-readable storage media may include non-transitory computer-readable storage media and communication media; non-transitory computer readable media include all but transitory propagating signals. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or distributed as desired in various embodiments.

Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, Random Access Memory (RAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash Memory or other Memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical Disc storage, magnetic cassettes, magnetic disks, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Computer storage media itself does not include signals.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modular data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modular data signal" refers to a signal that has one or more sets of characteristics or is altered in such a way as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, Radio Frequency (RF), infrared and other wireless media. Combinations of the above are included within the scope of computer-readable media.

FIG. 1 is a block diagram of an example of a computing system 100 capable of incorporating a processor 104 of an embodiment of the invention. Computing system 100 broadly represents any single or multi-processor computing device or system capable of executing computer-readable instructions. Examples of computing system 100 include, but are not limited to, workstations, laptops, client terminals, servers, distributed computing systems, handheld devices, or any other computing system or device. In its most basic configuration, computing system 100 may include at least one processor 104 and system memory 106 of embodiments of the present invention.

Processor 104 embodies embodiments of the present invention and generally represents any type or form of processing unit capable of processing data or interpreting and executing instructions. In some embodiments, the processor 104 may receive instructions from a software application or module. These instructions may cause processor 104 to implement the functionality of one or more of the exemplary embodiments described and/or illustrated herein. In various embodiments, the processor 104 may include multiple processors operating in parallel.

System memory 106 generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and/or other computer-readable instructions. Examples of system memory 106 include, but are not limited to, RAM, ROM, flash memory, or any other suitable memory device. Although not required, in some embodiments computing system 100 may include both volatile memory units (e.g., system memory 106) and non-volatile storage (e.g., primary storage 122).

Computing system 100 may include one or more components or elements in addition to processor 104 and system memory 106. For example, in the embodiment of FIG. 1, computing system 100 includes a memory controller 108, an input/output (I/O) controller 110, and a communication interface 112, each of which may be interconnected via a communication infrastructure 102. Communication infrastructure 102 generally represents any type or form of infrastructure capable of facilitating communication between one or more elements of a computing device. Examples of communication infrastructure 102 include, but are not limited to, a communication bus (such as an Industry Standard Architecture (ISA), Peripheral Component Interconnect (PCI), PCI Express (PCIe), or similar bus), and a network.

Memory controller 108 generally represents any type or form of device capable of processing memory or data or controlling communication between one or more elements of computing system 100. For example, the memory controller 108 may control communications between the processor 104, the system memory 106, and the I/O controller 110 via the communication infrastructure 102.

I/O controller 110 generally represents any type or form of module capable of coordinating and/or controlling the input and output functions of a computing device. For example, the I/O controller 110 may control or facilitate the transfer of data between one or more elements of the computing system 100, such as the processor 104, the system memory 106, the communication interface 112, the display adapter 116, the input interface 120, and the storage interface 124.

Communication interface 112 broadly represents any type or form of communication device or adapter capable of facilitating communication between exemplary computing system 100 and one or more additional devices. For example, the communication interface 112 may facilitate communication between the computing system 100 and a private or public network including additional computing systems. Examples of communication interface 112 include, but are not limited to, a wired network interface (such as a network adapter), a wireless network interface (such as a wireless network adapter), a modem, and any other suitable interface. In one embodiment, communication interface 112 provides a direct connection to a remote server via a direct link to a network such as the Internet. The communication interface 112 may also provide such a connection indirectly through any other suitable connection.

Communication interface 112 may also represent a host adapter configured to facilitate communication between computing system 100 and one or more additional network or storage devices via an external bus or channel. Examples of host adapters include, but are not limited to, Small Computer System Interface (SCSI) host adapters, Universal Serial Bus (USB) host adapters, IEEE (institute of electrical and electronics engineers) 1394 host adapters, Serial Advanced Technology Attachment (SATA) and external SATA (esata) host adapters, Advanced Technology Attachment (ATA) and parallel ATA (pata) host adapters, fibre channel Interface adapters, ethernet adapters, and so forth. The communication interface 112 may also allow the computing system 100 to engage in distributed or remote computing. For example, the communication interface 112 may receive instructions from a remote device or send instructions to a remote device for execution.

As shown in FIG. 1, computing system 100 may also include at least one display device 114 coupled to communication infrastructure 102 via a display adapter 116. Display device 114 generally represents any type or form of device capable of visually displaying information forwarded by display adapter 116. Similarly, display adapter 116 generally represents any type or form of device configured to forward graphics, text, and other data for display on display device 114.

As shown in fig. 1, computing system 100 may also include at least one input device 118 coupled to communication infrastructure 102 via an input interface 120. Input device 118 generally represents any type or form of input device capable of providing computer-generated or manually-generated input to computing system 100. Examples of input device 118 include, but are not limited to, a keyboard, a pointing device, a voice recognition device, or any other input device.

As shown in fig. 1, computing system 100 may also include a primary storage device 122 and an optional backup storage device 123 coupled to communication infrastructure 102 via a storage interface 124.

Storage devices

122 and 123 generally represent any type or form of storage device or medium capable of storing data and/or other computer-readable instructions. For example,

storage devices

122 and 123 may be magnetic disk drives (e.g., so-called hard drives), floppy disk drives, tape drives, optical disk drives, flash drives, and the like. Storage interface 124 generally represents any type or form of interface or device for transferring data between

storage devices

122 and 123 and other elements of computing system 100.

In one example, the database 130 may be stored within the primary storage device 122. Database 130 may represent a portion of a single database or computing device, or it may represent multiple databases or computing devices. For example, database 130 may represent (be stored on) a portion of computing system 100. Alternatively, database 130 may represent (store) one or more physically separate devices that are accessible by a computing device, such as computing system 100.

With continued reference to FIG. 1,

storage devices

122 and 123 may be configured to read from and/or write to removable storage device units configured to store computer software, data, or other computer-readable information. Examples of suitable removable storage units include, but are not limited to, floppy disks, tape cassettes, optical disks, flash memory devices, and the like.

Storage devices

122 and 123 may also include other similar structures or devices for allowing computer software, data, or other computer-readable instructions to be loaded into computing system 100. For example,

storage devices

122 and 123 may be configured to read and write software, data, or other computer-readable information.

Storage devices

122 and 123 may also be part of computing system 100 or may be separate devices accessed through other interface systems.

Many other devices or subsystems may be connected to computing system 100. Rather, all of the components and apparatus identified in FIG. 1 need not be present to practice the described embodiments of the present invention. The above-mentioned devices and subsystems may also be interconnected differently than shown in fig. 1, for example, in a computer system architecture, the processor 104 is connected to the system memory 106, the I/O controller 110, the communication interface 112, the display device 114, the input interface 120, the storage interface 124, etc. via a Chipset (Chipset) and performs information interaction with the corresponding external devices. Computing system 100 may also employ any number of software, firmware, and/or hardware configurations. For example, exemplary embodiments of the invention may be encoded on a computer readable medium as a computer program (also referred to as computer software, software applications, computer readable instructions, or computer control logic).

A computer readable medium containing a computer program may load computing system 100. All or a portion of the computer program stored on the computer-readable medium may then be stored in system memory 106 and/or portions of

storage devices

122 and 123. When executed by the processor 104, loading the computer program in the computing system 100 may cause the processor 104 to implement and/or be a means for implementing the functionality of the exemplary embodiments of the present invention described and/or illustrated. Additionally or alternatively, the exemplary embodiments described and/or illustrated herein may be implemented in firmware and/or hardware.

FIG. 2 depicts an exemplary computer-controlled process for automatically inserting specific code in a register transfer level design file, according to an embodiment of the invention. While the steps in the flow diagrams are shown and described sequentially, those skilled in the art will appreciate that some or all of the steps may be performed in a different order, and some or all of the steps may be performed in parallel. Furthermore, in one or more embodiments of the invention, one or more of the steps described below may be omitted, repeated, and/or performed in a different order. Accordingly, the arrangement of steps in FIG. 2 should not be construed as limiting the disclosed aspects. In addition, it will be apparent to those skilled in the relevant art having reference to the teachings provided herein that other functional flows are within the scope and spirit of the present invention. The method flow 200 may be described with continued reference to the above-described exemplary embodiment, although the method is not limited to this embodiment.

Fig. 2 is a flowchart 200 illustrating a method for automatically inserting specific code into a register file according to an embodiment of the present invention, so that those skilled in the art can understand the technical content of the present invention, and the RTL code illustrated in fig. 4A and the insertion information stored in the queue illustrated in fig. 4B are also combined for explanation when describing the flow of fig. 2/3. The method may be performed in the processor 104 shown in FIG. 1.

In step S205, the processor reads an RTL file into which a chip designer wants to insert a code, and obtains a storage information according to the RTL file, wherein the storage information at least includes: the number of rows of each module definition statement in the RTL file, the number of rows of each module instantiation statement in the RTL file, and the corresponding relationship between each module instantiation name and each module definition name. To describe in more detail, after the processor reads in the RTL file, the number of rows of each module instantiation statement and the number of rows of each module definition statement are analyzed through format matching, and the corresponding relationship between each module instantiation name and each module definition name is analyzed. The processor stores the corresponding relation into the storage information. Referring to the RTL code of FIG. 4A, it can be seen that there is a module instantiation statement in line 120, where the module instantiation name ins _ a is shown with a module definition name mod _ a, and the module definition statement of mod _ a is in line 200 (and ends in line 250); similarly, line 225 also has a module instantiation statement, where the module instantiation name ins _ b is shown with the module definition name mod _ b, and the module definition statement of mod _ b is located on line 300 (and ends on line 340). Therefore, the row number of all the module instantiation statements in the RTL file can be obtained through step 205, and the module instantiation name and the module definition name corresponding thereto are obtained from the row number, and further the corresponding relationship such as the module definition name statement and the row number are obtained, and finally the corresponding relationship is stored.

Next, in step S210, the processor reads an insertion message, where the insertion message includes a code to be inserted and an absolute path of a module corresponding to the code to be inserted in the RTL file. In step S215, the processor obtains a module instantiation name from the absolute path, and stores the module instantiation name in a queue. For example, if a chip designer wants to insert the following code in mod _ b:

mod _ c ins _ c (…); // code to be inserted at mod _ b

According to the relationship between the module top and the module instantiation names ins _ a and ins _ b shown in the RTL file of fig. 4A, the absolute path is "top, ins _ a, ins _ b", which means that the module instantiation name ins _ b of the module mod _ b is contained in the module instantiation name ins _ a (the module is defined as mod _ a), and the module instantiation name ins _ a is contained in the module top, and step S210 reads in the insertion code and the absolute path. In the next step S215, since the absolute path corresponding to the code to be inserted is "top _ in _ a _ in _ B", the top-level path is removed from the absolute path (i.e., "top" is removed, because top is the module definition name rather than the module instantiation name), and the rest of the module instantiation names (i.e., "ins _ a _ in _ B") are retained, and then the module instantiation names are stored in the queue, as shown in fig. 4B.

In step S220, the processor executes an insertion position searching procedure. The detailed flow of the insertion procedure is illustrated in fig. 3. Fig. 3 is a flowchart 300 illustrating a method for a processor to execute an insertion procedure according to an embodiment of the invention. In step S305, the processor sequentially retrieves the module instantiation names from the queue. Next, in step S310, the processor searches the RTL file for a module instantiation statement corresponding to the module instantiation name, and obtains a module definition name corresponding to the module instantiation statement. In step S315, the processor jumps to the start position of the module definition sentence corresponding to the module definition name according to the stored information. In step S320, the processor determines whether the queue has no instantiation name of the module. When the processor determines that there is no module instantiation name in the queue (yes in step S320), the process ends. The processor may obtain a final module definition statement in step S315. When the processor determines that the module instantiation names still exist in the queue (no in step S320), the processor returns to step S305, and sequentially retrieves the module instantiation names from the queue. The processor then repeats the steps S305-S315 until there is no module instantiation name in the queue, and obtains a final module definition statement. Taking fig. 4B as an example, the instantiation name of "ins _ a. ins _ B" is stored in the queue, and in step S305, the instantiation name ins _ a is first retrieved, and in the following step S310, the module instantiation statement of the module instantiation name ins _ a is found in the 120 th row of the RTL file in fig. 4A, and the module definition name of the module ins _ a is mod _ a in the row. Therefore, in the next step S315, the module definition statement of mod _ a is searched, and after finding the module definition statement of mod _ a in line 200 of the RTL file in fig. 4A, the start position (i.e., line 200) of mod _ a is skipped, and finally, in step S320, it is determined whether there is any module instantiation name in the queue. Since the module instantiation names ins _ b are not searched yet, the determination result of "no" is obtained, and the process returns to step S305. Then, in step S305, the module instantiation name ins _ b is fetched, and in the subsequent step S310, the module instantiation statement of ins _ b is found on the 225 th row of the RTL file, wherein there is the module definition name mod _ b of ins _ b, then in step S315, a search is performed, and in the 300 th row, the mod _ b module definition statement is found and jumps to the row, and finally in the subsequent step of step S320, it is found that there is no module instantiation name unprocessed, so that the yes judgment result is obtained and the flow of fig. 3 is ended, and the flow returns to fig. 2.

Returning to fig. 2, after the insertion position search routine of step S220 is executed, in step S225, the processor inserts the code to be inserted into the final module definition statement. More specifically, the processor inserts the code to be inserted between a final start position of the final module definition statement and a final end position of the final module definition statement. For example, as described in the paragraph above, since the code to be inserted is "mod _ c ins _ c (…); the final module definition statement in step S220 is the module definition statement of mod _ b, and according to the RTL code shown in fig. 4A, the final starting position is line 300 (the number of lines of the keyword module), the final ending position is line 340 (the number of lines of the keyword endmodule), and the insertion code is inserted into line 310. It should be noted that fig. 4B shows the number of lines for inserting the code between the keyword module and the endmodule, but those skilled in the art should understand that the code can be inserted at the position of the module definition sentence according to the actual situation, for example, at the rearmost (i.e., at the row before the keyword "endmodule") and the frontmost (e.g., at the row next to the keyword "module").

It should be noted that the operation of inserting code according to the present invention does not substantially affect the chip behavior defined by the original RTL file, but may cause problems after inserting code, which requires the chip designer to handle. For example, the code to be inserted is illustrated in fig. 4A as a new module mod _ c that is not present in the RTL file, so that a chip designer can insert the code "mod _ c ins _ c" into mod _ b by the present invention (…); if the code to be inserted into mod _ b is needed, the module definition statement of the module mod _ c is added to the RTL file after the code is inserted (for example, the contents shown in

lines

400 and 420 in fig. 4A) by itself. Furthermore, since the module mod _ c illustrated in fig. 4A further includes the module instantiation statement of the half adder (half adder) HA1 (the module definition statement of the half adder is in line 500 and 505), the chip designer still HAs to deal with the unknown signal (unknown signal) by himself because the half adder will generate a signal "carry _ out" that is not present in the original RTL file. Since the operation of these parts is well known to those skilled in the art, it is not described in detail.

In an embodiment, after the step S205 is executed, the processor may further filter the comment statement in the RTL file, and store the comment statement in a temporary file. After step S220 is executed, the processor recovers the comment statement in the RTL file. For example, the ins _ a declared as mod _ a in the comment statement "// top of line 120 in FIG. 4A can be temporarily removed from the RTL file and stored in a temporary file, and then restored to line 120 of the RTL file after completing the code insertion operation in step S220, so that the search operation of the present invention can be performed correctly and smoothly without being influenced by the comment.

In another embodiment, the insertion information further includes a first level (hierarchy) to which the code to be inserted belongs. The processor can read another new insertion information after reading the insertion information, or simultaneously read a plurality of insertion information, wherein the new insertion information at least comprises a new code to be inserted, an absolute path of a module corresponding to the new code to be inserted in the RTL file, and a second level to which the new code to be inserted belongs. The processor may compare whether a second level to which the new code to be inserted included in the new insertion information belongs is the same as a first level to which the code to be inserted belongs. When the first level is the same as the second level, the processor combines the code to be inserted and the new code to be inserted into a code group, and inserts the code group into the final module definition sentence after executing the insertion program. Taking the example of the insertion code with multiple levels illustrated in fig. 4C as an example, if the chip designer wishes to insert the following four insertion codes (where the fourth is an annotation statement) in the module mod _ b:

module instantiation name insertion code

ins _ a.ins _ b mod _ c ins _ c (…); // first set of codes to be inserted at mod _ b

ins _ a.ins _ b mod _ d ins _ d (…); // second set of codes to be inserted at mod _ b

tire1.tire2mod _ e ins _ e (…); // first set of codes to be inserted at tier 2

ins _ a, ins _ b// mod _ b, which is widely used in SoC without any modification

Since the absolute paths of the inserted codes in

lines

1, 2 and 4 are all "ins _ a.ins _ b", the three groups of inserted codes can be merged (for example, merged into one code group and simultaneously perform the inserting operation), and the inserting operation is simultaneously performed in the module definition statement mod _ b. It should be noted that the absolute path of the inserted code on line 3 of fig. 4C is "tire 1.tire 2" instead of "ins _ a. ins _ b", and therefore cannot be merged with the insertion operation of the above three codes. In addition, it is known from the content of the inserted code in line 4 of fig. 4C that it is an annotation, so the present invention can also be used to insert an annotation or any statement, rather than just code such as a module instantiation statement.

FIG. 4D illustrates a first embodiment of inserting code into an RTL file in a Batch processing (Batch processing) manner, which contains all the code that the chip designer wants to insert and the corresponding absolute path, where the contents of lines 1-4 are the same as FIG. 4C. Similarly, the present invention can find that the absolute paths of the insertion codes of the 1 st, 2 nd and 4 th lines are the same after checking the absolute paths of all the insertion codes, so that the insertion operations of the 1 st, 2 nd and 4 th lines can be combined. On the other hand, the absolute paths of the insertion codes of

lines

3 and 5 in fig. 4D are not only different from the absolute paths of the insertion codes of

lines

1, 2 and 4, but also different from each other in

lines

3 and 5, and thus the code insertion operations can be handled separately.

FIG. 4E depicts a second embodiment of inserting code into an indicated RTL file in a batch manner by the present invention. The difference between FIG. 4E and FIG. 4D is that the module definition name, rather than the absolute path of the inserted code, is input in FIG. 4E. Since the line number of each module definition statement is stored in the step S205 when the RTL file is analyzed, the chip designer can directly input the module definition name of the code to be inserted, and the present invention can directly skip to the beginning of the corresponding module definition statement and execute the insertion operation according to the line number of the module definition statement obtained in the step S205. For example, after step S205 is executed, it is known that the module definition statement of the module definition name mod _ b is located at line 300, so that after the module definition name mod _ b is obtained from line 1 of fig. 4E, the user can directly jump to line 300 of the RTL file of fig. 4A to execute the code insertion operation. Similarly, since the module definition names corresponding to the insertion codes in

lines

1, 2, and 4 of fig. 4E are all mod _ b, the code insertion operations may also be combined, for example, after jumping to the module definition statement of mod _ b, the code insertion operations in

lines

1, 2, and 4 are executed at the same time.

It is noted that the present invention can use Perl, PHP, ASP, JSP, Python, etc. to write the required script (script) or program. In one embodiment, when a chip designer needs to insert code into a specific RTL file, the script can be directly executed when the RTL file to be inserted and the insertion information are ready to perform the operation of inserting the code. In another embodiment, the program written by the spirit of the present invention may start to open or pop a window after the chip designer inputs the RTL file to be inserted with the insertion information, and then after the chip designer confirms, the program/script of the present invention will insert the code into the RTL file through the process of fig. 2-3 and output it, and the chip designer may finally confirm the correctness of the RTL file after inserting the code or confirm/adjust the unknown signal derived after inserting the code (for example, the aforementioned problem derived from carry _ out after inserting the instantiation name ins _ c of the half adder). In addition, in another embodiment of the present invention, the chip designer can also use the RTL file to be code-inserted and the input batch file of fig. 4D as input parameters (for example, write the present invention as an application program, and use the RTL file and the two files containing the input code as parameters for calling the application program) when the chip designer starts up, so that the functions of the present invention can automatically execute the code insertion operation after the chip designer starts up, and then output the RTL file with the completed code insertion to the chip designer.

As described above, since the processor of the present invention has obtained the stored information in advance, the chip designer does not need to search the RTL file line by line, which can significantly reduce the invalid time of RTL search line by line and also greatly reduce the time required for searching the location of the module. In addition, the invention can insert the specific code without changing the original design function, thereby saving time and labor and being not easy to make mistakes. The chip designer can automatically realize the insertion by only providing the position or the related information of the code to be inserted and the specific content of the code to be inserted, so that the running efficiency of the processor is improved, the time consumption is low, the running speed is not influenced along with the increase of the number of the code to be inserted, and the influence caused by annotation does not need to be considered.

Any particular ordering or layering of steps in the processes disclosed herein is purely by way of example. Based upon design preferences, it should be understood that any specific order or hierarchy of steps in the processes may be rearranged within the scope of the disclosures made in this document. The accompanying method claims present elements of the various steps in a sample order, and are therefore not to be limited to the specific order or hierarchy presented.

The use of the ordinal terms "first," "second," "third," etc., in the claims to modify an element does not by itself connote any priority, precedence, or order of steps performed by the method, but are used merely as labels to distinguish one element from another having a same name (but for use of a different ordinal term).

Although the present invention has been described with reference to the above embodiments, it should be understood that various changes and modifications can be made therein by those skilled in the art without departing from the spirit and scope of the invention as defined in the appended claims.

[ description of symbols ]

100 computing system

102 communication infrastructure

104 processor

106 system memory

108 memory controller

110I/O controller

112 communication interface

114 display device

116 display adapter

118 input device

120 input interface

122 storage device

123 spare storage device

124 storage interface

130 database

200 method flow chart

S205, S210, S215, S220, S225 step

300 flow chart of the method

S305, S310, S315, S320 step

Claims

1. A method of automatically inserting a specific code in a Register Transfer Level (RTL) design file, comprising:

reading an RTL file and obtaining storage information according to the RTL file;

reading first insertion information, wherein the first insertion information comprises a first insertion code and first module insertion information of the first insertion code in the RTL file;

searching a first module definition statement corresponding to the first module insertion information in the RTL file according to the first module insertion information; and

inserting the first insertion code into the first module definition sentence.

2. The method as claimed in claim 1, wherein said first module insertion information is a first module definition name corresponding to said first module insertion code or an absolute path of said first module definition name corresponding to said first module insertion code in said RTL file.

3. The method for automatically inserting special code into a register transfer level design file as claimed in claim 1, further comprising:

reading second insertion information, wherein the second insertion information comprises a second insertion code and second module insertion information of the second insertion code in the RTL file; and

and when the first module insertion information is the same as the second module insertion information, inserting the first insertion code and the second insertion code into the first module definition sentence at the same time.

4. The method as claimed in claim 1, further comprising opening or popping up a window to input said RTL file and said first insertion information, or directly executing a script (script) including said method for automatically inserting a specific code in the register transfer level design file to insert a code.

5. The method according to claim 1, further comprising a program for initiating said method for automatically inserting specific code into said register transfer level design file, wherein said RTL file and said first insertion information are parameters of said program for initiating said method for automatically inserting specific code into said register transfer level design file.

6. The method as claimed in claim 1, wherein the RTL file is started after being opened according to the instruction of a chip designer.