The BUILD_SINGLE_RPD MACRO is used to create a RELATIVE_PROPAGATION_DELAY (RPD) constraint for a group of nets that must be routed as a MATCH_GROUP with a tolerance to a reference net.
Refer to the Relative Propagation Delay Section in the Allegro ConstraintCore Documentation for more information
(this link discusses the location of the documentation: Cadence Allegro Constraint System Reference Information)
NAME
The NAME Attribute provides a unique name for each group of nets that needs to be match routed.
Syntax:
NAME=>RPD_NAME
Example:
NAME=>MP_C1_CSRP_RING
This RPDConstraint will be named MP_C1_CSRP_RING
SCOPE
The SCOPE Attribute defines the SCOPE of the RPD constraint
Syntax:
SCOPE=>SCOPE_NAME
Valid Options:
- GLOBAL
LOCALBUSCLASS
Scoping in the Allegro Constraint System is a complicated concept when handling hierarchy, but because dal constraints builds the RPD from the netlist using absolute netNames that are already resolved from the hierarchical (or flat) design the GLOBAL scope should always work.
When LOOP COMMANDS are used to create MULTIPLE RPD Constraints, the loop variable substitution maintains global netNames.
Example:
SCOPE=>GLOBAL
TYPE
The TYPE Attribute defines the RELATIVE_PROPAGATION_DELAY_PATH_TYPE
Syntax:
TYPE=>RPD_TYPE
Valid Options:
- AD:AR (Prop Delays will be measured from All Drivers to All Recievers)
- L:S This will enforce the prop delay only on the longest PinPair on the target Net or XNET
- D:R Prop Delays will be measured from the Longest Driver to Reciever pinPair on the target Net or XNET
- PIN_PAIR (this is implicit if the targets are pin-pairs (or do we need to set this to PIN_PAIR to tell dal_constraints to set the pin-pairs?)
The FILE attribute that dal constraints will read to extract pin-delay data for each PIN_NAME or PIN_NUM (depending on the MAP_DLY_USING attribute)
The file may be specified as a relative path or with a fully qualified path.
Example:
FILE=>PinDelayInfo/HC1B_MC_SGD_FPGA_dly.csv
in this case the file assignment is a relative path, so there must be a PinDelayInfo directory in the same directory as the .brd file containing the HC1B_MC_SGD_FPGA_dly.csv file.
UNITS
The UNITS Attribute tells dal constraints what units should be used for the tolerance.
Syntax:
UNITS=>UNIT_TYPE
Valid Options:
- PS (tolerances/offsets are provided in pico-seconds)
- NS (tolerances/offsets are provided in nano-seconds)
MILSINMM
It is recommended to set this to one of the TIME options (PS or NS) since segments of each route may exist on different layers with different delay characteristics and the Allegro Constraint System can properly track the path delay from start to end
Example:
UNITS=>PS
Use PS for tolerance and offsets
TOLERANCE
The TOLERANCE Attribute sets the tolerance for the RPD constraint
Syntax:
TOLERANCE=>TOL_SPEC
Examples:
- TOLERANCE=>10
All nets in the RPD must be routed within +/- 10ps of the selected TARGET Net
TARGET
the TARGET Attribute specifies which net to use to measure all the other nets in the RPD against.
Syntax:
TARGET=>TARGET_NET_NAME
Example:
TARGET=> C1_MP_RING_CLK_P
The RPD will measure all the other nets against the C1_MP_RING_CLK_P net
More Target Discussion
In many cases like most modern memory systems, The target will be the clock or data strobe. (and here we mention that normally the Allegro Constraint Manager does not make it easy to pick the proper Target)
If the clock is differential we suggest picking the non-inverting net of a differential clock.
When adding RPDS for groups of High Speed Serial Links, we usually pick one of the nets that will get routed near the middle of the length distribution.
Note that most serial data interfaces allow a pretty wide tolerance on the RPD because they implement internal circuitry to internally align the individual data paths.
MEMBERS
The MEMBERS=> Attribute is a comma separated list of pattern matches used to identify which nets to include in the RPD.
dal constraints will allow multiple MEMBERS attributes so you can distribute the target nets across more than one row for easy reading and organization
Syntax:
MEMBERS=>NET_MATCH_1,NET_MATCH_2....,NET_MATCH_N
Example:
MEMBERS=> C1_MP_CSR_,M01_A01_A23,
MEMBERS=>C1_MP_RING_CLK_N,C1_MP_RING_CLK_P
These 2 MEMBERS Attributes are combined and tell dal constraints to add any net containing C1_MP_CSR, or M01_A01_A23 or C1_MP_RING_CLK_N or C1_MP_RING_CLK_P (which is also selected as the TARGET in the example above) to the new RPD.
in this case the net_match is a simple text pattern, and can appear anywhere in the netName
The MEMBERS net_matches are really regular expressions by dal constraints and are quite powerful. For instance with simple modifications to the NET_MATCH we can specify the pattern must occur in the netName (like at the beginning or end.)
To see more information on regular expression entry see Regular Expressions In CadEnhance Tools
NOT_MATCHING
the NOT_MATCHING Attribute is optional and works together with the MEMBERS attribute to fully define the set of target nets
Syntax:
NOT_MATCHING is a comma separated list of patterns that will be used to exclude nets from the set of nets that match the MEMBER patterns
Example:
NOT_MATCHING=>FRAME
MEMBERS and NOT_MATCHING
Together the MEMBERS and NOT_MATCHING attributes make it very efficient to target a large set of diverse nets without having to create a very long list of specific matches. You can create a very general set of matches with the MEMBERS attribute and then exclude certain pattern matches with the NOT_MATCHING patterns.
If we apply the NOT_MATCHING=>FRAME to the group of MEMBERS described above, we would exclude any net that matched the original MEMBERS list if they contained the FRAME string (eg C1_MP_CSR_FRAME or FRAME_M01_A01_A23)
As it turns out in a sample netlist there were a bunch of nets that matched the C1_MP_CSR pattern and then there were 2 nets: C1_MP_CSR_FRAME_P and C1_MP_CSR_FRAME_N that we did not want to include in the RPD. If we didn't have the
NOT_MATCHING Attribute, we would have had to write the pattern for every one of the C1_MP_CSR nets to accomplish what we needed.
Add Comment