This replaces the arch-specific DelayInfo structure with new DelayPair
(min/max only) and DelayQuad (min/max for both rise and fall) structures
that form part of common code.
This further reduces the amount of arch-specific code; and also provides
useful data structures for timing analysis which will need to delay
with pairs/quads of delays as it is improved.
While there may be a small performance cost to arches that didn't
separate the rise/fall cases (arches that aren't currently separating
the min/max cases just need to be fixed...) in DelayInfo, my expectation
is that inlining will mean this doesn't make much difference.
Signed-off-by: gatecat <gatecat@ds0.me>
During packing we replace them by standard SB_IO cells and create the
'fake' SB_GB that matches that IO site global buffer connection.
It's done in a separate pass because we need to make sure the nextpnr iob
have been dealt first so we have our final Bel location on the SB_IO.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Those are cells that are created mainly to handle the various sources a
global network can be driven from other than a user net.
When the flag is set, this means the global network usually driven by
this BEL is in fact driven by something else and so that SB_GB BEL and
matching global network can't be used.
This is also what gets used to set the extra bits during bitstream
generation.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
