It's been a pleasure to meet you at the ICCAD DC-WG face to face meeting. I am
representing Synopsys on the DC-WG. I was reading your e-mail regarding Declarational
versus Executional Constraint Languages. I would like to get some feed back regarding
Synopsys Design Constraints ( SDC); Do you think Synopsys Design Constraints format
meets your requirements below. I like to help make sure that what Synopsys is
licensing to the EDA industry meets your needs.
I value your judgement highly and want to benefit from your opinions.
Thank you very much.
Best regards,
Ibna
Steven Schulz wrote:
> Dave,
>
> Good summary of points and issues. I also tend toward the side of a
> declarative language, however in the ICCAD DC-WG discussion it became
> clearer to me the importance of a "familar" mechanism for designers.
> After much good discussion in that mtg., I was tending towards what might
> be referred to as a hybrid solution:
>
> 1) The "base" part of the language for constraints, I think, could be
> a set of declarative statements (with support for conditional scoping,
> etc.). This base would be a fairly concise and exacting specification;
> its consistency would be determined by applying these statements
> onto the design and evaluating it through EDA tools. In other words,
> it wouldn't be executable itself, but it would be supported by tools which
> are executable, so the same objective can be reached either way.
>
> 2) For the synthesis-level constraints (if not also at an SLDL level, TBD),
> these base constraints would be "wrapped" in a chosen scripting
> language. Thus, how one can scope, find objects, select and de-select
> objects prior to applying one or more constraints could be done in an
> interoperable way using this part of the standard. Then, the set of
> objects would have their constraints applied with the declarative
> statements. This command-driven approach would be a more familiar
> way for designers. Both (1) and (2) together would represent the
> standard. SLDL might or might not find the scripting portion beneficial
> for its unique aspects, but the base part would certainly be common.
>
> I have yet to think through all the details, but that is my proposal. The
> benefits of this approach are that the SLDL declarative constraints would be
> the same at any abstraction level, and could easily be mapped/passed up
> and down. The declarative part would still be amenable to static and/or
> formal methods of analysis, while the complete set would provide the
> algorithmic intuitive style present in today's synthesis environment.
>
> At 12:40 PM 11/16/98, you wrote:
> >On Executional and Declarative Constraint Languages
> >
> >The purpose of this note is to incite discussion on the list. There
> >was a great deal of discussion on this very point during the face to
> >face meeting at ICCAD, and it is hoped that this note will cause some
> >of the same points, and some additional points, to be brought up on
> >the list. This is being done as part of the DCWG / SLDL joint
> >subcommittee on the language.
> >
> >The primary considerations in the decision between an executional
> >versus a declarative style (and definition) for a constraint language
> >are centered in how the language will be used. And the general
> >guideline is sufficiently clear that it sounds like something close to
> >motherhood and platitudes: if the purpose is to calculate the values
> >for the constraints and to describe how the constraints are to be
> >checked, then an executional style is best; if the purpose is to state
> >constraints independent of any given implementation, then the
> >declarative style is best.
> >
> >Within this, there are several ways of approaching the question:
> >"sub-topics", as it were. First, we can make some specific technical
> >statements that are undeniably true; however, they may not make any
> >difference in the practical world.
> >
> >1) Declarative languages can state things that executional languages
> > cannot. In particular, executional languages are limited to Turing
> > computable functions, while declarative languages are not.
> >
> >2) The direct corollary to the above statement: declarative languages
> > can state constraints that cannot be checked. The converse
> > statement for an executional language needs to be stated more
> > carefully. It is always possible to write incorrect specifications
> > in an executional language that do not terminate, or that yield an
> > incorrect answer (just as it is possible to define incorrect
> > constraints in a declarative language). The converse should
> > probably be stated as follows: it is an intrinsic quality of
> > executional specifications that they terminate with the correct
> > answer. Intuitively, executional specifications can be executed; a
> > tool can use them to produce values and check that constraints are
> > satisfied. There is no guarantee that this is true for declarative
> > languages.
> >
> >In practice, the technical points mean little. It is unlikely that
> >the executional limit will impose great restrictions on constraint
> >specification, and fairly large subsets of a fully declarative
> >language can be executional. Examples of the latter are functional
> >languages (Haskell, ML, Erlang, Clean) and logic languages (Prolog,
> >OBJ3, Maude).
> >
> >Also in practice, the question of which language to use as a "base"
> >for the language may be more important than that of executional versus
> >declarative. For example, among the present exemplars we have is one
> >that is based on TCL. Scripting languages have a great deal of
> >practical appeal in that they can be connected directly to various
> >tools, and these tools can both produce values for the constraints and
> >actually check the constraints. If the committee chooses to go in
> >this direction, th question of which scripting language to use becomes
> >a vital --- and controversial --- one. Several other candidates
> >propose themselves, such as Python.
> >
> >The primary requirement in this area may not be a "scripting" language
> >per se, but the ability to call external tools. If this is the
> >consideration, then any language with connections to C or Java becomes
> >a candidate (including C, C++, and Java; let's not omit the obvious).
> >However, even for this requirement we may wish to examine a more
> >language independent solution. Haskell has a connection to any
> >routine defined via IDL through the HaskellDirect package. Moreover,
> >any language with a similar connection mechanism can be used for this
> >as well, even a fully declarative one.
> >
> >In the final analysis, the question comes down to what we want our
> >constraint descriptions to look like:
> >
> >1) How much like an existing language should we make them look? Like
> > C or Java? Should we just use C or Java?
> >
> >2) How mathematically sound do we want the descriptions to be? Like
> > it or not, C and Java are not as easy to make mathematically
> > precise as declarative languages are.
> >
> >3) Do we want our constraints to look like statements of the
> > constraints, or like mechanisms for checking the constraints?
> > Which is more understandable? Which is more useful?
> >
> >Having made an effort to remain somewhat neutral, I am going to now be
> >personally biased and give my own opinion: I like to think of
> >constraints as things that describe the system being constrained
> >rather than as procedures for checking the constraints. Therefore, I
> >come down heavily on the side of declarative constraints. I also want
> >the correspondance between the DCWG constraint language and the SLDL
> >constraint language to be as close as possible, and it is fairly sure
> >that the SLDL constraint language will be declarative in nature.
> >
> >However, the purpose of this note is to create discussion, not to
> >convince people; thus, I hope the above opinion will generate
> >discussion more than make people fall in line. Comments, questions,
> >and flames are all, of course, welcome.
> >
> > Dave Barton <*>
> > dlb@averstar.com )0(
> > http://www.averstar.com/~dlb
> >
>
> Regards,
> Steve
>
> +------------------------------------------------------------------+
> | Steven E. Schulz, P.E. | Internet: ses@ti.com
> |
> | Senior Member, Technical Staff | Voice: (972) 480-1662
> |
> | Advanced ASIC Architecture | FAX: (972) 480-2356 |
> | Semiconductor Group | P.O. Box 660199, M/S 8645 |
> | Texas Instruments | Dallas, Tx. 75266-0199
> |
> +------------------------------------------------------------------+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ibna Faruque
mailto:ibna@synopsys.com
Phone 650.528.4774 Fax 650.694.4102
Synopsys, Inc. 700 East Middlefield Road
Mountain View CA 94043-4033
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~