Page Comparison

The ASSIGN_PIN_DELAYS MACRO tells dal constraints to add pin_delay information from a spreadsheet type file for a list of Reference Designators in your design

PIN_DELAY FILE

The PIN_DELAY_FILE is expected to be a list of comma separated rows where the pin delay for each pin is specified.

The FILE_HDR_ROWS and FILE_CONTENT_FMT attributes allow the user to tell dal_constraints how the pin-delayt data is actually formatted in the file.

Note that any row starting with a '#' in the pin_delay_file witll 

REF_DES

The REF_DES Attribute is a comma separated List of patterns used to identify the target of the ASSIGN_PIN_DELAYS MACRO

Syntax:

REF_DES=>REF_DES_1,REF_DES_N...,REF_DES_N

dalTools will assign pinDelay data it extracts from the FILE attribute to every REF_DES in the List 

Example:

REF_DES=>U1,U2,U3,U83

Here dal  constraints will add the data from the specified FILE to any part in the design whose Reference designator (or LOCATION) property= U1 or U2 or U2 or U83

Future: PART_NUMBER

This would be a more portable way to define pin_delays since the PartNumber would be consistent across designs while the REF_DES would probably be different

The PART_NUMBER Attribute is a comma separated List of PART_NUMBERS used to identify the target of the ASSIGN_PIN_DELAYS MACRO

This would work well if the organization adds a unique PART_NUMBER to each device in their library.

Syntax:

PART_NUMBER=>PART_NUMBER_1,PART_NUMBER_2...,PART_NUMBER_N

dalTools will assign pinDelay data it extracts from the FILE attribute to every part in the design whose partNumber poperty matches one of the PART_NUMBERS in the list

Example:

PART_NUMBER=>1005_0004_001

Here dal  constraints will add the data from the specified FILE to any part in the design whose PART_NUMBER property=1005_0004_001

if U1,U2,U3 and U83 were the same part with PartNumber=1005_0004_001 then this would be equivalent to the REF_DES attribute above (and would also be portable to another design that uses PN:1005_0004_001

To implement this properly, dal constraints might need a configuration setting to define which device property actually maps to the PART_NUMBER property,

as some organizations may use a different name for the PART_NUMBER property

FILE

The FILE Attribute points to the  PIN_DELAY_FILE which contains all the available pin-delay data for a device. 

Syntax:

FILE=>FILE_NAME or FILE=>FULL_PATH_TO_FILE_NAME

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.

FILE_HDR_ROWS

The FILE_HDR_ROWS Attribute tells dal constraints which rows to skip when reading the PIN_DELAY_FILE

Syntax:

FILE_HDR_ROWS=>NONE

or 

FILE_HDR_ROWS=>ROW_NUM_1,ROW_NUM_2...ROW_NUM_N

The user can specify that the FILE contains no HEADER rows using NONE

or they can provide a comma separated list of  Rows to skip when reading the pin_delay file

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._HDR_ROWS=>NONE

This tells dal constraints that there are no header rows in the PIN_DELAY_FILE, so every line will be processed as if they contain valid pin-delay information 

FILE_HDR_ROWS=>1,2,3,5,7

This tells dal constraints to ignore rows 1,2,3 5 and 7 when processing the PIN_DELAY_FILE, all other lines will be processed as if they contain valid pin-delay information 

FILE_CONTENT_FMT

The FILE_CONTENT_FMT Attribute describes how the pin_data is organized on each line of the PIN_DELAY_FILE. 

The purpose of this Attribute is to let dal constraints adapt to various pin_delay file layouts which may be provided by different vendors, so that the user

does not have to force fit the delay file into one fixed format. 

Syntax:

FILE_CONTENT_FMT=>FIELD_INFO_SPEC_1,FIELD_INFO_SPEC_2...,FIELD_INFO_SPEC_N

The FIELD_INFO_SPEC should be one of the following values:

1. PIN_NUM
2. PIN_NAME
3. PIN_DELAY

OR

some of the FIELD_INFO_SPEC can be left blank

Examples:

• FIELD_CONTENT_FMT=>PIN_NAME,PIN_NUM,PIN_DELAY

This describes a line format where the first column is the PIN_NAME, the 2nd column is the PIN_NUM and the third column is the PIN_DELAY

• FIELD_CONTENT_FMT=>PIN_DELAY,,PIN_NAME,,,PIN_NUM

This describes a line format where the PIN_DELAY is in the first column, the PIN_NAME is in the 3rd column and the PIN_NUM is in the 6th column

MSP_DLY_USING

the MAP_DLY_USING Attribute specifies which field to use to assign PIN_DELAYS to pins

Syntax:

MAP_DLY_USING=> PIN_NUM | PIN_NAME

Example:

MAP_DLY_USING=> PIN_NUM

dal Constraints will lookup the pinDelay in the PIN_DELAY_FILE using the PIN_NUM field and assign it to the target device pin with the same pin_number

This is the preferred choice since the device should always have the same pin numbers, but the pin_name may change per pin_number (especially a programmable device like an FPGA)

MAP_DLY_USING=>PIN_NAME

dal Constraints will lookup the pinDelay in the PIN_DELAY_FILE using the PIN_NAME field and assign it to the target device pin with the same pin_name.

This should only be used if the PIN_DELAY_FILE does not have a PIN_NUM lookup field, since PIN_NAMES may change in a desgin.

UNITS (To be implemented)

The UNITS Attribute tells dal Constriants what the units the PIN_DELAY is provided in. 

until this is implemented dal constraints will use PS as default

If the PIN_DELAY Field in the PIN_DELAY_FILE contains these units, like 57 PS or .057 NS  or 120 MILS, the units in the actual file should override the UNITS selection.

Syntax

UNITS=>[PS|NS|MILS|MM|IN]

Example:

UNITS=>PS

specifies that the PIN_DELAY units in the file are in picoSeconds

Ideally PIN_DELAY should always be provided as a propagation delay instead of a length, but some vendors will use a length.

The problem with using length is it cannot account for the different prop delay characteristic of the traces based on the package materials and construction.

Handling Length based PIN_DELAY

If the PIN_DELAYS are provided using length, it is suggested that the user add a column in the spreadsheet and insert a calculation to convert Length to time with some constant like 162 Ps/in

Or

could we encode the conversion constant in the UNITS Attribute like this????

UNITS=MIL:162

or

add another Attribute

PIN_DLY_LENGTH_CONVERT=>162

 More About the PIN_DELAY_FILE

The PIN_DELAY_FILE should provide a list of comma separated rows where the pin delay for each pin is specified.

The FILE_HDR_ROWS and FILE_CONTENT_FMT attributes allow the user to tell dal_constraints how the pin-delaytdata is actually formatted in the file.

Any row starting with a '#' will be treated as a comment and will be ignored

PIN_NAME,PIN_NUM,PIN_DELAY
TPIN2,A5,37
RPIN5,A11,52
GND1,T22,,
VDD18,R11,,

In this case, FILE_HDR_ROWS should be set to 1
and FIELD_CONTENT_FMT should be PIN_NAME,PIN_NUM,PIN_DELAY

#PIN_DELAY,PIN_TYPE,PIN_NAME,IO_STD,PULLUP,PIN_NUM
37,INPUT,TPIN2,LVCMOS18,PULLUP,A5
52,OUTPUT,RPIN5,HSTL1,NONE,A11,
57,GROUND,GND1,,,T22
22,POWER,VDD18_1,,,R11

In this case, FILE_HDR_ROWS should be set to NONE or 1... since the first row is commented out
and FIELD_CONTENT_FMT should be set to PIN_DELAY,,PIN_NAME,,,PIN_NUM