Data management system and management method

Abstract

The invention provides a data management system and method, and the system comprises a path analysis module which is electrically connected with a storage module, reads a discrete code file from the storage module, and obtains and outputs a file path of the discrete code file; the archiving module receives the discrete code files and outputs archived files to the storage module, the archived files comprise a plurality of discrete code files, in the archived files, the discrete code files comprise header identifiers, design code data and tail identifiers, the header identifiers comprise starting characters and file paths of the discrete code files, and the tail identifiers comprise starting characters and file paths of the discrete code files. The tail identifier comprises an end character and a file path of the discrete code file; wherein when the archiving module receives an archiving starting signal, the archiving module starts the path analysis module and outputs an archiving file. According to the chip design code data management method and device, efficient and automatic chip design code data management can be achieved, and the modification and maintenance efficiency of the chip design code data is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a data management system and a management method. Background Art

[0002] The design of digital circuits is a nested tree-like structure. In digital circuit design, the designed digital circuits are split into many small modules, which not only facilitates the distribution of digital circuit designs to multiple designers, but also enables designers to complete functional designs more clearly. From the perspective of the entire chip design cycle, as chip design code data is updated and bug fixes involve many versions, the discrete file format is not conducive to the modification and maintenance of chip design code data. Summary of the invention

[0003] The object of the present invention is to provide a data management system and management method, which can realize efficient and automatic chip design code data management and improve the efficiency of chip design code data modification and maintenance.

[0004] In order to solve the above technical problems, the present invention is achieved through the following technical solutions:

[0005] The present invention provides a data management system, wherein the data management system is electrically connected to a storage module, and the data management system comprises:

[0006] a path parsing module, electrically connected to the storage module, the path parsing module obtaining an original file path of the discrete code file, wherein the original file path may include variables and the like, the path parsing module parsing the variables and the like to output an actual file path of the discrete code file, and reading the discrete code file from the storage module; and

[0007] an archiving module, the archiving module receiving the discrete code files and outputting an archive file to the storage module, wherein the archive file includes a plurality of the discrete code files, and in the archive file, the discrete code files include a header identifier, design code data, and a tail identifier, and the header identifier includes a start character and an original file path of the discrete code file, and the tail identifier includes an end character and the original file path of the discrete code file;

[0008] When the archiving module receives the archiving start signal, the archiving module starts the path parsing module and outputs the archive file.

[0009] In an embodiment of the present invention, the head identifier is located at the head of the design code data, and the tail identifier is located at the tail of the design code data.

[0010] In one embodiment of the present invention, the original file path of the discrete code file includes variables, and the path parsing module assigns values ​​to the variables in the original file path according to the storage location of the discrete code file, and outputs the file path of the discrete code file after the assignment.

[0011] The purpose of introducing variables into the original file path is to avoid modifying the path list file due to code updates or copies that cause the actual file path to be different.

[0012] In one embodiment of the present invention, the data management system includes a data updating module, and the data updating module includes:

[0013] an update file generating unit, which, when updating the separate code file, splits the archive file into a plurality of the separate code files and updates the separate code files;

[0014] a virtual file generating unit, which outputs a virtual replacement file when generating or updating the discrete code file, wherein the virtual replacement file has the same format and connection relationship as the discrete code file, and wherein the design code data of the virtual replacement file is empty; and

[0015] A mode setting unit, wherein the data update mode of the data update module includes an overwrite mode and a non-overwrite mode. In the overwrite mode, the mode setting unit outputs a first start signal. In the non-overwrite mode, the mode setting unit outputs a second start signal.

[0016] In an embodiment of the present invention, the data update module includes a synchronous update unit. Under the first start signal, the synchronous update unit reads and updates the source file of the discrete code file according to the file path of the discrete code file.

[0017] In one embodiment of the present invention, in the non-overwrite mode, the update file generation unit receives the second start signal, the update file generation unit reads the discrete code file, and generates a new discrete code file and a file list of the discrete code file outside the archive file, and can update the corresponding version information to the version comment field of the new discrete code file as needed.

