[sv-ec] Re: soft constraint proposal

Ok, got it
Thanks

From: Arturo Salz [mailto:Arturo.Salz@synopsys.com]
Sent: Monday, September 26, 2011 12:38 PM
To: Miller Hillel-R53776; 'Dhiraj.Goswami@synopsys.com' <Dhiraj.Goswami@synopsys.COM>; 'Arturo.Salz@synopsys.COM' <Arturo.Salz@synopsys.COM>; 'sv-ec@eda.org' <sv-ec@eda.org>
Subject: RE: soft constraint proposal

Hillel,

The scenario you describe is not compilation order dependency. Also, the only way that such a scenario could affect the priority is if someone intentionally split a container construct (class, struct, or constraint block) across multiple include files (which IMHO is already a pretty bad idea) and the chose to include them in a different order. Note that the declaration order of the container itself (e.g., class) is not relevant to the priority. But, if someone chose to do that then presumably one testbench would exhibit a set of priorities different from the second testbench. However, that priority would remain the same, regardless of the compilation command used to build the two testbenches.

                Arturo

From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
Sent: Monday, September 26, 2011 10:26 AM
To: 'Dhiraj.Goswami@synopsys.com'; 'Arturo.Salz@synopsys.COM'; 'sv-ec@eda.org'
Subject: Re: soft constraint proposal

Can you explain why we are compilation order independent?

What if the constraints are in include files and two different testbenches include the files differently.

Thanks

From: Dhiraj Goswami [mailto:Dhiraj.Goswami@synopsys.com]
Sent: Monday, September 26, 2011 11:53 AM
To: Arturo Salz <Arturo.Salz@synopsys.COM>; Miller Hillel-R53776; 'sv-ec@eda.org' (sv-ec@eda.org) <sv-ec@eda.org>
Subject: RE: soft constraint proposal

The priority has been defined in such a way that it is independent of compilation order as well as compilation scheme. Debugging will depend on the capability of the tool.

Regards,
Dhiraj

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Arturo Salz
Sent: Monday, September 26, 2011 9:29 AM
To: Miller Hillel-R53776; 'sv-ec@eda.org' (sv-ec@eda.org)
Subject: [sv-ec] RE: soft constraint proposal

The issue of ordering exists because of the definition of soft - since they can be overridden, we must define a priority.

The problem with an explicit ordering is that creating such an ordering would put all the burden on the users. It would make the syntax more complex (require the priority) and would make soft constraints even harder to use. Plus, we would also still need to determine an implicit ordering for all constraints with the same explicit priority. The current conceptual model of having constraints override “earlier” constraints seems to fit well with the existing expectation. Incidentally, I don’t believe compilation order plays a role in the ordering.

                Arturo

From: Miller Hillel-R53776 [mailto:r53776@freescale.com]
Sent: Monday, September 26, 2011 6:01 AM
To: Arturo Salz; 'sv-ec@eda.org' (sv-ec@eda.org)
Subject: RE: soft constraint proposal

Arturo,

Is it a good idea to do implicit priority based on ordering of constructs?
This may have some pitfalls:

- Debugging tool complexity.

- Behavior changing based on compilation order.

- I don’t recall precedence for this type of prioritization.

Perhaps an explicit ordering would be safer.

Thanks
Hillel


From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Arturo Salz
Sent: Monday, September 26, 2011 1:19 AM
To: 'sv-ec@eda.org' (sv-ec@eda.org)
Subject: [sv-ec] soft constraint proposal

I have uploaded a new proposal for Mantis 2987. The new write-up incorporates all the feedback we’ve had, including the following:

- Makes soft a keyword.

- Uses the suggested “disable soft” instead of empty dist to reset soft constraints.

- Decouples the disable functionality from the soft-dist. Now the two features can be specified separately.

- Includes the BNF change from solve_before_primary to constraint_primary.

    Arturo



--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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