Traceability and Design Verification Synergy

The IC design and verification process can be comprised of many independent point tools, or for more synergy you can have tools that work together by a more synergistic process. We’ve all heard the maxim, “Work smarter, not harder.” A white paper just came out from Methodics on a smarter approach, Traceability for the Design Verification Process, so I’ve taken the time to read the 9 pages and then present my findings. The three activities in electronic systems that can be smartly made to work together are:

• Requirements Management
• Design Management
• Verification Management

When you’re designing something safety critical then you’re likely following a standard like ISO26262 and DO-254, where traceability is part of the FuSa specifications. In a utopian world you could follow a linear process, like:

1. Write requirements

2. Perform design

3. Verify that the design meets requirements

4. Ready for production

In reality, we have iterations between step 3 verification and step 2 design, and even from verification back to a change or clarification of the requirements. Remembering what has been verified and on what version of iteration it happened is critical for a smart work flow, so traceability matters a lot.

At the start of an electronic system design the verification of the design is happening in parallel with the actual design, while later on in the process the design has settled down and stopped changing so there’s a shift to completing all verification work, resulting in bug fixes or performance tweaks in order to meet the specifications. So throughout the verification process a smart flow will be able to track each design release with specific verification results. With such traceability your team can reproduce a bug condition and verify that the design fix now passes all regression tests.

In the first diagram shown above you can see the three inter-related activities: Requirement management, Design management and Verification management. What ties all of these activities together is the Percipient tool, because it’s an IP Lifecycle Management platform (IPLM) that can manage IPs, workspaces and verifications. In Percipient you define a project release and that includes all of the IP being used, plus verification tests and results. This is also called the Bill of Materials (BOM).

With Percipient there’s a traceable path from requirements to both design and verification, so when there’s a change in requirements then you know which parts of the design and verification need to be updated as well. Workspaces are built and managed with Percipient, so it always knows with each release what the top-level IP and all lower-level IP blocks are, along with the dependencies. As your team runs verification tests they are kept track of by this IPLM framework, along with release tracking. Here’s a diagram of a design hierarchy and test frame to show the interactions that are tracked by Percipient:

In the lingo of Percipient all of the design blocks, even new content, are called IPs in the workspace. When a test frame runs then this workspace keeps track of that run and the verification results. Instead of relying on human memory about which tests have been run on each IP or workspace, the Percipient tool is doing the verification tracking for us, leaving kind of an audit trail as shown below:

With this methodology you will know the version of the top IP in your workspace, the user running each test, the status of the test, how much run time it took, and any extra arguments that were passed to the test. Each team member using this tool flow will automatically have their verification activities stored by default, then the results can be retrieved as needed.

The automatic benefit of verification traceability means that you can track which tests were run in each workspace created with each release, and know which engineer ran the test. There’s no ambiguity about what tests have been run and verified on your project.

Let’s say that your team is building an electronic system for automotive use and that you will adhere to the ISO26262 requirements, providing proof about:

• Known versions of all IP blocks
• Design content of each IP by version
• All tests run and passed on all IPs, per version

If it took 10 versions to achieve a stable design that met all of the design requirements, then we know that the “IP Tree” of version 10 has a top-level IP in Percipient with all of the hierarchy and low-level IPs. All IP contents as files and versions are cataloged. Verification records detail all the tests and results that passed with version 10. This list can be output from Percipient as a PDF document using a standard format like DITA.

Conclusion
Work smarter, not harder. When it comes to designing electronic systems for FuSa markets you should consider using a tool like Percipient because it connects together requirements management, design management and verification management in a work flow that doesn’t slow down your engineering staff. You get traceability automatically with Percipient, so both design engineers and verification engineers are working toward a common goal by using a single source of truth.

Read the complete White Paper online here.

Related Blogs

• How Well did Methodics do in 2018?
• SoC Design Partitioning to Save Time and Avoid Mistakes
• Using IP in a SoC Compliant with ISO 26262
• IP Management Using both Git and Methodics