Fuzz BUFCE_ROW_FSR configuration

[daveshah1]

Looks like half the work is done: https://github.com/SymbiFlow/prjuray/blob/3f5736237309e0670b4351f39fad8b4bd9cb6dd0/tools/dump_features.tcl#L646

but this isn't actually appearing in the databases yet presumably because nothing actually fuzzes this.

I believe this is needed to correctly clock-route a design that spans multiple clock regions in the vertical direction, see p245 of https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug949-vivado-design-methodology.pdf

However, this is not yet a blocking issue for me as nextpnr's UltraScale+ clock routing is still very simplistic and wouldn't be able to use this in any case.

[litghost]

I believe we have enough configuration to use the BUFCE_ROW_FSR, but not enough to control the dynamic taps.

For example:

https://github.com/SymbiFlow/prjuray-db/blob/366ab03c81d4559a1dfff6661df16454d1f6899f/zynqusp/segbits_rclk_clem_l.db#L1

GitHub

SymbiFlow/prjuray-db

Contribute to SymbiFlow/prjuray-db development by creating an account on GitHub.

[daveshah1]

Thanks, that's a good workaround for now. There's a slight inconsistency in treating BUFCE_ROW_FSR as a pseudo pip only and BUFCE_LEAF as a primitive only but that's no major issue on my side and it will do until BUFCE_ROW_FSR is properly fuzzed.

[litghost]

Thanks, that's a good workaround for now. There's a slight inconsistency in treating BUFCE_ROW_FSR as a pseudo pip only and BUFCE_LEAF as a primitive only but that's no major issue on my side and it will do until BUFCE_ROW_FSR is properly fuzzed.

That isn't a psuedo pip, because it controls a real mux. However I do believe the equivalent of BUFCE_ROW_FSR.USED got lumped into each of those PIP features. I don't have a problem with that, as if you activate a pip that only goes to a BUFCE_ROW_FSR, you almost certainly are going through the BUFCE_ROW.

[daveshah1]

Ah, sorry, I misread that line - I thought it was the "in to out" pseudo-pip