1. Complete taxonomy (2 months)
a. Add glossary
b. Review and update parasitics boundary conditions
c. Add tags to timing boundary conditions
d. Add clock to clock uncertainty
e. Add non-clock buffer tree insertion delays, skew, slew
f. Add operating conditions
g. Add modes
h. Decide whether to support something like reset_path, which
partially unsets a constraint
i. Compare against existing constraint languages/formats for
completeness, compatibility
2. Define general language constructs and macros (2 months)
a. Choose a name for the constraint description language
(CDL is already used by a Dracula spice-like language)
b. Define the relationship between the constraint language and tcl
Issues:
- Do we want to support general scripting capabilities
intertwined with constraints?
- Pros:
- powerful
- what users are used to and want
- Cons
- scripts won't be portable to non-tcl tools
- it will be nearly impossible for tools which need to update
constraints to update a general tcl script containing
constraints
- If we do support intertwining, how are values passed between
the constraint language and tcl?
c. Define the set of macros and how they can be combined
Examples:
- all inputs
- all sequential elements
- clock input on a register
- registers in fanout cone of a port (search primitives)
- pin cap on the input pin of an inverter (library access)
3. Map the taxonomy onto the strawman (6 weeks)
a. Convert the Ambit strawman document to IEEE std format
b. Decide how/whether to support both a general semantics description
(language-independent) and the language-specific description
b. Relate each entry in the taxonomy to existing constraint language
commands
c. Reconcile differences between the taxonomy and the existing commands
d. Add missing commands
e. Expand semantic description for each command
f. Compare against existing constraint languages/formats for
completeness, compatibility
g. Convert several large constraint scripts from other constraint
languages into the DC-WG language
4. Add precedence rules (1 month)
a. Which commands accumulate values versus reseting them
e.g.
set_data_arrival_time -min -rise 1.0
set_data_arrival_time -min -fall 2.0
versus
set_data_arrival_time -min -rise 1.0
set_data_arrival_time -min -rise 2.0
b. For similar types of commands, what is the precedence
e.g.
set_drive_cell, set_drive_resistance, set_slew_time
set_false_path, set_cycle_addition, set_min_delay, set_max_delay
set_external_delay, set_data_required_time
set_port_capacitance, set_port_wire_load, set_num_external_sinks
c. For several commands of the same type, what is the precedence when
their effect overlaps?
e.g.
set_cycle_addition -from I1/Q 1
set_cycle_addition -from I1/Q -to I2/D 2
5. Develop golden parser/syntax checker or TCL stubs (1 month)
a. Decide how the syntax checker will be implemented, maintained,
and distributed (resource intensive)
b. Implement the syntax checker
c. Fix language issues identified during implementation
d. Build a set of test cases to stress the syntax checker and
the language definition
6. Polish the specification (1 month)
a. Technical editor review and changes
b. Incorporate DC-WG member company feedback
c. Incorporate VSI, VI feedback
7. Rollout
a. Start discussions with EDA companies for DAC '99 demo support
b. Define the objectives and content for DAC demos
c. Obtain designs, library data for shared testing
d. Actively coordinate on demo progress with all participants
e. Work with OVI to get space for demo on DAC floor
f. Prepare OVI presentations, press releases, newsletters
g. Work with VSI, VI, SLDL to get additional press coverage
h. Present at other conferences leading up to DAC
i. Finalize spec
j. Vote to approve the spec and send to OVI board
k. Plan roadmap for subsequent releases
-- Mark Hahn phone: (408) 428-5399 Architect, Deep Submicron Business Unit fax: (408) 428-5959 Cadence Design Systems email: mhahn@cadence.com