Debugging Verification Constraints

In his DAC keynote last year (2012) Mike Mueller of ARM compared how much CPU was required to verify the first ARM versus one of the latest ARM Cortex CPUs. Of course the newer CPU is hundreds of times larger than the first ARM but the amount of verification required was millions of times as much, requiring ARM to construct their own datacenter outside their office buildings. The reasons are two fold. Firstly, verification suffers from a sort of combinatorial explosion: verifying just doesn’t scale linearly with the size of the design because the number of interactions goes up closer to exponentially. The second reason is that we switched from directed verification (where all the vectors were written by hand) to constrained random verification, where we use random verification to substitute computer power (cheap) for brainpower (expensive) and then use constraints to keep it under control (stop duplicate verification) and expand coverage to areas that were not exercised. This allows us to expand the amount of verification in large systems…but not too much (a good thing).

A second thing that has happened with the development of Universal Verification Methodology (UVM) and the growth of the Verification IP (VIP) business is that much of the verification code was not written by the verification engineer. It comes from other groups in the company or from 3rd parties.

All these together mean that designs now can have 50-100K lines of constraints which leads to performance issues. The constraint solver under the hood of Synopsys’s verification environment has been improved and that has sped things up, sometimes by as much as 25 times but more often just a factor of 2.

But the big problem is now debugging constraints. When the simulation doesn’t do what you expect, then it can be a problem with the constraints. There are three big areas where problems occur:

• randomization failure due to inconsistent constraints
• unexpected solutions from the solver
• unwanted solution distribution

Jason Chen, a CAE in the verification group at Synopsys, presents a webinar on how to use the latest VCS verification environment to debug constraints in a more efficient way, often without requiring recompilation (which for a large design makes the whole process a lot nimbler).

The first thing is the capability to set solver breakpoints: when certain things occur in the solver then the simulation is halted and control is in the debug environment allowing a deeper investigation at just the point of interest. For example, an unexpected solution from the solver.

I’m not a verification engineer but as a C-programmer (well, an emeritus C-programmer) I can sympathize with a problem like this (where the assumption is that if y is 1, x is 10 otherwise 20):x == y ? 10 : 20

But the precedence order is different and this expression is actually evaluated as:(x==y) ? 10 : 20

which doesn’t constrain x at all.

Another significant future problem that is going to occur is that there are now (new! improved!) soft constraints that can be honored or dropped depending on whether they cause consistency problems. Of course, if you write a constraint it is pretty important to know if it is being honored and is actually being used in the verification, or dropped and contributing nothing.

Another feature that improves efficiency is on-the-fly re-randomization. You can make changes to the constraints (such as disabling a constraint block) and then re-randomize without requiring a recompilation or a restart of the simulation. This lets you zoom in on the cause-effect relationship immediately.

The link to the webinar is here.