Open daveshah1 opened 4 years ago
I believe we have enough configuration to use the BUFCE_ROW_FSR, but not enough to control the dynamic taps.
For example:
GitHub
Contribute to SymbiFlow/prjuray-db development by creating an account on GitHub.
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.
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
.
Ah, sorry, I misread that line - I thought it was the "in to out" pseudo-pip
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.