Open acomodi opened 3 years ago
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.
Problem statement
Currently, the number of IDELAYCTRLs in a design is fixed to the number of instantiations in the design itself.
It is common though, that there are multiple IDELAY banks that use the same IDELAYCTRL. This causes issues, as there need to be multiple IDELAYCTRL cells in the resulting netlist in order to be correctly placed on the device.
Vendor tools are able to auto-infer the necessary IDELAYCTRL cells to implement them during P&R, therefore we would need to allow the same behavior.
Example
This issue came up when building the linux-capable LiteX design for the nexys-video board. The ethernet module requires as well the use of IDELAYs and the required IDELAY banks are now two:
The LiteX builder instantiates only one IDELAYCTRL though, and, given that no
IDELAY_GROUP
is specified in the design, the same IDELAYCTRL gets associated with the two IDELAY banks.