@litghost FYI

I've started looking into this, and it might be hard :(

The problem as I see it is how capacity is defined. VPR defines capacity by completely duplicating the tile N times, when what I really want to 1 tile with N placement sites inside. I want the pin definitions to be explicit, etc.

I'll open an issue upstream.

The up-side of this though is that actually the CLK_BUFG tiles currently have the same pin names repeated 16 times. This is good because the tile does not have extra pins that do not get duplicated, so, for VPR, it could be enough to have the pins stated only once for the tile.

I think the problem could be to link the pins when building the rr_graph.

I think the problem could be to link the pins when building the rr_graph.

Yes. That would work, but I'm also thinking ahead to the the heterogenous capacity problem.

I think what I want to do is de-couple capacity from pin class definition (via an attribute), and then require an explicit physical type to logical tile mapping of the pins. This will allow flexiblity in the pin assignments from the physical tile definition to the logical tile definition. The capacity definition in this case will modify how many logical instances exist, but not modify how the physical ports are created.

This has a two fold benefit. First it allows the existing routing import logic to work. Second, when we add heterogeneous capacity, the requirement for uniform port definitions is relaxed.

The up-side of this though is that actually the CLK_BUFG tiles currently have the same pin names repeated 16 times. This is good because the tile does not have extra pins that do not get duplicated, so, for VPR, it could be enough to have the pins stated only once for the tile.

I think the problem could be to link the pins when building the rr_graph.

Given that I'm going on vacation soon, it might be worthwhile for you to try to implement capacity using the existing VPR version. That may be faster, and then in the new year when I can finish the flexible physical tile <-> logical tile mapping, we can switch over. Thoughts?

@litghost sure, I can deal with this.
I think that this has higher priority than the IDELAYCTRL with no outputs as now we can use the RDY pin with your latest update.

#1227 adds capacity for BUFG, but we still the need ability to LOC tiles with capacity.