Should this be considered a synthesis behavior? If so, then this likely needs a yosys plugin?

Indeed, I need to improve this issue and provide some additional data, and yes, I believe as well this needs to be solved at synthesis time.

I believe that an entire new plugin might be required, and it would check all things related to IDELAY and IDELAYCTRL, so that we can have full support on all the cases specified here: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/0e9281577f10ba2e2688c1de51e45eaa81302dea/xc/common/utils/prjxray_create_place_constraints.py#L765-L778

I have been thinking about possible solutions to solve this, and there is one issue that might be complicated to solve.

Basically, the synthesis step is not aware of which and how many IDELAY banks are being used, as it does not have the information on the relationship between IDELAY and the CMT in which that IDELAY belongs.

This makes it non-trivial to determine how many IDELAYCTRLs should be added to the final circuit.

The IDELAY <-> CMT relation though is present in the vpr_grid_map.csv, therefore I am thinking that a possible solution would be to add a python step (as done for the fix_xc7_carry.py), that modify an intermediate json produced by yosys and generated the correct number of IDELAYCTRLs based on the IDELAY locations (these locations must be constrained in the XDC for the IOPADs using IDELAYs)

I believe we already have some Yosys plugins that consume fabric data, so this is not a new behavior. @tmichalak ?

I believe we already have some Yosys plugins that consume fabric data, so this is not a new behavior.

We do use json11 library for extracing the bank_tiles information from tilegrid.json.
You can use the same mechanism as here to get the information you need from tilegrid which I believe contains the information you are looking for.