[0018] In one embodiment of the present invention, the data management system includes a list parsing module, which stores multiple preset list formats. Before the archiving module reads out the discrete code file, the list parsing module reads the file list of the discrete code file and adjusts the file list of the discrete code file to one of the preset list formats.

[0019] In one embodiment of the present invention, the data management system includes a formatting module, which stores a preset code format. After the archiving module reads out the discrete code file and before the archive file is formed, when the formatting module receives a formatting start signal, the formatting module adjusts the design code data to the preset code format.

[0020] In one embodiment of the present invention, the data management system includes a checking module, in which checking rules are stored. After the archiving module reads out the discrete code file and before the archive file is formed, when the checking module receives a code checking signal, the checking module compares the discrete code file with the checking rules. When the discrete code file and the checking rules are consistent, the checking module sends an archiving continuation signal to the archiving module, continues to generate the archive file, and generates an inspection report at the same time.

[0021] The present invention provides a data management method, based on any one of the data management systems described above, the data management method comprises the following steps:

[0022] When the archiving module receives the archiving start signal, the actual file path of the separate code file is acquired and output, and the separate code file is read out from the storage module;

[0023] Adding a header mark and a tail mark to the separate code file, wherein the header mark includes a start character and a file path of the separate code file, and the tail mark includes an end character and an original file path of the separate code file;

[0024] Merging the plurality of separate code files to form an archive file; and

[0025] Output the archive file to the storage module.

[0026] As described above, the present invention provides a data management system and management method, which can choose whether to format and check the code as needed, and choose whether to overwrite the source code as needed, and can flexibly manage and maintain according to actual conditions. The present invention can quickly merge separate chip design code files into a total file, and add identifiers during the merging process, so that the code can be quickly managed and maintained, and blocking verification compilation problems or certain test points can be quickly avoided. In the present invention, the signal tracing only needs to be performed in one file, so that the structure and changes of the code can be intuitively understood. The method provided by the present invention can manage and maintain the code through a simple tool, without the need to learn complex commands and operations, and the present invention can realize the automated management of chip design, and the management and maintenance efficiency is high.

[0027] Of course, any product implementing the present invention does not necessarily need to achieve all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for describing the embodiments are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0029] Figure 1 Schematic diagram of the structure of a data management system in one embodiment of the present invention.

[0030] Figure 2 Schematic diagram of the structure of a list parsing module in one embodiment of the present invention.

[0031] Figure 3 Schematic diagram of the structure of a data updating module in one embodiment of the present invention.

[0032] Figure 4 FIG. 4 is a flow chart of a data management method in one embodiment of the present invention.

[0033] Figure 5 The figure is a structural principle block diagram of an electronic device.

[0034] Figure 6 The present invention is a block diagram of the structural principle of a computer-readable storage medium.

[0035] In the figure: 100, data management system; 200, archiving module; 300, path parsing module; 400, list parsing module; 410, format parsing unit; 420, list editing unit; 500, data update module; 510, mode setting unit; 520, update file generation unit; 530, synchronous update unit; 540, update identification unit; 550, virtual file generation unit; 600, formatting module; 700, checking module; 800, processor; 900, memory. DETAILED DESCRIPTION

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

[0037] Register Transfer Level (RTL) code is used to describe the digital logic design of integrated circuits. Specifically, RTL code is used to describe signal conversion and combinational logic between registers. During the chip design cycle, RTL code includes multiple separate files, and multiple separate files are set in different directories. Among them, code updates and defect repairs involve many versions. Through a distributed version control system, such as Git, the design code data of chip development is managed and maintained. Among them, Git is a general version control system, which has poor optimization and adaptation capabilities for RTL code requirements, and the method of merging codes is complicated. When multiple developers modify the same file at the same time, code conflicts and errors may also occur, thereby generating additional development time. In addition, Git runs slowly when managing large code bases, and the storage space requirements are also high. Git is too complex and has poor automation capabilities. The present invention proposes a data management system that can manage and merge separate files of RTL code to ensure that the RTL code is correct and consistent when modifying and maintaining chip design code data.

