Allow fixing of non-iopads

[litghost]

Description

This PR was developed by @acomodi.

This PR allows VPR to place clusters other than IO pads, which is useful for placing clock elements explicitly.

Related Issue

#1045

Motivation and Context

In fabrics with specialized clocking networks, clock elements within the network may have specific requirements. See #1045 for discussion. For example, in the 7-series fabric, there are top global buffers and bottom global buffers. In order to use the dedicated clock path between an input pad and the global clock buffer, if the input pad is in the bottom half of the fabric, it needs to use a "bottom" global buffer, top half of the fabric, it needs to use a "top" global buffer.

Rather than finding a general solution to this problem, for now these elements are given fixed placements prior to running VPR via the IO fixing code. This PR enables that pathway to be more general, and fix any cluster, rather than just IO pads.

How Has This Been Tested?

Symbiflow has been using this code since December to place non-IO cluster instances.

Types of changes

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed

[kmurray]

As I understand it, this extends the current PAD file support to work for arbitrary block types. Is that correct?

Seems like the long term fix is proper constraint support as noted in #932, and this is a small extension for the interim. Am I following correctly?

[litghost]

As I understand it, this extends the current PAD file support to work for arbitrary block types. Is that correct?

Yes

Seems like the long term fix is proper constraint support as noted in #932, and this is a small extension for the interim. Am I following correctly?

Sure, but given that I don't believe there is a design for placement constraint, nor an initial prototype, this feature seems like a natural step. Once a constraint system is in place, this feature will simply be one of the inputs.

[vaughnbetz]

I think this is a good change; it is immediately useful and minimal code. It may become superfluous once we have #932 done, but that is a significant time in the future.

Should we rename the pad_loc_type, pad_loc_file, etc. names to place_loc_type, place_loc_file, etc in the variables, comments & command line help? Perhaps not worth the churn, but the name is now not very intuitive.