Jin
-------------------
Preface
------
Before I start, I would like to describe my mindset:
I am looking for a break-through, in that, I am willing to look beyond
the currently popular form of man-machine interface: one that bases on a
design/command language. To standardize an interface for one
application among multiple tool vendors is hard enough, to standardize
an interface for multiple applications among multiple tool vendors is
unthinkable. Without some kind of break-through, the chance of whatever
standard created by this WG to prevail is slim.
The kind of break-through I think we need is one that can generously
capture the "designer's intent." We may be able to do that, if we can
isolate the part of a designer's design considerations that is canonical
reusable and universal, therefore, reflect the designer's intent. Only
with such a realization, can then we narrow the scope of our project to
a point that a mechanism with built-in simplicity, whether it be a
command language or a spreadsheet, can be devised to tackle the problem
at hand.
The ramification of the above argument is that the "design intent" we
are to capture may not contain all the information necessary to operate
any specific tool, but the essential information that all tools must
abide to.
Finally, if preservation of design intent is to be THE objective for
this WG, we need to think hard about an entry mechanism that is most
nature to a designer for expressing his/her design intent.
Charter
-------
The Design Constraints Working Group is chartered with developing a
standard interface for designers to express and capture their Design Intent
in a non-obscured way. The captured Design Intent can be transcribed,
translated, or transformed into constraining conditions for all design
processes involved in the implementation of a RTL or structure netlist
design represented in either VHDL or Verilog language.
Scope
-----
The standard should allow all nontrivial constraining conditions for the
implementation of a chip design be supplied from multiple sources: system
architect, logic designer, library provider, technology vendor and design
integrator, be captured in a non-overlapping, coherent and consistent
manner.
The standard should include semantic definition, common interface, and
entry mechanism for the design constraints been defined.
The constraining conditions should be the totality that is essential to:
design estimation, logic synthesis, design planning, timing analysis,
physical layout, physical transformation, power analysis, signal integrity
analysis, and final timing verification.
The standard should cover a number of different domains, including timing,
area, power, signal integrity, logic architecture, clocking, physical
design, test, manufacturability, reliability/lifetime, and mixed signal.
At the point the totality of the constraining conditions has been worked
out at conceptual level, the details should be worked with priority given
to timing domain first, followed by physical domain in second, and perhaps
mixed signal at last.
The standard should be independent of RTL language, tools, or technologies,
and should be sufficient flexible to be handled by existing extension
languages, and compatible to P1481 standards.
Target Deliverables
------------
Conceptual Model
Constraint Dictionary
Entry Mechanism -- spreadsheet model?
Command Language -- including a golden parser
Constraint Resolution and Maintenance