[0038] See also Figure 1 As shown, the present invention provides a data management system 100. The data management system 100 includes an archiving module 200, a list parsing module 400, a data updating module 500, a formatting module 600 and a checking module 600. The archiving module 200 is used to obtain separate code files and merge the separate code files into an archive file. The list parsing module 400 is used to obtain the format requirements of the manufacturer and tool for the file list, and generate a file list that meets the format requirements. The data updating module 500 is used to update the design code data in the archive file and generate a virtual replacement file. The formatting module 600 is used to format the code file according to the preset formatting rules, and insert file version comment information into the code file during formatting. The checking module 600 is used to check the code file in the process of forming the archive file to ensure the correctness and consistency of the design code data, and can integrate the commonly used demand scenario functions involved in the chip, such as formatting, checking and virtual file generation.

[0039] See also Figure 1 and Figure 2As shown, in one embodiment of the present invention, the discrete code file is a design code data file generated during the digital circuit design process of the chip. The discrete code file is stored in a storage module, which can be a flash memory or a cloud storage. The archiving module 200 is electrically connected to the storage module to read the discrete code file from the storage module when there is a need for archiving. Among them, the storage module is electrically connected to the code design platform, and when editing the design code, a discrete code file is generated, and the discrete code file is stored in the storage module. In this embodiment, the storage module can have multiple storage interfaces. The storage module is interconnected with the data management system 100. In this embodiment, the archiving module 200 copies and pastes the discrete code file to a new address to form an archive file. Among them, the archiving module 200 can be automatically triggered, for example, after the discrete code file is generated, the processor generates an archive start signal, and the archiving module 200 automatically reads the discrete code file. After the discrete code file is input, the system recognizes the discrete code file and automatically pastes the discrete code file to the same address to form an archive file. A new discrete code file can be input later, or it can be input into the previously generated archive file. In this embodiment, the address of the archive file is fixed and unchanged. In other embodiments of the present invention, the archive module 200 can also be triggered by the designer. For example, when the discrete code file needs to be delivered between different departments, the archive module 200 sends an archive start signal, the archive module 200 reads the discrete code file, and generates an archive file through the archive module 200. In this embodiment, in the case of an existing archive file, for a new discrete code file, the new discrete code file is copied and pasted into the archive file through the archive module 200. For the editing of an existing discrete code file, the discrete code file can be updated in the archive file through the data update module 500.

[0040] See also Figure 1 and Figure 2As shown, in one embodiment of the present invention, the archiving module 200 obtains the discrete code file and the original file path of the discrete code file. In this embodiment, the archiving module 200 adds an identifier to the header of the discrete code file to form a header identifier, and adds an identifier to the tail of the discrete code file to form a tail identifier. The header identifier includes a start character and an original file path. The tail identifier includes an end character and an original file path. The header identifier and the tail identifier of the discrete code file can be used to identify the position and length of the current discrete code file and distinguish between multiple discrete code files. The start character and the end character can be designed by the designer. In this embodiment, the original file path refers to the path of the discrete code file in the file list. In this embodiment, in the file path, the text path is represented by the file name. For example, a file name is top.v, and its path is C:\Users\admin\Desktop\top.v. For another example, the file path can be expressed as C:\Users\admin\Desktop\subsystem.v, which represents the sub system. folder. The subsystem.v file is from the Desktop folder, which is located in the admin folder, which is located in the Users folder, which is located in the C drive of the computer. In this embodiment, the archive module 200 copies and pastes multiple discrete code files to the same address to form an archive file. In this embodiment, the text display order of the discrete code files in the archive file is consistent with the order of the discrete code files in the file list filelist to comply with the compilation order of the digital circuit.

