The following table describes the various PIN2UCF scenarios.
Scenarios | PIN2UCF Behavior | Files Created or Updated |
---|---|---|
User does not have a UCF file. | PIN2UCF creates a UCF file. Writes the pin locking constraints to the UCF file. | pinlock.rpt design.ucf |
User has a UCF file. There are no pin locking constraints in the UCF file or this file contains some user-specified pin locking constraints outside of the PINLOCK section. None of the user specified constraints conflict with the PIN2UCF generated constraints. | PIN2UCF appends the pin locking constraints in the PINLOCK section to the end of the file. | pinlock.rpt design.ucf |
User has a UCF file. This file contains some user-specified pin locking constraints either inside or outside of the PINLOCK section. Some of the user specified constraints conflict with the PIN2UCF generated constraints. | PIN2UCF will not write the PINLOCK section. Instead it exits after providing an error message. Writes a list of conflicting constraints | pinlock.rpt |
User has a UCF file. There are no pin locking constraints in the UCF file. There is a PINLOCK section in the UCF file generated from a previous run of PIN2UCF or manually created by the user. None of these constraints in the PINLOCK section conflict with PIN2UCF generated constraints. | PIN2UCF will write a new PINLOCK section in the UCF file after deleting the existing PINLOCK section. The contents of the existing PINLOCK section will be moved to the new PINLOCK section. | design.ucf pinlock.rpt |