On Nov 16, 12:40pm, David Barton wrote:
> Subject: DC-WG: Declarational versus Executional Constraint Languages
> On Executional and Declarative Constraint Languages
...
> 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.
There are several additional factors I think we should consider:
- How adoptable is the resulting standard?
The initial adoption will be in the area of timing analysis
and timing-driven tools, particularly including synthesis.
In this domain, the existing practice is an executable form
with tight ties between the constraint description and various
scripting languages.
A key factor in the success of any new standard is how easy it
is to migrate from previous approaches. Convincing people to
adopt the standard involves a classic cost/benefit tradeoff.
If the new standard doesn't provide radically improvements,
it will be extremely difficult to convince people to take radically
different approaches. We need to weigh how much benefit we'll
provide in either style.
- How will the constraint description reference elements in the
design and the library?
It's common practice today to rely on tool-specific interfaces
to find objects in the design in order to apply constraints to
those objects. Often, the constraint description will find a
set of similar objects, then screen out particular elements of
the set using the full range of scripting language capabilities
before applying a constraint.
It's also common practice to extract certain information from the
library, such as the load of a basic inverter, then use that to
set constraints. In addition, constraints are sometimes applied on
a master basis by identifying a cell in the library. Constraints
specified in this way apply to all occurrences of the cell within
the current design.
In the DC-WG face to face meeting, we discussed taking an initial
approach where the standard would just define the types of constraints
and the types of their parameters. The mechanisms for finding things
in the design and library would be undefined, and tools could provide
different interfaces for assembling the parameters for the constraint
primitives. Steve Schulz's mail elaborates on this approach.
If we take this approach in combination with the executable style, the
first phase of the standard will be straightforward and very consistent
with existing practice and tool support. However, the DCD entered by the
user would only be directly readable by one tool.
If we take this approach in combination with the declarative style, it
implies a more severe use model change, because designers will have to
somehow expand the parameters to the constraints themselves. If the
declarative style is to be embedded in a larger declarative language such
as SLDL, we will need to define mechanisms which explicitly or implicitly
refer to constructs in the surrounding languge in order to assemble the
parameters for the constraint primitives.
- How will the constraint description be accessed (and updated)
by different tools in the overall design flow?
Today, initial constraint descriptions are usually entered by designers
using a tool-specific executable style. The tool which interprets the
initial constraint description converts it into an expanded, declarative
style for use by other tools.
In the DC-WG face to face meeting, Steve Schulz made the point that
it's generally impossible to reverse that process. This is particularly
true after another tool modifies the expanded constraints in any way
(including any refinements specified by the user, as well as budgeting
and other automatic constraint transformations).
A declarative style alleviates some of the issues associated with
maintaining constraints through the design flow but makes it harder
to enter the initial constraint description.
> 1) How much like an existing language should we make them look? Like
> C or Java? Should we just use C or Java?
The classic approaches for EDA standards used by multiple tools are
file formats and APIs. I think that APIs are suitable for types of data
which are created automatically once then reused many times. They're not
as good for capturing data which is design-specific and highly interactive.
Designers need easy ways to enter, view, modify, and track their constraints.
Relying on tools on top of an API to provide these capabilities introduces
a chicken-and-egg problem for adoption: designers can't use the standard
until the tools are there, but there's no incentive to develop the tools
until lots of tools use them.
The chicken-and-egg problem is most easily addressed by making it
easy to translate to and from existing representations. File-based
translators are generally much less complicated than API-based translators.
Making the constraint descriptions look like C or Java implies that
we're going down the API route, because a C or Java description
of constraints is useless unless there is a standard interface between
the constraint description and EDA tools.
> 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.
True, but an API can be defined so as to be mathematically precise,
even if the language which implements the API is not.
> 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?
I think they should look like statements of the constraints.
When we talk about an executable style for the constraints, the
executable part is the part that controls which values for which
constraints are applied to what things in the design. It's not
what code is executed to verify the constraints -- many large EDA
applications do nothing but verify particular kinds of constraints,
so in general it's impractical to ask the user to write the code
which verifies constraints.
In certain cases, all of the hard work is in determining the
current value of a constrained property (like power), and the
verification using that value is simple. But in these cases
it's easier to define how an application is required to do the
checking than to define a complex interface for users to write
their own check.
Generally, I think that restricting the constraint primitives to
an inherently static and declarative form is a reasonable tradeoff.
I can imagine elaborate constraint descriptions which dynamically
re-evaluate themselves when queried, but supporting this kind of
thing would cause tremendous problems for EDA tools. In the OLA
committee there has been a lot of debate around issues like this,
where allowing queries to return different answers based on the
current state makes it impossible to efficiently optimize a design.
> 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.
My personal bias is towards a declarative set of constraint primitives
which happen to have a TCL-compatible syntax.
OLA is successful because the main stakeholders (ASIC vendors) saw
significant value in adopting it.
DCDL will be successful only if the main stakeholders (designers) see
significant value in adopting it. I think this value will come from
two main aspects:
- Consistent semantics for constraint primitives across multiple tools
and levels of design abstraction
- A robust set of interfaces to these constraint primitives
Obviously, DC-WG has to define the constraint primitives and
their semantics. But it's probably more important for the success
of the standard to define the constraint primitives such that they
can be used in many different ways, some of which we would never
think of ourselves. In interfaces I include at least scripting
languages, declarative languages, GUIs, translators to and from
other formats, and databases.
The key is for designers to believe that DCDL is the right foundation
for representing their constraints, regardless of where they are in the
design flow. They'll only believe this if they can enter the constraints
in a reasonable way themselves, then somehow get the constraints into
all the tools they use. The more complicated and language-dependent
we make DCDL, the less likely it is that they will be able to do this.
Mark
-- Mark Hahn phone: (408) 428-5399 Architect, Deep Submicron Business Unit fax: (408) 428-5959 Cadence Design Systems email: mhahn@cadence.com