[0041] See also Figure 1 and Figure 2As shown, in one embodiment of the present invention, when parsing and generating a file list, the path parsing module 300 performs variable replacement on the list information to obtain the actual file path of the discrete code file. For example, the discrete code file aa.v, the discrete code file bb.v, and the discrete code file cc.v are stored in the folder src. Then the file path of the discrete code file aa.v includes . / Project / aa.v, the file path of the discrete code file bb.v includes . / Project / bb.v, and the file path of the discrete code file cc.v includes . / Project / cc.v. When the src folder is copied to / share / proj / work / test / v0, the actual file path of the discrete code file aa.v is / share / proj / work / test / v0 / src / aa.v. Similarly, the actual file path of the discrete code file bb.v is / share / proj / work / test / v0 / src / bb.v. The actual file path of the discrete code file cc.v is / share / proj / work / test / v0 / src / cc.v. When the src folder is copied to / share / proj / work / release / v1, the actual file path of the discrete code file aa.v is / share / proj / work / release / v1 / src / aa.v. Similarly, the actual file path of the discrete code file bb.v is, for example, / share / proj / work / release / v1 / src / bb.v. The actual file path of the discrete code file cc.v is, for example, / share / proj / work / release / v1 / src / cc.v. When parsing the file path of the discrete code file, the variables in the file path are specified according to the actual path to form the actual file path of the discrete code file. For example, the location of the above src is set to $RTL_PATH. When changing the storage location of the discrete code file, $RTL_PATH can be changed from / share / proj / work / test / v0 to / share / proj / work / release / v1. In this embodiment, the fixed source path is a fixed path parameter, such as Project / a / aa.v, / a / aa.v, / aa.v, etc. The path parameter of the variable in the file list can be set by the list parsing module 400 .

[0042] See also Figure 1 and Figure 2As shown, in one embodiment of the present invention, the list parsing module 400 is used to obtain the format requirements of the manufacturer and tool for the file list, and generate a file list that meets the format requirements. In the embodiment, the list parsing module 400 obtains the specific format required by the work as a preset format, and generates a file list that meets the preset format. In this embodiment, the list parsing module 400 is illustrated by taking the code simulation test as an example. Different companies have different requirements for the format of the file list, and the code simulation test will use tools from different companies. For example, there are both list information and design code data in the file list. Company a requires a -F mark to be added before the file path of the list information, and a -V mark to be added before the design code data. For another example, the vivado design suite requires the add_files mark to be added before each file path. Various tool software have different format requirements for file lists. In this embodiment, the list parsing module 400 includes a format parsing unit 410 and a list editing unit 420. Among them, the format parsing unit 410 obtains and stores the preset format information, and the list editing unit 420 adds the preset format information to the file list. In the present invention, the preset format information can be input to the format parsing unit 410 when there is an application requirement, or the preset format information that may be applied to the format parsing unit 410 can be used as a preset format information library before the application data management system 100 is applied, and when there is an application requirement, the corresponding preset format information is read from the preset format information library. In the present invention, when a file list is formed in an archive file, the list parsing module 400 adjusts the format of the file list according to the file requirement.

[0043] See also Figure 1 and Figure 3 As shown, in one embodiment of the present invention, when updating a discrete code file in an archive file, the data update of the discrete code file is completed by a data update module 500. In this embodiment, the data update module 500 includes a mode setting unit 510, an update file generation unit 520, a synchronous update unit 530, an update identification unit 540, and a virtual file generation unit 550. In the present invention, in the archive file, the discrete code file to be updated can be obtained by the file name, the design code data of the discrete code file is updated in the archive file, and a virtual replacement file related to the updated discrete code file is generated.

[0044] See also Figure 1 and Figure 3As shown, in one embodiment of the present invention, the mode setting unit 510 has an overwrite mode and a non-overwrite mode. In this embodiment, the overwrite mode and the non-overwrite mode can be distinguished by means of a mode identification code or pointer data. For example, when the mode identification code is set to a high level, that is, set to 1, the current state is in an overwrite mode. When the mode identification code is set to a low level, that is, set to 0, the current state is in a non-overwrite mode. In the non-overwrite mode, the update file generation unit 520 identifies the character length of the currently updated discrete code file according to the header and tail identifiers of the discrete code file, and copies the characters of the discrete code file one by one. Specifically, the update file generation unit 520 copies the discrete code file, and updates the copy file of the discrete code file to form a new discrete code file. In this embodiment, the new discrete code file is set outside the archive file. The present invention does not limit the address of the generated new discrete code file. After forming the new discrete code file, the archive module 200 can perform an archive merge operation on the new discrete code file again to merge the new discrete code file into the archive file. The update file generation unit 520 updates the version change record in the new separate code file version comment field. For example, separate code file aa.v, separate code file bb.v and separate code file cc.v are merged into archive file all.v. At this time, separate code file bb.v needs to be modified. If it is in non-overwrite mode, separate code file bb.v is copied to the outside of archive file all.v and modified to form a new separate code file bb.v.

