[sv-ec] Soft Constraint - more details and examples

Hi Everyone,

Here are some examples for soft constraints to discuss today. I'll add this to the mantis item.

-Tom

Example #1:

Hi Tom,
Since our testbenches were in SV, and SV doesn't support soft constraints, this is similar to the hoops that we had to go though...

rand cmd_e cmd;
rand bit use_invalid_cmd;

constraint use_invalid_cmd_c {
  allow_invalid_cmd dist {
    0 := 64'hFFFF_FFFF_FFFF_FFFF,
    1 : = 1
  };
  (allow_invalid_cmd == 0) => cmd inside {READ, WRITE, MSG}
}

If a test writer wanted to allow an invalid command, calling randomize() with {}, they would need the following code:

xaction.randomize() with {
  allow_invalid_cmd == 1;
  cmd dist {
    READ := 30,
    WRITE := 30,
    MSG := 19,
    INVALID := 1
  };
 };

In the above example, we couldn't put a distribution directly on cmd, heavily weighted against INVALID, because SV doesn't provide a good definition of what happens if you have multiple distributions defined for the same variable (one in the base class, and another in a derived class or with {} clause). There are other ways of doing the above (disabling constraints prior to randomize) but they wouldn't have worked in our environment where the randomize() with {} code was generated from a macro. For our purposes, any method of disabling/overriding a constraint from inside a with {} clause would have been sufficient.

Example #2:

Hi Tom, I've attached an email of mostly single line examples I pulled together in the past. Not much explanation ... hopefully they don't need much.

I will say that the implication form ( => ) would likely be more prevalent in SVTB because in e it is fairly common to find soft constraints within a "when" extension, and many of those would likely need to be converted to conditional soft constraints using implication in SVTB.

Attachment:

Here are some single line examples of soft constraints that don't map to a single initial value or a basic distribution constraint (soft select in e) - I don't know SVTB well enough to say whether they can easily be translated to it. Also I will say that "default" value usage is the most common, but some of these cases get real benefit from the soft constraint.

Identifiers in all capitals are constant values (enum values or #define values) while identifiers in all lower case are fields that participate in generation (unless within read_only() in which case considered an "input"). Let me know if you want more context for any of them:

(talsop note - These soft constraints are pulled from 'e' files used at Intel). I don't understand 'e' well enough so hopefully someone on the call today can explain them. Else I have to go back to the contributor. :))
  keep soft modify_exclusive_line_delay < 200;
  keep soft gen_mpl_cachelines_factor in [2..6];
  keep soft reqtype not in [WB, UNC_LOCK, UNC_UNLOCK];
  keep soft target not in [SQFENCE, DUMMY];

  keep read_only(fetch_test_cachelines in [SOME,NO]) => soft ifu_cacheline_addr_l.size() in [1..100];
  keep !cfg_allow_demotion => soft cfg_allow_promotion == select { 99: FALSE; 1: TRUE };
  keep soft (fuse_dcu_mode == NORMAL) => (fuse_dcu_mode_val == 0);
  keep soft (reqtype == UNC_LOCK) => (attr.split == 0);
  keep (dl1_state in [E,M]) => soft (mlc_state in [E,M]);
  keep soft kind in [LOAD_TICKLE,STA_TICKLE] => addr_kind in [LINEAR,PHYSICAL,GUEST_PHYSICAL];

  keep soft valid != global_page;
  keep soft ml4_cr_sq_ctl__fillhigh_threshold > ml4_cr_sq_ctl__filldrop_threshold;
  keep (dcu_cr_mc1_cet_vs_cecnt == EQ) => soft (dcu_cr_mc1_misc2__cet == dcu_cr_mc1_status__cecnt);
  keep (dcu_cr_mc1_cet_vs_cecnt == GT_NEAR) => soft ((dcu_cr_mc1_misc2__cet > dcu_cr_mc1_status__cecnt) &&
                                                                           (dcu_cr_mc1_misc2__cet < dcu_cr_mc1_status__cecnt + 5));

  keep soft linaddr[20:0] == 0; // linaddr is 48 bits
  keep (access.register == CTAP_CR_PROBE_MODE) => (soft access.data[0:0] == 1); // data is 64 bits

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.