Tristate control signals are inverted in designs routed with router1

[hansfbaier]

This fixes a bug which breaks designs using router1 (which is now default), because the ZINV_T bit is not written.

[gatecat]

Thanks for figuring this one out!

[hansfbaier]

@gatecat You're welcome! Thanks for merging! I have another issue with router2 on the same design: For example it generates the bit CMT_TOP_L_LOWER_B_X106Y61.MMCM_CLK_FREQ_BB_REBUF3_NS.MMCM_CLK_FREQ_BB_NS3 but in prjxray there is only the bit in the opposite direction segbits_cmt_top_l_lower_b.db:CMT_TOP_L_LOWER_B.MMCM_CLK_FREQ_BB_NS3.MMCM_CLK_FREQ_BB_REBUF3_NS 28_1073 29_1068 29_1076 29_1080, which means I get a fasm error here. Looking in the tile type JSON file I see that this pip is bidirectional: How does nexpnr-xilinx handle bidirectional pips?

[gatecat]

Bidirectional pips are implemented as two pips, one in each direction, in nextpnr (if you look at them on a hardware level, this is coincidentally how they usually look in the recent Xilinx architectures too).

There are two possible solutions here - either it's truly a bidrectional pip, and the fix is to emit the opposite direction in the FASM. Or, it's actually two unidrectional pips but only the bits for one direction have been fuzzed, so the unsupported direction needs to be disabled. As the pip is "is_pass_transistor": 0 and also has multiple config bits associated with it, I would imagine it is the latter case.