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 : 20But the precedence order is different and this expression is actually evaluated as:
(x==y) ? 10 : 20which 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.
<script type="IN/Share" data-counter="right"></script>