DesignPSL (Product Datasheet)

The centerpiece of Assertive Design's tool suite is DesignPSL. DesignPSL is a new Design Language built from the ground up to provide RTL designers with the control they need while capturing their intent to allow for automatic assertion generation.

These automatic check and coverage assertions are what allow DesignPSL to provide a 75% reduction in RTL development and debug. Designers get bug feedback immediately, Verifiers are redirected to high-value system level verification and DesignPSL tracks coverage to allow both to understand what is and is not tested.

Contents:
History
Problems & Solutions
Assertion Theory
Assertion Practice (Not Catching On)
What is Wrong?
What Happens Instead?
Lesson Learned
The Result

History:
Existing Design Languages have evolved over many years from modeling languages. Verilog and VHDL predate "synthesis" and were original created to "model" digital logic.

RTL synthesis brought a new rapid design approach, but worked backwards from what the models described. A sub-set of Verilog/VHDL became "synthesizeable."

The remaining capabilities of these languages which were not synthesizeable continued to evolve for verification/modeling leaving us with 2 languages in one with newer variants (systemVerilog) adding even more "languages" into the same tool.
(top)

Problem	DesignPSL Solution	Alternate Solution?

Verilog/VHDL synthesizeable sub-set loses designer intent	Capture Intent immediately by structuring language to do so from an RTL-level description	Require Designer to further qualify design description with new language constructs or more abstract descriptions

"Further Qualifications" require 2 models: a. RTL - b. Assertions as constraints	Generate Check Assertions Automatically from RTL description	Learn/Use new Language constructs to help Designer do this additional work

Need to know what has been covered well beyond simple line/toggle coverage (a third "coverage model" is required)	Generate Cover Assertions Automatically from RTL description	Learn/Use new Language constructs to help Designer & Verifier do this additional work (build third model)

Verifiers take too much time to check ballooning permutations of large designs	Automatic assertions make modules self-checking, verification focuses on system-level functionality	Learn/use new language constructs for incremental efficiency gains, write more verification code, but do it faster

If you write your own assertions, they must be kept up-to-date	Automatic assertions updated with every design change - just recompile	Learn/use new language constructs, write more code, keep track of it manually

Need to measure assertion efficacy	Statistic for generated assertions reported with each run - total/exercised/fired	Manual review

When debugging a failure, root cause must be determined	Automatic Assertions show file, line and column in YOUR RTL source of a failure	Reverse engineer your own code, work backwards to root cause

Manually generated assertions show that the assertion fired, but are not tied to RTL	Automatic Assertions show file, line and column in YOUR RTL source of a failure	Read comments around assertions to correlate back to source intended to be covered by a given assertion

(top)

Assertion Theory:
Assertions methodologies, in theory, describe a very powerful way to approach your design process:
- Instrument your design to tell you whenever it deviates from your expectations
- Stimulate the design, perhaps randomly
- Wait for assertions to indicate that a deviation between the design and expectation occurs
- Use Coverage assertions to measure test completeness

This Methodology as widely understood to provide an improvement over more directed methodologies which strive to intentionally reach every possible mode of a device and check the result. The number of permutations in a typical design is so large, that unfortunately, it is no longer practical to imagine exercising every mode of operation in a directed fashion in a timely manner.
(top)

Assertion Practice (Not Catching On):
However, assertion methodologies have failed to catch on. Even with the demonstrable benefits, most design teams are still struggling with the dual requirements of meeting schedule and producing a design that meets its specification. Assertion use is limited to "hundreds" in most cases and a "few thousand" in the best of cases.
(top)

What is Wrong?:
The Burden falls almost entirely to the designer. The Verifier generally is not sufficiently familiar with the details of the implementation to instrument it with assertions. While they can instrument system-level requirement checks, the real power of assertions comes from having a design "soaked" with assertion so that even the most subtle of deviations is trapped immediately.

This leaves the designers as the "Right" choice to generate the assertions, but for them it is a thankless and seemingly redundant task. The end result is that it does not get done. If it gets done at all, it does not get maintained throughout the project.
(top)

What Happens Instead?:
More IP re-use, less innovation. The obvious solution to having too much new functionality to verify, is to create less new functionality

The trouble is that this line of thinking while attractive for the near term, leaves formerly innovative companies with nothing differentiating them from their competitors who purchased and used the same IP.
(top)

Lesson Learned:
Assertion methodologies are very powerful, but the assertion generation needs to be:
- Objective - Until the device is tested, you don't know what works, you need to assume the worst and have checks everywhere - Complete - See above - Up-to-date - If the design changes, so to must the assertions

DesignPSL accomplishes this by fully automating this process. Inferring from the RTL design itself what every possible mode of failure might be and instrumenting them with assertions. Further, it looks at every possible correct mode of functionality and instruments that for coverage.
(top)

The Result:
DesignPSL Generates more than 1 assertion per line of source. Every conceivable failure and function mode is instrumented to ensure that it functions as desired. Any deviation is trapped immediately as a failure and reported.

The Designer sees trivial functional bugs as if they were syntax errors (right away with minimal if any testing). More complex errors are caught with stimulus but reported equally obviously at their root cause.

Automatic Functional Coverage means:
- The Designer debugs with information of what the chip has done right and wrong at the same time
- Manager and Designer get unparalleled visibility into verification progress
- Testing can dynamically incorporate functional coverage data to steer stimulus without writing coverage assertions or managing them when the design changes
(top)