Get email delivery of the Cadence blog featured here
If you've run simulation, you have probably used scoreboards to check that outputs properly match inputs. As revealed in a newly archived webinar, there's an easy way to use scoreboards with formal verification. It requires a slightly different methodology, but it turns out to be a good way to quickly find data transport bugs.
The webinar, titled "Quickly Find Data Transport Bugs with Formal Scoreboarding," was presented Nov. 17, 2011 by Joerg Mueller, solutions engineer at Cadence. It's available on demand to Cadence Community members by registering here.
At the start of the webinar, Mueller noted the "conventional wisdom" that formal verification works for control logic but not at all for datapath. The fallacy, he said, is that people who make that claim aren't distinguishing data transport from data transformation. While data transformation continues to be difficult for formal technology, "data transport is a sweet spot if you apply the right methodology," Mueller said. Scoreboarding is a classical approach to datapath checking, and a modified approach to scoreboarding enables formal tools to find data transport errors.
In simulation, a scoreboard samples all input values, stores them in a tracker, and then checks the output for matches of tracked input values. If an output value does not exist in the tracker, there's a bug. At the end of the simulation the tracker should be empty.
While this methodology works well for simulation, it results in too many input values for a formal verification tool. A simulator can handle a flexible variable list, but a formal tool needs a fixed-size list. Thus, the approach described in the webinar tracks symbols rather than values. The tool selects one arbitrary input value, chosen to trigger failures, that is represented as a "symbol." The scoreboard checks the output for matches of the tracked input symbol. One symbol represents all possible values, in all possible locations, under any possible condition.
Mueller showed how this approach can be applied to datapath checking using a liveness check ("what goes in must eventually go out"). Such a check will find data loss and corruption errors, but miss data ordering and creation errors. There are also potential capacity and performance "gotchas" with this kind of check. One solution is parameterization (reduce datapath depth and width) and check reduction (reduce check width).
Sequences of Symbols
Another alternative is to use safety properties instead of liveness properties, and to apply sequences of symbols. Here, you force (constrain) a sequence of input values and check (assert) that the same sequence will occur at the output. Mueller reviewed several different types of sequences. For example, a sequence with two consecutive symbols can find errors due to data loss, manipulation, creation, duplication, or data reordering. This approach "provides all the verification capabilities of a full-fledged simulation style scoreboard, but the formal tool has only to work with a single symbol storage," he said.
Mueller showed how users of the Cadence Incisive verification platform can access these capabilities today with the Incisive Formal Scoreboard, included in the Incisive 10.20 s100 release. It provides datapath checking, including liveness and sequence checks, and it works with both formal and assertion-driven simulation. "Data transport verification is a great target for formal," Mueller concluded.