[0045] See also Figure 1 and Figure 3 As shown, in one embodiment of the present invention, in overwrite mode, after completing the update of the discrete code file in the archive file, the synchronous update unit 530 reads the file path from the header identifier and the tail identifier of the discrete code file, and finds the source file of the updated discrete code file according to the actual file path, and performs the same update operation on the source file of the discrete code file. For example, the discrete code file aa.v, the discrete code file bb.v and the discrete code file cc.v are merged into the archive file all.v. At this time, the discrete code file bb.v needs to be modified. If it is in overwrite mode, the discrete code file bb.v is edited and modified directly in the archive file all.v, and updated to the discrete code file bb.v under the source path in the same form. In overwrite mode and non-overwrite mode, when it comes to updating multiple discrete code files in the archive file, the discrete code files can be updated in sequence according to the compilation order.

[0046] See also Figure 1 and Figure 3As shown, in one embodiment of the present invention, after the discrete code file is updated, the virtual file generation unit 550 generates a virtual replacement file. The virtual replacement file retains the interface signal declaration of the discrete design code and assigns constants to the output signal. Therefore, using the virtual replacement file to replace the discrete code file does not change the code interface connection relationship, and the code can be compiled correctly. In this embodiment, during the chip verification process, when the chip firmware runs defectively and the cause of the chip error is detected, such as a defect in the design code data, a functional abnormality, or a compilation error, when the erroneous discrete code file has a related virtual replacement file, the discrete code file at the error position is replaced with the virtual replacement file in the chip firmware to quickly solve the overall hang or compilation error caused by a certain module, ensure project delivery, improve chip design verification efficiency, and avoid wasting project development time due to unknown repair time of some defects. In the step of replacing the discrete code file at the error position with the virtual replacement file, specifically, a level signal is output to the input end of the virtual replacement file, thereby calling the virtual replacement file.

[0047] See also Figure 1 and Figure 3 As shown, in one embodiment of the present invention, the update identification unit 540 is used to parse the original path of the discrete code file, so as to determine whether the discrete code file has been modified after the archive file is formed. Among them, the update identification unit 540 reads the header and tail identifiers of the discrete code file, and parses the original file path in the header and tail identifiers. According to the actual file path parsed, the update identification unit 540 obtains the source file of the discrete code file, and compares whether the design code data content of the source file and the discrete code file is consistent. Among them, the design code data content of the discrete code file is a string between the start character and the end character. When the design code data content of the source file and the discrete code file is consistent, the discrete code file has not been modified. It should be noted here that for the update of the discrete code file in the overlay mode, since the discrete code file and the source file are consistent, it can be considered that the discrete code file is unchanged. For the non-overlay mode, a new discrete code file is generated, and the modified discrete code file can actually be found in the archive file. Therefore, according to the design requirements, you can freely choose to update in non-overlay mode or in overlay mode. The number of files updated in overlay mode is smaller. In the non-overwrite mode, since the discrete code source files under the actual file path are not overwritten, the design code data content before the update can be traced.

