Bits are 0 by default anyway, so if they are unknown (because icestorm
is too od) but we want them at 0 ... it's not much of an issue.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Technically you can enable it independently on CORE and GLOBAL
output, but this is not exposed in the classic primitive, so
we do the same as icecube2 and enable/disable it for both output
path depending on the argument
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
If a port specified as output (and thus had a $nextpnr_obuf inserted)
is undriven (const `z` or const `x`), we make sure to not enable
the output driver. Also enable pull-ups if it was requested by the user.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
We try to copy the attribute only when there is a chance for
the output driver to not be active.
Note that this can _also_ happen when a port is specified as
output but has a TBUF, which the previous code wasn't handling.
We could copy the attribute "all-the-time" but this would
mean if a user specified a `-pullup yes` in the PCF for a
permanently driven output pin, we'd be burning power for
nothing.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When there is a constraint conflict while placing IOs, the user gets an
error message such as
ERROR: Bel 'X0/Y27/io1' of type 'SB_IO' is not valid for cell 'my_pin' of type 'SB_IO'
While this identifies the problematic cell, it does not explain why
there is a problem. Add some verbose messages to allow users to
determine where the problem is. This can result in something like
Info: Net '$PACKER_VCC_NET' for cell 'my_pin' conflicts with net 'ce' for 'ce_pin'
which provides something actionable.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
I noticed this during my work reimplementing nextpnr, and it seems to be dead and wrong, or at least dead. Either way I think this is what was intended unless anyone can correct me.
This uses a new data structure for net.users that allows gaps, so
removing a port from a net is no longer an O(n) operation on the number
of users the net has.
Signed-off-by: gatecat <gatecat@ds0.me>
This makes predictDelay be based on an arbitrary belpin pair rather
than a arc of a net based on cell placement. This way 'what-if'
decisions can be evaluated without actually changing placement;
potentially useful for parallel placement.
A new helper predictArcDelay behaves like the old predictDelay to
minimise the impact on existing passes; only arches need be updated.
Signed-off-by: gatecat <gatecat@ds0.me>
