Open litghost opened 4 years ago
Does marking these as carry chain pack patterns have an effect?
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).
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.
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.
Can the routing just be moved into a tile and then a pack pattern used to keep these things together?
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.
What prevents it?
One (or more) BUFH drives an entire CMT (e.g. SLICEL, SLICEM, BRAM)? You are very confused about the problem at hand here.
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:
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
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.
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.
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
(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 #932 is done.
(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.
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:
Some placements will result in unroutable solutions. Examples:
Some placements will result in sub-optimal routing (e.g. using general interconnect). Examples:
I can give more examples if needed.
FYI @vaughnbetz @mkurc-ant