[0048] See also Figure 1 and Figure 3As shown, in one embodiment of the present invention, in the process of merging the separate code files by the archiving module 200, the separate code files can be formatted by the formatting module 600. In this embodiment, the formatting process of the separate code files can be started by sending a formatting start signal to the formatting module 600. In this embodiment, the formatting rules are stored in the formatting module 600, and the separate code files are formatted according to the preset formatting rules. The formatting rules can be embodied as program statements of the formatting firmware pre-entered into the data management system 100, and calling the formatting firmware can complete the formatting of the separate code files, thereby improving the readability and maintainability of the design code data. In this embodiment, the working steps of the formatting module 600 include obtaining formatting parameters when receiving the formatting start signal, and inserting template comments into the separate code files. The formatting parameters refer to template comment information, such as version information and update personnel of the separate code files. Specifically, the template comment information can be but is not limited to the project name of the current design, the author participating in the editing of the design code data, the editing time of the design code data, the version number of the separate code file, etc. In the present invention, when editing a separate code file, the template annotation information required to be recorded by the formatting module 600 can be automatically recorded, and the template annotation information can be stored in a storage unit, so that when the formatting module 600 is started, the required template annotation information can be directly retrieved from the storage unit, and the template annotation information can be added to the separate code file, and then the template annotation information can be merged into the archive file. In this embodiment, when the separate code file has been merged into the archive file, and the update of the separate code file is involved, each time the separate code file is updated, whether in the overwrite mode or in the non-overwrite mode, in the last step of the update process, the formatting module 600 automatically inserts the template annotation information into the separate code file. The work of the formatting module 600 is performed in the last step of the update process, which can be understood as the formatting module 600 starts to work after the data update process of the data update module 500 is completed. In this embodiment, when the formatting module 600 does not receive the formatting start signal, the separate code file is not formatted.

[0049] See also Figure 1 and Figure 3As shown, in one embodiment of the present invention, the inspection rules are stored in the inspection module 700. The inspection rules are embodied as code inspection firmware in the input data management system 100, and when the processor reads and calls the code inspection firmware, the code inspection method of the present invention is executed. In this embodiment, in the step of merging the discrete code files in the archiving module 200, the inspection module 700 can be started to complete the inspection of the discrete code files, thereby ensuring the consistency and correctness of the discrete code files. In this embodiment, after the archiving module 200 reads the discrete code files, a check start signal can be sent to the inspection module 700, thereby calling the code inspection firmware. In the step of checking the discrete code files, it can be checked whether the read design code data is wrong, and it can also be checked whether the design code data conforms to the preset grammatical rules. For example, it is checked whether the design code data in the discrete code files conforms to the Verilog and Syste mVerilog grammatical rules. Specifically, it is checked whether the design code data in the discrete code files starts with a module statement, ends with an end module statement, and whether the signals of the register class are declared, etc. The inspection module 700 may store a preset inspection result. When the inspection result is consistent with the stored preset inspection result, the discrete code file passes the inspection. The inspection module 700 may output a feedback signal to the archiving module 200, so that the archiving module 200 continues the archiving step and completes the merging of multiple discrete code files. When the inspection result is different from the stored preset inspection result, the discrete code file fails the inspection. In this embodiment, the inspection module 700 does not output a feedback signal to the archiving module 200. In the absence of a feedback signal or a feedback signal within a preset time, the archiving module 200 performs the archiving process normally and sends an error signal to inform the designer. In another embodiment of the present invention, when the inspection result is consistent with the stored preset inspection result, the discrete code file passes the inspection, and the inspection module 700 sends a first feedback signal to the archiving module 200. When the inspection result is different from the stored preset inspection result, the discrete code file fails the inspection, and the inspection module 700 sends a second feedback signal to the archiving module 200. The first feedback signal and the second feedback signal are different and may be opposite feedback signals. For example, the first feedback signal is a high-level signal, and the second feedback signal is a low-level signal. According to the type of the received signal, the archiving module 200 performs the archiving step when receiving the first feedback signal, and performs the archiving step and reports an error when receiving the second feedback signal. The archiving module 200 can directly display the error type when reporting an error.

[0050] See also Figures 1 to 4 As shown, the present invention provides a data management method based on the data management system 100, including steps S10 to S40.

[0051] Step S10: parse and obtain a file list of discrete code files, and read the discrete code files.

[0052] Step S20: Add a header identifier and a footer identifier to the separate code files, merge multiple separate code files, and obtain an archive file.

[0053] Step S30: Update the separate code files in the archive file.

[0054] Step S40: Setting a preset list format, adjusting the file list of the discrete code file to the preset list format.

