Items:
 

Proposal for a grouping command

History:
When we discussed about how to specify a complex path with several -trough options, we decided to investigate a new command to group different objects in the design.

group

The group command defines a group of elements. The goal of this command is to use the group name as a shortcut in other commands.

Usage:
group -name group_name  (-ports ports_list | -pins pins_list | -instances instances_list | -cells cells_list | -groups groups_list ) [-properties {properties_list}]

Required keywords:

    The -name keyword specifies the name for the group.     specify the components of the group. At least one is required. Several options can be specified.

Optional keyword:

    specify a list of properties that would be assigned to all the elements of the group. The properties_list contains any of these values: rise, fall, min, max, lead, trail, analog, digital.

Examples:
group -name gr123 -ports {IN OUT} -cells {a4} -properties {max lead}

Scoping:
The File Scope is used for the "group" command. See Section 5 in Draft 0.3.7 to have all the explanations about the scoping theory and the use of "include" command with or without "-inline" option.
 

Review of disable command

Overview: The disable command disables timing arcs in a library cell and all instances of that cell or a particuliar instance.

Actual options:
-cell
-instance
-library
-from_port
-from_pin
-to_port
-to_pin
-output_arcs
-input_arcs
-internal_arcs
 


Review of false_path command

Overview: The false_path command identifies timing paths that should not be analyzed.

Actual options:
-early
-late
-rise
-fall
+ path options

Path options: -from_pin, -from_pin_rise, -from_pin_fall, -from_port, -from_port_rise, -from_port_fall,  and the same for instance and cell, -from_group (we can specify in the group if it is rise or fall), -from_clock, -from_clock_lead, -from_clock_trail.
the same for -through_...  (ex -through_port_fall, -through_cell_rise, -through_group, -through_clock_lead)
the same for -to_...  (ex -to_pin_rise, -to_instance_fall, -to_group...)

Review of multi_cycle_path command

Overview: The multi_cycle_path command identifies timing paths that span over multiple clock cycles.

Actual options:
-target
-source
-waveform
-early
-late
-rise
-fall
+ path options ; the same than for false_path

Issue:
What about BG supporting floating point number versus integer elsewhere?
 

Proposal for path_delay_limit

History: DCDL had  not a command to specify a path_delay constraint.

path_delay_limit

Overview: The path_delay command specifies constraints on the delay of paths through non-sequential parts of the design, such as the following:
-path through combinational logic
-connections between hierarchical blocks
-paths between asynchronous clock domains.

(equivalent in GCF: PATH_DELAY, equivalent in BuildGates: set_path_delay_constraint)

Options:
[{-from | -from_rise | -from_fall} pin_list]
[{-through | -through_rise | -through_fall} pin_list]
[{-to | -to_rise | -to_fall} pin_list]
[-early | -late]
[-include_uncertainty]  refers to hierarchical port semantics (see "other issue" below)
float_list

float_list specifies the delay value for the constraint.
This list can have one, two or eight values.
 
FROM TO MIN MAX
rise rise 1 5
rise fall 2 6
fall rise 3 7
fall fall 4 8

One value: The value specified is used in each cells of the array that corresponds to the options specified.
ex: "-from {A}-to_rise {B} -min 2.3"  implies that the cells #1 and #3 will have the value 2.3

two values: The first one corresponds to the -min analysis and the second value corresponds to the -max analysis.
ex: "-from_fall {A}-to {B} {3.2 5.7} implies  cell #3 = cell #4 = 3.2 and cell #7 = cell#8 = 5.7

eight values: the values are discibed in this order {{1 2 3 4} {5 6 7 8}}
ex: "-from {A} -to {B} {{2.3 3.4 2.3 3.4} {3.6 5.6 3.6 5.6}}
 

BuildGates has other options:
-clock_from      Sets the delay for all paths originating from the specified clocks.
-edge_from {leading | trailing}  Specifies an edge for the -clock_from. Default is both edges.
-the same with to instead of from
-bidi_input_from | -bidi_output_from   Specifies that the assertion applies to the input or output of bidirectional pins in the -from pin list.
-the same with through and to.

Other issue:
We need to talk about sequential semantics.
See figure in "path_delay_limit.pdf"
What about adding the option -include_uncertainty to make the distinction between classical path_delay_limit and path_delay_limit with hierarchical port.