At 09:50 AM 12/2/98, Ibna Faruque wrote:
>Hi Steve,
>
>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'm gratified to hear such an open, customer-oriented perspective! I must
tell you that I have yet to see the specifics of exactly what the SDC licensing
consists. Until very recently, my requests for Synopsys to open their DC were
met with multiple barriers, usually in these categories:
- Synopsys' constraints are always changing and in flux
- these are proprietary IP of Synopsys (now handled via TAP-IN licensing)
- too closely tied to their tools and internal algorithms to be shared
So, now that TAP-IN has been launched and extended to SDC, I'd like to
know, "what has changed" in the above scenario? Is there any way I can
actually see what is being offered? It's hard to evaluate with so little
specific knowledge. I learned this with the RTL synthesis subset effort --
when the team finally received the Synopsys documents, they were devoid
of any semantic descriptions, and weren't particularly useful. Of course, we
defined a "Level 0" that was back-fit to be essentially the same thing, but the
group had to re-generate the semantic definitions from their own expertise.
I would hope that the SDC includes both syntax and semantics, or the same
problems will result.
So, if I could actually preview the contents of SDC, then I would be in a better
position to comment on a more technical foundation. I have publically stated
my position on licensing of standards -- I do not oppose the approach if it
represents significant IP (R&D expense) of the contributor, but it will always
compete against any other new or existing alternatives that do not require
licensing. Each contributing company must play the odds of which approach,
and at what licensing level, will be acceptable as a "chosen" format. If it
is used excessively or where satisfactory non-licensed options exist, then
the sourcing company will lose its stature and influence; otherwise, it may
gain stature and influence.
Even so, I want to point out that, from a broad industry perspective, it is
essential that we coordinate design constraints at the RTL level with those
now being defined at the HW-SW system (SLDL) level. So, any existing
technology may require some minor changes to accomplish a greater
long-term objective for the design community. The challenge is to accomplish
both through careful, expert consideration of the alternatives for possible
architectures. The architecture I had proposed in my prior email was a
strawman suggestion to preserve the present-day operational features, but
also enable declarative features that are more robust for complex HW-SW
design needs, both for co-synthesis and verification/analysis. SDC would
not be the full answer in this case, however it's semantic elements might be
sufficient for the RTL-level operators (which would be re-combined for both
abstraction level standards).
I hope this input is helpful. Let me know if you can share more details
of the SDC licensing to aid in a more technical assessment.
Steve
>
>I value your judgement highly and want to benefit from your opinions.
Thank you. I promise to be open and honest in my responses, both from
an "industry" and "TI" perspective.
>
>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
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
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
|
+------------------------------------------------------------------+