Placer awareness of dedicate routing resources

[litghost]

Proposed Behaviour

Placer should be place instances to take advantage of dedicated routing resources

Current Behaviour

Placer only uses delay matrix to choose placement decisions

Possible Solution

Open to suggestions

Context

This is in the context of the 7-series routing fabric. There are two classes of placements that are relevant here:

• Placements where the nets are unroutable
• Placements where the nets will have to use sub-optimal routing

Some placements will result in unroutable solutions. Examples:

• BUFIO have exactly one IO pair that can be used. If an unconstrained BUFIO is instanced, it must be placed on the instance that connects to its IO pad.
• BUFH (horizontal clock buffers) drive into a specific CMT (clock management tiles), and all clocked instances that use that BUFH must be in that CMT, otherwise there is no routing path

Some placements will result in sub-optimal routing (e.g. using general interconnect). Examples:

• Some IO pads are CCIO pins, and can connect to BUFG instances (global clock buffers) directly. If IO pads are not fixed (e.g. prior to PCB design), then some placements will prevent the usage of this dedicate clock path to the BUFG.
• Even if clock IO pads are fixed, PLL/MMCM instances must be located within the same CMT to use the dedicated path from the IO pad to the PLL.

I can give more examples if needed.

FYI @vaughnbetz @mkurc-ant

[mithro]

Does marking these as carry chain pack patterns have an effect?

[litghost]

Does marking these as carry chain pack patterns have an effect?

They do not qualify, because they actually have routing. For example, the CCIO -> PLL connections can route to either CLKIN1 or CLKIN2 (or both).

[mithro]

Well, you mentioned two types of issues. The first type might be solved in a similar style to dedicate carry chain outputs.

The second is more complicated.

[litghost]

Well, you mentioned two types of issues. The first type might be solved in a similar style to dedicate carry chain outputs.

The second is more complicated.

Nah, they both are really the same issue. BUFH to clock in also has routing choices.

[mithro]

Can the routing just be moved into a tile and then a pack pattern used to keep these things together?

[litghost]

Can the routing just be moved into a tile and then a pack pattern used to keep these things together?

For the BUFIO, maybe? For the BUFH and it's ilk, absolutely not.

[mithro]

What prevents it?

[litghost]

One (or more) BUFH drives an entire CMT (e.g. SLICEL, SLICEM, BRAM)? You are very confused about the problem at hand here.

[vaughnbetz]

These detailed, relatively one-off, placement constraints are fairly nasty to make fully data-driven, so I suspect the best we can do is make them partially data-driven, and have some cleanly isolated architecture-specific code and clean data hand offs to the main placer. So here's a proposed high-level plan:

1. Before main placement starts (before even initial placement, or maybe as the first line in it), call a pre-placer function. To make this as clean / extensible as possible, I suggest we make an interface class and derive an Artix7 specific class from it. The interface can have just one method for now: pre-place_special_blocks or some such. The base class would have an empty implementation. The file implementing the derived class should go in a new subdirectory in vpr/src -- say dev_specific/artix7

2. In the Artix7 function you can set the .x, .y and .locked flags of special blocks. The rest of the placer will leave them alone.

3. The Artix7 function should walk the routing graph whenever possible to figure out the relationship between blocks, so we're still somewhat data-driven. For future chips we can hopefully generalize that code, but it's hard to generalize the first time you write it, so I'd do what's necessary for Artix 7.

4. If a block doesn't need to be placed at a certain spot, but needs to be kept at a fixed offset from another block, you could create a placement macro for each and store that in the appropriate data structure. This could be another method in that placer object: create_special_placement_macros

5. (maybe/optional) I think your cases of interest want to fix blocks to specific spots (x,y). If there are some where you instead just need to constrain to a 2D region (e.g. matching a clock region) we can support them after the region constraint support of Add Placement Constraints to VPR #932 is done.

6. (optional/future) For a small number of specific constraints this is probably enough, with the most specific / constrained blocks being locked down first. For a larger number (which we shouldn't get to for a while) you'd probably need to build an algorithm similar to initial placement (with the move to front heuristic we've talked about) or extend initial placement to ask for valid locations from the architecture specific interfaces I mentioned above.

[github-actions]

This issue has been inactive for a year and has been marked as stale. It will be closed in 15 days if it continues to be stale. If you believe this is still an issue, please add a comment.

[github-actions]

This issue has been marked stale for 15 days and has been automatically closed.