Soft constraints override rules

I have one config class inheriting from a base class and extending some constraints:


class config_base extends uvm_object;

  rand int unsigned sync_time_min;
  rand int unsigned sync_time_max;

  constraint sync_time_c {
    soft sync_time_min == 5; // ms
    sync_time_min <= sync_time_max;
  }

endclass

class config_extended extends config_base;

  rand bit extended_sync;

  constraint sync_time_extended_c {
    if ( extended_sync == 1) {
      soft sync_time_min == 50; // ms
    }
  }

endclass


My questions would be:

  1. would both constraints be applied?
  2. is there any ‘solve/before’ constraint I need to add to get sync_time_max above sync_time_min when using config_extended and ‘extended_sync = 1’?
  3. is sync_time_extended_c overriding sync_time_c even when extended_sync is not 1?

I’m trying to trace an issue in my config setup, it seems some of the constraints are not applied and I’m not sure why.
Thanks in advance for your support.

Al

In reply to abs:
Your answers are:

  1. Both constraints apply because you gave them different names.
  2. Solve/before constraints are not really constraints, they just affect the distribution of chosen values. See this link.
  3. All constraints are enforced. Your problem is that soft constraints do not get removed unless there is a conflicting constraint. As long as extended_sync is 0, there will never be a conflict.

I’m not exactly sure what your requirements are, but you probably want:

class config_extended extends config_base;
  constraint sync_time_extended_c {
    disable soft sync_time_min;
    soft sync_time_min dist {5, 50};
  }
endclass

I would limit the use of soft constraints as they become hard to rationalize as your simple test case demonstrates.

In reply to dave_59:

As long as extended_sync is 0, there will never be a conflict.

that means that sync_time_min will still be set to 5. But in my actual code (much more complex than the example reported here) it seems to me that my base class constraint is not taken into account.

I would limit the use of soft constraints as they become hard to rationalize as your simple test case demonstrates.

Unfortunately we have soft constraints all over the place and I fear that some weird interaction is leading to the unexpected behavior above mentioned.