This is the Verisium Manager (formerly known as vManager) instance, used purely for verification tests. The verification team receives a requirement document—an external document published by the requirements team—and uses it to write tests. In the planning section, no sections or requirements are displayed. However, in Jama, all the requirements are defined.
In this demo, all these requirements will first be integrated into Verisium Manager, after which regular integration will begin, enabling both teams to collaborate seamlessly in near real-time. Let’s quickly review the requirement hierarchy in Jama. At the top level, there is an interconnect requirement, followed by power estimation, and beneath that, the full chip use case for power estimation.
To demonstrate, I will bring up one requirement to show its history. In this demo, not only will the current state of the requirement be transferred, but the entire history from Jama will also be retrieved, allowing the Verisium Manager team to view all activities that were performed in Jama. Updates to vendor descriptions, the title, the status, and other details will be available.
Here is the full chip use case for power estimation. By right-clicking on activities, you can view actions taken by users, such as the status being moved from approved to in-progress. There were also changes made to the description before that, and the status was modified from draft to approved, followed by its initial creation.
In the first phase of the demo, the initial load (or first set of integration) will be triggered to transfer the requirements from Jama to Verisium Manager. This may take a minute or two for all the requirements to be integrated. Let’s wait a moment and check Verisium Manager to see if the requirements have started to populate. Upon refreshing the view, several requirements are already populated. The hierarchy is now visible in the connected part of the tool. I’ll refresh again to ensure that all requirements have been loaded into Verisium Manager.
As evident, the full hierarchy is now present. As seen in Jama, the interconnected requirement is listed with power estimation, the full chip use case, and all other requirements, just as they were defined in Jama. I’ll bring up the full chip use case for power estimation, and its description is intact, exactly as it was entered in Jama.
Now, if the history for this requirement is opened, all updates from Jama are visible. Each update to the status in Jama has been replicated in Verisium Manager. This is one of the unique features of OpsHub integration—replicating all history between the tools. Initially, the requirement was in draft status, then moved from draft to approved, and finally to in-progress. The same level of detail is available for any other field.
Once the requirements are available in Verisium Manager, the verification team gains near real-time visibility into the current status of each requirement. They can then begin writing verification tests directly linked to these requirements. Let’s create a metric report for the full GPU use case for power estimation. This is the first test case being created, and it will be mapped to some actual regression tests.
Here, the APB is mapped to the UR one-stop for this topic. Next, we’ll create another metric report. Let me choose another child requirement and create it under security verification. This metric report is created. We’ll then map this report to a different regression test.
These two metric reports will now be integrated into Jama as verification items, linked to the same requirements as they were in Verisium Manager. The requirements team gains full visibility into the verification tests being performed against each requirement, and as the tests are developed, they can provide feedback and collaborate in real-time with the verification team. Let’s go to Jama to check if the test cases have been integrated. Upon refreshing the view, verification items under the full chip use case and the second test case (added under security verification) are now visible.
The product team will now review the test cases and make necessary changes to the requirement description. If there’s any gap, they will modify the description and save it. Once the product team has verified the test case, they will mark it as “in-progress,” indicating approval and that work can begin. These changes will also be replicated to Verisium Manager, where the verification team should see the updated requirement and test status.
Returning to Verisium Manager, the updated changes are now visible. The product team has updated the full chip use case for power estimation. If we examine the details for this requirement, benchmarks have been added, and the status of the stop bits test case should now be in-progress.
Now, the verification team will execute the test case and perform grade analysis. Clicking on the button will populate verification results for all metric ports and requirements. Let me sync the data. Verification results are now updated for all metric ports and requirements. For stop bits, the overall average upgrade is 100, with 6 past runs and no failed runs.
These details will now be synced to Jama and rolled up to the parent requirement, just as they appear in Verisium Manager. Let’s refresh Jama to check the verification results. By going to the parent requirement, results for all linked requirements are visible. The interconnect requirement now shows consolidated, aggregated results.
Beneath the interconnect requirement, power estimation shows the full chip use case has passed, while thermal security and security verification failed. Therefore, the overall status for the interconnect requirement is marked as failed, with the average results being aggregated. The requirements team now has full visibility into the verification status.
Assuming the full chip use case for power estimation passed, it will be transitioned to the “closed” status. This marks the final sign-off from the product team. Looking at the test case status for the full chip use case, the status in Jama will be updated to “done.”
Let’s go back to Verisium Manager to check if the status is reflected there. After resynchronizing, the status is now “Done,” indicating the closure of the requirement. For failed requirements, the verification team can continue retesting or address any necessary fixes.
This demonstrates how integration enables real-time collaboration. Thank you for watching the demo.
