The Constraint Rule File (CRF)

Owned by Bill OLeary
Last updated: Apr 04, 2019

The Constraint Rules File (CRF) is a Spreadsheet created by the Design Engineer(s) and is used to specify complex Physical and Electrical Design Constraints for the Allegro PCB Editor.

Constraints are specified as high level Macros and use very powerful net-name matching rules to choose the nets that will get 

The CRF  is an input to the dal constraint tool which interprets the high level Macros and adds Constraints to the design working outside of  the Constraint Manager Interface 


Building the CRF

Unfortunately, design constraints cannot be inferred or created out of thin air.

Constraining a design is a detailed, interactive process which must be owned by the board designer and or the signal integrity engineer.

Each interface can require multiple sets of rules that the designer must be aware of.

The CRF manages the constraints and documents them at the same time, and the dal constraints tool provides automation in many area to streamline the creation process.

Constraints defined in the CRF are designed to be portable between designs that use similar net-naming conventions.

Use 'dal browse' to help indentify targets of CRF Macros. 

The CRF uses powerful regular expression pattern matches to identify targets of the individual Command/Macros

The daltools 'dal browse' utility is an interactive tool which allows the user to view the nets in the design interactively using the same regular expressions. It provides a great front end to help select the targets of the CRF Macros.  

CRF Structure

The CRF is a regular Excel Spreadsheet that contains a list of COMMANDS/MACROS which the dal constraint tool parses to create the low level Constraint properties for the Allegro Constraint System.

Each COMMAND/MACRO It is organized in rows and columns and each column has specific meaning

The dal constraint tool reads the CRF from top to bottom.

Each time it encounters a valid COMMAND/MACRO in the COMMAND/MACRO column, it starts building all the information required for that MACRO by reading and processing the following rows until it reaches an new COMMAND/MACRO or the end of the file.

CRF Column Structure

Row 13 in the sample above shows the column headers which include

  1. COMMENT COLUMN
  2. COMMAND /MACRO COLUMN
  3. MACRO/ATTRIBUTE NAME COLUMN
  4. ATTRIBUTE/PARAMETER VALUE COLUMN(S)
  5. Row Comments


Comments and the Comment Column

The hashtag '#' character is used to mark any following information as a comment. 

It can appear anywhere in a row and anything that follows the first '#' character is ignored when dal constraints reads that row

The first Column (COMMENT_COLUMN) of the CRF is reserved as a special placeholder which can be used to Insert or delete a comment '#' character.

It is very easy to copy the '#' into multiple rows to comment out larger sections and its easy to remove the '#' from a large selection of rows as well.

Without this column, the user would need to edit each cell and insert the comment character before the first.

If a comment character appears in the first column, dal constraints ignores the whole row.

If not, it processes each column in the row and can still find comment characters at other positions.

(Note that ROW 13 in the sample above with the Column Header Names is actually a comment since it starts with the '#')

COMMAND/MACRO column 

The 2nd Column is reserved for the COMMAND or MACRO name. 

The dal constraint tool recognizes the following COMMANDS/MACROS

  1. SET_CONSTRAINT_UNITS
  2. BUILD_STACKUP_FROM_FILE
  3. AUTO_BUILD_DIFF_PAIRS
  4. BUILD_PCS
  5. BUILD_ECS
  6. BUILD_SCS
  7. AUTO_IDENTIFY_PIN_DIR
  8. AUTO_ASSIGN_VOLTAGE
  9. AUTO_ASSIGN_VOLTAGE_FEEDTHRUS
  10. ASSIGN_PIN_DELAYS
  11. BUILD_SINGLE_RPD
  12. CREATE_VAR
  13. BUILD_MULTI_RPD
  14. PIN_PAIR_LOCATORS
  15. BUILD_MIN_MAX_PROP_DELAY
  16. BUILD_TOTAL_LENGTH

Many of the COMMAND/MACROS require a Unique name

For instance the BUILD_PCS and BUILD_PCS macros needs a NAME to use for the PCS/ECS they will be creating 

The NAME Attribute and its Value are included in the same row as the MACRO/COMMAND like in this example 

The name of the ECS created will be DPAIR_6.5G



Command Attribute/Parameter Names

The 3rd Column is reserved for Command Attributes or Parameter Names

Each MACRO has a different set of available Attributes/Parameters

the Attribute NAME is placed in the 3rd column with the '=>' separator to help dal constraints recognize it.

An Attribute NAME can be repeated in multiple rows and dal constraint will append the values to create longer lists of values as needed

This is very useful for items like the MEMBERS Attribute which can become quite long as lists of NetName matches are added to the Target list of an ECS or PCS.



Command Attribute/Parameter Values

The 4th and following Columns are reserved for Attribute/Parameter Values

The Attribute Values are placed in their own column 



Row Comments

A optional comment can be added after the last Attribute/Parameter Value Column in each row, it start with the '#' comment character.

This column and any column after this row will be ignored



Constraint Macros

Constraints are defined using powerful macros    

A macro can create a design rule or tell the dal constraints to perform an automated task

Macros use advanced bus-aware pattern matches to identify constraint targets

Constraint definitions can easily be ported between related designs

Nested Loops and Replication constructs provide maximum efficiency/accuracy

Use variables to set tolerances… change the value and all constraints will update

Consistent schematic naming conventions make constraint definition easier

Use comment ‘#’ to temporarily remove constraint macros

Use worksheets to define rational values tolerances instead of over constraining



Detailed Macro Information

Use the following links to find more detail about each MACRO