A chip completeness verification method based on demand-use case bidirectional tracing
By constructing a structured requirements database and a two-way traceability mapping relationship, the problems of broken correlation between requirements and use cases, delayed changes, and information silos in chip design verification were solved, realizing full-link traceability and accurate coverage assessment, and improving the completeness and efficiency of verification.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JIANGSU XINSHENG INTELLIGENT TECH CO LTD
- Filing Date
- 2026-06-16
- Publication Date
- 2026-07-14
Smart Images
Figure CN122389771A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of chip verification technology, and in particular to a chip completeness verification method based on bidirectional traceability of requirements and use cases. Background Technology
[0002] In the chip design process, verification is a crucial step in ensuring the correctness of chip functionality, performance compliance, and stability. Its core objective is to cover all chip design requirements (including functional requirements, interface requirements, timing requirements, and exception handling requirements) by executing a series of verification test cases, ensuring no design defects are overlooked. However, with increasing chip integration (e.g., SoC chips include multiple modules such as CPU, GPU, memory controller, and peripheral interfaces) and increased functional complexity (e.g., supporting multi-protocol compatibility, dynamic power management, and security encryption), traditional verification methods face the following technical challenges in ensuring "verification completeness" and "no omissions": 1. Disconnect between requirements and use cases: In traditional verification processes, design requirement documents (such as Spec documents) and verification use case libraries are usually managed independently (requirements are recorded in Word / Excel, and use cases are stored in SystemVerilog / UVM code or test scripts), lacking a structured mapping. Verification personnel need to manually determine "whether a certain requirement has a corresponding design use case" and "which requirement a certain use case corresponds to," which is prone to errors due to human operation, resulting in omissions in requirement coverage (such as not designing a corresponding use case for a certain exception handling requirement) or redundant use cases (such as repeatedly designing use cases that cover the same requirement).
[0003] 2. Delayed test cases due to requirement changes: Chip design often involves requirement iterations (such as upgrading the interface protocol from PCIe 4.0 to PCIe 5.0, or adding security verification functions). In traditional processes, after requirement changes, "affected verification test cases" need to be manually screened and updated. If change notifications are not timely or manual screening is missed, some test cases may still be designed based on the old requirements and cannot cover the new requirements, or old, invalid test cases may not be deleted, resulting in wasted verification resources and a failure to guarantee completeness.
[0004] 3. Lack of traceability in coverage statistics: During the verification process, the completeness of verification needs to be evaluated through "coverage" (such as functional coverage, code coverage, assertion coverage). However, traditional coverage tools can only count whether "test case execution covers code branches / functional points" and cannot trace back to "which design requirement corresponds to the uncovered code branch / functional point". This makes it difficult for verification personnel to locate "whether the requirement is not covered or the test case is not designed" and cannot accurately fill the verification gap.
[0005] 4. Information silos caused by multi-team collaboration: Large chip projects are usually divided into requirements analysis teams, design teams, and verification teams. During the transmission of requirements documents, version confusion may occur (such as the verification team using a non-latest version of the requirements document), or the update of verification test cases may not be synchronized with the requirements team, resulting in inconsistent understanding of the "scope of verified requirements" among different teams, ultimately leading to verification omissions.
[0006] In existing technologies, some solutions attempt to create a requirement-use case mapping table using Excel spreadsheets, but this still relies on manual maintenance and cannot achieve dynamic association and automatic updates. Other solutions optimize coverage analysis tools, but do not solve the fundamental problem of "requirement-use case traceability," failing to fundamentally ensure that verification is complete. Therefore, there is an urgent need for a technical solution that can establish a structured association between requirements and use cases, achieve dynamic updates and traceability, and quantitatively assess the completeness of verification. Summary of the Invention
[0007] The purpose of this invention is to overcome the shortcomings of the prior art and provide a chip completeness verification method based on bidirectional traceability of requirements and use cases.
[0008] The objective of this invention is achieved through the following technical solution: a chip completeness verification method based on bidirectional traceability of requirements and use cases, comprising the following steps: S1. Construct a structured database of chip design requirements; S2. Establish a two-way traceability mapping relationship between verification test cases and chip design requirements; S3. When performing chip completeness verification, detect whether the chip design requirements have changed. If the requirements have changed, automatically trigger and track the dynamic updates of the verification test cases associated with the changed content. S4. Based on the bidirectional traceability mapping relationship, perform correlation verification and completeness assessment on the coverage data generated during the verification process; S5. Collect data generated at each step through a unified system platform. The requirements team, verification team and design team use the system platform to synchronize data, collaborate as a team and control access.
[0009] Preferably, step S1 includes the following sub-steps: S11. Define a classification system for chip design requirements, classifying chip design requirements according to module dimensions and attribute dimensions to form a tree-shaped requirement structure; the module dimension is divided according to the chip's functional modules, and the attribute dimension is divided according to the nature of the requirements; S12. Assign a unique requirement identifier to each chip design requirement in the database; S13. Associate the requirement content of each chip design requirement with the requirement identifier and store it in an expandable chip design requirement database.
[0010] Preferably, the chip functional modules include a CPU module, a storage module, a PCIe interface module, and a security module; the requirements include functional requirements, interface requirements, timing requirements, exception handling requirements, and power consumption requirements; the requirement identifier is in the format of module code-attribute code-serial number.
[0011] Preferably, step S2 includes the following sub-steps: S21. In the verification test case library, configure a traceability label for each verification test case. The label content of the traceability label includes: the associated list of requirement identifiers, test case type, test case status, and test case version number. S22. Read the requirement identifiers from the chip design requirement database and the traceability tags from the verification test case library, automatically generate and maintain a requirement-use case bidirectional traceability matrix; the requirement-use case bidirectional traceability matrix is used to trace forward from the requirement identifier to all the verification test case lists and test case statuses associated with it, and to trace backward from the verification test case to all the requirement identifiers and requirement acceptance criteria it covers. S23. Establish a real-time connection between the requirement-use case bidirectional traceability matrix, the chip design requirement database, and the verification use case library. When the chip design requirement or verification use case is updated, the traceability relationship is updated synchronously.
[0012] Preferably, step S3 includes the following sub-steps: S31. When chip design requirements are added, modified, or deleted, automatically capture the requirement identifier, change type, differences in requirement content before and after the change, and scope of impact of the change. S32. Based on the bidirectional traceability mapping relationship, the verification test cases affected by the requirement change are automatically filtered out through the test case matching algorithm, and the affected verification test cases are marked as test cases to be added, test cases to be updated, or test cases to be invalidated. S33. Based on the changes to the verification test cases, send an update notification containing a list of affected verification test cases and details of the changes to the relevant verification personnel, and track and record the update progress of the affected verification test cases.
[0013] Preferably, the use case matching algorithm executes different filtering logic based on the change type: If the change type is "new", then existing use cases with the same module dimension and attribute dimension as the new requirement are filtered as references, and a reminder for the new use cases is generated. If the change type is modification, then filter all validation test cases with requirement identifiers associated with modification requirements and mark them as test cases to be updated; If the change type is deletion, then filter all validation test cases with requirement identifiers associated with deletion requirements and mark them as test cases to be invalidated.
[0014] Preferably, step S4 further includes the following sub-steps: S41. Import the coverage data generated during the verification process into the traceability management tool, and map the coverage data to the target requirements through the association relationship between requirement identifier, use case identifier, and code module. S42. The traceability management tool automatically generates a verification completeness assessment report based on the association mapping results. The verification completeness assessment report includes: statistics on requirement coverage, statistics on the effectiveness of verification test cases, and the coverage rate of each dimension. S43. For the verification gaps identified in the verification completeness assessment report, guide the verification personnel to supplement or update the test cases, and mark the closed-loop status of the verification gaps.
[0015] Preferably, S41 includes the following steps: If the functional coverage does not reach the preset threshold after all verification test cases associated with the target requirement are executed, the requirement coverage of the target requirement will be marked as incomplete. If a code branch is not covered by any verification test cases, the chip design requirement corresponding to that code branch is located by reverse tracing and marked as an uncovered requirement.
[0016] Preferably, step S5 includes the following sub-steps: S51. Assign different system operation permissions to different team members; all teams can access the chip design requirements database, verification test case library, requirement-test case bidirectional traceability matrix, and coverage data through a unified web access interface. S52. Automatically record all user operations on the system platform to form a traceable operation log; S53. Once all verification test cases associated with a chip design requirement have been verified and met the standards, an automatic notification of requirement verification completion will be sent to the requirement team to synchronize the verification progress.
[0017] Preferably, the system operation permissions for the requirements team are: the permission to add, modify, and delete chip design requirements data; the system operation permissions for the verification team are: the permission to add, modify, and mark the status of verification test case data; and the system operation permissions for the design team are: read-only viewing permissions for chip design requirements data, verification test case data, and coverage data.
[0018] The beneficial effects of this invention are: 1) Achieve end-to-end traceability of requirements and use cases to avoid coverage omissions: Traditional methods rely on manual association of requirements and use cases, which is prone to requirement coverage omissions; This invention establishes an end-to-end association of "requirement ID (requirement identifier) - use case ID (use case identifier) - coverage data" through a structured requirement database and a two-way traceability matrix. Verification personnel can query the corresponding use case by requirement ID at any time, or trace back the requirements by use case, ensuring that every requirement has a corresponding verification use case and every use case has a clear requirement target, avoiding the problems of "uncovered requirements" or "use cases without corresponding requirements" from the source, and significantly improving verification completeness.
[0019] 2) Automatic use case updates triggered by requirement changes avoid use case lag: In the prior art, after a requirement change, the affected use cases need to be manually screened, which is prone to lag due to human omissions; the present invention can automatically capture requirement changes and screen affected use cases through the "change triggering module" and "use case matching algorithm", and send update notifications and track progress at the same time, ensuring the timeliness and accuracy of use case updates after requirement changes; shortening the use case update response time and reducing the update omission rate.
[0020] 3) Coverage verification combined with traceability relationships for precise gap identification: Traditional coverage tools can only count "whether coverage is achieved," but cannot pinpoint "the corresponding uncovered requirements." This invention links coverage data with traceability relationships, directly mapping "uncovered code branches / functional points" to specific requirements. This helps verification personnel quickly determine the cause of the gap (whether the requirement lacks test cases or the test cases are not executed), avoiding blindly adding test cases. For example, in a scenario where the code coverage of a CPU module is below standard, this invention can quickly locate "the CPU exception handling requirement corresponding to the uncovered code (CPU-EXC-002)." Verification personnel only need to add test cases for this requirement, without needing to check test cases for the entire CPU module, thus improving verification efficiency.
[0021] 4) Multi-team data synchronization and access control to eliminate information silos: In traditional multi-team collaboration, inconsistent data versions can easily lead to verification omissions; this invention enables real-time sharing of requirements, use cases, traceability relationships, and coverage data through a unified database and web access interface. At the same time, access control ensures the standardization of data modifications and avoids version chaos; it reduces the verification rework rate caused by data asynchrony between teams and shortens the overall project verification cycle.
[0022] 5) High scalability, adaptable to different chip verification scenarios: The requirement classification system, requirement ID encoding rules, and use case traceability tags of this invention can all be customized according to the chip type (such as MCU, SoC, AI chip). For example, for the neural network acceleration module of AI chip, attribute dimensions such as "computing power requirement" and "accuracy requirement" can be added; for the low power consumption characteristics of MCU chip, the requirement ID encoding can be optimized to "MCU-PWR-00X" (PWR represents power consumption requirement), ensuring the adaptability of the solution in different chip verification scenarios. Attached Figure Description
[0023] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation
[0024] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0025] See Figure 1 This invention provides a technical solution: a chip completeness verification method based on bidirectional traceability of requirements and use cases, comprising the following steps: S1. Construct a structured database of chip design requirements; S2. Establish a two-way traceability mapping relationship between verification test cases and chip design requirements; S3. When performing chip completeness verification, detect whether the chip design requirements have changed. If the requirements have changed, automatically trigger and track the dynamic updates of the verification test cases associated with the changed content. S4. Based on the bidirectional traceability mapping relationship, perform correlation verification and completeness assessment on the coverage data generated during the verification process; S5. Collect data generated at each step through a unified system platform. The requirements team, verification team and design team use the system platform to synchronize data, collaborate as a team and control access.
[0026] In this embodiment, the core is to build a closed-loop mechanism of "structured requirement management - use case association mapping - dynamic update triggering - coverage traceability verification" to solve the technical problems in existing chip verification technology, such as the broken association between requirements and use cases, the lag in use case updates after requirement changes, the lack of traceability basis for coverage statistics, and the lack of synchronization of information in multi-team collaboration, which leads to the inability to guarantee verification completeness and the easy occurrence of verification omissions.
[0027] In some embodiments, S1 includes the following sub-steps: S11. Define a classification system for chip design requirements, classifying chip design requirements according to module dimensions and attribute dimensions to form a tree-shaped requirement structure; the module dimension is divided according to the chip's functional modules, and the attribute dimension is divided according to the nature of the requirements; S12. Assign a unique requirement identifier to each chip design requirement in the database; S13. Associate the requirement content of each chip design requirement with the requirement identifier and store it in an expandable chip design requirement database.
[0028] In this embodiment, step 1: Construct a structured requirements database: 1.1 Define the requirement classification system: classify chip design requirements according to "module dimension" (such as CPU module, storage module, PCIe interface module, security module) and "attribute dimension" (functional requirements, interface requirements, timing requirements, exception handling requirements, power consumption requirements) to form a tree-shaped requirement structure; 1.2 Assign a unique identifier (ID) to each requirement: Generate requirement IDs using a combination format of "module code-attribute code-serial number" (e.g., "PCIe-IF-001" represents the first interface requirement of the PCIe interface module, and "CPU-EXC-003" represents the third exception handling requirement of the CPU module) to ensure the uniqueness of requirement identifiers; 1.3 Structured Storage of Requirements: The requirements content (requirement description, acceptance criteria, priority, version number, responsible person) is associated with the requirement ID and stored in an scalable requirement database (such as a relational database based on MySQL or a non-relational database based on MongoDB), supporting the addition, modification, deletion and version tracking of requirements.
[0029] In some embodiments, the chip functional modules include a CPU module, a storage module, a PCIe interface module, and a security module; the requirements include functional requirements, interface requirements, timing requirements, exception handling requirements, and power consumption requirements; the requirement identifier is in the format of module code-attribute code-serial number.
[0030] In some embodiments, S2 includes the following sub-steps: S21. In the verification test case library, configure a traceability label for each verification test case. The label content of the traceability label includes: the associated list of requirement identifiers, test case type, test case status, and test case version number. S22. Read the requirement identifiers from the chip design requirement database and the traceability tags from the verification test case library, automatically generate and maintain a requirement-use case bidirectional traceability matrix; the requirement-use case bidirectional traceability matrix is used to trace forward from the requirement identifier to all the verification test case lists and test case statuses associated with it, and to trace backward from the verification test case to all the requirement identifiers and requirement acceptance criteria it covers. S23. Establish a real-time connection between the requirement-use case bidirectional traceability matrix, the chip design requirement database, and the verification use case library. When the chip design requirement or verification use case is updated, the traceability relationship is updated synchronously.
[0031] In this embodiment, step 2: Establish a bidirectional traceability mapping between verification use cases and requirements: 2.1 Structured Design of Validation Test Cases: In the validation test case library (such as a test case library based on the UVM framework), add a "traceability tag" to each test case. The tag content includes: 1) List of associated requirement IDs (supports associating one use case with multiple requirements, such as "PCIe-IF-001" and "PCIe-TIM-002"); 2) Test case types (functional test cases, sequence test cases, exception injection test cases); 3) Use case status (pending execution, executing, passed, expired); 4) Use case version number (corresponding to the version number of the associated requirement); 2.2 Constructing a Two-Way Traceability Matrix: Using software tools (such as a traceability management tool developed based on Python), the requirement IDs in the requirement database and the traceability tags in the use case library are read to automatically generate a "requirement-use case two-way traceability matrix," which includes: 1) Forward tracing: A list of all use cases and their statuses corresponding to a specific requirement ID; 2) Reverse tracing: All requirement IDs and requirement acceptance criteria corresponding to a specific use case; 2.3 Traceability Relationship Storage: Establish real-time association between the bidirectional traceability matrix and the requirements database and use case library to ensure that the traceability relationship is updated synchronously when requirements or use cases are updated.
[0032] In some embodiments, S3 includes the following sub-steps: S31. When chip design requirements are added, modified, or deleted, automatically capture the requirement identifier, change type, differences in requirement content before and after the change, and scope of impact of the change. S32. Based on the bidirectional traceability mapping relationship, the verification test cases affected by the requirement change are automatically filtered out through the test case matching algorithm, and the affected verification test cases are marked as test cases to be added, test cases to be updated, or test cases to be invalidated. S33. Based on the changes to the verification test cases, send an update notification containing a list of affected verification test cases and details of the changes to the relevant verification personnel, and track and record the update progress of the affected verification test cases.
[0033] In this embodiment, step 3: Requirement changes trigger dynamic updates of use cases: 3.1 Requirement Change Detection: A "Change Trigger Module" is set up in the requirement database. When a requirement is added, modified, or deleted (after the requirement owner submits a change request and it is approved), the change trigger module automatically captures the following information: 1) Change request ID and change type (add / modify / delete); 2) Differences in requirements before and after the change (such as modification of acceptance criteria or adjustment of priority); 3) Scope of impact of changes (e.g., a change in the requirements of a certain interface may affect all functional use cases of that interface). 3.2 Affected Use Case Screening: The change triggering module calls the "use case matching algorithm" to screen use cases affected by the requirement change based on a two-way traceability matrix. 1) If the requirement is "new": filter existing use cases in the same module and attribute dimension as the requirement (as reference use cases) and generate "reminder of use cases to be added"; 2) If the requirement is "modification": filter all use cases associated with this requirement ID and mark them as "use cases to be updated"; 3) If the requirement is "delete": filter all use cases associated with this requirement ID and mark them as "use cases to be invalidated"; 3.3 Update Notification and Tracking: The change triggering module sends a "use case update notification" to the corresponding verification manager via email / project management tools (such as Jira), which includes a list of use cases to be processed, details of the requirement change, and the completion deadline; at the same time, it records the use case update progress (unprocessed / processing / completed) in the traceability management tool to ensure that no update is missed.
[0034] In some embodiments, the use case matching algorithm performs different filtering logic based on the change type: If the change type is "new", then existing use cases with the same module dimension and attribute dimension as the new requirement are filtered as references, and a reminder for the new use cases is generated. If the change type is modification, then filter all validation test cases with requirement identifiers associated with modification requirements and mark them as test cases to be updated; If the change type is deletion, then filter all validation test cases with requirement identifiers associated with deletion requirements and mark them as test cases to be invalidated.
[0035] In some embodiments, S4 further includes the following sub-steps: S41. Import the coverage data generated during the verification process into the traceability management tool, and map the coverage data to the target requirements through the association relationship between requirement identifier, use case identifier, and code module. S42. The traceability management tool automatically generates a verification completeness assessment report based on the association mapping results. The verification completeness assessment report includes: statistics on requirement coverage, statistics on the effectiveness of verification test cases, and the coverage rate of each dimension. S43. For the verification gaps identified in the verification completeness assessment report, guide the verification personnel to supplement or update the test cases, and mark the closed-loop status of the verification gaps.
[0036] In this embodiment, step 4: Coverage verification and completeness assessment based on traceability relationships: 4.1 Coverage Data Association: Import the coverage data generated during the verification process (such as functional coverage reports and code coverage reports) into the traceability management tool. The tool maps the coverage data to specific requirements through the association relationship of "requirement ID - use case ID - code module". 1) If, after all use cases corresponding to a certain requirement are executed, the functional coverage does not reach the preset threshold (such as 95%), then the requirement is marked as "incomplete coverage"; 2) If a code branch is not covered by any use case, trace back to locate the requirement corresponding to that code branch and mark it as "Requirement not covered"; 4.2 Completeness Assessment Report Generation: The traceability management tool generates a "Verification Completeness Assessment Report" periodically (e.g., daily / weekly), which includes: 1) Requirements coverage status: Number of covered requirements / total number of requirements, list of uncovered requirements and reasons (no corresponding use case / use case not executed / use case execution failed); 2) Test case validity status: number of valid test cases / total number of test cases, list of invalid test cases and reasons (requirement deletion / requirement modification); 3) Coverage compliance status: Coverage data for each module / attribute dimension, and improvement suggestions for modules that do not meet the standards; 4.3 Validation Gap Closure Processing: For validation gaps marked in the report such as "incomplete coverage" or "uncovered requirements", validation personnel supplement the design of test cases or update existing test cases based on the traceability relationship. After completion, they mark "gap closed" in the tool to form closed-loop management.
[0037] In some embodiments, S41 includes the following steps: If the functional coverage does not reach the preset threshold after all verification test cases associated with the target requirement are executed, the requirement coverage of the target requirement will be marked as incomplete. If a code branch is not covered by any verification test cases, the chip design requirement corresponding to that code branch is located by reverse tracing and marked as an uncovered requirement.
[0038] In some embodiments, S5 includes the following sub-steps: S51. Assign different system operation permissions to different team members; all teams can access the chip design requirements database, verification test case library, requirement-test case bidirectional traceability matrix, and coverage data through a unified web access interface. S52. Automatically record all user operations on the system platform to form a traceable operation log; S53. Once all verification test cases associated with a chip design requirement have been verified and met the standards, an automatic notification of requirement verification completion will be sent to the requirement team to synchronize the verification progress.
[0039] In this embodiment, step 5: Multi-team collaboration and data synchronization: 5.1 Access Control and Data Sharing: Different system permissions are assigned to the requirements team, design team, and verification team (e.g., the requirements team can only modify requirement data, and the verification team can only modify test case data). All teams access the requirements database, test case library, and traceability matrix through a unified web interface to ensure data version consistency. 5.2 Operation Log Recording: The system automatically records all user operations (such as requirement modification time, test case update personnel, coverage data import time), forming a traceable operation log to facilitate the identification of the root cause of problems; 5.3 Cross-team synchronous notification: When the verification team completes the verification of all test cases for a certain requirement and meets the target, the system automatically sends a "requirement verification completion notification" to the requirement team to ensure that each team is in sync with the verification progress.
[0040] In some embodiments, the system operation permissions of the requirements team are: the permission to add, modify, and delete chip design requirements data; the system operation permissions of the verification team are: the permission to add, modify, and mark the status of verification test case data; and the system operation permissions of the design team are: read-only viewing permissions for chip design requirements data, verification test case data, and coverage data.
[0041] The following uses the verification process of a certain SoC chip (including a CPU module, a PCIe 5.0 interface module, and a DDR5 memory module) as an example to illustrate the specific implementation steps of this invention: Example 1: Construction of a structured requirements database: 1. Requirements Classification System Definition: Based on the "module dimension", it is divided into CPU modules, PCIe interface modules, and DDR5 storage modules; based on the "attribute dimension", it is divided into functional requirements (F), interface requirements (IF), timing requirements (TIM), exception handling requirements (EXC), and power consumption requirements (PWR), forming a tree structure (e.g., "PCIe interface module → interface requirements", "CPU module → exception handling requirements"). 2. Requirement ID allocation: Assign ID "PCIe-F-001" to the "Link Negotiation Function Requirement" of the PCIe interface module, ID "PCIe-TIM-001" to the "Maximum Transmission Rate Timing Requirement", and ID "PCIe-EXC-001" to the "Link Disconnection Anomaly Handling Requirement". 3. Structured storage of requirements: Store the requirement description of “PCIe-F-001” (“After the chip is powered on, the PCIe interface must complete the link negotiation with the external device within 100ms”), acceptance criteria (“Negotiation success probability ≥ 99.9%, negotiation time ≤ 100ms”), priority (high), version number (V1.0), and person in charge (Engineer Zhang) in the MySQL requirement database.
[0042] Example 2: Establishment of bidirectional traceability mapping: 1. Use Case Traceability Tag Design: Based on the UVM framework, design the PCIe interface verification use case "uvm_test_pcie_link_negotiation" and add traceability tags: associated requirement ID list (PCIe-F-001, PCIe-TIM-001), use case type (functional + sequential test case), use case status (pending execution), and use case version number (V1.0). 2. Two-way traceability matrix generation: Using a traceability management tool developed in Python, the system reads the "PCIe-F-001" and "PCIe-TIM-001" requirement information from the MySQL database, as well as the traceability tags from the UVM use case library, and automatically generates a matrix: forward traceability displays "PCIe-F-001→uvm_test_pcie_link_negotiation", and reverse traceability displays "uvm_test_pcie_link_negotiation→PCIe-F-001, PCIe-TIM-001". 3. Traceability Relationship Storage: The matrix data is stored in the backend database of the traceability management tool and established in real time with the requirements database and UVM use case library through API interface. When the requirements or use cases are updated, the matrix is automatically refreshed.
[0043] Example 3: Requirement change triggers use case update: 1. Requirement Change Detection: Due to external device compatibility requirements, the requirement team modified the acceptance criteria for "PCIe-F-001" to "negotiation success probability ≥ 99.99%, negotiation time ≤ 80ms", updated the version number to V1.1, submitted the change request and it was approved. The change triggering module captured "Change Requirement ID: PCIe-F-001, Change Type: Modification, Scope of Impact: All use cases associated with this requirement"; 2. Affected use case screening: The use case matching algorithm uses a two-way traceability matrix to screen out the use case "uvm_test_pcie_link_negotiation" associated with "PCIe-F-001" and marks it as "use case to be updated"; 3. Update Notification and Tracking: The system sends an email notification to the person in charge of the use case (Engineer Li), which includes the following: "Use case to be updated: uvm_test_pcie_link_negotiation, requirement change details: negotiation success probability increased from 99.9% to 99.99%, time shortened from 100ms to 80ms, completion deadline: 2 working days"; After Engineer Li updates the use case, he marks it as "completed" in the system, and the change triggering module records the update time (Year Month Day 202X).
[0044] Example 4: Coverage Verification and Completeness Assessment 1. Coverage data association: After the test case "uvm_test_pcie_link_negotiation" is executed, a functional coverage report is generated (showing that the coverage of the "link negotiation success probability detection" function point is 90%). After being imported into the traceability management tool, the tool associates "PCIe-F-001" through the traceability matrix and marks the requirement as "incomplete coverage". 2. Completeness Assessment Report Generation: The system generates a weekly report showing that "The total requirements for the PCIe interface module are 15 items, 14 of which have been covered and 1 item has not been covered (PCIe-F-001, reason: functional coverage rate did not reach the 95% threshold); there are 20 valid use cases and 0 invalid use cases; the overall coverage rate of the PCIe interface module is 92%, which does not meet the target (95%)." 3. Verify gap closure: Based on the report, the verification personnel supplemented the design of the test case "uvm_test_pcie_link_negotiation_enhanced" (related requirement ID: PCIe-F-001). After execution, the functional coverage improved to 99%, and the system marked "PCIe-F-001 gap closed". In the next report, this requirement will be marked as "covered".
[0045] Example 5: Multi-team collaboration and data synchronization: 1. Permission Assignment: The requirements team member (Engineer Zhang) has the permission to "add / modify / delete requirements", the verification team member (Engineer Li) has the permission to "add / modify / mark status for test cases", and the design team member (Engineer Wang) has the permission to "read-only view requirements / test cases / coverage data". 2. Data sharing: Wang Gong used the web interface to query the requirements details and execution status of the corresponding use cases for "PCIe-F-001", confirming that the design code had met the latest acceptance criteria for the requirement; 3. Operation Log Recording: The system records "Mr. Zhang modified the PCIe-F-001 requirement on [Date]" and "Mr. Li updated the uvm_test_pcie_link_negotiation test case on [Date]" to facilitate subsequent problem tracing.
[0046] The above description is merely a preferred embodiment of the present invention. It should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or related technologies or knowledge. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of the present invention should be within the protection scope of the appended claims.
Claims
1. A chip completeness verification method based on bidirectional traceability of requirements and use cases, characterized in that: Includes the following steps: S1. Construct a structured database of chip design requirements; S2. Establish a two-way traceability mapping relationship between verification test cases and chip design requirements; S3. When performing chip completeness verification, detect whether the chip design requirements have changed. If the requirements have changed, automatically trigger and track the dynamic updates of the verification test cases associated with the changed content. S4. Based on the bidirectional traceability mapping relationship, perform correlation verification and completeness assessment on the coverage data generated during the verification process; S5. Collect data generated at each step through a unified system platform. The requirements team, verification team and design team use the system platform to synchronize data, collaborate as a team and control access.
2. The chip completeness verification method based on bidirectional traceability of requirements and use cases according to claim 1, characterized in that: S1 includes the following sub-steps: S11. Define a classification system for chip design requirements, classifying chip design requirements according to module dimensions and attribute dimensions to form a tree-shaped requirement structure; the module dimension is divided according to the chip's functional modules, and the attribute dimension is divided according to the nature of the requirements; S12. Assign a unique requirement identifier to each chip design requirement in the database; S13. Associate the requirement content of each chip design requirement with the requirement identifier and store it in an expandable chip design requirement database.
3. The chip completeness verification method based on demand-use case bidirectional traceability according to claim 2, characterized in that: The chip functional modules include a CPU module, a storage module, a PCIe interface module, and a security module; the requirements include functional requirements, interface requirements, timing requirements, exception handling requirements, and power consumption requirements; the requirement identifier is in the format of module code-attribute code-serial number.
4. The chip completeness verification method based on bidirectional traceability of requirements and use cases according to claim 1, characterized in that: S2 includes the following sub-steps: S21. In the verification test case library, configure a traceability label for each verification test case. The label content of the traceability label includes: the associated list of requirement identifiers, test case type, test case status, and test case version number. S22. Read the requirement identifiers from the chip design requirement database and the traceability tags from the verification test case library, automatically generate and maintain a requirement-use case bidirectional traceability matrix; the requirement-use case bidirectional traceability matrix is used to trace forward from the requirement identifier to the list of all verification test cases and test case status associated with it, and to trace backward from the verification test case to all requirement identifiers and requirement acceptance criteria it covers. S23. Establish a real-time connection between the requirement-use case bidirectional traceability matrix, the chip design requirement database, and the verification use case library. When the chip design requirement or verification use case is updated, the traceability relationship is updated synchronously.
5. The chip completeness verification method based on bidirectional traceability of requirements and use cases according to claim 1, characterized in that: S3 includes the following sub-steps: S31. When chip design requirements are added, modified, or deleted, automatically capture the requirement identifier, change type, differences in requirement content before and after the change, and scope of impact of the change. S32. Based on the bidirectional traceability mapping relationship, the verification test cases affected by the requirement change are automatically filtered out through the test case matching algorithm, and the affected verification test cases are marked as test cases to be added, test cases to be updated, or test cases to be invalidated. S33. Based on the changes to the verification test cases, send an update notification containing a list of affected verification test cases and details of the changes to the relevant verification personnel, and track and record the update progress of the affected verification test cases.
6. The chip completeness verification method based on bidirectional traceability of requirements and use cases according to claim 5, characterized in that: The test case matching algorithm executes different filtering logic based on the change type: If the change type is "new", then existing use cases with the same module dimension and attribute dimension as the new requirement are filtered as references, and a reminder for the new use cases is generated. If the change type is modification, then filter all validation test cases with requirement identifiers associated with modification requirements and mark them as test cases to be updated; If the change type is deletion, then filter all validation test cases with requirement identifiers associated with deletion requirements and mark them as test cases to be invalidated.
7. The chip completeness verification method based on bidirectional traceability of requirements and use cases according to claim 1, characterized in that: S4 further includes the following sub-steps: S41. Import the coverage data generated during the verification process into the traceability management tool, and map the coverage data to the target requirements through the association relationship between requirement identifier, use case identifier, and code module. S42. The traceability management tool automatically generates a verification completeness assessment report based on the association mapping results. The verification completeness assessment report includes: statistics on requirement coverage, statistics on the effectiveness of verification test cases, and the coverage rate of each dimension. S43. For the verification gaps identified in the verification completeness assessment report, guide the verification personnel to supplement or update the test cases, and mark the closed-loop status of the verification gaps.
8. The chip completeness verification method based on bidirectional traceability of requirements and use cases according to claim 7, characterized in that: S41 includes the following steps: If the functional coverage does not reach the preset threshold after all verification test cases associated with the target requirement are executed, the requirement coverage of the target requirement will be marked as incomplete. If a code branch is not covered by any verification test cases, the chip design requirement corresponding to that code branch is located by reverse tracing and marked as an uncovered requirement.
9. The chip completeness verification method based on bidirectional traceability of requirements and use cases according to claim 1, characterized in that: S5 includes the following sub-steps: S51. Assign different system operation permissions to different team members; all teams can access the chip design requirements database, verification test case library, requirement-test case bidirectional traceability matrix, and coverage data through a unified web access interface. S52. Automatically record all user operations on the system platform to form a traceable operation log; S53. Once all verification test cases associated with a chip design requirement have been verified and met the standards, an automatic notification of requirement verification completion will be sent to the requirement team to synchronize the verification progress.
10. The chip completeness verification method based on bidirectional traceability of requirements and use cases according to claim 9, characterized in that: The system operation permissions for the requirements team are: the ability to add, modify, and delete chip design requirements data; the system operation permissions for the verification team are: the ability to add, modify, and mark the status of verification test case data; and the system operation permissions for the design team are: read-only viewing permissions for chip design requirements data, verification test case data, and coverage data.