[0055] See also Figures 1 to 4 As shown, in one embodiment of the present invention, in step S10, when the archiving module 200 meets the archiving conditions, such as receiving the archiving start signal, the list parsing module 400 parses the file list of the discrete code file, and executes step S40 to adjust the file list of the discrete code file to a preset list format. Among them, the list parsing module 400 stores multiple preset list formats, or inputs the required preset list format to the list parsing module 400. The format parsing unit 410 generates a preset list format, in which uncertain parameter types can be displayed as variables. The list editing unit 420 obtains the values ​​corresponding to the variable parameters in the preset list format, and assigns the variable parameters, thereby adjusting the file list of the discrete code file to the preset list format. In step S20, the path parsing module 300 obtains the file path of the discrete code file, and outputs the file path to the archiving module 200. The archiving module 200 reads the discrete code file, and copies multiple discrete code files to a preset address to form an archive file. The order of the multiple discrete code files is arranged according to the display order of the file list. During the chip design cycle, for example, the verification department can directly read the archived file to obtain the design code data of a certain version in the update process. There is no need to query the file list or obtain the variable data in the file list to find the corresponding design code data. In addition, the present invention can also directly locate the required data, with less redundant data, and can provide clean design code data that meets the requirements.

[0056] See also Figures 1 to 4 As shown, in one embodiment of the present invention, step S30 includes steps S31 to S34.

[0057] Step S31: When updating a separate code file in an archive file, determine whether the current update mode is an overwrite mode.

[0058] Step S32: In overwrite mode, the source files of the separate code files are updated synchronously.

[0059] Step S33: Generate a new discrete code file in non-overwrite mode.

[0060] Step S34: When the discrete code file in the archive file is to be updated, a virtual replacement file of the updated discrete code file is generated.

[0061] See also Figures 1 to 4 As shown, in step S10, in step S31, according to whether the mode setting unit outputs the first start signal or the second start signal, it can be distinguished whether the current update mode is the overwrite mode. In this embodiment, the current update mode is the overwrite mode, and the mode setting unit 510 outputs the first start signal. The current update mode is the non-overwrite mode, and the mode setting unit 510 outputs the second start signal. In step S32, in the overwrite mode, the synchronous update unit 530 receives the first start signal, then after the discrete code file in the archive file is updated, the synchronous update unit 530 reads the source file of the discrete code file according to the file path in the header identifier and the tail identifier, and updates the source file of the discrete code file by comparing it with the updated discrete code file. In step S33, in the non-overwrite mode, the update file generation unit 520 receives the second start signal, and the update file generation unit 520 reads the discrete code file. Then, step S34 is executed, and after the design code data of the discrete code file is updated, the version annotation is updated to form a new discrete code file. The new discrete code file is stored outside the archive file.

[0062] See also Figure 5As shown, the present invention also proposes an electronic device, the electronic device includes a processor 800 and a memory 900, the memory 900 stores program instructions, and the processor 800 runs the program instructions to implement the above data management method. The processor 800 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components; the memory 900 may include a random access memory (RAM), and may also include a non-volatile memory, such as at least one disk storage. The memory 900 can also be an internal memory of the random access memory (RAM) type, and the processor 800 and the memory 900 can be integrated into one or more independent circuits or hardware, such as: an application-specific integrated circuit (ASIC). It should be noted that the computer program in the above-mentioned memory 900 can be implemented in the form of a software functional unit and can be stored in a computer-readable storage medium when it is sold or used as an independent product. Based on such an understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, an electronic device, or a network device, etc.) to perform all or part of the steps of the methods of various embodiments of the present invention.

[0063] See also Figure 6As shown, the present invention also proposes a computer-readable storage medium 110, the computer-readable storage medium 110 stores computer instructions 120, and the computer instructions 120 are used to enable the computer to execute the above-mentioned data management method. The computer-readable storage medium 110 can be an electronic medium, a magnetic medium, an optical medium, an electromagnetic medium, an infrared medium or a semiconductor system or a propagation medium. The computer-readable storage medium 110 can also include a semiconductor or solid-state memory, a magnetic tape, a removable computer disk, a random access memory (RAM), a read-only memory (ROM), a hard disk and an optical disk. The optical disk can include a compact disk-read only memory (CD-ROM), a compact disk-read / write (CD-RW) and a DVD.

