Improve or Enable

New tools, languages, or methodologies can be an improvement over existing ones, or they can be enablers for something different. The recently approved Accellera Portable Stimulus Standard (PSS) can be either or both.

A lot has been written recently about how PSS can be combined with constrained random verification methodologies and that demonstrates the improvement aspect of the language.

It is to be expected that the major EDA companies are focusing on this because it gives them a good story to tell their existing verification users and an incremental sales opportunity. It also allows them to increase the value and differentiate their existing products from those of the competition, providing a strategic scaling opportunity. Unlike existing verification technologies that have been commoditized, PSS is still in its infancy and they can employ some degree of creativity in this space.

Breker has also been actively pursuing these opportunities and has had many successes against its offerings.

PSS is more than this – it is an enabler that can completely change the way that aspects of verification are performed and will quickly become required for some flows. Consider the automotive industry, where standards such as ISO 26262 set the bar for how the safety aspects of a design have to be demonstrated.

ISO 26262, while not mandated by any government, is seen as mandatory by most of the automotive industry. Simply put, if their vehicles are found to be defective, they are potentially liable to lawsuits. ISO 26262 defines the best practices in the industry, and if they can demonstrate that they were adhered to, that may limit their liability. Not surprisingly, they have forced their IC suppliers to adhere to this standard.

ISO 26262 establishes the minimum necessary goal that must be attained. Everyone understands that ISO 26262 is not “current” best practices, but those in use when the standards effort started. By the time it was released, the industry had advanced, and new best practices developed, that will ultimately be adopted by ISO.

PSS directly plays into this because it provides a different way to look at and approach safety verification. Whenever there is a need to verify that a requirement has been satisfied, the test or tests that demonstrate that must be documented on an individual basis requirement by requirement. There are two ways using existing methodologies: either using constrained random and associate some aspects of functional coverage with it and then show which randomly generated tests happen to add to those coverage goals; or hand write a directed test that targets that requirement.

Neither of these solutions are even close to being ideal. Both are inefficient and somewhat ineffective methodologies for that task.

With PSS-based technologies, it becomes a different task. A requirement can be broken down into either an end point or a path through a graph representing an intent specification for the entire block. If the requirement is something like “a system must be capable of displaying an image,” then the display is set as a goal in PSS and a tool can explore all of the paths that are capable of making that goal happen. If the requirement is more specific, such as “it must be able to display an image from a SD memory card,” that places constraints on the paths through the graph that can be selected. In this case, two points were selected and now only those complete scenarios that pass through those two points will be selected.

Given a PSS graph model, it can now be shown exactly which tests show the requirement to be met. Furthermore, coverage of these exact tests can be measured and reported directly against individual requirements, using coverage paths across the graph, as required by ISO 26262. This is not vendor specific, which constrained random tests are. The graph becomes an integral part of the documentation and is portable among tool vendors. This has rapidly become a required method to demonstrate systematic completeness of the design process. The Breker solution to this was contained within a white paper published in September 2018, and is available at brekersystems.com.

Some companies that have adopted PSS for this application are also defining methodologies that extend beyond traditional verification into areas such as demonstrating operational safety. This is associated with ensuring that a system continues to operate even when internal components fail through environmental or malicious activities.

Detecting random failures requires the injection of faults into the design to ensure that it always results in a safe outcome. To do this using existing technologies requires running gate-level fault simulation and complex statistical analysis to reduce the total number of faults that need to be considered. It is a long and lengthy process and has to be conducted on the complete system. The composable nature of a PSS graph leveraging cross scenario constraints to target specific safety handling mechanisms may make this problem more tractable.

Consider that the same verification models can be used across a hierarchical flow. The graph developed to verify an RTL block can be reused to verify it once it has been synthesized and is running on an emulator. If it can be demonstrated that all faults are detected within the block using particular paths through the graph, that information can be directly raised to the integration level. It should no longer be necessary to run the gate-level model for that block within the system simulation. Instead, using RTL or some higher abstraction should suffice, so long as they exhibit the same behavior.

Given the modular nature of how portable stimulus scenarios can be implemented,  verification graphs for the blocks can be assembled into the graph for the sub-system or system without modification. It is known which paths through which blocks have to be contained within top-level scenarios to fully expose the detection of all faults in each block. If an error detection mechanism is considered to be an IO port of the block, then at the highest level, these become the primary places on which the random errors need to be injected. It is the collapsed representation of all the faults within the block.

Has such a methodology been fully developed and proven? I am not sure. This is a thought experiment as to what becomes possible when looking at capabilities and methodologies enabled by PSS. This is how PSS becomes an enabler – when it transforms what was an almost intractable problem into something that becomes addressable with finite resources.

We are working with companies to tackle problems such as this and will ensure that our tools enable innovative methodologies to be developed. Together we can do this.

Tags: Accellera, Breker, Breker Verification Systems, ISO26262, portable stimulus, PSS, PSS Graphs, RTL

This entry was posted on Thursday, April 18th, 2019 at 1:30 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.