Looks good to me. Are you fairly confident this can be prototyped in time
for the demo? This would be a strong showing. Any thoughts on how the
publicity and marketing will be handled to give this proper
attention? Perhaps VI could offer some services here...
Steve
At 06:28 PM 4/19/99, you wrote:
>Here's a second draft proposal for the DCDL subset for the DAC demo.
>I've incorporated some feedback from the early implementation work.
>The changes are:
>
> - a new convention for specifying multiple values, based on
> lots of discussions
> - switch to use slew_time instead of drive_resistance for the
> demo (both will be supported later)
> - a new -inverted option on waveform, to eliminate ambiguity
> about whether the lead edge is rise or fall
>
>The notation conventions still follow the BuildGates strawman:
> -abc specifies a required parameter
> <abc> specifies an argument of a given type
> a | b select either the a option or the b option
> ?<ab> | <de>? select one or none of the specified options within
> the delimiters
> {a b} a list containing elements a and b. The curly braces
> are required in pure DCDL, but DCDL commands embedded
> in a TCL script may use double quotes or refer to
> a variable containing a list instead.
>
>Proposal for the DAC demo subset
>--------------------------------
> 1. Units
>
> These statements must appear before any other dcd statements
>
> dcd::units
> ?-time <multiplier>?
> ?-capacitance <multiplier>?
> ?-resistance <multiplier>?
> ?-voltage <multiplier>?
> ?-temperature <multiplier>?
>
> 2. Clock
>
> dcd::waveform
> -name <waveform_name>
> -period <period>
> -edges { <lead> <trail> }
> ?-inverted?
>
> The default is that the <lead> edge is rising and the <trail>
> edge is falling. The -inverted option indicates that the <lead>
> edge is falling instead.
>
> dcd::clock
> -waveform <waveform_name>
> <pin_list>
>
> 3. Arrival times
>
> dcd::data_arrival_time
> ?-waveform <waveform_name>?
> ?-lead | -trail?
> ?-early | -late?
> ?-rise | -fall?
> <time_value>
> <pin_list>
>
> When any of the options -early, -late, -rise, or -fall are specified,
> <time_value> must be a single value, and it applies to all of the
> value slots implied by the combination of the options.
>
> When none of those options are specified, <time_value> can either be
> a single value that applies to all four value slots, or a list of four
> values, one for each slot:
> { <early_rise> <late_rise> <early_fall> <late_fall> }
>
> Asterisks can be used for one or more of the four values, to indicate
> that the value is unspecified by this statement (the value slot is left
> unchanged). If there are previous statements that specify a value for
> the same slot, the old value will be preserved. Later, we'll add
> a -reset option to each command to support eliminating an existing value
> from a slot.
>
> This approach has the advantage of preserving the common usage for
> initial entry, while also providing a more compact syntax for advanced
> users and for interchange.
>
> 4. Required times
>
> dcd::data_required_time
> ?-target | -source? /* only -target supported for DAC */
> ?-waveform <waveform_name>?
> ?-lead | -trail?
> ?-early | -late?
> ?-rise | -fall?
> <time_value>
> <pin_list>
>
> Same convention for <time_value> as for data_arrival_time.
>
> 5. False paths
>
> dcd::disable
> ?-library <library_name>?
> -cell <cell_name>
> ?-arcs <from_pin to_pin>?
>
> dcd::false_path
> ?-from <pin_list>?
> ?-through <pin_list>?
> ?-to <pin_list>?
> ?-early | -late?
>
> 6. Multi-cycle paths
>
> dcd::multi_cycle_path
> ?-target | -source? /* only -source supported for DAC */
> ?-from <pin_list>?
> ?-through <pin_list>?
> ?-to <pin_list>?
> ?-early | -late?
> <cycle_offset> /* only integer values supported for DAC */
>
> When either of the options -early or -late is specified,
> <cycle_offset> must be a single value, and it applies to just
> the value slot implied by that option.
>
> When neither -early nor -late is specified, <cycle_offset> can either
> be a single value that applies to both value slots, or a list of two
> values, one for each slot:
> { <early_offset> <late_offset> }
>
> 7. Slew time
>
> dcd::slew_time
> ?-early | -late?
> ?-rise | -fall?
> <time_value>
> <port_list>
>
> Same convention for <time_value> as for data_arrival_time.
>
> 8. External load
>
> dcd::external_capacitance
> <capacitance_value>
> <port_list>
>
> In full DCDL this should have -early and -late options, and
> the <capacitance_value> should be either a single value or a
> list of two values. For the DAC demo it will just be a single
> value.
>
> 9. Wire load model (WLM) selection
>
> dcd::wire_load_model
> ?-library <library_name>?
> <wire_load_model_name>
> ?<instance_list>? /* omit for top instance; must omit for DAC */
>
>10. Operating conditions
>
> dcd::operating_conditions
> ?-process <value>?
> ?-voltage <value>?
> ?-temperature <value>?
>
>--
>Mark Hahn phone: (408) 428-5399
>Senior Architect fax: (408) 428-5959
>Cadence Design Systems email: mhahn@cadence.com
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
----------