RE: [sv-ec] FWD message from Jonathan: Mantis items 2987, 2988,.3003 (constraints)

As Tom knows, we have a user who also says that soft/default constraints are his top problem.

Shalom

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Mehdi Mohtashemi
Sent: Wednesday, July 14, 2010 8:52 AM
To: sv-ec@eda.org
Cc: Jonathan Bromley
Subject: [sv-ec] FWD message from Jonathan: Mantis items 2987, 2988,.3003 (constraints)

forwarding message from Jonathan to the reflector regarding Mantis items
2987,2988 and 3003.

From: Jonathan Bromley [mailto:jonathan.bromley@verilab.com]
Sent: Tuesday, July 13, 2010 2:55 PM
To: Mehdi.Mohtashemi@synopsys.COM; thomas.r.alsop@intel.com
Subject: Fwd: [sv-ec] Mantis items 2987, 2988,.3003 (constraints)

Mehdi, Tom,

Please accept my apologies for intruding on your personal email.
I am still having some trouble sending to the SV-EC reflector.
Could I ask you to forward this to SV-EC, since a good fraction
of the participants expressed interest in the discussion?
I see all the sv-ec traffic, but at present I can't send mail
to the reflector - I'm working hard to get that fixed.

We were asked to look at the following Mantis items relating
to constraint enhancements. They are quite distinct, but they
all address a closely related set of usability problems. Here
is a brief summary to open the discussion.

2987 asks for the addition of soft constraints.
2988 requests default constraints that can be superseded by others.
3003 relates to constraint composition - in particular, applying
constraints from one object to the randomization of another.

Soft constraints exist in, and are a vital part of, the 'e' language.
A soft constraint is honored by the solver unless it contradicts
another constraint (whether hard or soft) that has been applied
"later", in which case the original offending soft constraint is
completely ignored. In 'e', "later" means further down the
inheritance/extension tree, and 'e's equivalent of "with" constraints
form leaves of that tree and therefore have the highest precedence.
I understand that at least one SystemVerilog simulator
has implemented something very similar as a proprietary
extension, but I'm not familiar with the details. I don't
know whether this proprietary solution might be available
as a donation.

Default constraints provide another way to deal with the same
usabllity problem, allowing writers of a base class to specify
a constraint that can be defeated by another constraint. This
is not especially interesting in the context of class inheritance
because of course you can in any case replace a constraint
in some derived class. It is particularly interesting if you hope
to put the overriding constraint in a "with" clause; there is
at present no convenient way to do this in SV. One obvious
possibility would be to allow "with" constraints to include
constraint_mode() calls; another would be to have named
constraints in "with"; yet another might be to find a way to
specify that a "with" constraint should take precedence over
any existing constraint with which it conflicts. A crucial
aspect of all this is the need to resolve what happens when
more than one "dist" constraint applies to a given variable,
because many of the existing attempts to work around this
problem depend on creative uses of "dist". Removing the
current rule whereby a "dist" weight of zero actually constrains
away its solution could also provide a useful get-out.

Finally there is 3003, constraint composition. I have not
yet seen anything that gives me a really clear idea of what
could be done here, and it would be good to see some
discussion from the experts. It seems to me that attempting
to capture a set of constraints in one class and then applying
them to an object of a different class is remarkably similar in
spirit to the "interfaces" (Java-like) style of multiple inheritance,
and perhaps should be considered along with that.

These are non-trivial changes, and for all of them I would like
to see much more discussion before we try to frame any
proposal. Does anyone have particularly strong feelings
about what is or isn't practicable? From my viewpoint as a
user, lack of soft or default constraints is the top usability
problem with SV-testbench right now. Any change that
provides the ability to defeat existing constraints from
a "randomize with" would make my day.

Thanks

Jonathan Bromley

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.