Debugging constraints with tcl interactive debug mode

You've asked this in a forum related to questions and suggestions about the forum itself, so you wouldn't expect to get answers to technical questions. I'll move this to a more appropriate forum.

Thankyou Andrew.

I've found the solution but it has some limitations. 

stop -create -randomize -always

The above command will always create a breakpoint when randomize() is invoked. At this point the scope is " top.c1@1_1.randomize "

Now we can disable the constraint using  'deposit -constraint_mode con2 = 0 ' ( I dont see any warnings now )

The only issue is the constraint is disabled in the next randomized call. check in the attached snapshot below.

Is there any workaround to disable the constraint at the specific instance?

Your initial problem was because you hadn't stopped inside a randomize call. The Tcl command for adding constraints is design to help debug randomize calls, so the idea is that you either stop on a randomization failure breakpoint or by single-stepping the source code and stepping into a randomize call.

The Tcl constraint works for adding a constraint in that particular call, so that you can spin round trying new constraints until the solver gives you an acceptable answer.

The feature wasn't designed as a generic way to write additional constraints, if you want a more permanent constraint then you need to add it in the SV code itself.

It makes sense as we use debugger mostly when something is failing. And here are my takeaways from this experiment

When the ranodmize() is failed, disabling the constraints will take effect on the next call. (run -rand_solve helps us to knows if solver is successful after changing the constraints/disabling)

Constraint_mode() has higher priority over rand_mode() in xcelium tool. Assume we have conflicting constraints on a variable. and we deposit rand_mode is made 0 for that variable and when we do a randomize() call we get SVRNDF randomize method call failed. If we deposit constraint_mode() to 0 we should not see any errors.

Nope, there is no "priority" between constraint_mode and rand_mode. In a SV randomize call, ALL the constraints have to be satisfied, even if all the variables have their rand_mode set to 0 (i.e. they are state variables). If you've turned off rand_mode for a variable, then its current value is used when testing the constraint, and if that value prevents the constraint fro being satisfied, then you'll get a randomisation failure error. This is not specific to Xcelium - all SV simulators should follow the exact same rules because this is clearly defined in the SV standard.

Here's a trivial example:

class c;

bit a,b; // non-rand state variables

constraint will_fail { a != b; }

endclass

If you randomize the above class, the constraint cannot be satisfied by the solver because a and b start with the value 0 and they are not rand variables thus the solver cannot change the values. However if you changed a to 1 then called randomize, the constraint would be satisfied and the call would succeed.

You're right. Thanks for the help.