CN117744588B - Chip verification system and method - Google Patents
Chip verification system and method Download PDFInfo
- Publication number
- CN117744588B CN117744588B CN202410182791.8A CN202410182791A CN117744588B CN 117744588 B CN117744588 B CN 117744588B CN 202410182791 A CN202410182791 A CN 202410182791A CN 117744588 B CN117744588 B CN 117744588B
- Authority
- CN
- China
- Prior art keywords
- component
- document
- code
- environment
- version number
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012795 verification Methods 0.000 title claims abstract description 58
- 238000000034 method Methods 0.000 title claims abstract description 22
- 238000013515 script Methods 0.000 claims abstract description 8
- 238000010276 construction Methods 0.000 claims abstract description 6
- 101150116173 ver-1 gene Proteins 0.000 claims description 18
- 230000008859 change Effects 0.000 claims description 6
- 238000012544 monitoring process Methods 0.000 claims description 6
- 238000012360 testing method Methods 0.000 claims description 5
- 238000004891 communication Methods 0.000 claims description 4
- 238000012545 processing Methods 0.000 claims description 3
- 230000006870 function Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 238000012942 design verification Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 238000007792 addition Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
Abstract
The invention discloses a chip verification system and a method, which belong to the technical field of chip verification, and comprise a workflow unit, wherein the workflow unit comprises a library tracking component, a document format checking component, a code generating component, a code synchronizing component and a verification system constructing component, the library tracking component monitors whether version update exists, and if yes, a signal is output to the document format checking component; the document format checking component checks errors of the input document according to the configured rules; the code generating component stores the input document generating environment component code passing the format check in a temporary directory tmp_dir; the code synchronization component synchronizes the generated environment component code from the temporary directory tmp_dir to the server; and the verification system construction component constructs a verification environment by using the environment component code, executes the script in the configuration file and runs. The chip verification system and the chip verification method simplify the operation flow of verification personnel.
Description
Technical Field
The present invention relates to the field of chip verification technologies, and in particular, to a chip verification system and method.
Background
In the current chip verification front-end workflow, integration work of various documents is often involved. For example, a verifier needs to build a verification environment component from an inter-module interface document, build a corresponding register model in the verification environment from a register description document, and so on. These documents are typically proposed and maintained by the designer. Along with the progress of the design of the front end of the chip and the verification work, the requirement change can not be avoided, if the addition, deletion and modification of interfaces or registers between modules are involved, verification personnel need to correspondingly modify the verification environment in time according to the latest document, and the flow is complicated.
As shown in the schematic diagram of the conventional chip front-end design verification process in fig. 1, after the chip designer updates the document, the chip designer needs to be notified in time, for example, through a meeting, a mail, an instant messaging tool, etc. The verifier knows the document repository where the project needs to be updated after the document changes, e.g., version control System (SVN), distributed version control system (Git), etc., and then manually performs a series of steps: the method comprises the steps of document format checking, generating a verification environment component or a register model according to a document, modifying codes, uploading to a server by using an FTP tool, merging to a code warehouse, manually running a command to carry out compiling test and the like, and if part of steps are wrong, the corresponding log file needs to be checked, and the process is very complicated after correction and is executed from the beginning. In addition, if the document is updated frequently, more work is wasted in updating the document.
Disclosure of Invention
The invention aims to provide a chip verification system and a chip verification method.
In order to achieve the above purpose, the technical scheme of the invention is as follows:
a chip verification method includes the steps of,
Step S1, monitoring a document warehouse in real time;
step S2, judging whether the document warehouse has version update or not, if so, entering step S3; if not, returning to the step S1;
step S3, checking the error of the input document according to the configured rule;
Step S4, judging whether the input document is wrong, if so, entering step S12, and feeding back error information; otherwise, continuing to step S5;
step S5, generating environment component codes from the input document passing the format check;
Step S6, judging whether the generation of the environment component codes is successful, if so, entering step S7; if not, the step S12 is carried out, and error information is fed back;
Step S7, synchronizing the environment component codes to a server;
step S8, judging whether the synchronization is successful, if so, entering step S9; if not, the step S12 is carried out, and error information is fed back;
s9, constructing a verification environment by using the environment component codes, and executing scripts in the configuration file to obtain compiling and running results;
Step S10, judging whether the operation is successful, if so, entering step S11; if not, the step S12 is carried out, and error information is fed back;
and S11, marking the newly added environment change or test case as a legal file, and automatically uploading the legal file to a code warehouse.
Further, run commandsIntercepting a version number field in the result to obtain a version number ver1 of a document warehouse, recording the version number ver1 in a file verfile, waiting for a set time, reading the version number ver2 of the document warehouse again, reading the version number ver1 recorded in a file verfile, comparing the two, if the version number ver2 is larger than the version number ver1, indicating that version update exists, carrying out subsequent procedures, and enabling the version number ver1 to be equal to the version number ver2; if the version number ver2 is equal to the version number ver1, the version number ver2 indicates that the version of the document warehouse is not updated, no processing is performed, and the step S1 is returned to for continuous monitoring.
The invention also provides a chip verification system, which is applied to the chip verification method, and comprises a workflow unit, wherein the workflow unit comprises a library tracking component, a document format checking component, a code generating component, a code synchronizing component and a verification system constructing component, the library tracking component monitors whether version update exists or not, and if yes, a signal is output to the document format checking component; the document format checking component checks errors of the input document according to the configured rules; the code generating component stores the input document generating environment component code passing the format check in a temporary directory tmp_dir; the code synchronization component synchronizes the generated environment component code from the temporary directory tmp_dir to the server; and the verification system construction component constructs a verification environment by using the environment component code, executes the script in the configuration file and runs.
In one embodiment, the library tracking component notifies the document format checking component by way of interprocess communication.
In a specific embodiment, the workflow unit further includes a log component that receives an execution log from a component of the workflow unit.
In a specific embodiment, the workflow unit further includes a notification component, where the notification component organizes the log generated by the log component and notifies a designer and a verifier.
In a specific embodiment, the chip verification system further includes an input document, and the input document is updated by a designer.
In a specific embodiment, the chip verification system further includes a configuration file, where the configuration file includes configuration items, and the configuration file is updated by a verifier.
The chip verification system and the method have the beneficial effects that tedious repeated labor of a verification staff in building a verification environment and a register model according to an interface and a register document can be reduced, unnecessary labor of the verification staff is reduced, and the working efficiency is improved; aiming at the working scene that the document update causes the update of the verification environment, on the basis of the same final effect, the operation flow of the verification personnel is greatly simplified, the problem of document asynchronism caused by untimely communication between the designer and the verification personnel is avoided, and the working quality of the design and verification of the front end of the chip is ensured.
In order to make the above features and advantages of the present invention more comprehensible, embodiments accompanied with figures are described in detail below.
Drawings
Fig. 1 is a schematic diagram of a conventional chip front-end design verification process.
Fig. 2 is a schematic structural diagram of a chip verification system according to the present invention.
Fig. 3 is a flowchart of a chip verification method according to the present invention.
Detailed Description
In order to make the purpose and technical solutions of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. It will be apparent that the described embodiments are some, but not all, embodiments of the invention. All other embodiments, which can be made by a person skilled in the art without creative efforts, based on the described embodiments of the present invention fall within the protection scope of the present invention.
Fig. 2 is a schematic structural diagram of a chip verification system according to the present invention. As shown in fig. 2, the chip designer (Design) is responsible for updating an input Document (Document) 2, which input Document 2 includes an inter-module interface Document and a register description Document. The verifier (Verification) is responsible for updating the configuration file (Config) 3.
The configuration file 3 is a plain text file, is a description of the workflow expected by the verifier, and contains a series of configuration items, wherein the configuration items comprise parameters of steps in the automatic flow, such as document checking enabling, document path, code checking enabling, running command, notification enabling, error number of triggering notification, format checking item and the like, and the parameters of specific steps are triggered or not triggered; the configuration file 3 further includes operations after the success or failure of the current execution, such as notifying a designer, authenticating personnel to re-run, etc. The verifier may modify the configuration values therein with any text editor, for example, setting the parameter document_check_ral=1, i.e. the ral check enable of the openable document.
The workflow unit 1 is a piece of software running on a server and is composed of a series of components, the main functions of which are to acquire a configuration file and 3 input the document 2, and to feed back the result to the verifier after performing a series of actions.
The workflow unit 1 mainly includes a library tracking component 11 (Trigger), a document format checking component 12 (Check), a code generating component 13 (generation), a code synchronizing component 14 (Sync), a verification system constructing component 15 (Build), a Log component 16 (Log), a notification component 17 (Notify), and other extensible components, and the like.
The function of the library tracking component 11 is to monitor the document repository in real time, and if a change in the document of the configuration path is found, a signal is output informing the workflow unit 1 that a subsequent procedure can be performed, in particular a signal is output to the document format checking component 12.
The document format checking component 12 functions to check the input document 2 for errors according to configured rules in order to meet the code generation requirements. The rules include interface naming rules, signal attribute constraint rules, signal description rules, data structure form rules, register field range rules, and the like. When the document format checking component 12 starts to operate, an input document 2 of a specified location is read, the specified location can be configured in the system, and then the input document 2 is checked according to the configured rule. If the input document 2 has errors, the document format checking component 12 feeds back error information to the log component 16; otherwise, continuing the subsequent flow.
In a specific embodiment, the interface naming rule includes, for the case that the same group of signals has multiple copies, the number of copies needs to be marked with brackets in the signal names, and the format is as follows: interface_signal_name [ N ], N is the number of copies defined in the interface document. If the signal names in the interface document are written as either interface_signal_name1 or interface_signal_name_a, which are not in compliance with the rules, the document format checking component 12 will feed back error information to the logging component 16.
In a specific embodiment, the signal attribute constraint rules include that the signal attributes in the interface document can only be selected within a given range, and if the filled signal attributes are not within the given range, indicating that the rule is not met, the document format checking component 12 will feed back error information to the log component 16.
In a specific embodiment, the signal description rule includes that a detailed description of a signal is required, and only numbers or symbols cannot be written.
In a specific embodiment, the register field segment range rule includes that the field segment range within the register file must not exceed the width of the register, and must start from 0.
The code generation component 13 functions to generate an environment component and a register model from the input document that will pass the format check. The code generating component 13 reads an input document 2, such as an interface document, at a designated position, and then analyzes the document content according to a template to obtain information in the document, namely the name, bit width, input/output attribute and the like of the interface; and filling the analyzed content into a code template of a document warehouse to obtain an environment component code, and storing the environment component code in a temporary directory tmp_dir. If the generation fails, the code generation component 13 feeds back error information to the log component 16, and interrupts the workflow; otherwise, continuing the subsequent flow.
The code synchronization component 14 synchronizes the generated environment component code from the temporary directory tmp dir of the document repository to the verifier's server. More specifically, the code synchronization component 14 generates and executes the ftp script according to the configured server address and location, and after execution is completed, the environment component code in the temporary directory tmp_dir is uploaded to the server of the verifier, so that the verification environment code can be updated, and the purpose of continuously integrating the latest environment component code is achieved. If the synchronization fails, the code synchronization component 14 feeds back error information to the log component 16, interrupting the workflow; otherwise, continuing the subsequent flow.
The verification system construction component 15 is configured to construct a verification environment by using the latest environment component code, execute a script, typically a Makefile command, in the configuration file 3, and obtain a compiling and running result. If the operation is successful, the newly added environment change or the test case is marked as a legal file and is automatically uploaded to a code warehouse, so that the aim of continuously deploying the latest verification environment is fulfilled. If the construction fails, for example, a compiling error or a simulation result failure occurs, the verification system construction component 15 feeds back error information to the log component 16, and interrupts the workflow; otherwise, continuing the subsequent flow.
The log component 16 is configured to receive the execution log from each workflow component, including general information, warning information, and error information, and to feed back the collected execution log to the notification component 17. Each time a workflow is executed, each component of the previous stage generates a large amount of log information including information of execution success and failure, a log generated by midway execution for debugging positioning, and the like. The logs are stored in the running positions of the respective components, the log component 16 reads the file contents of the positions, and the complete logs of the current execution workflow are obtained after the file contents are collected and combined.
The function of the notification component 17 is to normalize, beautify, visualize the log generated by the log component 16 into a human friendly form, and then notify designers and verifiers through system alarms, mail, etc. More specifically, the complete log generated by the log component 16 is likely to be very numerous and in plain text format, which is inconvenient for the verifier to view. The notification component 17 may parse the content therein, convert the log generated by each component into a unified format, and finally generate an execution report after compacting, for example, fill log information based on a web page template, and generate a rich text mail.
Furthermore, the designer and the verifier can quickly check which link is in error according to the received execution report, and correspondingly modify the link to finish the execution flow.
The invention also provides a chip verification method, the flow chart of which is shown in fig. 3, comprising the following steps.
Step S1, monitoring a document warehouse in real time.
Step S2, judging whether the document warehouse has version update or not, if so, entering step S3; if not, returning to the step S1.
More specifically, the run commandIntercepting a version number field in a result to obtain a version number ver1 of a document warehouse, recording the version number ver1 in a file verfile, waiting for a set time, wherein the set time can be configured in a system, reading the version number ver2 of the document warehouse again, reading the version number ver1 recorded in a file verfile, comparing the two, if the version number ver2 is larger than the version number ver1, indicating that the document is changed, indicating that version update exists, outputting a signal to inform a workflow unit 1 through an inter-process communication mode, such as a file, a network packet, a shared memory and the like, and enabling the version number ver1 to be equal to the version number ver2 after the workflow unit 1 receives the file and then carries out subsequent flow; if the version number ver2 is equal to the version number ver1, the version of the document warehouse is not updated, and no processing is performed. Returning to the step S1, and continuing monitoring.
Step S3, checking the error of the input document 2 according to the configured rule.
Step S4, judging whether the input document 2 is wrong, if so, entering step S12, and feeding back error information; otherwise, the process proceeds to step S5.
Step S5, generating the environment component code from the input document passing the format check.
Step S6, judging whether the generation of the environment component codes is successful, if so, entering step S7; if not, go to step S12 to feed back error information.
Step S7, synchronizing the environment component codes to the server.
Step S8, judging whether the synchronization is successful, if so, entering step S9; if not, go to step S12 to feed back error information.
And S9, constructing a verification environment by using the environment component codes, and executing the script in the configuration file to obtain compiling and running results.
Step S10, judging whether the operation is successful, if so, entering step S11; if not, go to step S12 to feed back error information.
And S11, marking the newly added environment change or test case as a legal file, and automatically uploading the legal file to a code warehouse.
Although the present invention has been described with reference to the above embodiments, it should be understood that the invention is not limited thereto, but rather is capable of modification and variation without departing from the spirit and scope of the present invention.
Claims (7)
1. A chip verification method is characterized by comprising the following steps of,
Step S1, monitoring a document warehouse in real time;
step S2, judging whether the document warehouse has version update or not, if so, entering step S3; if not, returning to the step S1;
step S3, checking the error of the input document according to the configured rule;
the rules comprise interface naming rules, signal attribute constraint rules, signal description rules and register domain segment range rules;
Step S4, judging whether the input document is wrong, if so, entering step S12, and feeding back error information; otherwise, continuing to step S5;
step S5, generating environment component codes from the input document passing the format check;
Step S6, judging whether the generation of the environment component codes is successful, if so, entering step S7; if not, the step S12 is carried out, and error information is fed back;
Step S7, synchronizing the environment component codes to a server;
step S8, judging whether the synchronization is successful, if so, entering step S9; if not, the step S12 is carried out, and error information is fed back;
s9, constructing a verification environment by using the environment component codes, and executing scripts in the configuration file to obtain compiling and running results;
Step S10, judging whether the operation is successful, if so, entering step S11; if not, the step S12 is carried out, and error information is fed back;
step S11, the newly added environment change or test case is marked as legal file and automatically uploaded to a code warehouse;
In the step S2, a command is run Intercepting a version number field in the result to obtain a version number ver1 of a document warehouse, recording the version number ver1 in a file verfile, waiting for a set time, reading the version number ver2 of the document warehouse again, reading the version number ver1 recorded in a file verfile, comparing the two, if the version number ver2 is larger than the version number ver1, indicating that version update exists, carrying out subsequent procedures, and enabling the version number ver1 to be equal to the version number ver2; if the version number ver2 is equal to the version number ver1, the version number ver2 indicates that the version of the document warehouse is not updated, no processing is performed, and the step S1 is returned to for continuous monitoring.
2. A chip verification system, characterized in that the chip verification method according to claim 1 is applied, the chip verification system comprises a workflow unit, the workflow unit comprises a library tracking component, a document format checking component, a code generating component, a code synchronizing component and a verification system constructing component, the library tracking component monitors whether version update exists, and if yes, a signal is output to the document format checking component; the document format checking component checks errors of the input document according to the configured rules; the code generating component stores the input document generating environment component code passing the format check in a temporary directory tmp_dir; the code synchronization component synchronizes the generated environment component code from the temporary directory tmp_dir to the server; and the verification system construction component constructs a verification environment by using the environment component code, executes the script in the configuration file and runs.
3. The chip authentication system of claim 2 wherein said library tracking component notifies said document format checking component by way of interprocess communication.
4. The chip authentication system of claim 3, wherein the workflow unit further comprises a log component that receives an execution log from a component of the workflow unit.
5. The chip authentication system of claim 4, wherein the workflow unit further comprises a notification component that collates the log generated by the log component to notify designers and authenticators.
6. The chip authentication system of claim 5 further comprising an input document, said input document updated by a designer.
7. The chip authentication system of claim 6 further comprising a configuration file, the configuration file comprising configuration items, the configuration file updated by an authentication person.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410182791.8A CN117744588B (en) | 2024-02-19 | Chip verification system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410182791.8A CN117744588B (en) | 2024-02-19 | Chip verification system and method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN117744588A CN117744588A (en) | 2024-03-22 |
| CN117744588B true CN117744588B (en) | 2024-05-31 |
Family
ID=
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103279419A (en) * | 2013-06-09 | 2013-09-04 | 浪潮电子信息产业股份有限公司 | Automation version verifying method and system based on B/S structural system |
| CN109101680A (en) * | 2018-06-26 | 2018-12-28 | 天津飞腾信息技术有限公司 | FPGA prototype automatic verification method and system based on GitLab-CI |
| CN111400119A (en) * | 2020-03-24 | 2020-07-10 | 天津飞腾信息技术有限公司 | Multi-project and multi-platform self-adaptive chip design FPGA prototype verification method and system |
| CN111859833A (en) * | 2020-07-22 | 2020-10-30 | 中国人民解放军国防科技大学 | Configurable system level verification environment construction method, system and medium |
| CN115587558A (en) * | 2022-10-26 | 2023-01-10 | 北京物芯科技有限责任公司 | Interface-based verification environment generation method and device, equipment and storage medium |
| CN116795425A (en) * | 2023-06-27 | 2023-09-22 | 北京时代民芯科技有限公司 | Chip front-end development system and method based on git |
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103279419A (en) * | 2013-06-09 | 2013-09-04 | 浪潮电子信息产业股份有限公司 | Automation version verifying method and system based on B/S structural system |
| CN109101680A (en) * | 2018-06-26 | 2018-12-28 | 天津飞腾信息技术有限公司 | FPGA prototype automatic verification method and system based on GitLab-CI |
| CN111400119A (en) * | 2020-03-24 | 2020-07-10 | 天津飞腾信息技术有限公司 | Multi-project and multi-platform self-adaptive chip design FPGA prototype verification method and system |
| CN111859833A (en) * | 2020-07-22 | 2020-10-30 | 中国人民解放军国防科技大学 | Configurable system level verification environment construction method, system and medium |
| CN115587558A (en) * | 2022-10-26 | 2023-01-10 | 北京物芯科技有限责任公司 | Interface-based verification environment generation method and device, equipment and storage medium |
| CN116795425A (en) * | 2023-06-27 | 2023-09-22 | 北京时代民芯科技有限公司 | Chip front-end development system and method based on git |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108920250B (en) | Application program containerization method and device | |
| KR101999409B1 (en) | Formatting data by example | |
| CN108469952B (en) | Code generation method and matched tool for managing game configuration | |
| US20060015839A1 (en) | Development of software systems | |
| US9098500B1 (en) | Revision history storage and maintenance | |
| CN106293664A (en) | Code generating method and device | |
| JP2007122135A (en) | Development support device, development support method and development support program | |
| US20030097637A1 (en) | Schema generation apparatus, data processor, and program for processing in the same data processor | |
| US8453053B2 (en) | Rapid software report development tool with auto database handling and menu tool-bar plug-in for application report access | |
| JP2009205190A (en) | Automatic software configuration device | |
| CN109284331A (en) | Accreditation information acquisition method, terminal device and medium based on business datum resource | |
| CN114840213A (en) | Service instance configuration management method and device | |
| CN114912897A (en) | Workflow execution method, workflow arrangement method and electronic equipment | |
| US11625228B2 (en) | System and method for facilitating efficient round-trip engineering using intermediate representations | |
| CN117744588B (en) | Chip verification system and method | |
| WO2002046909A1 (en) | Automatically deploy and upgrade an application based on markup language application definition | |
| CN116088846A (en) | Processing method, related device and equipment for continuous integrated code format | |
| CN117744588A (en) | Chip verification system and method | |
| US8726152B2 (en) | Automated detection and implementation of state and object modifications | |
| CN111427568A (en) | Interface configuration method and device | |
| CN114356430B (en) | DAG dependent configuration tool based on airflow scheduling system | |
| CN115357269A (en) | Configuration information updating method and device, computer equipment and storage medium | |
| US9501456B2 (en) | Automatic fix for extensible markup language errors | |
| CN112817585A (en) | Cocos2dx UI interface building method based on Unity editor | |
| Kolovos et al. | Towards flexible parsing of structured textual model representations |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant |