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
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_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:
- PIN_NUM
- PIN_NAME
- 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.
If the PIN_DELAY Field in the PIN_DELAY_FILE contains these units, it 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.
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
Add Comment