<sb0>
whitequark: hoes does this guarantee you balanced timing? what about routing delays?
<sb0>
whitequark: re. language changes, ok
<whitequark>
sb0: when nextpnr gains relative placement constraints i could actually guarantee routing delays too
<whitequark>
"place these two LUTs in the same slice"
<whitequark>
right now it's not really usable for a variety of reasons
<sb0>
okay, but then the two paths from that sllice can take different routes
<sb0>
for differential signaling you want very tight matching. i'm not sure if this trick works at all.
<whitequark>
sb0: and the whole thing is placed next to the IOB, of course
<whitequark>
according to my experiments it does work
<sb0>
in what case would you not use the built-in differential buffers?
<whitequark>
ice40 doesn't have differential output buffers
<whitequark>
it's not really a problem if you're using the IOB register, because if you clock both IOBs from the same GBUF it should happen at pretty much the same time
<sb0>
okay. so what about implementing this platform-specific hack for ice40 only instead of requiring some support for it on all FPGAs?
<whitequark>
however, there are routing restrictions that make it not always possible
<whitequark>
oh, but it's not just ice40
<whitequark>
for example, on ecp5, nextpnr currently will not pack an FF into an IOB at all
<whitequark>
and diamond sometimes refuses to pack an FF into an IOB, with unclear but obnoxious constraints on it
<sb0>
does ecp5 have differential in/out buffers?
<whitequark>
yes, both
<sb0>
so we don't need the pseudo-differential hack
<whitequark>
not on all pins though
<whitequark>
i think it's something like all pin pairs on top and bottom banks, and half pin pairs on left and right banks
<whitequark>
anyway, that's not really why i use it across the board
<sb0>
I worry that implementations for all FPGAs are tedious and won't be properly tested
<sb0>
in particular, they will have issues with delay matching between the two pairs
<whitequark>
right, but that's not why the ixor and oxor functions are present across all platforms
<whitequark>
it's just because when all IOB instantiation code looks roughly the same, it's easier to work with
<whitequark>
it makes no sense to abstract things like IOB names etc and use inheritance in this case, so it's mostly copy-paste, and it's just nicer when it's regular
<whitequark>
I actually made it the way you want first, and then I needed to make some change to all 4 platform files, and it turned out that when all of them are subtly different, it is very easy to introduce a bug, and miss it during testing
<whitequark>
anyway. i'm not married to get_ixor. if you really want to get rid of it, go ahead. but i'd expect that result in more bugs, not less