[0064] The embodiments of the present invention disclosed above are only used to help illustrate the present invention. The embodiments do not describe all the details in detail, nor do they limit the invention to specific implementation methods. Obviously, many modifications and changes can be made according to the content of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that those skilled in the art can understand and use the present invention well. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A data management system, characterized in that: The data management system is electrically connected to a storage module, and the data management system includes: a path parsing module, electrically connected to the storage module, the path parsing module acquiring and outputting an actual file path of a discrete code file, and reading the discrete code file from the storage module; and an archiving module, the archiving module receiving the discrete code files and outputting an archive file to the storage module, wherein the archive file includes a plurality of the discrete code files, and in the archive file, the discrete code files include a header identifier, design code data, and a tail identifier, and the header identifier includes a start character and an original file path of the discrete code file, and the tail identifier includes an end character and the original file path of the discrete code file; When the archiving module receives the archiving start signal, the archiving module starts the path parsing module and outputs the archive file.

2. A data management system according to claim 1, characterized in that: The head identifier is located at the head of the design code data, and the tail identifier is located at the tail of the design code data.

3. A data management system according to claim 1, characterized in that: The original file path includes variables, and the path parsing module assigns values ​​to the variables in the original file path according to the storage location of the discrete code file, and outputs the actual file path of the discrete code file after the assignment.

4. A data management system according to claim 1, characterized in that: The data management system includes a data updating module, and the data updating module includes: an update file generating unit, which, when updating the separate code file, splits the archive file into a plurality of the separate code files and updates the separate code files; a virtual file generating unit, which outputs a virtual replacement file when generating or updating the discrete code file, wherein the virtual replacement file has the same format and connection relationship as the discrete code file, and wherein the design code data of the virtual replacement file is empty; and A mode setting unit, wherein the data update mode of the data update module includes an overwrite mode and a non-overwrite mode. In the overwrite mode, the mode setting unit outputs a first start signal. In the non-overwrite mode, the mode setting unit outputs a second start signal.

5. A data management system according to claim 4, characterized in that: The data update module includes a synchronous update unit. Under the first start signal, the synchronous update unit reads and updates the source file of the discrete code file according to the file path of the discrete code file.

6. A data management system according to claim 4, characterized in that: In the non-overwrite mode, the update file generation unit receives the second start signal, reads out the separate code file, and generates a new separate code file and a file list of the separate code file outside the archive file.

7. A data management system according to claim 1, characterized in that: The data management system includes a list parsing module, which stores multiple preset list formats. Before the archiving module reads out the discrete code file, the list parsing module reads the file list of the discrete code file and adjusts the file list of the discrete code file to one of the preset list formats.

8. A data management system according to claim 1, characterized in that: The data management system includes a formatting module, in which a preset code format is stored. After the archive module reads out the discrete code file and before the archive file is formed, when the formatting module receives a formatting start signal, the formatting module adjusts the design code data to the preset code format.

9. A data management system according to claim 1, characterized in that: The data management system includes a checking module, in which a standard code type is stored. After the archiving module reads out the discrete code file and before the archive file is formed, when the checking module receives a code checking signal, the checking module compares the discrete code file with the standard code type. When the discrete code file and the standard code type are consistent, the checking module sends an archiving continuation signal to the archiving module to continue generating the archive file.

10. A data management method, characterized in that: Based on a data management system according to any one of claims 1 to 9, the data management method comprises the following steps: When the archiving module receives the archiving start signal, the file path of the discrete code file is acquired and output, and the discrete code file is read out from the storage module; Adding a header mark and a tail mark to the separate code file, wherein the header mark includes a start character and a file path of the separate code file, and the tail mark includes an end character and a file path of the separate code file; Merging the plurality of separate code files to form an archive file; and Output the archive file to the storage module.

Images