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
|
+------------------------------------------------------------------+